Requirement Specification

Case study

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 enables 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

document a Software Requirement Specification (SRS) for the proposed app.

Introduction

1.1 Purpose 1.2 Document conventions 1.3 Project Scope

2. Overall description 2.1 Product perspective 2.2 User classes and characteristic 2.3 Operating environment 2.4 Design and implementation constraints 2.5 Assumptions and dependencies

3. System features 3.1 Use case diagram. Note you will need to make a decision as to whether a flat use case diagram should be included, or a hierarchical organization of use case diagrams should be included. 3.2 Specification for selected use cases. 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

ID and Name, Created by ,Date Created Primary Actor, Secondary Actors, Description ,Trigger ,Preconditions, Post conditions, Normal Flow, Alternative Flows ,Exceptions ,Priority ,Frequency of Use, Business Rules Other information ,Assumptions

3.3 Swim lane diagram . Choose a process in the proposed app. Draw a Swim lane diagram for that process. 3.4 State-transition diagram. 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, e.g. fix water tap leak. Examine the various states such a request may be moved through. 3.5 Dialog map. Choose a use case other than the ones in 3.2. Draw a dialog map for that use case.

4. Data requirement 4.1 Logical data model. Include an Entity Relationship Diagram (ERD) for the proposed app.. 4.2 Data dictionary

5. External interface requirements

5.1 User interfaces .Including: 5.1.1. References to user interface standards or product line style guides that are to be followed 5.1.2. Standards for fonts, icons, button labels, images, color schemes, field tabbing sequences, commonly used controls, branding graphics, copyright and privacy notices, and the like 5.1.3. Screen size, layout, or resolution constraints 5.1.4. Standard buttons, functions, or navigation links that will appear on every screen, such as a help button 5.1.5. Shortcut keys 5.1.6. Message display and phrasing conventions 5.1.7. Data validation guidelines (such as input value restrictions and when to validate field contents) 5.1.8. Layout standards to facilitate software localization 5.1.9. Accommodations for users who are visually impaired, color blind, or have other limitations 5.2 Software interfaces 5.3 Hardware interfaces 6. Quality attributes 6.1 Usability 6.2 Performance 6.3 Security 6.X [any other quality attributes, e.g. reliability, you deem relevant] 7. Other requirement (nontrivi