<<Customer Logo>>

[CUSTOMER NAME – SYSTEM NAME]

Requirement Specifications
For <<App Name>>

Version: 0.7

Singapore, April 2014

Approval Page
The endorsement on this document by authorized [Customer Name] representative indicates [Customer Name]
and FPT‟s agreement on the “[Project Name] Requirement Specifications” document.

Prepared by : (FPT) Signature:

Business Analyst ____________________

Date:

____ /____ / ____

Reviewed by : (FPT) Signature:

Project Manager ____________________

Date:

____ /____ / ____

Supported by: (Customer Name) Signature:

____________________

Date:

____ /____ / ____

Approved by : (Customer Name) Signature:

____________________

Date:

____ /____ / ____

Revision History
Date Version Author Change Description

DD/MM/YYYY 0.5 Author First Creation

0.7 For internal review

0.8 For the first release to customer

0.9.x For updating version while reviewing with

customer

1.0 For official sign-off

TABLE OF CONTENTS

1. Introduction 5

1.1 Purpose 5

1.2 Overview 5

1.3 Intended Audience and Reading Suggestions 5

1.4 Abbreviations 5

1.5 References 6

2. High Level Requirements 7

2.1 Object Relationship Diagram 7

2.2 Workflow 8

2.3 State Transition 9

2.4 Use Case Diagram 10

2.5 Permission Matrix 12

2.6 Site Map 13

3. Use Case Specifications 15

3.1 Manage Use case 15

3.1.1 UC 1: Mange Company 15

3.1.2 UC 2: Create a new Request 17

3.1.3 UC 3: View an existing Request 18

3.1.4 UC 4: Search Requests 19

3.1.5 UC 5: Update an existing Request 21

3.1.6 UC 6: Delete an existing Request 23

3.2 Workflow Use case 26

3.2.1 UC 7: Submit a Request 26

3.2.2 UC 8: Approve a Request 27

3.2.3 UC 9: Reject a Request 29

3.3 Other Use case 32

 3.3.1 UC 10: Scheduled Job (E.g. Send email Reminder) 32

3.4 Common Business Rules 33

4. Mockups Screen 34

4.1 Landing Page 34

4.2 Detail Screen 34

4.3 Listing View 35

5. Non-Functional Requirements 36

5.1 Performance Requirements (optional) 36

5.2 Safety Requirements (optional) 37

5.3 Security Requirements (optional) 37

5.4 Software Quality Attributes (optional) 38

6. Other Requirements 40

6.1 Common field controls 40

6.2 Common Messages Configuration 40

6.3 View Columns Display 41

6.4 Pagination 41

6.5 Search Component 42

6.6 Bulk Action 42

7. Integration 44

8. Data Migration 44

8.1 Migration Scope 44

8.2 Data Mapping 44

9. Appendices 45

9.1 Messages List 45

9.2 Email Templates 46

1. Introduction
1.1 Purpose
The Functional Requirements Specification will:

❖ Define the scope of business objectives, business functions, and organizational units covered,
❖ Identify the business processes that the solution must facilitate,
❖ Facilitate a common understanding of what the functional requirements are for all parties involved,
❖ Establish a basis for defining the acceptance tests for the solution to confirm that what is delivered meets
requirements.
The purpose of the document is to collect and analyse all assorted ideas that have come up to define the system,
its requirements with respect to consumers. Also, we shall predict and sort out how we hope this product will be
used in order to gain a better understanding of the project, outline concepts that may be developed later, and
document ideas that are being considered, but may be discarded as the product develops.

1.2 Overview
<Describe the purpose & scope of the system>

1.3 Intended Audience and Reading Suggestions

This document is intended for:
❖ Development team: Responsible for developing detailed design, implement and perform unit test,
integration test and system test for the migrated application
❖ Data Migration team: Responsible for creating data migration scripts, and perform data migration for the
application.
❖ Documentation Team: Responsible for writing User Guide for the application.
❖ UAT team: Responsible for conducting user acceptance test sessions with end users.

1.4 Abbreviations
<Template only: List out all Acronym used in this documents and sort them alphabetically.>

Acronym Reference

SRS System Requirement Specification

UC Use Case
 BR Business Rules

CBR Common Business Rules

ET Email Template

N/A Not Applicable or Not Available

MSG Message

[Field] Convention for mentioning a field

<<Field>> Convention for value of this field, specifically use in the context of Email Template

