Trade Project - Lesson 7 – Chapter 5 – System Requirements Specification (SRS)

CHAPTER 5: SYSTEM REQUIREMENTS SPECIFICATION

This chapter should have a minimum of 5 pages and a maximum of 15 pages. This chapter
• Describes the requirements of the proposed project or software system.
• Defines what the software system will do and how it will be expected to perform.
• Serves as a blueprint or roadmap for the system software that will be built.
• Describes the intended purpose and environment for software under development.
• Provides a clear understanding of the software system's features and capabilities.
• Provides a basis for testing and evaluating the software system, which helps to ensure that
it is of high quality and meets the needs of its users. This chapter should
• Be clear and concise: This chapter should be easy to understand and not cluttered with
unnecessary information.
• Be specific and complete: This chapter should provide specific and complete
information about the system.
• Be organised: This chapter should be organised logically so it is easy to find the
necessary information.
• Be consistent: This chapter document should use consistent terminology and formatting.
CHAPTER FIVE SECTIONS
Consider the following as the chapter five sections
Chapter 5.0: System Requirements Specification
5.1 Introduction
5.2 Functional requirements
5.2.1 Use cases
5.2.2 User stories:
5.2.3 Functional Requirements Specifications (FRSs)
5.2.4 Functional Decomposition Diagrams (FDDs):
5.3 Acceptance criteria
5.4 Non-functional requirements
5.4.1 Performance requirements
5.4.2 Security requirements
5.4.3 Scalability requirements
5.3.4 Usability requirements
Trade Project - Lesson 7 – Chapter 5 – System Requirements Specification (SRS)

5.4 External Interface Requirements

5.5 Assumptions and Dependencies
5.6 Glossary
5.1 Introduction
This section provides an overview of the system requirements specification (SRS), including its
purpose, scope., and intended audience.
Example
This chapter provides an overview of the system requirements specification (SRS) for the new
online banking system. It describes the system's functional and non-functional requirements and
aims to ensure all stakeholders have a clear and shared understanding of the system requirements.
It is intended for system developers, testers, and end users.
5.1 Functional requirements
This section describes the system's functional requirements, i.e., what the system should do.
Functional requirements are typically described in terms of use cases, user stories, functional
requirements specifications (FRSs) and Functional Decomposition Diagrams (FDDs):
Use cases
Use cases describe how users interact with the system to achieve their goals. They can be used to
identify the functional requirements of the system, as well as the non-functional requirements,
such as performance and security requirements.
Example
The following are examples of use cases being used to show cash withdrawal from an ATM and
money transfer between accounts on an online banking system

Use case 1: Withdraw cash from an ATM

Trade Project - Lesson 7 – Chapter 5 – System Requirements Specification (SRS)

Steps:

1. The customer inserts their ATM card into the ATM.

2. The customer enters their PIN.
3. The customer selects the "Withdraw cash" option.
4. The customer enters the amount of cash they want to withdraw.
5. The ATM confirms the amount and asks the customer to confirm.
6. The customer confirms the amount.
7. The ATM dispenses the cash.
Trade Project - Lesson 7 – Chapter 5 – System Requirements Specification (SRS)

Use case 2: Transfer money between accounts

Steps:
1. The customer logs into the online banking system.
2. The customer selects the "Transfer money" option.
3. The customer selects the source account and the destination account.
4. The customer enters the amount of money to be transferred.
5. The customer confirms the transfer.
6. The online banking system transfers the money from the source account to the destination
account.
Note:
• These are just two examples of use cases. The specific use cases will depend on the
specific system being developed.
• Each use case should be described clearly and concisely and should include the following
information:
▪ Actor: Who is using the system?
▪ Goal: What is the user trying to achieve?
▪ Preconditions: What conditions must be met before the use case can begin?
▪ Postconditions: What conditions will be met after the use case successfully
completes?
▪ Basic flow: The steps involved in the use case under normal conditions.
▪ Alternate flows: The steps involved in the use case if something goes wrong.
Trade Project - Lesson 7 – Chapter 5 – System Requirements Specification (SRS)

