CAPSTONE PROJECT REPORT

Report 3 – Software Requirement Specification

– Hanoi, Jan 2024 –

Table of Contents
I. Record of Changes..............................................................................................................................3
II. Software Requirement Specification..................................................................................................4
1. Overall Requirements....................................................................................................................4
1.1 Context Diagram......................................................................................................................4
1.2 Main Workflows.......................................................................................................................5
1.3 User Requirements..................................................................................................................5
1.4 System Functionalities..............................................................................................................7
1.5 Entity Relationship Diagram.....................................................................................................8
2. Use Case Specifications..................................................................................................................9
2.1 <<Feature Name1>>.................................................................................................................9
2.2 Common Feature...................................................................................................................10
2.3 Xyz Feature.............................................................................................................................10
3. Functional Requirements.............................................................................................................11
3.1 <<Feature Name1>>...............................................................................................................11
3.2 System Administration...........................................................................................................11
3.3 ….............................................................................................................................................12
4. Non-Functional Requirements.....................................................................................................12
3.1 External Interfaces.................................................................................................................12
3.2 Quality Attributes...................................................................................................................12
5. Requirement Appendix................................................................................................................13
5.1 Business Rules........................................................................................................................13
5.2 System Messages...................................................................................................................13
5.3 Other Requirements…............................................................................................................14

ProjectCode – Report 3 (SRS Document) Page 2/18

I. Record of Changes
Date A* In charge Change Description
M, D

*A - Added M - Modified D - Deleted

ProjectCode – Report 3 (SRS Document) Page 3/18

II. Software Requirement Specification
1. Overall Requirements
1.1 Context Diagram
[Gives the overall description about the product with some introduction and the context diagram. The
context diagram presents the boundary and connections between the system you’re developing and
everything else in the universe. This identifies external entities (or terminators – software, hardware,
human components, and other systems) outside the system that interface to it in some way, as well
as data, control, and material flows between the terminators and the system.]

<<Sample: The Cafeteria Ordering System is a new software system that replaces the current manual
and telephone processes for ordering and picking up meals in the Process Impact cafeteria. The
context diagram below illustrates the external entities and system interfaces for release 1.0. The
system is expected to evolve over several releases, ultimately connecting to the Internet ordering
services for several local restaurants and to credit and debit card authorization services.

>>

ProjectCode – Report 3 (SRS Document) Page 4/18

1.2 Main Workflows
[Provide main workflows (business processes) using the swim-lane diagram(s) like sample below]
1.2.1 Order Processing

1.2.2 Customer Support

1.3 User Requirements

1.3.1 Actors
[An actor is someone/something that interacts with the system.

 The only external entities that interact with the system

 Actors are outside the system and not part of it
 A user is an individual, whereas an actor represents the role played by all users of the same type
 There are other types of actors in addition to or in place of human actors: external systems, I/O
devices, or timers

ProjectCode – Report 3 (SRS Document) Page 5/18

Following are some questions you might ask to help user representatives identify actors

 Who (or what) is notified when something occurs within the system?
 Who (or what) provides information or services to the system?
 Who (or what) helps the system respond to and complete a task?
This part gives the description of system actors, you can follow the table form as below]
# Actor Description
1 Administrator Actor description here..

2 Menu Manager ..

3 …

1.3.2 Use Cases

[A use case (UC) describes a sequence of interactions between a system and an external actor that
results in the actor being able to achieve some outcome of value. The names of use cases are always
written in the form of a verb followed by an object. Select strong, descriptive names to make it
evident from the name that the use case will deliver something valuable for some user.

Following are some questions you might ask to help user representatives identify use cases

 What will the actor use the system for?

 Will the actor create, store, change, remove, or read data in the system?
 Will the actor need to inform the system about external events or changes?
 Will the actor need to be informed about certain occurrences in the system?

In this section, you need to provide the UC diagram(s) to show the actor-UCs and UC-UC relationships
like the sample below. You can have multiple UC diagrams for the system, each diagram is for one
actor or one workflow]

1.3.2.1 UCs for Guest

ProjectCode – Report 3 (SRS Document) Page 6/18

1.3.2.2 UCs for Student

1.3.2.3 …

1.4 System Functionalities

[Provide functionality overview of software system: screen flow, screen descriptions, system user
roles, screen authorization, non-screen functions, ERD]
1.4.1 Screens Flow
[This part shows the system screens and the relationship among screens. You can draw the Screens
Flow for the system in the form of diagram as below.]

1.4.2 Screen Authorization