“Text Value” Convention for mentioning a value

<Value> Convention for mentioning special value, i.e. <Today>, <Current User>

TBU To be Updated

NRF National Research Foundation

OOE Other Operating Expenditure

1.5 References
<Template only: List any other documents or Web addresses to which this SRS refers. These may include user
interface style guides, contracts, standards, system requirements specifications, use case documents, or a vision
and scope document. Provide enough information so that the reader could access a copy of each reference,
including title, author, version number, date, and source or location.
List any version information relating to external Tools, Plugins or Platforms that the system uses or is built upon.
If no, put N/A>

Title Reference Description

Title of Document / Link to the Document or Description of the purpose or information

Website Website provided by the Document, Website.

Title of Tools, Plugins or Link to the Tools, Plugins or Version information of the Tools, Plugins or
Platforms Platforms Website. Platforms that the systems uses or is built upon.
2. High Level Requirements
This section describes the general overview of the system functions or business processes which are depicted in
different diagrams. It shows the types of users, their granted permissions to perform specific system functions
and the sequence required to complete a business workflow (if any). As the section name implies, it is high-level
which means not detailed enough. For detailed requirement specification, please see Use Case Specifications
section below.

2.1 Context Diagram

This section shows the static relationship between each object in the system. An object could be described as an
instance of a particular entity in the system. For example, “Booking Request Form” is an object in this system
which holds its own information, such as: Requestor Details, Resource, Equipment, Booking Date Time…

Figure 1:

Description:

# Object Description

Object

1 NRF <Purpose of this object, what kind of information storing in this object>

2 OOE

Actor

<Responsibility of people in this group>

1 NRF <How to recognize user in this group? E.g. person in SharePoint group,
selected person in a field abc>

2 OOE

External System
 1 SAP <Purpose of this system, how to integrate to this system>

2.2 Workflow
This section shows the flow of tasks or steps taken by each user of the system in order to complete a business
process. The user’s actions are shown in each business process stage of the system along with the conditions
under which it can move to the next stage or revert to the previous.

Figure 2:

Workflow Explanation:

<Can remove this section for simple workflow>

2.3 State Diagram

This represents the behavior of the system in response to user’s actions by changing state of data objects. The
circle shows the state. The line that connects one state to another shows the action required for that state
change to happen. These actions are usually triggered by a user.
 Figure 3:

2.4 Sequence Diagram

2.5
2.6 Use Case Diagram
The use case diagram here shows the specific goal and objective or how the user interacts with the system. The
ellipse in the system boundary represents the system use case/functions while the stickman represents the
actor/user of the system. The line connecting the actor and the use case shows that the actor can perform that
function in the system to achieve a goal.

(Use UML standard for UC diagram)

Figure 4:

# UC Name Description

2
3

4
2.7 Site Map
The site map describes the way for navigating through the system.

<Template only: Note: Only need to draw up to 3 levels from the Home page to reduce the complexity and make
the map readable.>

Figure 5:

Page Description Permission

Let’s submit Link to the screen description Who has permission to view this page

My Suggestions

…
3. Use Case Specifications
This section covers the system’s functional requirements which details what the system must do in terms of
input, behavior and the expected output. It elicits the interaction between the actor(s) and the system, the
system’s behavior and the results of their interactions.

3.1 Manage Use case

3.1.1 UC 1: Mange Company
Objective: This use case allows user to manage the list of Companies including creating,
viewing, updating or deleting.

Actor: System Admin

Trigger: User accesses to the Companies view to create, view, update or delete Country.

Pre-condition: User is logged in successfully as actor above.

Post-condition: Company is created, viewed, updated.

Activity Flows
Business Rules

Step BR Code Description

(2) BR 1 Screen Displaying Rules:

The system will load “Companies” view screen <<link to screen>>.

(4) BR 2 Creating Rules:

<Template only: Used during “Create”>

❖ After user clicks to save, system will check the following rules:
⮚ If any mandatory field is left blank, system shows error message MSG 1 You
must specify a value for this required field.
⮚ If the Company Name is existed, system shows error message MSG 5 You
must specify a unique value for this field.
⮚ If the inputted email is of invalid format (<mailbox name>@<domain name>),
system displays MSG 6 Invalid Email Address.
❖ Otherwise, system creates new Company.
(4) BR 3 Viewing Rules:

<Template only: Used during “View”>

