Requirements Specifications Document

This document provides a comprehensive overview of the requirements for a project, including functional and non-functional requirements, use cases, class diagrams, and more.

Requirements Specifications Document
Object-Oriented Requirements Analysis and Specification Report
Assignment 2
Version 1.0
Author(s) Asif Gill
Copyright Statement
This template is developed and owned by Dr. Asif Q. Gill. Any part of this document cannot be used without the explicit permission of
the Author. Students enrolled in the 31269 BRM @ UTS are allowed to use this template only for the purposes of developing and
submitting their assignments.
Project Name X.X Page 1 of 19 30/8/2024

Requirements Specifications Document
Table of Contents
1. DOCUMENT MANAGEMENT................................................................................................................... 3
1.1 REVISION HISTORY............................................................................................................................... 3
1.2 INTENDED AUDIENCE............................................................................................................................ 3
1.3 REFERENCE DOCUMENTS..................................................................................................................... 3
1.4 GLOSSARY........................................................................................................................................... 3
2. INTRODUCTION....................................................................................................................................... 4
2.1 DOCUMENT PURPOSE........................................................................................................................... 4
2.2 PROJECT PURPOSE.............................................................................................................................. 4
2.3 PROJECT SCOPE.................................................................................................................................. 4
2.3.1 In Scope...................................................................................................................................... 5
2.3.2 Out of Scope............................................................................................................................... 5
2.4 ASSUMPTIONS...................................................................................................................................... 5
3. FUNCTIONAL REQUIREMENTS............................................................................................................. 6
3.1 USER STORIES AND USER STORY MAP................................................................................................. 6
3.2 USE CASES.......................................................................................................................................... 7
3.2.1 Use Case Name: Buy Ticket....................................................................................................... 7
3.2.2 Use Case Name: ….................................................................................................................... 8
3.2.3 Use Case Name: ….................................................................................................................... 8
3.2.4 Use Case Name: ….................................................................................................................... 8
3.3 SEQUENCE DIAGRAMS.......................................................................................................................... 9
4. DATA REQUIREMENTS......................................................................................................................... 10
4.1 CLASS DIAGRAM................................................................................................................................. 10
4.2 STATE TRANSITION DIAGRAM.............................................................................................................. 11
5. NON-FUNCTIONAL REQUIREMENTS.................................................................................................. 12
5.1 USER INTERFACE REQUIREMENTS....................................................................................................... 12
5.2 SECURITY REQUIREMENTS.................................................................................................................. 13
5.3 PERFORMANCE REQUIREMENTS.......................................................................................................... 13
6. BIBLIOGRAPHY..................................................................................................................................... 14
7. APPENDICES......................................................................................................................................... 15
Project Name X.X Page 2 of 19 30/8/2024

Requirements Specifications Document
1. Document Management
1.1 Revision History
Project Name X.X Page 3 of 19 30/8/2024

Requirements Specifications Document
Date Version Description of Change Author
12/01/2014 0.1 Initial Draft Suresh Paryani
17/02/2014 0.2 Changed use case diagram based on the
feedback from team
Changes class diagram based on tutor feedback
Added ….
..
… 0… …. ..
… 1.0 Final Signed Off/ Submitted
1.2 Intended Audience
Name Title Action
Sign-off
Review
Info
Date
Approved
Suresh Paryani Lecturer Review and
Sign Off
… ..
… ..
1.3 Reference Documents
Ref Name Description Location
O1 BRM Lectures … UTS Online
1.4 Glossary
Term Description / Meaning
Cos System Customer on boarding System
BR Business Requirements
…
Project Name X.X Page 4 of 19 30/8/2024

Requirements Specifications Document
2. Introduction
2.1 Document Purpose
This document presents the business requirements for the Epic Video Company and its Ka-Ching team
which have been documented by using the following Assignment 2 template.
Requirements priority indicators used within this document:
 H = High. Must be met before the project can be launched.
 M = Medium. Should be met unless there is a good reason it cannot be at this stage.
 L = Low. Optional, nice to have requirement.
