3.

Functional Requirements
3.1 System Functional Overview
a. Screen Flow

b. Screen Details

# Feature Screen Description

1 Login Account Login Login the Account to more action
2 Register New
Account Register Register account for new user
3 Forget For user who forget password can verified and
Get New Password Password get new password
4 View Homepage Homepage Show all PT with information and photo
5 Manage Profile Profile Edit, add, delete information of user
6 View profile of PT PT Profile View all information of a PT have been chosen
7 View all blog of
chosen PT PT Blog View and comment about all Blog of the PT
8 View training
course of chosen View the time and information of the PT’s
PT PT course course
9 Register the
course of chosen
PT Register course Register the course of PT
1 View all information of the course have been
0 View My Course My Course joined
1 Send report Report Send the report about PT or training session to

1|Page
 1 Admin
1
2 Send rating Rating Rating the PT
1 payment confirmation after completing the
3 Payment Payment training session
1 View Process
4 detail View Process View all Process details
1
5 View Profile My Profile View all information in profile
1
6 Update Profile Update Edit, Add, Delete information in profile
1 View Training Training
7 Schedule Schedule View training schedule with details information
1 Manage Request
8 training Request View the request of user for new training course
1
9 View Blog Blog View the blog PT have been written
2
0 Edit blog Edit post Update or delete blog
2
1 Upload post Upload Write new blog and upload
2 Manage User’s add, edit, delete or update permissions for
2 Account Manage User the user’s account
2 Manage User’s Manage View the request from user and decide to
3 request request processing
2 content content censor posts or content posted from user, PT,
4 moderation moderation GYM
2 Upload GYM Upload GYM edit the posted information about price,
5 information information operating time
2 Upload work Upload work Update if there is a change in working schedule
6 schedule schedule and related information

c. Screen Authorization

Screen User PT GYM Admin Guest

Login X X X X
Register X
Forget Password X X X X
Homepage X X X X X
Profile X X X X
PT Profile X
PT Blog X
PT course X
Register course X
My Course X

2|Page
 Report X
Rating X
Payment X
View Process X
My Profile X X X X
Update X X X X
Training Schedule X
Request X
Blog X
Edit post X
Upload X
Manage User X
Manage request X
content moderation X
Upload GYM information X
Upload work schedule X

d. Non-Screen Functions

# Feature System Function Description

collect user aggregates personal information and information about
1 Collect data
information search habits, reading habits and exercise habits
recommend
PT articles and recommendations on PT, products and articles
2 Propose
related users may be interested in based on user behavior
products
auto automatically censor and remove if detecting posts
3 Censorship
censorship or information that violates community standards
training
automatically send notifications to remind users
4 schedule Remind
and PTs when it's time to exercise on the schedule
reminder
calculate the calculate the amount that the user needs to pay
5 amount to be calculate money based on the parameters from the PT and the
paid number of training sessions completed

e. Entity Relationship Diagram

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

3|Page
 Meal
including
M Subscription
M

Payroll
Category
booking Deduction
M 1

1 1
1
Meal incharging User requesting having
M 1
1 1

M
booking Product

M
M
including Order including
1 M

Entities List

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

3.2 <<Feature Name 1>>