[Provide the system roles authorization to the system features (down to screens, and event to the
screen activities if applicable) in the table form as below – replace Role1, Role2,… with your specific
system user role names]

Screen Role-Name1 Role-Name2 Role-Name3 …

<<Screen Name1>> X X X
<<Screen Activity>> X X
<<Screen Name2>> X X
Query All Data X
Query Own Data X
ProjectCode – Report 3 (SRS Document) Page 7/18
 Add New Data X X
Update All Data X
Update Own Data X
Delete Data
…

1.4.3 Non-UI Functions

[Provide the descriptions for the non-screen system functions, i.e batch/cron job, service, API, etc.]
# Feature System Function Description

1 <<Feature Name>> <<Function Name1>> <<Function Name1 Description>>

2 …

1.5 Entity Relationship Diagram

[Provide the entity relationship diagram and the entity descriptions in the table format as below]

ProjectCode – Report 3 (SRS Document) Page 8/18

2. Use Case Specifications
[Provide specifications for the use cases (UCs) those are covered in the system. The UCs are grouped
by the system features and even sub features. You just need to provide UC specifications for UCs
involving in the main workflows (business processes) or the complex ones. Other UCs (i.e CRUD or
data-viewing UCs) are simple, and you just need to refer the descriptions in the Functional
Requirement (part 3) below)]

2.1 <<Feature Name1>>

2.1.1 UC Name1
Primary Actors Secondary Actors
Description
Preconditions
Postconditions
Normal Flows
Alternative
Flows

Primary and Secondary Actors

An actor is a person or other entity external to the software system being specified who interacts
with the system and performs use cases to accomplish tasks. Name the primary actor that will be
initiating this UC and any other secondary actors who will participate in completing execution of the
UC.
Description
Provide a brief description of the reason for and outcome of this use case, or a high-level description
of the sequence of actions and the outcome of executing the use case. The description can be in the
form of a user story (As a <type of user>, I want <some goal> so that <some reasons>)
Preconditions
List any activities that must take place, or any conditions that must be true, before the use case can
be started.
Postconditions
Describe the state of the system at the successful conclusion of the use case execution.
Normal Flow
Provide a description of the user actions and corresponding system responses that will take place
during execution of the use case under normal, expected conditions.
Alternative Flows
Describe below two information if any:
 Other successful usage scenarios that can take place within this use case. State the alternative
flow, and describe any differences in the sequence of steps that take place.
 Any anticipated error conditions that could occur during execution of the use case and how
the system is to respond to those conditions.

2.1.2 UC Name2
…

ProjectCode – Report 3 (SRS Document) Page 9/18

2.2 Common Feature
2.2.1 Login System
Primary Actors Customer Secondary Actors None

Description As a user, I want to be able to log into the system so that I can use the system’s
authenticated features and access my personalized account.

Preconditions User account has been created & authorized

Postconditions  User logs in the system successfully

 The system tracked successful login into the Activity Log
Normal Flows Login System
1. User clicks Login button from the page header or accesses an authenticated
feature (from a link or type the page URL directly into the address bar)
2. User accesses the User Login screen
3. User types in the login details or choo other login options
4. User clicks the Login button
5. System validates the login details
6. System allows user to access
7. System tracks user’s success login to the Activity Log
8. System accesses the Home Page (or the previous calling page if any)
Alternative Flows:
Step 2.1_Google Login
1. User clicks Google Login button to login system using Google account
2. System redirects the user to the Google’s Login screen
3. User types in the Google account details and chooses to login
4. Google validates user’s login information successfully and redirect him/her
back to the system
5. Return to step 5 of normal flow.
Step 4_System can’t authenticate the user
User can’t be authenticated & get relevant error message in one of below cases
1. He/she leaves the Email and/or Password field blank (MSG10)
2. Input Email or Password are incorrect (MSG09)
3. Input Email/Password are correct but email has not been verified (MSG11)
4. The user account is blocked / inactive (MSG12)
If user inputs wrong logging-in details 5 times continuously, system will lock
his/her account in 30 minutes (with relevant warning message - MSG13)
2.2.2 …
2.3 Xyz Feature
…

ProjectCode – Report 3 (SRS Document) Page 10/18

3. Functional Requirements
[Provide descriptions about the system’s functions/screens. The functions/screens are grouped by the
system features, and even sub-features if needed. For the screens, you need to provide the screen
layouts (mock-up screens) and relevant specifications if needed]

3.1 <<Feature Name1>>