2.2 Project Purpose
The purpose of this project is to produce an Object-Oriented Requirements Analysis and Specification
Report for developing a new and improved Customer Onboarding System (COS). The report will include
UML diagrams and parts of a software requirement specification (SRS) document.
2.3 Project Scope
Figure 1 showing project scope of use case diagram
2.3.1 In Scope
Ref. Item Description
SC001 Registration Customer , wants to register on line via customer on boarding
system so as customer can use service of customer on
board system
SC002 Verify detail Customer ,to confirm age so as to verified whether is above
18 because subscription of package is only allowed for those
above 18
Project Name X.X Page 5 of 19 30/8/2024

Requirements Specifications Document
2.3.2 Out of Scope
Ref. Item Description
OC001 Offer online chat service Competitors, also offer online chat service
OC002
2.4 Assumptions
Ref. Item Description
A001 Integration Cos System is integrated with the external payment System.
A002 registration COS system assumes all customer using system have to
register
Project Name X.X Page 6 of 19 30/8/2024

Requirements Specifications Document
3. Functional Requirements
3.1 User Stories and User Story Map
Provide all your identified user stories here.
Identify all possible user stories for the new and improved Customer Onboarding System (COS). At least two
of your user stories should be from the Customer’s perspective, and two user stories from the “Ka-ching”
Team’s perspective.
Insert your user story map here. See the following user story map example from lecture and workshop.
The user story map for Assignment 2 should have different processes/journeys (column headings) than the
following map and your user stories should be based on COS case study.
Each user story must have an id (number) and be estimated and prioritised and user stories with High
priority must be shown in the top rows, ones with Medium priority in the middle rows, and ones with Low
priority in bottom rows.
Project Name X.X Page 7 of 19 30/8/2024

Requirements Specifications Document
3.2 Use Cases
Provide your use case narratives here.
Select only four user stories from the user story map (may consult your tutor) – two from the customer’s
perspective, and two from the “Ka-ching” team’s perspective. Detail the selected four user stories in terms of
four use cases by using the use case narrative template.
See below a use case narrative example from the lecture.
3.2.1 Use Case Name: Buy Ticket
Use Case ID UC101: Registration
User Story Customer , wants to register on line via customer on boarding system so as
customer can use service of customer on board system
Goal Online registration on boarding system
Priority H, M, L
Actors Primary Actor – customer
Secondary Actor – K aching , owner and third party service provider
Pre-conditions The customer to access customer on broad system.
The customer has to register first and all details.
Post-conditions The customer has successfully registered and can access services of
customer on boarding system bought the ticket via the Online Ticketing
System.
Trigger The passenger launches the Online Ticketing (OT) system via their internet
browser.
Main Flow 1. The (OT) system displays the OT system landing page and displays
the hyperlink to list the available tickets i.e. departure, destination,
types, dates and fare.
2. The passenger clicks on the hyperlink to list the available tickets.
3. The OT system displays the available tickets to select from.
4. The passenger selects the desired ticket and presses the “Buy
Ticket” button.
5. The OT system displays the “Pay Fare” page for the selected ticket
and requests for payment.
6. The passenger chooses to “Pay via Credit Card”.
7. The OT system asks the passenger to enter their credit card details.
8. The passenger submits the credit card details.
9. The OT system checks the credit card number format and
processes the credit card details via the “Credit Card” System”.
Please see “UC102: Pay via Credit Card Fare” for credit card
payment processing details.
10. The OT system successfully receives the payment via the “Credit
Card” System” and displays the payment receipt.
If the OT system does not receive the payment, then refer to
Alternate Flow 2 “Failed Payment”.
11. The passenger chooses to “Print Receipt”.
Please see “UC103: Print Receipt” for receipt printing process
details.
12. The OT system successfully prints the payment receipt via the
“Printing System”.
Project Name X.X Page 8 of 19 30/8/2024