From Companies view, user selects existing Company then clicks to open the selected
Company in detailed page (refer to <<link to screen>>).

(4) BR 4 Updating Rules:

<Template only: Used during “Update”>

❖ From Companies view, user selects existing Company then clicks to update the
selected Company.
❖ After updating data user click to save, system will check the following rules:
⮚ If any mandatory field is left blank, system shows error message MSG 1 You
must specify a value for this required field.
⮚ If the Company Name is existed, system shows error message MSG 5 You
must specify a unique value for this field.
⮚If user inputs an invalid Contact email address, system shows error message
MSG 6 Invalid Email Address.
❖ Otherwise, system updates changes to the selected Company.
(4) BR 5 Deleting Rules:

<Template only: Used during “Delete”>

❖ From Companies view, user selects existing Company then clicks to delete the
selected Company.
❖ The system shows a confirmation message MSG 7 Are you sure you want to
 delete this item? with two buttons “OK” and “Cancel”.
⮚ If user clicks on the “OK” button from the confirmation dialog, system will
move the selected Company to the Recycle Bin/flag the document as
deleted/delete the Company permanently.
⮚ If user clicks on the “Cancel” button, system will close the confirmation dialog
and do nothing.

3.1.2 UC 2: Create a new Request

Objective: This use case allows user to create a request.

Actor: All authenticated users

Trigger: User selects to create a new Request, then selects to save.

Pre-condition: User is logged in successfully as actor above.

Post-condition: A request is saved successfully.

Activities Flow
Business Rules

Step BR Code Description

(2) BR 6 Screen Displaying Rules:

The system will load Request screen <<link to screen>>.

(4) BR 7 Validating Rules:

System will check the following rules:

❖ If the value of any mandatory fields is blank, system will show an error message
for the required fields as MSG 1 You must specify a value for this required field.

❖ <<Other validation rules>>

(5) BR 8 Saving Rules:

After all validation rules passed, system will perform the following actions:

❖ Save all changes.

❖ Append a new line in the [Audit Trail] section as the following:

⮚ <<input audit trail rules>>

3.1.3 UC 3: View an existing Request

Objective: This use case allows user to view the details of a Request.

Actor: All authenticated users

Trigger: User selects to open an existing Request.

Pre-condition: ❖ User is logged in successfully as actor above.

❖ General Users, Application Admin can view all Requests excluding draft Requests
of other users. They can view draft Requests created by themselves.

❖ System Admin can view all Requests regardless its statuses.

Post-condition: The Request is opened for viewing.

Activities Flow
Business Rules

Step BR Code Description

(2) BR 9 Screen Displaying Rules:

The system will load the Request list view based on screen <<link to screen>>.

3.1.4 UC 4: Search Requests

Objective: This use case allows user to search for existing requests.

Actor: All authenticated users

Trigger: User selects to search requests.

Pre-condition: User is logged in successfully as actor above.

Post-condition: Search Result is displayed.

Activities Flow

Business Rules

Step BR Code Description

(2) BR 10 Screen Displaying Rules:

The system will load Request searching screen <<link to screen>>.

(4) BR 11 Validating Rules:

The system will check at the time of searching requests:

❖ In case both From Date and To Date of Date Submitted are inputted, if [From Date] is
later than [To Date], system will show error message MSG 8 Invalid Date combination.

(5) BR 12 Searching Rules:

❖ When user clicks Search button, system will retrieve all requests which satisfy all
following conditions:
⮚ If user does not enter any criteria, system will show all Requests on the result
 view.
⮚ If user enter any criteria, system will show all returned Requests as per following
table:

# Searching Condition Searching Result

If the [Requester] field is System will retrieve all records without

blank filtering by Requester’s Name. Otherwise,
filter only records whose Requester’s
Name matches inputted [Requester].

If the [Request Title] field is System will retrieve all records without
blank filtering by Request Title. Otherwise, filter
only records whose Request Title matches
inputted [Request Title].

If the [Request Type] field is System will retrieve all records without
“All” filtering by Request Type. Otherwise, filter
only records whose Request Type matches
inputted [Request Type].

If the [Status] field is “All” System will retrieve all records without
filtering Status. Otherwise, filter only
records whose Status matches inputted
[Status].

<<insert more search

condition>>

❖ In case there is no item matches the search criteria, system displays an message MSG
9 No information found! on the Search Results view. Otherwise, system shows all
returned Requests on the result view.