Example
Actor: Bank teller
Goal: To open a new bank account for a customer.
Preconditions: The customer has all required documentation, such as a government-issued ID
and proof of address.
Postconditions: The customer has a new bank account and receives a debit card.
Basic flow:
1 The customer approaches the bank teller and states that they would like to open a new bank
account.
2 The bank teller asks the customer for their documentation.
3 The bank teller verifies the customer's documentation and enters the customer's information
into the bank's computer system.
4 The bank teller creates a new bank account for the customer and prints a debit card for the
customer.
5 The bank teller reviews the account information with the customer and answers any
questions the customer may have.
6 The bank teller provides the customer with their new debit card and account information.
Alternate flows:
• If the customer does not have all of the required documentation, the bank teller will
inform the customer of what documentation is needed and will reschedule the
appointment for when the customer has all of the required documentation.
• If there is a problem creating the new bank account, the bank teller will inform the
customer of the problem and will work with the customer to resolve the problem. User
stories
User stories are short, informal descriptions of how a system will be used from the user's
perspective. They can be used to capture the system's functional requirements in a way that is
easy for users and developers to understand.
Trade Project - Lesson 7 – Chapter 5 – System Requirements Specification (SRS)

Examples one
• As a customer, I want to be able to withdraw cash from an ATM to access my money
when I need it.
• As a customer, I want to be able to transfer money between accounts so that I can quickly
move money between my checking and savings accounts.
• As a customer, I want to be able to pay bills online so that I can conveniently pay my bills
without having to write checks or mail them in. Examples two
• As a bank teller, I want to be able to open a new bank account for a customer so that the
customer can start using our banking services.
• As a bank teller, I want to be able to verify the customer's identity and proof of address to
ensure that the customer is who they say they are.
• As a bank teller, I want to be able to create a new bank account for the customer in our
computer system so that the customer can start using their account.
• As a bank teller, I want to be able to print a debit card for the customer so that the
customer can start using their account to make purchases and withdraw cash.
• As a bank teller, I want to be able to review the account information with the customer
and answer any questions they may have so that they are comfortable using their new
account.
Functional Requirements Specifications (FRSs)
FRSs are formal documents that describe the functional requirements of a system in detail. They
typically include descriptions of the system's inputs, outputs, and processing steps.
Authentication
• The system shall allow customers to reset their forgotten passwords.
• The system shall implement two-factor authentication to protect customer
accounts. Account management
• The system shall allow customers to open and close bank accounts.
• The system shall allow customers to apply for loans and credit cards.
• The system shall allow customers to set up and manage budgets.
Trade Project - Lesson 7 – Chapter 5 – System Requirements Specification (SRS)

System administration
• The system shall generate reports for system administrators on account activity,
transactions, and other system metrics
• The system shall be able to be integrated with other banking systems and services.
Note:
• FRSs are an essential tool for software development, as they help ensure that the system
is developed to meet the users' specific requirements. By writing FRSs, the developers
can better understand the system's requirements and how to design the system to meet
those requirements.
• FRS are specific and detailed, and they describe the specific function that the system
must be able to perform to meet the needs of the users.
• FRSs are more specific and detailed than the user stories, and they describe the specific
functions that the system must be able to perform to meet the needs of the users.
Recommendation
Write a minimum of five Functional Requirements Specifications (FRSs) for each system
module
Functional Decomposition Diagrams (FDDs)
FDDs show how a system's functionality can be broken down into smaller components. This can
help identify the individual functional requirements of the system and for understanding how
these requirements are related to each other.
Trade Project - Lesson 7 – Chapter 5 – System Requirements Specification (SRS)

Example one
FDD 1: Overall system
Describe or explain the following FDD Karen hospital management system
Trade Project - Lesson 7 – Chapter 5 – System Requirements Specification (SRS)
Trade Project - Lesson 7 – Chapter 5 – System Requirements Specification (SRS)

Explanation
The Karen hospital management system has five main modules, namely,
• Administration: This module is for registering hospital staff members, wards and assigning
user roles.

• Admissions: This module is for patient management, i.e. patient registration, patient admission,
patient discharge and viewing of patient reports.

• Pharmacy: This module is for drug inventory and sales management. It also allows the viewing
of pharmacy reports

• Billing: This module generates patient bills, i.e., admission and pharmacy bills. It allows the
view of financial reports.

• Reports: This module generates reports on various aspects of the hospital's operations,
such as patient visits, financial performance, and inventory levels.
Example two
Use FDDs to represent all major activities within individual system modules
FDD 2: Patient registration

Patient
registration

