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. System Requirement Specification.....................................................................................................4
1. Overall Description.........................................................................................................................4
1.1 Product Overview.....................................................................................................................4
1.2 Business Rules..........................................................................................................................5
2. User Requirements........................................................................................................................6
2.1 Overview..................................................................................................................................6
2.2 <<Feature Name 1 – i.e Order Meals>>...................................................................................7
2.3 <<Feature name 2 – i.e: Meal Subscriptions>>......................................................................10
2.4 <<Next Feature Name..>>......................................................................................................11
3. Functional Requirements.............................................................................................................12
3.1 System Functional Overview..................................................................................................12
3.2 <<Feature Name 1>>..............................................................................................................14
3.3 <<Feature Name 2>>..............................................................................................................14
4. Non-Functional Requirements.....................................................................................................15
4.1 External Interfaces.................................................................................................................15
4.2 Quality Attributes...................................................................................................................16
5. Other Requirements.....................................................................................................................18
5.1 Appendix1 - Messages List.....................................................................................................18
5.2 Appendix2 - …........................................................................................................................18
5.3 ….............................................................................................................................................18

2|Page
I. Project Report
1. Status Report
# Work Item Status Notes (Work Item in Details)
 1   Pending  
 2   In Progress  
 3   Completed  

2. Team Involvements
# Task Member Notes (Task Details, etc.)
 1   KienNT  
 2   TuanTV  
 3   AnhLM  

3. Issues/Suggestions
# Issue Status Notes (Solution, Suggestion, etc.)
 1   Pending  
 2   In Progress  
 3   Completed  

3|Page
II. Software Requirement Specification
1. Overall Description
1.1 Product Overview
[This section presents a high-level overview of the product and the environment in which it will be
used, the anticipated users, and known constraints, assumptions, and dependencies]

[This section Describe the product's context and origin of the product you are developing. Is it the
next member of a growing product line, the next version of a mature system, a replacement for an
existing application, or an entirely new product? If this SRS defines a component of a larger system,
state how this software relates to the overall system and identify major interfaces between the two.
Consider including visual models such as a context diagram or ecosystem map to show the product's
relationship to other systems or anything else in the universe.

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.

An ecosystem map shows all of the systems related to the system of interest that interact with one
another and the nature of those interactions. It represents scope by showing all the systems that
interconnect (directly or indirectly) and that therefore might need to be modified to accommodate
your new 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
1.2 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|Page
2. User Requirements
(This is optional part)

2.1 Overview
a. Use Case Diagram
[Provide your use case diagram(s) which is something like the sample below]

b. System 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 give the description of system actors, you can follow the table form as below]
# Actor Description
1 Administrator

2 Menu Manager
3 …

c. Use Cases List

[A use case 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; This part describe the use
cases, you can follow the table form as below, in which: the primary actors initiate the use case and
derive the main value from it, the secondary actors are the person or system which will participate in

6|Page
completing execution of the use case (participates somehow in the successful execution of the use
case)]

ID Use Case Primary Actors Secondary Actors