3.1.5 UC 5: Update an existing Request

Objective: This use case allows user to update an existing Request.

Actor: All authenticated users

 Trigger: User selects to edit an existing Request then selects to Save.

Pre-condition: ❖ User is logged in successfully as actor above.

❖ If the current request is a Draft, the current user = Requester or Application

Admin.

❖ If the current request is Pending Approval, the current user = Requester,

Approver or Application Admin.

Post-condition: The Request is updated successfully.

Activities Flow

Business Rules

Step BR Code Description

(2) BR 13 Screen Displaying Rules:

 The system will load Request screen <<link to screen>>.

(4) BR 14 Validating Rules:

Depending on the current status of the Request at the point of editing, system will
validate based on the existing rules Requested under each of the use-case.

The validation logic is:

❖ The Request’s status is “Draft” and the Requester is working on it, system will
perform following validation rules:
⮚ If the value of any mandatory fields is blank, system will show an error
message for the required fields as MSG 1 You must specify a value for this
required field.
⮚ <<Other validation rules>>
❖ The Request’s status is “Pending Approval”, system will perform following
validation rules:
⮚ System will show an error message for the required fields as MSG 1 You must
specify a value for this required field. if the value of any mandatory and any
of following fields are blank:
o [Final Approver].
o [Implementer].
⮚ <<Other validation rules>>
(5) BR 15 Updating Rules:

❖ Save all changes.

❖ Append a new line in the [Routing History]:

<<Current date time>> - “Updated by” <<Current user’s name>>

3.1.6 UC 6: Delete an existing Request

Objective: This use case allows user to delete a Request.

Actor: All authenticated users

Trigger: User selects to delete a Request

Pre-condition: ❖ User is logged in successfully as actor above.

❖ If the current Request is a Draft, current user = Requester, System Admin or

Application Admin.
 ❖ If the current Request is in any status other than “Draft, current user =
Application Admin.

Post-condition: The selected Request is deleted successfully.

Activities Flow

Business Rules

Step BR Code Description

(4) BR 16 Confirmation Message Rules:

The system shows confirmation message MSG 7 Are you sure you want to delete this
item?

(6) BR 17 Deleting Rules:

❖ If user clicks on the “OK” button from the confirmation dialog, system will move
the selected Request to the Recycle Bin/flag the document as deleted/delete the
request permanently.
❖ If user clicks on the “Cancel” button, system will close the confirmation dialog and
do nothing.
3.2 Workflow Use case
3.2.1 UC 7: Submit a Request
Objective: This use case allows user to submit (or re-submit) a Request.

Actor: ❖ Requester

❖ Application Admin

Trigger: User selects to submit a Request.

Pre-condition: ❖ User is logged in successfully as actor above.

❖ Request’s Status = “Draft” or “Rejected”.

Post-condition: A Request is submitted successfully.

Activities Flow

Business Rules
 Step BR Code Description

(2) BR 18 Screen Displaying Rules:

The system will load Request screen <<link to screen>>

(4) BR 19 Validating Rules:

The system performs the following validation:

❖ If the value of any mandatory fields is blank, system will show an error message for
the required fields: MSG 1 You must specify a value for this required field.

❖ <Other validation rules that required specifically for submission function>

(5) BR 20 Submitting Rules:

❖ After all validation rules are passed, system performs the following actions

⮚ Save all changes.

⮚ Update [Status] to “Pending Approval”

⮚ Update [Date Submitted] to the current date.

⮚ Update [Submitted By] to the current user.

⮚ Append a new line in the [Audit Trail]:

<<Current date time>> - “Submitted by ” <<Current user>>

❖ Show a confirmation message “Your request is submitted successfully.”

(5) BR 21 Email Notification Rule:

The system sends an email notification email according to the following template:

❖ Submit request: ET1

❖ Re-submit request: ET 1: Sending email to Evaluator when Suggester submits a
Suggestion.

3.2.2 UC 8: Approve a Request

Objective: This use case allows user to approve a Request.

Actor: ❖ Approver
❖ Application Admin
Trigger: User selects to approve a Request.

Pre-condition: ❖ User is logged in successfully as actor above.

 ❖ [Status] is “Pending Approval”.

Post-condition: A Request is approved and pending for implementation.

Activities Flow

Business Rules

Step BR Code Description

(2) BR 22 Screen Displaying Rules:

The system will load Request screen <<link to screen>>.

(4) BR 23 Validating Rules:

❖ System will show an error message as MSG 1 You must specify a value for this
required field. if any of following fields is blank:

⮚ [Remark from Approver]

 ⮚ [Expected Date of Implementation]

⮚ [Implementer]

⮚ Any mandatory fields

❖ System will show a confirmation message as <TBU> if validation was successful.

(6) BR 24 Approval Rules:

After user clicks on “OK” button, system performs the following actions

❖ Save all changes.

❖ Update [Status] to “Approved”
❖ Update [Date Approved] to the current date.
❖ Update [Approved By] to the current user.
❖ Append a new line in the [Audit Trail]: <<Current date time>> - “Approved by ”
<<Current user>>
(6) BR 25 Email Notification Rule:

The system sends an email notification based on email template <TBU>.

3.2.3 UC 9: Reject a Request

Objective: This use case allows user to reject the Request.

Actor: ❖ Approver
❖ Application Admin
Trigger: User selects to reject the Request.

Pre-condition: ❖ User is logged in successfully as actor above.

❖ [Status] is “Pending Approval”.

Post-condition: A Request is rejected.

Activities Flow

Business Rules

Step BR Code Description

(2) BR 26 Screen Displaying Rules:

The system will load Request screen <<link to screen>>.

(4) BR 27 Validating Rules:

❖ System will show the error message MSG 1 You must specify a value for this required
field. under field [Reason for Rejecting] if it is blank.
❖ System will show a confirmation message as <TBU> if validate successfully.
(6) BR 28 Rejecting Rules:
 Upon user selecting to reject the current request, the system perform the following
processing:

❖ Save all changes.

❖ Update [Status] to “Rejected”
❖ Update [Date Rejected] to the current date.
❖ Update [Rejected By] to the current user.
❖ Append a new line in the [Audit Trail]: <<Current date time>> - “Rejected by ”
<<Current user>>
(6) BR 29 Email Notification Rule:
The system sends a notification email based on the following email template <TBU>
3.3 Other Use case
3.3.1 UC 10: Scheduled Job (E.g. Send email Reminder)
Objective This use case allows System to send email reminder.

Actor System

Trigger At 02:00 AM Daily

Pre-conditions N/A

Post-condition Email reminders for appropriate requests are sent.

Activities Flow

Business Rules

BR Code Description

BR 30 Sending Notification Email Rule: Tasks that need to be done by [Assigned To]:

System sends notification email for the Request under following conditions:

❖ [Status] of To Do Request is not equal to "Done”

❖ Today date is less than [Due by]
Using the following email template: <TBU>

BR 31 Sending Notification Email Rule: Overdue Approval Requests

System sends notification email for the Request under following conditions:

❖ [Status] of Request is equal to "Pending for Approval”

❖ Today date is greater than [Expected Deadline]
Using the following email template: <TBU>
3.4 Common Business Rules
This section defines business rules that are used across use cases and can be considered as common rules.
Each common business rule below is applied only for use cases that have reference to it.

BR Code Description

CBR1
4. Mockups Screen
This section contains the screens and their respective attributes associated with one or more use cases defined in Use Case Specifications section above.

4.1 Landing Page

<Purpose of this screen & How to access>

<Screenshot>

Screen 1: <Screen Name>

# Component Description

1 Left menu <Describe all links in the left menu>

2 Main Content <Default view?>

4.2 Detail Screen

<Purpose of this screen & How to access>

<Screenshot for Read Mode>

Screen 2: <Screen Name>

<Screenshot for Edit Mode>

Screen 3: <Screen Name>

# Component Comp. Type Editable Mandatory Default Value Description

1 Title Singe Line of Text Yes Example:

 ❖ Purpose of this field if just the name is not enough
to describe.
❖ This is read-only field. (Doesn’t need to mention if
this is editable field)
❖ Date time format e.g. DD/MM/YYYY HH:mm
2 Multiple Line of
Text

3 Drop Down List

4 Radio Button

5 Submit Button N/A This button triggers UC 1 (Need a cross reference to

the UC).

4.3 Listing View

<Purpose of this screen & How to access>

<Screenshot for view>

Screen 4: <Screen Name>

# Component Value Description

1 Title [Title] ❖ Link to item

❖ Grouping and sorting ascending
2

4 Submit Button To submit selected item(s). Refer to UC …

