Advanced to

Software Engineering
 Software Engineering

Requirement engineering
 Topics Covered
 Requirement Engineering
 The software requirements document
 Requirements specification
 Requirements engineering processes
 Requirements elicitation and analysis
 Requirements validation
 Requirements management

3
 What is Requirement Engineering?
Requirements is the description of the system, its used to define what a
system should do and how it should perform, which reflects the needs of
customers

Requirement Engineering (RE) is the systematic process of defining,

documenting, and managing the requirements for a system throughout its
lifecycle. It ensures that the final product meets the stakeholders' needs
and expectations.

There are different types of requirements, including:

■ System Requirement
■ Business Requirements
■ User Requirements
4
 Cont…
System requirements are a detailed description of the functionalities, features, and
attributes that a system must have in order to meet the needs of its users and stakeholders.
SRs are typically divided into 2: functional and non-functional requirements.

Functional Requirements: defines the behavior, features, components, or functions that the
system must perform. It focuses on how the system should react to specific inputs and
behave in particular situations.
Non-Functional Requirements: It defines the system's quality, like performance, security,
usability, scalability, and standards.
Business requirements: it describe the level needs of the organization or stakeholders,
often focusing on goals and objectives.
User Requirements: it defines what the end-users expect from the system.
Can users be able to change something easil?.
 Cont….
functional requirements include:

 Specifications of what the system must do.

 Business rules that must be met.
 Steps that the system must take in authentication.
 Details of what must be tracked in the system.
 The reporting requirements of the system.
 Outlines the levels of user and their authorization.
 Details of how transactions must occur.
 The external interfaces of the system.
Non-functional Requirements including

7
 Importance of System Requirements
■ Clear Vision: They provide a shared understanding of the system's
functionality and performance across the development team and
stakeholders.
■ Scope Control: Well-defined requirements help control project scope and
prevent scope creep.
■ Testing and Validation: They serve as a basis for system testing and
validation to ensure the system works as expected.
■ Efficient Development: They help developers understand what features
to build, in what order, and how to design the system's architecture.
 Challenges in Defining System Requirements
■ Ambiguity: Requirements may be vague or unclear, leading to
misinterpretation.
■ Changing Requirements: As the project progresses, new needs or
constraints may arise, requiring frequent updates to the requirements.
■ Conflicting Requirements: Different stakeholders may have conflicting
needs, making it difficult to prioritize or resolve certain requirements.
■ Complexity: Large systems may have interdependent requirements,
increasing the complexity of managing and implementing them.
 Software Requirements Document
SRD is an official document that outlines the complete set of functional and
non-functional requirements for a software system.

it serves as a key reference or guide for developers, testers, project

managers, and stakeholders to ensure that the system meets user
expectations and business needs.

If there are a large number of requirements, the detailed system

requirements may be presented in a separate document.
Requirements documents are essential when an outside contractor is
developing the software system.

it is typically prepared during the early stages of a project, after the

requirement elicitation and analysis. 10
Ways of Writing a System Requirements Specification

11
 Problems with Natural Language
Lack of Clarity
Precision is difficult without making the document difficult to read.

Requirements Confusion
Functional and non-functional requirements tend to be mixed up.

Requirements Amalgamation
Several different requirements may be expressed together.
 Structured natural Language
Structured natural language is a way of writing system requirements where
the freedom of the requirements writer is limited and all requirements are
written in a standard way.

Structured language notations use templates to specify system requirements.

The specification may use programming language constructs to show
alternatives and iteration, and may highlight key elements using shading or
different fonts.

to use a structured approach to specifying system requirements, you define

one or more standard templates for requirements and represent these
templates as structured forms.
 Key Phases in Requirement Engineering Process
■ Requirements Elicitation
■ Requirements Analysis
■ Requirements Specification
■ Requirements Validation
■ Requirements Management.
 Requirements Elicitation