a. <<Function Name 1>>
[A function can be a screen or a non-screen function (listed in the part 5.1 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: mockup prototype of the screen, sample below is for Manage Products screen

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

b. <<Function Name 2>>

…

3.3 <<Feature Name 2>>

…

5|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 elements.]

a. User Interfaces
[Describe the logical characteristics of each interface between the software product and the users.
This may include sample screen images, any GUI standards or product family style guides that are to
be followed, screen layout constraints, standard buttons and functions (e.g., help) that will appear on
every screen, keyboard shortcuts, error message display standards, and so on. Define the software
components for which a user interface is needed. Details of the user interface design should be
documented in a separate user interface specification.]
UI-1: The Cafeteria Ordering System screen displays shall conform to the Process Impact Internet
Application User Interface Standard, Version 2.0 [3].
UI-2: The system shall provide a help link from each displayed webpage to explain how to use
that page.
UI-3: The webpages shall permit complete navigation and food item selection by using the
keyboard alone, in addition to using mouse and keyboard combinations.
b. Software Interfaces
[Describe the connections between this product and other software components (identified by name
and version), including other applications, databases, operating systems, tools, libraries, websites,
and integrated commercial components. State the purpose, formats, and contents of the messages,
data, and control values exchanged between the software components. Specify the mappings of
input and output data between the systems and any translations that need to be made for the data
to get from one system to the other. Describe the services needed by or from external software
components and the nature of the inte-component communications. Identify data that will be
exchanged between or shared across software components. Specify non-functional requirements
affecting the interface, such as service levels for responses times and frequencies, or security controls
and restrictions.]
SI-1: Cafeteria Inventory System
SI-1.1: The COS shall transmit the quantities of food items ordered to the Cafeteria
Inventory System through a programmatic interface.
SI-1.2: The COS shall poll the Cafeteria Inventory System to determine whether a
requested food item is available.
SI-1.3: When the Cafeteria Inventory System notifies the COS that a specific food item is
no longer available, the COS shall remove that food item from the menu for the
current date.
SI-2: Payroll System
The COS shall communicate with the Payroll System through a programmatic interface for
the following operations:
SI-2.1: To allow a Patron to register and unregister for payroll deduction.
SI-2.2: To inquire whether a Patron is registered for payroll deduction.
SI-2.3: To inquire whether a Patron is eligible to register for payroll deduction.
SI-2.4: To submit a payment request for a purchased meal.

6|Page
 SI-2.5: To reverse all or part of a previous charge because a patron rejected a meal or
wasn’t satisfied with it, or because the meal was not delivered per the confirmed
delivery instructions.
c. Hardware Interfaces
[Describe the characteristics of each interface between the software and hardware (if any)
components of the system. This description might include the supported device types, the data and
control interactions between the software and the hardware, and the communication protocols to be
used. List the inputs and outputs, their formats, their valid values or ranges, and any timing issues
developers need to be aware of. If this information is extensive, consider creating a separate
interface specification document]
No hardware interfaces have been identified.
d. Communications Interfaces
[State the requirements for any communication functions the product will use, including e-mail, Web
browser, network protocols, and electronic forms. Define any pertinent message formatting. Specify
communication security or encryption issues, data transfer rates, handshaking, and synchronization
mechanisms. State any constraints around these interfaces, such as whether e-mail attachments are
acceptable or not.]
CI-1: The COS shall send an email or text message (based on user account settings) to the Patron
to confirm acceptance of an order, price, and delivery instructions.
CI-2: The COS shall send an email or text message (based on user account settings) to the Patron
to report any problems with the meal order or delivery.
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]

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

b. 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).

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

c. 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

Degradation modes (what is the acceptable mode of operation when the system has been degraded
in some manner)

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

d. Dependability
[Software dependability includes a range of characteristics including reliability, security and safety.
Dependable software should not cause physical or economic damage in the event of system failure.
Malicious users should not be able to access or damage the system]

d1. Security
[Specify any requirements regarding security or privacy issues that restrict access to or use of the
product. These could refer to physical, data, or software security. Security requirements often
originate in business rules, so identify any security or privacy policies or regulations to which the
product must conform. If these are documented in a business rules repository, just refer to them.]

d2. Safety
[Specify requirements that are concerned with possible loss, damage, or harm that could result from
use of the product. Define any safeguards or actions that must be taken, as well as potentially
dangerous actions that must be prevented. Identify any safety certifications, policies, or regulations
to which the product must conform.]

e. Supportability
[This section indicates any requirements that will enhance the supportability or maintainability of the
system being built, including coding standards, naming conventions, class libraries, maintenance
access, and maintenance utilities.]

f. Design Constraints
[This section indicates any design constraints on the system being built. Design constraints represent
design decisions that have been mandated and must be adhered to. Examples include software
languages, software process requirements, prescribed use of developmental tools, architectural and
design constraints, purchased components, class libraries, and so on.]

g. Support Documents
[Describes the requirements, if any, for o-line user documentation, help systems, help about notices,
and so forth.]

8|Page
h. Purchased Components
[This section describes any purchased components to be used with the system, any applicable
licensing or usage restrictions, and any associated compatibility and interoperability or interface
standards.]

5. Other Requirements
[Examples are: legal, regulatory or financial compliance, and standards requirements; requirements
for product installation, configuration, startup, and shutdown; and logging, monitoring and audit
trail requirements. Instead of just combining these all under "Other," add any new sections to the
template that are pertinent to your project. Omit this section if all your requirements are
accommodated in other sections. ]

5.1 Appendix1 - Messages List

# Message Message Context Content
code Type
1 MSG01 In line There is not any search result No search result.
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
again.

5.2 Appendix2 - …
5.3 …

9|Page