5. Non-Functional Requirements
This section describes the operation of the system with respect to the Use Case Specifications section (Functional
requirements). This comprises mostly of the technical architecture of the system which could be referred to as
the quality of the system.

5.1 Performance Requirements (optional)

< Template only: If there are performance requirements for the product under various circumstances, state them
here and explain their rationale, to help the developers understand the intent and make suitable design choices.
Specify the timing relationships for real time systems. Make such requirements as specific as possible. You may
need to state performance requirements for individual functional requirements or features.>

Performance requirements refer to the capability of the software to provide the required performance relative
to the amount of resources used, under stated conditions

Title Variables / Criteria Remarks

❖ Measurement Point. i.e. Number of operations performed per second.

❖ Statistic Type. i.e. The system shall be able to process 100 payment
❖ Measurement Period.
transactions per second in peak load
Response ❖ Platform.
i.e. Production of a simple report shall take less than 20
Time ❖ Error Rate.
seconds for 95% of the cases.

i.e. Scrolling one page up or down in a 200 page

document shall take at most 1 second.

❖ Workload percentage at peak i.e. In standard workload, the CPU usage shall be less
time. than 50%, leaving 50% for background jobs.
Workload
❖ Workload percentage at off-
peak time.
Scalability Ease of Scalability.

❖ Hardware. ❖ Operating systems:

❖ Software. ⮚ Windows: latest + 2 previous versions.
❖ External System Integration. ⮚ Mac OS: latest + 2 previous versions.
Platform ❖ Devices:
⮚ Mobile.
⮚ Tablet.
⮚ Desktop.
5.2 Safety Requirements (optional)
<Template only: Specify those requirements that are concerned with possible loss, damage, or harm that could
result from the use of the product. Define any safeguards or actions that must be taken, as well as actions that
must be prevented. Refer to any external policies or regulations that state safety issues that affect the product’s
design or use. Define any safety certifications that must be satisfied.>

Safety Requirement refers to the aspects of a solution that protects solution contents or solution components
from accidental or malicious access, use, modification, destruction, or disclosure.

Title Variables / Criteria Remarks

Authenticit Mode of authentication

y

Password and message encryption i.e. The system needs to follow standard encryption
Privacy
algorithm called DES (Data Encryption Standard).

5.3 Security Requirements (optional)

< Template only: Specify any requirements regarding security or privacy issues surrounding use of the product or
protection of the data used or created by the product. Define any user identity authentication requirements.
Refer to any external policies or regulations containing security issues that affect the product. Define any security
or privacy certifications that must be satisfied.>

Title Variables / Criteria Remarks

Authenticati ❖ Success rate in i.e. The application shall identify all of its client
on authentication. applications before allowing them to use its capabilities.
❖ Resistance to known attacks.
i.e. The application shall ensure that the name of the
❖ Probability/time/resources to
detect an attack. employee in the official human resource and payroll

❖ Percentage of useful services databases exactly matches the name printed on the
still available during an employee’s social security card.
attack.
i.e. At least 99% of intrusions shall be detected within 10
❖ Percentage of successful
attacks. seconds.
 ❖ Lifespan of a password, of a
session.
❖ Encryption level.

5.4
Software Quality Attributes (optional)
< Template only: Specify any additional quality characteristics for the product that will be important to either the
customers or the developers. Some to consider are: adaptability, availability, correctness, flexibility,
interoperability, maintainability, portability, reliability, reusability, robustness, testability, and usability. Write
these to be specific, quantitative, and verifiable when possible. At the least, clarify the relative preferences for
various attributes, such as ease of use over ease of learning.>

Title Variables / Criteria Remarks

Usability: Ease with which a user can learn to use the solution.

❖ Color-blind users
Accessibility ❖ Voice-over for hearing
impaired users
❖ Time zone adaptation. The webpage must support 03 languages: English,
❖ Support multiple Chinese, Korean.
Internationalisation currencies.
❖ Support multiple
languages.
❖ Maximum number of i.e. Assure maximum 04 clicks to complete a
clicks to complete any transaction.
operation.
i.e. Four out of five users shall be able to book a guest
❖ Learnability.
❖ Efficiency. within 5 minutes after a 2-hour introduction to the

❖ Memorability. system.
Ease of Use ❖ Error Avoidance. i.e. Novice users shall perform tasks X and Y in 15
❖ User Satisfaction. minutes. Experienced users shall perform tasks X and Y
in 2 minutes.