3.1.1 <<Screen/Function Name1>>
[Screen/Function description]
[Screen layout(s)]
[Screen specifications: field initializations, the showing/hiding of some fields, etc.]
3.1.2 User Login
This screen allows user to be authenticated to the system screens/functionalities.

S1_User Login screen S2_Select account to login (with Google)

3.1.3 …

3.2 System Administration

3.2.1 System Settings
a. Setting List
This is for the administrator to view the list of current system settings. On the screen, s/he can also
activate or deactivate (change status) of a specific setting.

(1) (2)

(3)

(1) Setting Type:

 Initialized with all the active setting types filled in,

 Allow user to filter the setting list by a specific setting type
ProjectCode – Report 3 (SRS Document) Page 11/18
  Default value is “All Types”, allowing user to see the settings at all types

(2) Setting Status:

 Initialized with two values Active and Inactive filled in

 Allow user to filter the setting list by a specific status (Active or Inactive)
 Default value is “All Types”, allowing user to see the settings at all statuses

(3) The change-status action is Activate or Deactivate depending on the current status of the relevant
setting (Inactive or Active, respectively)

b. Setting Details
This is for the administrator to add new or view/update an existing system setting

3.2.2 …
3.3 …

4. Non-Functional Requirements
3.1 External Interfaces
[This section provides information to ensure that the system will communicate properly with users
and with external hardware or software/system elements.]

3.2 Quality Attributes

[List all the required system characteristics (quality attributes) specification. Some of the possible
attributes are provided with the guide/descriptions are mentioned here]

3.2.1 Usability
[This section includes all those requirements that affect usability. For example, specify the required
training time for a normal user and a power user to become productive at particular operations
specify measurable task times for typical tasks or base the new system’s usability requirements on
other systems that the users know and like specify requirement to conform to common usability
standards, such as IBM’s CUA standards Microsoft’s GUI standards]

3.2.2 Performance
[The system’s performance characteristics are outlined in this section. Include specific response times.
Where applicable, reference related Use Cases by name.
Response time for a transaction (average, maximum)
Throughput, for example, transactions per second
ProjectCode – Report 3 (SRS Document) Page 12/18
Capacity, for example, the number of customers or transactions the system can accommodate
Resource utilization, such as memory, disk, communications, and so forth.]

3.2.3 …

5. Requirement Appendix
[Provide business rules, common requirements, or other extra requirements information here]

5.1 Business Rules

[Provide common business rules that you must follow. The information can be provided in the table
format as the sample below]
ID Rule Definition
BR-01 Delivery time windows are 15 minutes, beginning on each quarter hour.
BR-02 Deliveries must be completed between 10:00 A.M. and 2:00 P.M. local time, inclusive.
BR-03 All meals in a single order must be delivered to the same location.
BR-04 All meals in a single order must be paid for by using the same payment method.
BR-11 If an order is to be delivered, the patron must pay by payroll deduction.
BR-12 Order price is calculated as the sum of each food item price times the quantity of that
food item ordered, plus applicable sales tax, plus a delivery charge if a meal is delivered
outside the free delivery zone.
BR-24 Only cafeteria employees who are designated as Menu Managers by the Cafeteria
Manager can create, modify, or delete cafeteria menus.
BR-33 Network transmissions that involve financial information or personally identifiable
information require 256-bit encryption.
BR-86 Only regular employees can register for payroll deduction for any company purchase.
BR-88 An employee can register for payroll deduction payment of cafeteria meals if no more
than 40 percent of his gross pay is currently being deducted for other reasons.

5.2 System Messages

# Message Message Context Content
code Type
1 MSG01 In line There is not any search result No search results.
2 MSG02 In red, under Input-required fields are empty The * field is required.
the text box
3 MSG03 Toast Updating asset(s) information Update asset(s)
message successfully successfully.
4 MSG04 Toast Adding new asset successfully Add asset successfully.
message
5 MSG05 Toast Confirming email of asset A confirmation email has
message hand-over is sent successfully been sent to
{email_address}.
6 MSG06 Toast Resetting asset information Return asset(s) successfully.
message successfully

ProjectCode – Report 3 (SRS Document) Page 13/18

7 MSG07 Toast Deleting asset information Delete asset(s) successfully.
message successfully
8 MSG08 In red, under Input value length > max Exceed max length of
the text box length {max_length}.
9 MSG09 In line Username or password is not Incorrrect user name or
correct when clicking sign-in password. Please check
again.
1 ..
0

5.3 Other Requirements…

ProjectCode – Report 3 (SRS Document) Page 14/18