Requirements Specifications Document
13. The use case ends.
Exceptions Exception1. Step 1 – If the OT system in not available and the system is
down.
Exception2. Steps 1-12 – passenger closes the browser window anytime,
and then the OT system blocks the transaction at that point in time and log
the activity.
Exception3. Step 12 – printer does not respond.
Includes/Extends/Inherits UC102: Pay via Credit Card, UC103: Print Receipt
Supporting Information Passenger, Purchased Ticket, Payment and Receipt information needs to
be stored on a central server.
Non-functional
Requirements
Performance: All pages must load and display within two (2) seconds of a
button click at least 97% of the time.
Security: Secure credit card transaction
Alternate Flow 2 “Failed Payment”
Trigger The OT system does not receive the payment.
Step 1. The OT system takes the passenger to the fare and payment options page.
2. The OT system displays the payment error message “Insufficient Funds”.
3. Re-join at Step 5 in the Main Flow. .
Alt Flow N/A
Post conditions The OT system successfully displayed the payment error message.
Exceptions Exception1. Steps1-2 – passenger closes the browser window anytime, and then
the OT system blocks the transaction at that point in time and logs the activity.
3.2.2 Use Case Name: …..
Use Case ID
User Story
Goal
Priority
Actors
Pre-conditions
Post-conditions
Trigger
Main Flow
Exceptions
Includes/Extends/Inherits
Supporting Information
Non-functional Requirements
Alternate Flow 1
Trigger
Step
Alt Flow
Post conditions
Exceptions
Alternate Flow 2
Trigger
Step
Post conditions
Exceptions
Project Name X.X Page 9 of 19 30/8/2024

Requirements Specifications Document
3.2.3 Use Case Name: …..
3.2.4 Use Case Name: …..
NOTE: For your assignment 2, you need to narrate four use cases - two for Customer and two for Ka-ching
Team use cases.
Project Name X.X Page 10 of 19 30/8/2024

Requirements Specifications Document
3.3 Sequence Diagrams
Project Name X.X Page 11 of 19 30/8/2024

Requirements Specifications Document
NOTE: For your assignment 2, you need to document two sequence diagrams - draw sequence diagrams for
any one use case of your choice for Customer and one for any Ka-ching Team use case.
You must provide a title for each sequence diagram which must clearly mention the corresponding use case
name. Messages in the sequence diagram should match with the main flow of the corresponding use case
narrative.
Project Name X.X Page 12 of 19 30/8/2024

Requirements Specifications Document
4. Data Requirements
4.1 Class Diagram
Project Name X.X Page 13 of 19 30/8/2024

Requirements Specifications Document
4.2 State Transition Diagram
Project Name X.X Page 14 of 19 30/8/2024

Requirements Specifications Document
Project Name X.X Page 15 of 19 30/8/2024

Requirements Specifications Document
5. Non-functional requirements
5.1 User Interface Requirements
See below wireframe example. Source: Smart Draw - http://www.smartdraw.com/examples/view/wireframe+-
+online+store+-+1/
NOTE: Assignment 2 should have two wireframes, one for the Customer use case and one for the Ka-ching
Team use case (should be the same as the ones you choose for the sequence diagrams). Make sure the
user interface/wireframe is linked to the narrative of that use case.
Project Name X.X Page 16 of 19 30/8/2024

Requirements Specifications Document
5.2 Security Requirements
SRID User Case ID Security Requirements
SR001 UC101 Credit card number must be masked as “********”
Document at least two security requirements for the system. Requirement statements must satisfy the
“SMART” requirements quality criteria.
5.3 Performance Requirements
PRID User Case ID Performance Requirements
PR001 UC101 Credit card payment must be processed in less than 5 seconds.
Document at least two performance requirements for the system. Requirement statements must satisfy the
“SMART” requirements quality criteria.
Project Name X.X Page 17 of 19 30/8/2024

Requirements Specifications Document
6. Bibliography
Use correct Harvard referencing style.
Project Name X.X Page 18 of 19 30/8/2024

Requirements Specifications Document
7. Appendices
Contribution to Team Work (Evidence):
1) Keep record and submit the contribution of each team member to each task. Every team member should
work on each task, though the contribution can be different.
Contribution should be shown via a table (showing exactly who was assigned which tasks) or any other
appropriate breakdown of team tasks, e.g. chart or other format.
2) Keep record and submit the team communication (e.g. emails, meeting minutes, screenshots of online
conversations, etc.)
Students to submit evidence of team communication (eg emails, meeting minutes, screenshots of online
conversations, etc)
Project Name X.X Page 19 of 19 30/8/2024