i.e. At least 80% of customers polled after a 3 months

usage period shall rate their satisfaction with the
system at 7 and more on a scale of 1 to 10.

Reliability: Ability of a solution or component to perform its required functions under stated conditions.
 Percentage of time available i.e. The system must be available 98% of time on a
monthly basis.

i.e. No more than 1 per 1000000 transactions shall

result in a failure requiring a system restart.

i.e. The system shall meet or exceed 99.99% uptime.

Availability
i.e. The system shall not be unavailable more than 1
hour per 1000 hours of operation.

i.e. Less than 20 seconds shall be needed to restart the

system after a failure 95% of the time. (This is a MTTR
requirement)

Backup Backup frequency Backup must be triggered every three days at 12:00AM.

Functional Suitability: Degree to which the solution functions meet user needs

Accuracy Rate i.e. The precision of calculations shall be at least 1/106.

i.e. The system defect rate shall be less than 1 failure

Accuracy
per 1000 hours of operation.

Completeness Completeness Percentage

Compliance: Regulatory, financial, or legal constraints which can vary based on the context or jurisdiction.

Data Protection The system must conform to the GDPR regulations.

Regulatory
❖ EU: GDPR
Compliance
❖ Canada: PIPEDA
Constraint: Constraints of the organization being served by the solution that are formally agreed to by both
the provider and the user of the solution.

❖ Target price for the

solution
Price
❖ Limit for extensions
❖ Subscription allowance
Timeline Release duration Short releases – every 3 to 4 weeks
6. Other Requirements
6.1 Common field controls
<Template only: It is recommended that this part of the requirement refers directly to the library used by the
development team. But in case that is not an option, please use the following section. Reference to embedded
file.>

6.2 Common Messages Configuration

Message Type Remarks

In-line Error ❖ Display in red italic text.

Message ❖ Display below error field.
❖ Highlight error field in red.
❖ Message is displayed when there is error in validation.
In-field Error ❖ Display in red italic text.
Message ❖ Display inside error field, completely cover the content of the field.
❖ Upon selecting the field, the message disappears and the content is displayed
again.
❖ Highlight error field in red.
❖ Message is displayed when there is error in validation.
❖ Sample:

⮚ .
⮚ Where Description Text is the placeholder.
⮚ “Wrong entry / Entry required” is the message content.
Error Message ❖ Pop-Up contains only message content and a button “Close”.
❖ Clicking outside of the pop-up does not close it, only button “Close” on the pop-up
does.
❖ After closing popup, return to the current screen.
❖ Message is displayed when there is error in validation.
Confirmation ❖ Pop-Up contains only message content and two buttons “Yes”, “No”.
Message ❖ Clicking outside of the pop-up does not close it, only button “Yes” or “No” does.
 ❖ After closing popup, performs the corresponding function or action, which is
described specifically in each place using the Pop-up Confirmation Message.
❖ Message is displayed when there needs a confirmation of action.
Informing Message ❖ Pop-Up contains only message content and will disappear after 10s.
❖ Message is displayed after the system successfully performs a certain function or
action.
Standard platform ❖ Any standard platform message can be presented here.
Message

6.3 View Columns Display

<Template only: It is recommended that this part of the requirement refers directly to the library used by the
development team, or get suggestions from design team. But in case those are not viable options, please use the
following section>

Unless otherwise stated, view columns’ display specifications are:

❖ Displayed color & fonts are as specified in approved screen designs.

❖ When the text to be displayed is longer than the width of cell, cut the text at the end of first line, and replace
the missing characters with “…”. Hovering mouse over this “…” will pop up a tooltip at mouse position that
displays full content of the respective cell.
Unless otherwise stated, view columns’ headers are:

❖ Is unsorted by default.

❖ When unsorted, show icon as follows:

❖ When sorted in ascending, show icon as follows:

❖ When sorted in descending, show icon as follows:

6.4 Pagination
<Template only: Parts of this segment will vary depends on pagination settings used by the current system.
Please check and update accordingly>