01 View Menu Patron
02 Order a Meal  Patron
03 Manage Meal Orders  Patron
04 Register for Payroll Deduction  Patron Payroll System
05 Request Monthly Payments  [Auto] Payroll System
06 Manage Meal Subscription  Patron
07 Manage Menu Administrator,
(View, Create, Modify, Delete, Archive) Menu Manager
08 Define a Meal Special Menu Manager,
Cafeteria Staff
09 Handle Meal Orders  Cafeteria Staff
10 Prepare Meal  Cafeteria Staff
11 Request Meal Delivery  Cafeteria Staff
12 Record Meal Delivery  Deliverer
13 Print Delivery Instructions  Deliverer
14 Manage Users Administrator
15 Login [Guest]
2.2 <<Feature Name 1 – i.e Order Meals>>
a. <<Use Case Name 1.1>>
[Provide the specification for the related use case following the table format as below.
UC ID and Name:

Created By: Date Created:

Primary Actor: Secondary Actors:

Trigger:
Description:

Preconditions: 1.
Post-conditions: 1.

Normal Flow: 1.
Alternative Flows:

Exceptions:
Priority: High (Medium, Low)

Frequency of Use:
Business Rules:

Other Information:
Assumptions:

7|Page
In which:
Use Case ID and Name
Give each use case a unique integer sequence number identifier. State a concise name for the use
case that indicates the value the use case would provide to some user. Begin with an action verb,
followed by an object.
Author and Date Created
Enter the name of the person who initially wrote this use case and the date it was written.
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. Different actors often correspond to
different user classes, or roles, identified from the customer community that will use the product.
Name the primary actor that will be initiating this use case and any other secondary actors who
will participate in completing execution of the use case.
Trigger
Identify the business event, system event, or user action that initiates the use case. This trigger
alerts the system that it should begin testing the preconditions for the use case so it can judge
whether to proceed with execution.
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.
Preconditions
List any activities that must take place, or any conditions that must be true, before the use case
can be started. The system must be able to test each precondition. Number each precondition.
Example: PRE-1: User’s identity has been authenticated.
Post-conditions
Describe the state of the system at the successful conclusion of the use case execution. Label each
post-condition in the form POST-X, where X is a sequence number. Example: POST-1: Price of item
in the database has been updated with the new value.
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. This dialog sequence will
ultimately lead to accomplishing the goal stated in the use case name and description. Show a
numbered list of actions performed by the actor, alternating with responses provided by the
system. The normal flow is numbered “X.0”, where “X” is the Use Case ID.
Alternative Flows
Document 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. Number
each alternative flow in the form “X.Y”, where “X” is the Use Case ID and Y is a sequence number
for the alternative flow. For example, “5.3” would indicate the third alternative flow for use case
number 5. Indicate where each alternative flow would branch off from the normal flow, and if
pertinent, where it would re-join the normal flow.
Exceptions
Describe any anticipated error conditions that could occur during execution of the use case and
how the system is to respond to those conditions. Number each alternative flow in the form
“X.Y.EZ”, where “X” is the Use Case ID, Y indicates the normal (0) or alternative (>0) flow during
which this exception could take place, “E” indicates an exception, and “Z” is a sequence number
for the exceptions. For example “5.0.E2” would indicate the second exception for the normal flow
for use case number 5. Indicate where in the normal (or an alternative) flow each exception could
occur.

8|Page
 Priority
Indicate the relative priority of implementing the functionality required to allow this use case to
be executed. Use the same priority scheme as that used for the functional requirements.
Frequency of Use
Estimate the number of times this use case will be performed per some appropriate unit of time.
This gives an early indicator of throughput, concurrent usage loads, and transaction capacity.
Business Rules
List any business rules that influence this use case. Don’t include the business rule text here, just
its identifier so the reader can find it in another repository when needed.
Other Information
Identify any additional requirements, such as quality attributes, for the use case that may need to
be addressed during design or implementation. Also list any associated functional requirements
that aren’t a direct part of the use case flows but which a developer needs to know about.
Describe what should happen if the use case execution fails for some unanticipated or systemic
reason (e.g., loss of network connectivity, timeout). If the use case results in a durable state
change in a database or the outside world, state whether the change is rolled back, completed
correctly, partially completed with a known state, or left in an undetermined state as a result of
the exception.
Assumptions
List any assumptions that were made regarding this use case or how it might execute.
You can see the samples in the next sections]
b. <<Use Case Name 1.2 – i.e Order a Meal
ID and Name: UC-01 Order a Meal

Created By: Prithvi Raj Date Created: 10/4/13

Primary Actor: Patron Secondary Actors: Cafeteria Inventory System

Description: A Patron accesses the Cafeteria Ordering System from the corporate
intranet or from home, views the menu for a specific date if desired, selects
food items, and places an order for a meal to be delivered to a specified
location within a specified 15-minute time window.
Trigger: A Patron indicates that he wants to order a meal
Preconditions: PRE-1. Patron is logged into COS.
PRE-2. Patron is registered for meal payments by payroll deduction.
Post-conditions: POST-1. Meal order is stored in COS with a status of “Accepted”.
POST-2. Inventory of available food items is updated to reflect items in this
order.
POST-3. Remaining delivery capacity for the requested time window is
updated.
Normal Flow: 1.0 Order a Single Meal
1. Patron asks to view menu for a specific date. (see 1.0.E1, 1.0.E2)
2. COS displays menu of available food items and the daily special.
3. Patron selects one or more food items from menu. (see 1.1)
4. Patron indicates that meal order is complete. (see 1.2)
5. COS displays ordered menu items, individual prices, and total price,
including taxes and delivery charge.
6. Patron either confirms meal order (continue normal flow) or requests to
modify meal order (return to step 2).
7. COS displays available delivery times for the delivery date.

9|Page
 8. Patron selects a delivery time and specifies the delivery location.
