ASSESSMENT BRIEF
Subject Code and Title	MIS604 Requirement Engineering
Assessment	Two – Requirement Specification
Individual/Group	Group
Length	N/A. There is no length requirement. You are required to sufficiently address all the tasks in this assessment.
Learning Outcomes	b, c
Submission	Due 23:59 (Sydney time) Friday, end of module 4.2.
Weighting	40%
Total Marks	40 marks

Context:

In the first two Modules, you learnt an overview of requirements engineering, studied the various types of requirements, and a range of requirement elicitation techniques. The subsequent two Modules, Module 3 and 4, introduced you to a number of requirement analysis tools and techniques. The primary focus was on how to model user requirements with UML and document them in a Software Requirement Specification. In particular, you studied the use case approach and a number of other diagramming techniques to visualise requirements and learnt the formality and basic inclusions of a Software Requirement Specification.

In this assessment, you will, as a group, use various of UML diagramming tools to visualise requirement and document a Software Requirement Specification.

Task Instructions:

You, as a group, should first read and understand the following case before proceeding to answer the questions in Assessment Tasks section. Note that every piece of information provided in the following case serves a purpose.

The case

ABC Pty Ltd is a start-up tech company (the ‘Company’) based in Sydney Australia. They are currently seeking to develop a mobile app or a web application (collectively called an ‘app’), which provide on- demand trades & handyman services to their customers. The objective of the app is to connect tradesmen and customers. ABC envisioned that this app will provide a strong revenue stream to the company and other business opportunities from a wide handyman network.

The founder of the Company has envisaged an app that enable customers to find trustworthy tradesmen to get the job done; it is also a platform for tradespersons to find jobs and earn an extra income stream. Typical jobs posted on the platform should include home cleaning, heating and cooling

system services, gardening, airport pick up & delivery, IKEA furniture assembly, garbage removal, plumbing, and other tradesmen & handyman jobs. The founder also provided the following very high- level and rough ideas for the app:

For customers, they can post job(s) on the app, browse through tradespersons’ profile, and contact them through the in-app instant messenger.

For tradespersons, they can put up a profile on the app, browse through jobs available, and contact customers through the in-app instance messenger.

Once the job is completed, payment can be made securely through the app. The customer will also have the opportunity to rate and review the tradesperson.

ABC wants to push this app to the market in the next six months and have secured an investment for this app.

ABC has engaged you (i.e. a group of you) as the requirements analyst in this project.

Assessment tasks

As a group, document a Software Requirement Specification (SRS) for the proposed app. Your submission must, as a minimum, contain the following:

Title page: Subject code and name, assessment number, report title, assessment due date, word count (actual), student names, student IDs, Torrens email address, campus learning facilitator, and Subject coordinator.

Table of Contents (ToC): should list the report topics using decimal notation. Need to include the main headings and subheadings with corresponding page numbers, using a format that makes the hierarchy of topics clear. Because you are including a ToC the report pages should be numbered in the footer as follows: title page has no page number; and main text to have Arabic numerals commencing at 1. Create the ToC using MS Word’s ToC auto-generator rather than manually typing out the ToC. Instructions can be found here https://support.office.com/en-gb/article/Create- a-table-of-contents- or-update-a-table-of-contents-eb275189-b93e-4559-8dd9-c279457bfd72# create_a_table.

1.  Introduction (3 marks)

• Purpose (1 mark)
• Document conventions (1 mark)
• Project Scope (1 mark)

2.  Overall description (5 marks)

• Product perspective (1 mark)

2.2  User classes and characteristics (1 mark)

• Operating environment (1 mark)

2.4  Design and implementation constraints (1 mark)

• Assumptions and dependencies (1 mark)

3.  System features (12 marks)

• Use case diagram (3 mark). Note you will need to make a decision as to whether a “flat” use case diagram should be included, or a hierarchical organisation of use case diagrams should be
• Specification for selected use cases (3 mark). Select n use case where n equals the number of students in your group. Document a detailed specification for the selected use case. The Use case must include the following elements as a minimum
• Swimlane diagram (2 mark). Choose a process in the proposed Draw a Swimlane diagram for that process.
• State-transition diagram (2 mark). Draw a state-transition diagram for a customer job request in the proposed app. A job request is referring to a request initiated by the customer, g. “fix water tap leak”. Examine the various states such a request may be moved through.
• Dialog map (2 mark). Choose a use case other than the ones in 2. Draw a dialog map for that use case.

4.  Data requirement (4 marks)

• Logical data model (2 mark). Include an Entity Relationship Diagram (ERD) for the proposed app. ERD is taught in
• Data dictionary (2 mark)