Verify the patient's Collect the patient's

Create a new patient
identity and proof contact information Bill patient
record in the system
of insurance and medical history

Assign the patient a Assign patient a

unique patient ID
doctor.
number

Steps
1. Verify the patient's identity and proof of insurance.
2. Collect the patient's contact information and medical history.
3. Create a new patient record in the system.
3.1 Assign the patient a unique patient ID number.
3.2 Assign patient statis, i.e. In patient
3.3 Assign patient a doctor.
4. Bill patient
10
Trade Project - Lesson 7 – Chapter 5 – System Requirements Specification (SRS)

Example three
FDD 3: Patient admission

Patient admission

Assign the patient Upadte patient staus Bill patient

A ward A bed A nurse A doctor

Steps:

1. Assign the patient.

1.1 A ward.
1.2 A bed.
1.3 A nurse
1.4 A doctor
2. Update patient status i.e. outpatient
3. Bill patient

Note:

• Draw FDDs for all your major system activities

• FDDs can decompose any functional requirement, regardless of complexity. By breaking
down complex functional requirements into smaller, more manageable tasks, FDDs can
help developers to understand the requirements better and to design the system to meet
those requirements.
Trade Project - Lesson 7 – Chapter 5 – System Requirements Specification (SRS)

Acceptance criteria
Acceptance criteria are specific conditions that must be met for a functional requirement to be
satisfied. They should be written clearly and unambiguously so that the development team and
the customer can agree on what the system must do.
Example
Patient admission
• The system shall be able to verify the patient's identity and proof of insurance within 10
minutes.
• The system shall be able to collect the patient's demographic information, medical
history, and insurance information within 15 minutes.
• The system shall be able to assign the patient to a room and bed within 30 minutes.
• The system shall be able to physically examine the patient and order any necessary
diagnostic tests within 60 minutes.
• The system shall be able to develop a treatment plan for the patient within 2 hours.
• The system shall be able to document the patient's admission in the patient's medical
record within 4 hours. Patient discharge
• The system shall be able to review the patient's medical record to ensure that all
necessary treatment has been completed within 1 hour.
• The system shall be able to provide the patient with discharge instructions, including
medications, follow-up appointments, and any other relevant information within 30
minutes.
• The system shall obtain the patient's signature on the discharge form within 15 minutes.
• The system shall be able to update the patient's medical record to reflect the discharge
within 10 minutes.
• The system shall be able to arrange for the patient's transportation home or to another
healthcare facility, if necessary, within 1 hour.

Patient registration:
Trade Project - Lesson 7 – Chapter 5 – System Requirements Specification (SRS)