Unless stated otherwise, pagination-related behavior in all views of the system will follow the following
specifications:
❖ When user performs a new search (both completely new and searching within the current search results),
refresh table, go back to page 1.
❖ When user changes the pagination setting (number of items to show per page), refresh table, go back to
page 1.
❖ When user is in page 1, disable buttons of “<<” and “<”
❖ When user is in the last page, disable buttons of “>>” and “>”
❖ Otherwise, enable all buttons.
❖ Button “<” and “>” move the pagination backward or forward by 1.
❖ Button “<<” or “>>” move the pagination to page 1 or the last page.
❖ If there is 1 page, still display the pagination with 1 page.
❖ On the most left position, the system displays all records found that satisfied the current condition (display
all or searched or filtered, etc…).
❖ User can input the number of pagination they want to go to, next to the total number of pagination.

❖ Sample:

6.5 Search Component

<Template only: Parts of this segment will vary depends on search settings used by the current system. Please
check and update accordingly>

Unless stated otherwise, search-related behavior in all views of the system will follow the following
specifications:

❖ Search field is a Free Text (single line of text) field, thus it follows this field’s common properties.
❖ Search behavior follows “contain” logic, where the system searches all presenting columns for records that
have value containing the keyed in value.
❖ Searched results are presented by refreshing the table listing information and the system updates pagination
information accordingly.
❖ If keyed in value is blank, the system will reset to the default view information.

6.6 Bulk Action

<Template only: Parts of this segment will vary depends on Bulk Action settings used by the current system.
Please check and update accordingly>

Unless stated otherwise, Bulk Action behavior in all views of the system will follow the following specifications:

❖ In the table listing, the first column will always be a checkbox columns allowing user to select records/items
to apply Bulk Action.
❖ Selecting the checkbox on Column Header will select all checkboxes only on the current pagination of the
table listing.
❖ Upon jumping between pagination, the selected state of checkboxes is kept.
❖ Users can select Bulk Action from the Dropdown list or available bulk action buttons (depending on the
system) to apply to the selected items.
❖ For Dropdown list Bulk Action:
⮚ Bulk Action is the default option, which performs nothing when apply.
⮚ Value list contains:
▪ Bulk Action.
▪ Export.
▪ Delete.
❖ For available bulk action buttons:
⮚ These buttons are enable only when at least 1 checkbox is selected.
⮚ Button includes:
▪ Delete.
▪ Export.
7. Integration
<Template only: Describe external system(s) which integrates with the system>

8. Data Migration
<Template only: Describe data migration scope and requirements.

In case SRS for data migration in a separated SRS, note down this point: e.g. Detailed requirements for Data
Migration part will be described on separated SRS. The data migration SRS and the functional SRS will be a couple
of documents to fulfil the whole requirements for SSS migration.>

8.1 Migration Scope

<Template only: This section is to define the scope of data migration. It contains the list of data objects or the
specific condition to define the set of data which will be migrated.>

8.2 Data Mapping

<Template only: This section shows the mapping for migrated data. It contains the data properties on the old
platform and the corresponding properties on the new platform. Data conversion and data patching rules are
also described if any.>
9. Appendices
9.1 Messages List
<Suggestion of new presentation>

For description of Message Type, please refer to Common Messages Configuration.

# Message Code and Content Type

1. MSG 1 You must specify a value for this required field. Error Message
2. MSG 2 You must specify a valid date within the range of 1/1/1900 and Error Message
31/12/2100.
3. MSG 3 The value of the field is not a valid number. Error Message

4. MSG 4 Are you sure, you want to send the item(s) to the site Recycle Bin? Confirmation
Message
5. MSG 5 You must specify a unique value for this field. In-line Error
Message
6. MSG 6 Invalid Email Address. Error Message

7. MSG 7 Are you sure you want to delete this item? Confirmation
Message
8. MSG 8 Invalid Date combination. Error Message

9. MSG 9 No information found! Informing Message

9.2 Email Templates
<Template only: It is recommended that Email Template Contents are written in Past Tense instead of Present
Tense to be more formal. Define any Prefix necessary for the Email>.

ET 1: Sending email to Evaluator when Suggester submits a Suggestion.

Send to Evaluator

CC Suggester(s)

Subject [Prefix] SSS: A new Suggestion <<Suggestion Code>> has been submitted for your evaluation.

Body Dear <<Evaluator’s name>>

The Suggestion <<Suggestion Code>> - <<Suggestion Title>> has been submitted for your
evaluation.

To view the Suggestion details, please click here.

Sincerely,

SSS Admin

Note: This is an auto-generated email, please do not reply.

Note: The link here leads to screen <Reference here>.