CAPSTONE PROJECT REPORT

Report 3 – Software Requirement Specification

– Hanoi, August 2019 –

1|Page
Table of Contents
I. Project Report.....................................................................................................................................3
1. Status Report.................................................................................................................................3
2. Team Involvements........................................................................................................................3
3. Issues/Suggestions.........................................................................................................................3
II. Software Requirement Specification..................................................................................................4
1. Overall Description.........................................................................................................................4
1.1 Product Overview.....................................................................................................................4
1.2 Business Rules..........................................................................................................................5
2. User Requirements........................................................................................................................6
2.1 System Actors...........................................................................................................................6
2.2 Use Cases.................................................................................................................................6
3. Functional Requirements...............................................................................................................8
3.1 System Functional Overview....................................................................................................8
3.2 <<Feature Name 1>>..............................................................................................................10
3.3 <<Feature Name 2>>..............................................................................................................10
4. Non-Functional Requirements.....................................................................................................11
4.1 External Interfaces.................................................................................................................11
4.2 Quality Attributes...................................................................................................................12
5. Other Requirements.....................................................................................................................14
5.1 Appendix1 - Messages List.....................................................................................................14
5.2 Appendix2 - …........................................................................................................................14
5.3 ….............................................................................................................................................14

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

*A - Added M - Modified D - Deleted

3|Page
II. Software Requirement Specification
1. Product Overview
[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.

>>

4|Page
2. User Requirements
2.1 Actors
[An actor is a person (or sometimes another software system or a hardware device) that interacts
with the system to perform a use case. 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

2 Menu Manager

3 …

2.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]

2.2.1 Diagram(s)
[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]

2.2.2 Descriptions
This part describes the use cases, you can follow the table form as below]

5|Page
 ID Use Case Actors Use Case Description
01 View Menu Patron
02 Order a Meal Patron
03 …

3. Functional Requirements
3.1 System Functional Overview
[Provide functionality overview of software system: screen flow, screen descriptions, system user
roles, screen authorization, non-screen functions, ERD]
3.1.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. Please note that beside the normal flat screen,
we might have the oval notation for pop-up screen (Import Order) or a screen with multiple
information tab (Order Details), etc. You may also use text or background format for different
visuality purpose]

3.1.2 Screen Descriptions

[Provide the descriptions for the screens in the Screens Flow above]
# Feature Screen Description
1 Order Meals Create Order <<Screen Brief description>>
2 Order Meals Change Order
3 ..

3.1.3 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

6|Page
 <<Screen Name2>> X X
Query All Data X
Query Own Data X
Query Managed Data X
Add New Data X X
Update All Data X
Update Own Data X
Update Managed Data X
Delete Data
…

3.1.4 Non-Screen Functions

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

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

2 …

3.1.5 Entity Relationship Diagram

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

Entities Description

# Entity Description
1 User
2 Meal
3 Meal Subscription
4 …

7|Page
3.2 <<Feature Name 1>>
3.2.1 <<Function Name 1>>
[A function can be a screen or a non-screen function (listed in the part 3.1.5 above). In this part, you
need to provide the details on the related function, focus on mentioning below information
 Function trigger: how this function is triggered (navigation path, a timing frequency, etc.
 Function description: actors/roles, purpose, interface, data processing, etc.
 Screen layout: mock-up prototype of the screen, sample below is for Manage Products screen

 Function Details: provide explanation for the data, validation, business rules, functionalities
(for both normal cases and abnormal cases), etc. of the function so that the reader can
image how it work.

3.2.2 <<Function Name 2>>

…

3.3 <<Feature Name 2>>

…

8|Page
4. Non-Functional Requirements
4.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.]

4.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]

4.2.1 Usability
[This section includes all those requirements that affect usability. For example, specify the required
training time for a normal users 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]

4.2.2 Reliability
[Requirements for reliability of the system should be specified here. Some suggestions follow:

Availability—specify the percentage of time available ( xx.xx%), hours of use, maintenance access,
degraded mode operations, and so on.

Mean Time Between Failures (MTBF) — this is usually specified in hours, but it could also be specified
in terms of days, months or years.

Mean Time To Repair (MTTR)—how long is the system allowed to be out of operation after it has
failed?

Accuracy—specifies precision (resolution) and accuracy (by some known standard) that is required in
the system’s output.

Maximum Bugs or Defect Rate—usually expressed in terms of bugs per thousand lines of code
(bugs/KLOC) or bugs per function-point( bugs/function-point).

Bugs or Defect Rate—categorized in terms of minor, significant, and critical bugs: the requirement(s)
must define what is meant by a “critical” bug; for example, complete loss of data or a complete
inability to use certain parts of the system’s functionality.]

4.2.3 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

Capacity, for example, the number of customers or transactions the system can accommodate

Resource utilization, such as memory, disk, communications, and so forth.]

4.2.4 …

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

9|Page
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 Common Requirements

[Fill all the common requirements here..]

5.3 Application Messages List

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

10 | P a g e
 again.

5.4 Other Requirements…

11 | P a g e