Requirement
Specification
Introduction
• Requirement Specification is a critical phase in software engineering
that documents the desired functionalities and constraints of a system.
It acts as a bridge between stakeholders and developers, ensuring
that the final product aligns with user expectations and business goals.
• Purpose:
• To define what the system should do (functional requirements).
• To specify conditions under which the system must operate (non-functional
requirements).
• To ensure mutual understanding among all stakeholders, including business
analysts, developers, and end-users.
• Key Outcomes:
• Clarity in requirements.
• A baseline for design, development, and testing.
• Reduced risk of project failure due to unclear or incomplete requirements.
Importance of Requirement
Specification
• Avoids Miscommunication: Provides a common
language for stakeholders and developers.
• Guides Development: Serves as a blueprint for
designing and building the system.
• Facilitates Testing: Enables creation of test cases to
verify the system meets requirements.
• Improves Project Management: Helps in estimating
time, resources, and cost.
• Legal Protection: Acts as a reference in case of
disputes over project deliverables.
Key Characteristics of a High-Quality
Requirement Specification
• A good requirement specification should have the
following attributes:
Characteristic Explanation
Covers all aspects of the system, leaving no functionality
Complete
unaddressed.
Unambiguous Clear and precise; every stakeholder interprets it the same way.
Consistent Free from contradictions between requirements.
Verifiable Can be validated through testing or inspection.
Modifiable Easy to update as project needs evolve.
Can link each requirement to its origin and to design, code, and
Traceable
tests.
Components of a Requirement
Specification Document
• A Requirement Specification typically includes the following sections:
• 1. Introduction:
• Purpose: States the objectives of the project and the reason for developing
the system.
• Scope: Describes the boundaries of the system, what it will and won’t do.
• Definitions: Includes terms, acronyms, and abbreviations to ensure clarity.
• 2. Overall Description:
• System Perspective: Explains how the system fits within its environment.
• System Functions: Lists the major features of the system at a high level.
• User Characteristics: Describes the end-users, their skills, and how they
will interact with the system.
• Assumptions and Dependencies: Notes any assumptions made and
external factors that could affect the system.
Components of a Requirement
Specification Document
• 3. Functional Requirements:
• These define the specific behaviours and functions of the system.
• Example: “The system shall allow users to reset their passwords via email.”
• 4. Non-Functional Requirements:
• These specify system attributes such as performance, security, and usability.
• Example: “The system shall handle 10,000 concurrent users with a response time of less than 2
seconds.”
• 5. External Interfaces:
• Describes how the system will interact with users, hardware, and other systems.
• 6. Constraints:
• Includes limitations like budget, timeline, regulatory compliance, and technical
constraints.
• 7. Use Cases or Scenarios:
• Provides detailed descriptions of user interactions with the system through Use
Case Diagrams or narratives.
Challenges in Requirement
Specification
• Incomplete Requirements: Missing important details.
• Changing Requirements: Frequent updates due to
evolving user needs.
• Ambiguity: Vague or unclear descriptions leading to
misinterpretation.
• Stakeholder Conflicts: Different stakeholders may
have conflicting expectations.
Requirement Specification vs.
Requirement Analysis
Aspect Requirement Analysis Requirement Specification
Gathering and understanding Documenting those needs in a clear
Purpose
user needs. and structured form.
Initial ideas and insights about A detailed requirement document
Output
system requirements. (BRS, SRS, etc.).
Workshops, interviews, and Writing, structuring, and reviewing
Involves
brainstorming sessions. requirements.
Best Practices for Requirement
Specification
• Collaborate Early: Engage stakeholders, end-users, and
developers from the start.
• Use Standardized Templates: Ensures consistency across
projects.
• Validate Requirements: Regular reviews to confirm
alignment with business goals.
• Focus on Clarity: Avoid jargon and ensure all terms are
well-defined.
• Visualize with Models: Use diagrams like Use Case
Diagrams, Data Flow Diagrams (DFDs), and State Diagrams
to complement textual requirements.
Requirement Modelling
• Visual representation of requirements.
• Common Models:
• Use Case Diagrams: Show interactions between users and the
system.
• Data Flow Diagrams: Represent data processing and flow.
• State Diagrams: Describe the states and transitions of the
system.
Use case Diagram
• A Use Case Diagram is a type of Unified Modelling
Language (UML) diagram that represents the functional
requirements of a system. It shows the interactions
between actors (users or external systems) and the
system itself.
• Purpose:
• Visualize the functional aspects of a system.
• Identify the roles (actors) and their interactions with the
system.
• Serve as a guide for system development and validation.
Components of a Use Case Diagram
• Actors:
• Entities (people, devices, or systems) that interact with the
system.
• Types:
• Primary Actor: Directly benefits from the system.
• Secondary Actor: Supports or is used by the system.
• Represented by a stick figure.
• Use Cases:
• Specific functionalities or goals the system must achieve.
• Represented by ovals (ellipses).
• Example: Login, Search Product, Generate Report.
Use Case Diagram
State Diagrams
• A State Diagram (also called a state machine diagram)
is a type of UML diagram that models the dynamic
behavior of an object by illustrating its states and
transitions.
• Purpose:
• Visualize how an object transitions between states in response
to events.
• Represent lifecycle behaviour of an object or system
component.
• Useful for designing and understanding complex system
behaviours.
State Diagrams
• States:
• Represents a condition or situation during the lifecycle of an object.
• Types:
• Initial State: The starting point (denoted by a filled black circle).
• Final State: The ending point (denoted by a circle with a black dot inside).
• Intermediate States: Other states the object can be in.
• Notation: Rounded rectangle.
• Transitions:
• Represents the movement from one state to another triggered by events or conditions.
• Notation: Arrow between states, optionally labelled with event/condition.
• Events:
• External or internal occurrences that trigger a transition.
• Example: Button click, timeout, or data received.
• Actions:
• Activities performed during the transition or in a state.
• Example: "Send email," "Display error."
State Diagrams of a Microwave
Oven
Table Representation of
Requirements
• Using a table format to represent requirements is a
widely used approach in requirement specification
because it provides a clear, structured, and easy-to-read
view of what the system needs to achieve. Here's a
breakdown
Column Name of each Explanation
component in the table:
Example
A unique identifier assigned to each FR-001: A unique code where "FR" stands
Requirement ID requirement to simplify tracking and for Functional Requirement, and "001" is
referencing. the sequence number.
A concise and precise statement of what "The system shall allow users to log in
Requirement Description
the system should do or provide. with valid credentials."
Indicates the importance or urgency of the
High: Essential for the system to function;
Priority requirement. Typically categorized as
must be implemented.
High, Medium, or Low.
Specifies if the requirement depends on FR-002 depends on FR-001: Users need to
Dependency another requirement being completed register an account (FR-001) before
first. logging in (FR-002).
"Login functionality test" involves entering
Describes how the requirement will be
Verification Method valid credentials to confirm the login
tested to ensure it works as intended.
feature works.
Key Advantages of Using a Table
• Clarity: The table format organizes information in a structured
manner, making it easier to understand each requirement.
• Traceability: Requirement IDs allow for easy tracking of requirements
throughout the project lifecycle, especially during design,
implementation, and testing.
• Prioritization: The Priority column helps development teams focus
on the most critical requirements first.
• Dependency Management: The Dependency column highlights
relationships between requirements, helping in planning the order of
implementation.
• Verification Readiness: Including a Verification Method ensures
each requirement can be tested, aiding in quality assurance and
validation.
Use Case Example
• Imagine an e-commerce system where requirements are
listed in a table. For instance:
• FR-001: User account creation is a high-priority feature with no
dependency.
• FR-002: User login is also high-priority but depends on account
creation (FR-001).
• FR-005: Payment processing is critical and depends on integrating
APIs, which may delay testing until the integration is done.
• The table format ensures that:
• Developers know the order in which to implement features.
• Testers can create test cases based on Verification Methods.
• Stakeholders can easily review and understand the requirements.
Table Representation for Functional
Requirements
Requirement ID Requirement Description Priority Dependency Verification Method
FR-001 The system shall allow users High None User registration testing
to register using their email
address.
FR-002 The system shall allow users High FR-001 Login functionality test
to log in with valid credentials.
FR-003 The system shall allow users Medium Database setup Search operation testing
to search for items by
keywords.
FR-004 The system shall allow users High FR-003 Cart operation testing
to add selected items to a
shopping cart.
FR-005 The system shall process High Payment API integration Payment functionality testing
payments using PayPal and
Stripe.
Table Representation for Non-
Functional Requirements
Requirement ID Requirement Priority Category Verification Method
Description
The system shall handle up High Performance Load testing
to 500 concurrent users.
NFR-001
The system shall respond Medium Performance Response time
to user actions within 2 measurement
NFR-002 seconds.
The system shall comply High Compliance Audit against GDPR
with GDPR regulations for guidelines
data protection.
NFR-003
The system shall have High Reliability Monitoring and uptime
99.9% uptime availability. reports
NFR-004
The system shall have an Medium Usability Usability testing and
intuitive and user-friendly surveys
NFR-005 interface.
Recap
• Functional Requirements describe what the system
should do (features or functionalities).
• Non-Functional Requirements describe how the
system performs those functions (quality, performance,
compliance, etc.).
• Associating use cases with requirements ensures
traceability from the design phase to implementation
and testing.