Requirements Elicitation (Requirements discovery) is the process of
gathering, identifying, and understanding the needs of required or existing
systems from the stakeholders to clarify system requirements.
Key Steps in Requirements Elicitation
1.. Identifying Stakeholders
2. Gathering Information
3. Gathering Information
4. Understanding the Problem Domain
5. Documenting Requirements
6. Validating Requirements
 Techniques for Requirements Elicitation
 Interviews (Structured Interviews and Unstructured Interviews
 Surveys and Questionnaires
 Workshops
 Focus Groups
 Observation
 Document Analysis
 Prototyping
 Use Case Modeling
 Brainstorming
 Cont…
During the elicitation process, details are added to create a complete
description of that interaction.
The general scenario may include:
1. A description of what users expect when the scenario starts.
2. A description of the normal flow of events in the scenario.
3. A description of what can go wrong and how it is handled.
4. Information about other activities that might be going on at the same
time.
5. A description of the system state when the scenario finishes
 Requirements Analysis
Requirements Analysis is a critical part of the SDLC following
requirements elicitation. Its primary purpose is to analyze, refine, and
prioritize the gathered requirements to ensure are they clear, complete, and
aligned with stakeholder expectations.

■ Key Steps in Requirements Analysis

1. Requirements Categorization
2. Gap Analysis
3. Conflict Resolution
4. Prototyping and Simulation
5. Impact Analysis
 Problems of Requirements Analysis
Eliciting and understanding requirements from system stakeholders is a
difficult process for several reasons:

 Stakeholders don’t know what they want.

 Stakeholders express requirements in their own terms.
 Different stakeholders may have conflicting requirements.
 Organizational and political factors may influence the system requirements.
 The requirements change during the analysis process.
 New stakeholders may emerge and the business environment may change.

19
 Common Techniques Used in Requirements
Analysis
■ Use Case Diagrams: Visualize user interactions with the system, helping
to define functional requirements.
■ Data Flow Diagrams (DFD): Map out the flow of data within the system
to understand processes and relationships.
■ Entity-Relationship Diagrams (ERD): Model the data relationships and
structures that will be needed for the system.
■ Storyboarding and Wireframes: Create visual representations of how the
system will look and function, used to clarify requirements.
■ SWOT Analysis: Identify strengths, weaknesses, opportunities, and threats
to better understand project challenges.
 Requirements Specification
Requirements specification is the process of writing down the user and
system requirements in a requirements document.

■ The user and system requirements should be clear, unambiguous, easy

to understand, complete, and consistent.

■ if you are writing user requirements, you should not use software
jargon, structured notations, or formal notations. You should write user
requirements in natural language, with simple tables, forms, and
diagrams.

21
 Key Components of the SRS

Introduction: Purpose, scope, and system overview

•Functional Requirements: What the system should do

•Non-Functional Requirements: Performance, security, usability, etc.

•System Interfaces: How the system interacts with other systems

•Constraints: Legal, technical, or operational limitations

•Traceability Matrix: Links requirements to design and testing

 Requirements validation
Requirements validation is the process of ensuring that the documented
requirements accurately represent the stakeholders' needs.
Requirements validation is important because errors in a requirements
document can lead to extensive rework costs when these problems are
discovered during development or after the system is in service.

There are different types of checks which including:

1. Validity checks: A user may think that a system is needed to perform
certain functions. further analysis may identify additional or different
functions that are required.
 Cont…
1. Consistency checks: Requirements in the document should not conflict.
That is, there should not be contradictory constraints or different
descriptions of the same system function.

2. Completeness checks The requirements document should include

requirements that define all functions and the constraints intended by the
system user.

3. Realism checks: Using knowledge of existing technology, the requirements

should be checked to ensure that they can actually be implemented.

4. Verifiability: To reduce the potential for dispute between customer and

contractor, system requirements should always be written so that they are
 Managing Requirements
Managing Requirements: is the process of understanding and controlling
changes to system requirements.

You need to keep track of individual requirements and maintain links

between dependent requirements so that you can assess the impact of
requirements changes.

You need to establish a formal process for making change proposals and
linking these to system requirements.
 Requirements Management Planning
During the requirements management stage, you have to decide on:
1. Requirements identification: Each requirement must be uniquely
identified.
2. A change management process: This is the set of activities that assess
the impact and cost of changes.
3. Traceability policies: These policies define the relationships between each
requirement and between the requirements and the system design that
should be recorded.
The traceability policy should also define how these records should be
maintained.
4. Tool support: Requirements management involves the processing of large
amounts of information about the requirements.
 Requirements Change Management
Requirements change management should be applied to all proposed
changes to a system’s requirements after the requirements document has
been approved.
There are three principal stages to a change management process:
1. Problem analysis and change specification: the process starts with an
identified requirements problem to check that it is valid.
2. Change analysis and costing: The effect of the proposed change
should assessed using traceability information and general knowledge
of the system requirements.
3. Change implementation: The requirements document should be
follow to modified the system.
 Chapter Assessment
By considering what we learn in this chapter, Write Software requirements
document that is based on the Hospital/ Banking/ Army systems or any
other that you prefer.

Standard Formats for Writing a System Requirements Specification (SRS)

IEEE 830-1998 (Recommended Practice for SRS
ISO/IEC/IEEE 29148:2011 (Systems and Software Engineering - Life Cycle Processes - Requirements
Engineering)