Supervisor: Griffin Kenga
Email: kenga@[Link]
Tel: +254-724584694
• This is the fourth milestone of your project.
• This document describes what the system will do.
• It consists of a set of precisely stated properties and constraints which the product must satisfy.
• What is SRS?
• A document that describes the functional and non-functional requirements of a software application.
It provides a formal guide and reference point throughout the development process to ensure that the
system being built meets user needs, business goals, and technical constraints.
Advancing Knowledge, Driving Change | [Link]
Griffin Kenga 10/17/20
24
• The cover page:
Include the name for the document e.g. System Requirement Specifications for XYZ (XYZ is the name of your
product).
Include your name, regno, course title and course code, supervisor and date submitted.
• The table of contents:
This section helps readers to quickly navigate your document.
It must be auto-generate.
4.1. Introduction:
4.1.1. Purpose: Defines the reason for the SRS and what the system should accomplish.
4.1.2. Scope: Describes the system's boundaries, including what the system will and won’t do.
4.1.3. Acronyms: Lists key terms and acronyms used in the document.
[Link] Description:
4.2.1. System perspective: Describe how the product will fit into the existing environment? Will it be a stand
alone or it will be integrated with some other existing system? You may need a block diagram to support
this description.
4.2.2. System environment: Describes the hardware, software and network environments where the
application will operate.
4.2.3. User Characteristics: Identifies the target users and their experience and skills.
4.2.4. Constraints: Outlines any limitations on the design or implementation, such as regulatory or hardware
constraints.
Advancing Knowledge, Driving Change | [Link]
Griffin Kenga 10/17/20
24
4.3. Functional requirements
• This is the most import section of the SRS.
• For each requirement, provide the input, process and output.
• Functional requirements describe what the system will do
Example: The system shall authenticate users before they can access the system.
Input: Get userid and user name
Process: Check if userid and user name match those in the database
Output: Load the system the userid and user name exist otherwise display error message.
Remark: I believe your system will have several functional requirements. Be sure to describe each
FR(functional requirement) clearly.
NB: Some the tools you can use in this section include Use case diagram. Do not copy paste
diagrams
Advancing Knowledge, Driving Change | [Link]
Griffin Kenga 10/17/20
24
4.4. Non function requirements
• These requirements describe the quality attributes of the product.
• May include reliability, scalability, security, portability etc.
Performance: How fast or efficient the system needs to be.
Security: Authentication, data protection, and privacy requirements.
Usability: Ease with which the user can learn and use the application
Scalability: How the system should handle growth.
Reliability: Uptime and fault tolerance.
Portability: Ease with which the solution can be transferred from one operating
environment to another
Availability: The extend to which the system will be available when needed e.g. 24/7
Advancing Knowledge, Driving Change | [Link]
Griffin Kenga 10/17/20
24
4.6. External requirements
These are conditions that the application must meet due to factors outside of the system
itself. These requirements can come from regulatory bodies, client specifications,
integration with other systems, and environmental considerations.
4.6.1. User interfaces- Describe which user, the screens they will use, what type of inputs
expected.
4.6.2. Software interfaces- Describe Interface between application and other components like
OS.
4.6.3. Hardware Interfaces: Specifies any hardware components the system needs to
interface with.
References:
Give references accessed.
Advancing Knowledge, Driving Change | [Link]
Griffin Kenga 10/17/20
24