• The system shall be able to verify the patient's identity and proof of insurance within 10
minutes.
• The system shall be able to collect the patient's demographic information, medical
history, and insurance information within 15 minutes.
• The system shall be able to create a new patient record within 20 minutes.
• The system shall be able to assign the patient a unique patient ID number within 25
minutes.
• The system shall be able to issue the patient a patient ID card within 30 minutes.
Note: These acceptance criteria are specific, measurable, achievable, relevant, and time-bound.
This makes them easy to understand and verify, and it helps ensure that the system meets the
users' needs.
Recommendation
Write a minimum of five acceptance criteria for each system module
Recommended tools or techniques to use
The best tool or technique to use will depend on the specific software system and the needs of
the audience. For example, if you are communicating the functional requirements to a technical
audience, you should use FRSs and FDDs. If you are communicating the functional requirements
to a non-technical audience, you may want to use use cases and user stories.
Since we cannot use all the techniques used to describe functional requirements, the following
combination of tools or techniques is recommended for use in your project either
• Uses cases and Functional Requirements Specifications (FRSs)
• Functional Decomposition Diagrams (FDDs) and Functional Requirements Specifications
(FRSs).
• Uses cases and Acceptance criteria
• Functional Decomposition Diagrams (FDDs and Acceptance criteria

Non-functional requirements
This section describes the system's non-functional requirements, i.e., how the system should
perform. Non-functional requirements are not directly related to the system's functionality, but
Trade Project - Lesson 7 – Chapter 5 – System Requirements Specification (SRS)

they are important for ensuring that the system meets the needs of the users and stakeholders.
Non-functional requirements may include performance, security, usability, and scalability
requirements. Some common non-functional requirements include:
• Performance: How fast should the system respond to user requests? How many users
should the system be able to support simultaneously?
• Security: How should the system protect user data and system resources from
unauthorised access?
• Reliability: How often should the system be available? How quickly should the system
be recovered from failures?
• Maintainability: How easy should modifying and maintaining the system be?
• Scalability: How easily should the system scale up or down in response to changes in
demand?
• Usability: How easy should it be for users to learn and use the system? Example one
• The system shall be accessible to users with disabilities.
• The system shall be available in multiple languages.
• The system shall be compliant with all applicable financial regulations.
• The system shall be scalable to handle increased load as the business grows.
• The system shall be interoperable with other healthcare systems and services.
• The system shall be reliable and secure, with appropriate safeguards in place to protect
patient data and privacy.
• The system shall be easy to use and learn, with a user-friendly interface and clear
documentation.
• The system shall be customizable to meet the specific needs of the hospital and its
patients.
• The system shall be affordable and cost-effective to implement and maintain.
Example two
• Performance: The system shall be able to process patient data in less than 1 second. The
system shall be able to handle up to 100,000 concurrent users.
• Reliability: The system shall be available 24/7. The system shall be able to recover from
a system failure within 1 hour.
• Security: The system shall protect patient data from unauthorised access. The system
shall be compliant with all applicable healthcare privacy regulations.
Trade Project - Lesson 7 – Chapter 5 – System Requirements Specification (SRS)

• Scalability: The system shall be able to scale to handle increased load as the hospital
grows.
• Maintainability: The system shall be easy to maintain and update. The system shall be
well-documented and easy to understand.
• Usability: The system shall be easy to use for all users, including clinicians, nurses,
administrative staff, and patients. The system shall be available in multiple languages and
accessible to users with disabilities.
Example three
Non-functional requirement Description
Performance The system shall be able to process 100 transactions per second.
The system shall protect user data and system resources from
Security unauthorized access.
Reliability The system shall be available 99.9% of the time.
The system shall be able to be modified and maintained with
Maintainability minimal effort.
The system shall be able to scale up or down in response to changes
Scalability in demand.
Usability The system shall be easy for users to learn and use.
Example four
The following are some specific examples of how these non-functional requirements could be
implemented:
• Interoperability: The system could use standard data formats and protocols to
communicate with other healthcare systems and services, such as electronic health
records (EHRs) and laboratory information systems (LISs). This would allow the system
to share information with other systems seamlessly, improving efficiency and patient
care.
• Reliability and security: The system could be hosted on a redundant server
infrastructure to ensure it is always available and accessible. The system could also use
encryption and other security measures to protect patient data and privacy.
• Usability: The system could have a user-friendly interface with clear navigation and
instructions. The system could also be available in multiple languages and accessible to
users with disabilities.
Trade Project - Lesson 7 – Chapter 5 – System Requirements Specification (SRS)

• Customizability: The system could be configured to meet the hospital's specific needs.
For example, the system could be customized to include different types of patient data,
clinical workflows, and reporting features.
• Affordability: To reduce costs, the system could be implemented and maintained using
open-source software and cloud computing technologies.
Recommendations
The best option is to write non-functional requirements specific to the system under
development, as demonstrated in example four. As demonstrated by examples 1.2 and 3, other
formats are also ok.
External Interface Requirements
This section describes the system's external interfaces, i.e., how the system will interact with
other systems and devices.
Example one
Online banking system:
• The system shall be able to communicate with the Automated Clearing House (ACH) to
process direct deposits and withdrawals.
• The system shall be able to communicate with credit card networks to process credit and
debit card transactions.
• The system shall be able to communicate with other financial institutions to process wire
transfers and other types of transactions.
• The system shall be able to communicate with government agencies to report income and
other financial information.

Example two
Hospital management system:
• The system shall be able to communicate with electronic health record (EHR) systems to
exchange patient data.
• The system shall be able to communicate with laboratory information systems (LISs) to
exchange lab results.
• The system shall be able to communicate with insurance companies to process claims.
Trade Project - Lesson 7 – Chapter 5 – System Requirements Specification (SRS)

• The system shall be able to communicate with pharmacies to dispense medications.

• The system shall be able to communicate with government agencies to report public
health data.
Note: External interface requirements are important because they help ensure that the system can
communicate and exchange data with other systems it needs to interact with. By writing clear
and concise external interface requirements, the developers and users can agree on how the
system will communicate with other systems. This can help to avoid misunderstandings and
disputes later in the development process.
Recommendations
Write at least five External Interface Requirements for each system module.
Assumptions and Dependencies
This section describes any assumptions and constraints that apply to the system.
Example one
The following assumptions and Dependencies were made during the development of the system
Online banking system:
Assumptions:
• The customer has a valid bank account and a valid username and password.
• The customer has a reliable internet connection.
• The bank's servers are up and running.
Dependencies:
• The online banking system depends on the bank's core banking system to process
transactions.
• The online banking system depends on the bank's security systems to protect customer
data.
Example two
The following assumptions and Dependencies were made during the development of the system.
Hospital management system:
Assumptions:
• The patient has a valid medical record number.
• The healthcare provider has a valid username and password.
• The hospital's network is up and running.
Dependencies:
Trade Project - Lesson 7 – Chapter 5 – System Requirements Specification (SRS)

• The hospital management system depends on the hospital's electronic health record
(EHR) system to store and retrieve patient data.
• The hospital management system depends on the hospital's laboratory information system
(LIS) to receive and store lab results.
Note: Assumptions and dependencies are important because they help identify the factors
necessary for the system to function properly. The developers and users can identify and mitigate
potential risks by carefully considering all assumptions and dependencies.
Glossary
This section defines any terms or acronyms used in the SRS document.
Example one
Online banking system:
• Account balance: The amount of money in a customer's bank account.
• ATM (automated teller machine): A self-service machine that allows customers to
withdraw cash, deposit checks, and perform other banking transactions without visiting a
bank branch.
• Bill pay: A service that allows customers to pay their bills online
• Debit card: A plastic card that allows customers to withdraw cash from ATMs and make
purchases at merchants without having to write a check.
• Direct deposit: A service that allows customers to have their paycheck or other recurring
payments deposited directly into their bank account.
• Electronic funds transfer (EFT): A method of transferring money electronically
between two bank accounts.
• Online banking: A service allowing customers to access their bank accounts and perform
banking transactions online.
• Overdraft: A situation in which a customer withdraws more money from their bank
account than they have available.
• PIN (personal identification number): A secret code that customers use to verify their
identity when using an ATM or debit card.
• Routing number: A nine-digit number identifying a bank or financial institution.
• Savings account: A type of bank account designed to help customers save money.
• Wire transfer: A method of transferring money electronically between two bank
accounts quickly and securely.
Trade Project - Lesson 7 – Chapter 5 – System Requirements Specification (SRS)

Example two
Hospital management system:
• Admission: The process of admitting a patient to a hospital.
• Discharge: The process of releasing a patient from a hospital.
• Electronic health record (EHR): A digital version of a patient's medical record.
• Hospital information system (HIS): Hospitals use software to manage patient data,
billing, and other administrative functions.
• Laboratory information system (LIS): Hospitals use software to manage laboratory
data and processes.
• Medical record: A patient's medical history, including symptoms, diagnosis, treatment,
and medications.
• Nurse: A healthcare professional who provides care to patients under the supervision of a
physician.
• Order: A request from a physician for a test, treatment, or medication for a patient.
• Patient: A person who is receiving medical care in a hospital.
• Physician: A licensed medical doctor who provides medical care to patients.
• Prescription: A written order from a physician for a medication or other treatment.
• Procedure: A medical or surgical operation.
• Treatment: The medical care that a patient receives.

Note:
• Glossaries are important because they help to ensure that everyone involved in the
development and use of the system has a common understanding of the terminology used.
The developers and users can avoid misunderstandings and confusion by creating a
glossary.
• When creating a glossary, it is important to include all of the terms used in the system and
any acronyms or abbreviations. It is also important to provide clear and concise
definitions for each term. References
• IEEE Standard 830-1998: Recommended Practice for Software Requirements
Specification
• Karl Wiegers and Joy Beatty. A Practical Guide to Requirements Engineering
• Chris Britton and Peter Jackson Requirements Analysis: A Practitioner's Guide
• Alistair Cockburn Writing Effective Use Cases
Trade Project - Lesson 7 – Chapter 5 – System Requirements Specification (SRS)

• Stephen R. Palmer and Donald L. Furey The Art of Modeling Requirements: Essential
Modeling Techniques for Software Development.