9. Patron specifies payment method.
10. COS confirms acceptance of the order.
11. COS sends Patron an email message confirming order details, price, and
delivery instructions.
12. COS stores order, sends food item information to Cafeteria Inventory
System, and updates available delivery times.
Alternative Flows: 1.1 Order multiple identical meals
Patron requests a specified number of identical meals. (see 1.1.E1)
Return to step 4 of normal flow.
1.2 Order multiple meals
Patron asks to order another meal.
Return to step 1 of normal flow.
Exceptions: 1.0.E1 Requested date is today and current time is after today’s order cutoff time
1. COS informs Patron that it’s too late to place an order for today.
2a. If Patron cancels the meal ordering process, then COS terminates use case.
2b. Else if Patron requests another date, then COS restarts use case.
1.0.E2 No delivery times left
1. COS informs Patron that no delivery times are available for the meal date.
2a. If Patron cancels the meal ordering process, then COS terminates use case.
2b. Else if Patron requests to pick the order up at the cafeteria, then continue with
normal flow, but skip steps 7 and 8.
1.1.E1 Insufficient inventory to fulfill multiple meal order
1. COS informs Patron of the maximum number of identical meals he can order,
based on current available inventory.
2a. If Patron modifies number of meals ordered, then Return to step 4 of normal
flow.
2b. Else if Patron cancels the meal ordering process, then COS terminates use case.
Priority: High
Frequency of Use: Approximately 300 users, average of one usage per day. Peak usage load for
this use case is between 9:00 A.M. and 10:00 A.M. local time.
Business Rules: BR-1, BR-2, BR-3, BR-4, BR-11, BR-12, BR-33

Other 1. Patron shall be able to cancel the meal ordering process at any time
Information: prior to confirming it.
2. Patron shall be able to view all meals he ordered within the previous six
months and repeat one of those meals as the new order, provided that
all food items are available on the menu for the requested delivery
date. (Priority = M)
3. The default date is the current date if the Patron is using the system
before today’s order cutoff time. Otherwise, the default date is the next
day that the cafeteria is open.
Assumptions: Assume that 15 percent of Patrons will order the daily special (source:
previous 6 months of cafeteria data).

c. <<Next Use Case Name 1.x>>

…

2.3 <<Feature name 2 – i.e: Meal Subscriptions>>

a. <<Use Case Name 2.1 – i.e Register for Payroll Deduction>>
ID and Name: UC-05 Register for Payroll Deduction
Created By: Nancy Anderson Date Created: 9/15/13

10 | P a g e
 Primary Actor: Patron Secondary Actors: Payroll System

Description: Cafeteria patrons who use the COS and have meals delivered must be
registered for payroll deduction. For noncash purchases made through the
COS, the cafeteria will issue a payment request to the Payroll System, which
will deduct the meal costs from the next scheduled employee payday direct
deposit.
Trigger: Patron requests to register for payroll deduction, or Patron says yes when
COS asks if he wants to register
Preconditions: PRE-1. Patron is logged into COS.
Postconditions: POST-2. Patron is registered for payroll deduction.

Normal Flow: 5.0 Register for Payroll Deduction

1. COS asks Payroll System if Patron is eligible to register for payroll
deduction.
2. Payroll System confirms that Patron is eligible to register for payroll
deduction.
3. COS asks Patron to confirm his desire to register for payroll deduction.
4. If so, COS asks Payroll System to establish payroll deduction for Patron.
5. Payroll System confirms that payroll deduction is established.
6. COS informs Patron that payroll deduction is established.
Alternative Flows: None
Exceptions: 5.0.E1 Patron is not eligible for payroll deduction
5.0.E2 Patron is already enrolled for payroll deduction
Priority: High

Frequency of Use:
Business Rules: BR-86 and BR-88 govern an employee’s eligibility to enroll for payroll
deduction.

Other Expect high frequency of executing this use case within first 2 weeks after
Information: system is released.
Assumptions:

b. <<Next Use Case Name 2.x>>

[Use Case Description in the same format as above]

2.4 <<Next Feature Name..>>

…

11 | P a g e
3. Functional Requirements
3.1 System Functional Overview
a. Screen Flow
[This part show the system screens and the relationship among screens. You can draw the Screens
Flow for the system in the form of diagram as below]

b. Screen Details
[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 ..

c. 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 the specific
system user role names]

Screen Role1 Role2 Role3 Role4 RoleX

<<Screen Name1>> X X X
<<Screen Activity>> X X
<<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

12 | P a g e
 Delete Data
…
In which:
 Role1: <<role1 description>>
 Role2: <<role2 description>>
 …

d. 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 …

e. Entity Relationship Diagram

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

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 …

13 | P a g e
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

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

…

14 | P a g e
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.

15 | P a g e
 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).

16 | P a g e
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.]

17 | P a g e
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 …

18 | P a g e