5.  External interface requirements (8 marks)

• User interfaces (4 mark). Including:
  • References to user interface standards or product line style guides that are to be followed
  • Standards for fonts, icons, button labels, images, colour schemes, field tabbing sequences, commonly used controls, branding graphics, copyright and privacy notices, and the like
  • Screen size, layout, or resolution constraints
  • Standard buttons, functions, or navigation links that will appear on every screen, such as a help button
  • Shortcut keys
  • Message display and phrasing conventions
  • Data validation guidelines (such as input value restrictions and when to validate field contents)
  • Layout standards to facilitate software localization
  • Accommodations for users who are visually impaired, colour blind, or have other limitations
• Software interfaces (2 mark)
• Hardware interfaces (2 mark)

6.  Quality attributes (4 marks)

• Usability

6.2  Performance

• Security

6.X [any other quality attributes, e.g. reliability, you deem relevant]

7.  Other requirements (Bonus: 2 marks for nontrivial and valid requirements)

8. Reference list (4 marks)

9.  Appendices if necessary.

General Assessment Requirement

MSVisio or other professional diagramming tools. All UML diagrams must be drawn with MSVisio or other equivalent professional diagramming tools. Hand-drawn diagrams are not accepted. MSPaint is not regarded as a professional diagramming tool and is therefore not accepted.

Incomprehensible submissions. Assessments provide the opportunity for students to demonstrate their knowledge and skills to achieve the required standard. To do this, assessment responses need to be both clear and easy to understand. If not, the University cannot determine that students have demonstrated their knowledge and skills. Assessments will, therefore, be marked accordingly including the potential for 0 (zero) marks where relevant.

Case study. Assessment response must focus on the case study scenario given in the Task Instructions. Any assessment items that do not address the case study scenario may be awarded 0 (zero) marks.

Track changes. If you use Track Changes when writing your assessment, you must ensure that the submitted document is the final and correct version of the document. That is, if your submitted report contains Track Changes or Comments or any other editing marks it may be awarded 0 (zero) marks. It is your responsibility to submit the final and correct version of your report.

Academic language. All submissions should be thoroughly proof-read for spelling, typographical or grammatical errors before being submitted. Do not reply on the ‘spell-check’ function in your word processing program. If, for example, ‘affect’ is substituted for ‘effect’, your program may not detect the error.

Group Assessment Requirement

Group assessment. This assessment is a group assignment for all students. Each group consists of 2 or

3 students. To ensure your success in this group assignment, please read and follow these requirements regarding group formation and administration.

Group Formation

Same group. You must stay in the same group that you formed for Assessment 1, therefore you do not need to for form and register your group for this assessment.

Group Administration

Conflicts. If there is anything that you think you will need to involve your Learning Facilitator, please do not hesitate to do so.

Burden to prove. If you make any allegation against any other group members, you bear the evidential onus to prove your allegation and claims.

Group marks. Everyone in the same group will receive the same mark unless:

• there is an issue brought to the attention of the Learning Facilitator; and
• the Learning Facilitator finds it is fundamentally unfair to give every group member the same

You may be removed from a group. In some circumstances, you may be removed from you group due to your significant and persistent lack of contribution. Once it happens, those being removed from a group will need to undertake all assessment individually from the time they are removed. The marking standard and criteria will remain the same.

Referencing

It is essential that you use appropriate APA style for citing and referencing research. Please see more information on referencing here http://library.laureate.net.au/research_skills/referencing

Submission Instructions:

Means of submission. ALL students must submit ONE MSWord document (.doc or .docx) via the Assessment link in the main navigation menu in MIS604: Requirements Engineering. Physical copies/Email submissions are not accepted.

No Zipped files. Students must NOT zip the MSWord document and submit it as one single zip/compressed file.

Complete and correct submission. Assessment, once submitted, are FINAL and therefore cannot be modified. You bear all the onus to ensure that your submissions are final, correct (correct files in correct format) and complete before submitting to Blackboard.

You are expected to begin this assessment when you begin the trimester, especially as you relate the learning activities (formative assessment) in the modules to this and the other (summative) assessments. Be sure to keep several drafts of your work as well as your notes and any sources you used to draw on in preparing your report.

Extensions will be considered only in extenuating circumstances where the student has applied before the due date. At that point, students are required to provide the latest draft, in case the extension is not granted and to demonstrate they have earnestly done everything to avoid lateness.

Students are responsible for keeping appropriate back-ups and drafts of their assignments and to submit the correct version.

Torrens University Australia policies apply to the preparation and submission of this assignment.