Software Requirements

Engineering

06/09/2025 By Abel A. 1
 CHAPTER 1
BASICS OF SOFTWARE
REQUIREMENTS ENGINEERING

06/09/2025 2
 Introduction

• The development of computer based systems has been facing

problems like
• Late delivery
• Over budget
• They don’t do what the users really want and
• They are often never used to their full effectiveness by the people who have
paid for them.

06/09/2025 3
• The most common reasons for project failures are not technical and
Table 1.1 identifies the main reasons why projects fail.
• The data is drawn from surveys conducted by the Standish Group in
1995 and 1996, and shows the percentage of projects that stated
various reasons for project failure.
• The problems fall into three main categories:
Requirements – either poorly organized, poorly expressed, weakly
related to stakeholders, changing too rapidly, or unnecessary;
unrealistic expectations
Management problems of resources – failure to have enough
money, and lack of support, or failure to impose proper discipline
and planning, many of these arise from poor requirements control
Politics – which contributes to the first two problems
06/09/2025 4
06/09/2025 5
06/09/2025 6
• Because there are so many different types of requirements, it isn’t
possible to describe a standard way of writing requirements or to
define the ‘best’ way to specify requirements.
• It depends on
• who is writing the requirements,
• who is likely to read them,
• the general practices of the organization developing the requirements, and
• the application domain of the system.

06/09/2025 7
• The problem of writing requirements are universal and there is no
complete solution for these problems.
• But Good Requirements engineering practices can reduce the
number of problems and minimize their impact on the final system.

06/09/2025 8
 Requirements Definition
• Requirements are

• description of the services provided by the system and its operational

constraints reflecting needs of the customer that helps to solve their
problem.

• condition or a capability possessed by software or system component

in order to solve a real world problem.

• a statement that identifies a product or process operational, functional,

or design characteristic or constraint, which is unambiguous, testable
or measurable, and necessary for product or process acceptability (by
consumers or internal quality assurance guidelines).
06/09/2025 9
• IEEE definition

• (1) A condition or capability needed by a user to solve a problem or

achieve an objective.
• (2) A condition or capability that must be met or possessed by a
system or system component to satisfy a contract, standard,
specification, or other formally imposed documents.

06/09/2025 10
 Requirements Engineering

• Requirements Engineering
• is the process of finding out, analyzing, documenting and checking
services and operational constraints called requirements for a
computer based system.

• Requirements Engineering phase is the first software engineering

activity, which translates the ideas or views into a requirements
document.

06/09/2025 11
Requirements Engineering Vs Systems Engineering

• Requirements Engineering the subset of systems engineering

concerned with discovering, developing, tracing, analyzing, qualifying,
communicating and managing requirements that define the system at
successive levels of abstraction.

• Systems engineering is concerned with systems as a whole including

hardware, software and operational processes.

06/09/2025 12
The Systems Engineering Process

System System
requir ements validation
engineering

Architectural System
design integration

Requirements Sub-system
partitioning development

Software
requirements
engineering

06/09/2025 13
System Engineering Activities
• System requirements engineering
• The requirements for the system as a whole are established and written to be
understandable to all stakeholders
• Architectural design
• The system is decomposed into sub-systems
• Requirements partitioning
• Requirements are allocated to these sub-systems
• Software requirements engineering
• More detailed system requirements are derived for the system software
• Sub-system development
• The hardware and software sub-systems are designed and implemented in parallel.
• System integration
• The hardware and software sub-systems are put together to make up the system.
• System validation
• The system is validated against its requirements.
06/09/2025 14
 Summary

• What are requirements?

• A statement of a system service or constraint
• What is requirements engineering?
• The processes involved in developing system requirements
• How much does requirements engineering cost?
• About 15% of system development costs
• What happens when the requirements are wrong?
• Systems are late, costly, unreliable and don’t meet customers needs
• Is there an ideal requirements engineering process?
• No - processes must be tailored to organisational needs

06/09/2025 15
 Types of Requirements

06/09/2025 16
• Requirements commonly considered are classified into two
categories

1. Functional requirements
2. Nonfunctional requirements

06/09/2025 17
1. Functional Requirements
(Behavioral requirements)

• Describe
The functionality or services that software should provide.

The interaction of software with its environment

Functions that should and should not be included in the software.

06/09/2025 18
• IEEE definition
 “a function that a system or component must be able to
perform.”
Should be complete and consistent.
 Completeness
 all the Functional requirements should defined.
 Consistency
all the Functional requirements should be specified clearly without any
contradictory definition.

06/09/2025 19
2. Non-functional Requirements
(Quality Attributes)
• Related to system attributes, such as reliability and response time
which makes the software to perform efficiently.
• Are not directly related to functions provided by the system

• Arise due to
User requirements

Budget constraints

Organizational policies

06/09/2025 20
 Classifications of NFR

06/09/2025 21
06/09/2025 22
1. Product requirements
• Specify how software product performs.
• comprises
• Efficiency requirements
• the extent of optimal use of resources
• the speed with which system executes and
• the memory consumptions for its operation.
• E.g. The system should be able to operate at least three times
faster than the existing system.

06/09/2025 23
 • Reliability requirements
• acceptable failure rate of the software.
• E.g. The software should be able to operate even if a hazard occurs.
• Portability requirements
• the ease with which software can be transferred
from one platform to another.
• E.g. It should be easy to port software to different operating system without
the need to redesign the entire software.
• Usability requirements:
• the ease with which users are able to learn to operate the
software.
• E.g. The software should be able to provide access to functionality with fewer
keystrokes and mouse clicks.

06/09/2025 24
2. Organizational requirements

• Derived from the policies and procedures of an organization.

• comprise of the following

• Delivery requirements
• Specify when software and its documentation are to be delivered to the user

• Implementation requirements
• Describe requirements, such as programming language and design method.

• Standards requirements:
• the process standards to be used during software development.

• E.g. The software should be developed using standards specified by ISO (International Organization
for Standardization) and IEEE standards.
06/09/2025 25
3. External requirements:
• include all the requirements that affect the software or its development
process externally.
• comprise of the following
• Interoperability requirements
• Define the way in which different computer-based systems interact with each other in one or
more organizations.
• Ethical requirements:
• Specify the rules and regulations of the software so that they are acceptable to users.
• Legislative requirements:
• Ensure that software operates within the legal jurisdiction.
• E.g. Web pages developed for the federal government must comply with the law for equality
of treatment of people with disabilities (obstacle free Internet, from 1/1/2006)

06/09/2025 26
Non-functional requirements examples
• Product requirement
• The user interface for LIBSYS shall be implemented as simple HTML without
frames or Java applets.
• Organizational requirement
• The system development process and deliverable documents shall conform to
the process and deliverables defined in XYZCo.
• External requirement
• The system shall not disclose any personal information about customers apart
from their name and reference number to the operators of the system.

06/09/2025 27
• Some of NFR metrics used to verify and test requirements written
quantitatively are:

06/09/2025 28
06/09/2025 29
Requirements for Critical Systems
• Critical systems
Systems whose ‘failure’ causes significant economic, physical or human damage
to organizations or people.
There are three principal types of critical system:
 ‹Business critical systems
- Failure of the system leads to significant economic damage to business
 Mission critical systems
- Failure leads to the abortion of a mission
 ‹Safety critical systems
- Failure endangers human life and causes significant environmental damage.
06/09/2025 30
• The cost of failure in CS is likely to exceed the cost of the system itself.
• Examples of CS
• Communication systems such as aircraft radio systems
• Embedded control systems such as air-traffic control systems
• Financial systems such as banking systems
• Criticality attributes
• Reliability
• Availability
• Maintainability
• Safety
• Security

06/09/2025 31
• Reliability
• Number of times a system fails to deliver the specified services
expected by end-users.
• Metrics used
• MTTF – Mean Time To Failure
• time between observed system failures
• Rate of occurrence of Failure – number of failures in a given time period
• Availability (esp. for nonstop systems)
• Determine how likely the system is available to meet a demand for
service when requested by end-users.
• Metrics used
• POFOD – Probability Of Failure On Demand

06/09/2025 32
• Performance
• Constrain the speed of operation of a system.
• Response requirements
• Specify the acceptable response of the system to end-users input.
• E.g. The system should respond to user request for service within 2 seconds.
• Throughput requirements
• Specify the amount of data which must be processed in a given time
• E.g. The system should process at least 10 transactions per second.
• Security
• To ensure unauthorized access to the system and its data is not allowed and
ensure the integrity of the system from accidental or malicious damage.
• E.g.
1. The access permissions for system data may only be changed by the system’s
data administrator.
2. All external communications between the system’s data server and clients must
be encrypted
06/09/2025 33
• Safety
• Ability to deliver its services in such away the human life and its environment
will not be damaged by the system.
• E.g. The system shall not operate if the external temperature is below 4
degree Celsius.

06/09/2025 34
Characteristics of Good Requirements
• Complete
• ‹Functionality is described completely
• Correct
• According to stakeholders‘ intentions
• Consistent
• There are no two requirements that can not be reached in one single system
• Testable
• Requirements can be used to generate tests on the final software

06/09/2025 35
• Comprehensible
• ‹Requirements are to be understood by all stakeholders
• Necessary
• Requirement should be needed by customer and user
• Traceable
• Well-Defined
• Requirement can only be understood in one single way
• ‹Leaves no space for interpretation

06/09/2025 36
 CHAPTER 2
REQUIREMENTS ENGINEERING
PROCESSES

06/09/2025 37
Process

• A Process
• An organized set of activities which transforms inputs to outputs

• A mechanism for dealing with problem complexity

• Once these activities are used to solve a problem, can be documented as a

process description and used by others facing same problems.
• Examples of process descriptions
• Instruction manual for a Cookery book

06/09/2025 38
 Requirements Engineering Processes

• A series of activities performed in requirements Engineering phase to

• understand the requirements and its types

• express requirements in SRS document using appropriate techniques.

• The processes used for RE vary widely depending on the

• application domain

• the people involved and

• the organization developing the requirements.

• But there is conventional Generic activities common to all processes

06/09/2025 39
RE Process - Inputs and Outputs
Existing
systems
information

Stakeholder Agreed
needs requirements

Requirements System
Organisational engineering process
standards specification

System
Regulations models

Domain
information

06/09/2025 40
 RE Process Input/output description
Input o r o utput Ty pe Des cri pti o n
Existing system Input Information about the functionality of systems to be replaced or
information other systems which interact with the system being specified
Stakeholder needs Input Descriptions of what system stakeholders need from the system to
support their work
Organisational Input Standards used in an organisation regarding system development
standards practice, quality management, etc.
Regulations Input External regulations such as health and safety regulations which
apply to the system.
Domain information Input General information about the application domain of the system
Agreed requirements Output A description of the system requirements which is understandable
by stakeholders and which has been agreed by them
System Output This is a more detailed specification of the system functionality
specification which may be produced in some cases
System models Output A set of models such as a data-flow model. an object model, a
process model, etc. which describes the system from different
perspectives
06/09/2025 41
Reading Assignment

• Types of Process Models in Requirements Engineering include:

• Coarse-grain activity models

• Fine-grain activity models

• Role-action models

• Entity-relation models

06/09/2025 42
Definition of a Stakeholder
• Stakeholder: An individual, group of people, organization or other entity
that has a direct or indirect interest (or stake) in a system and
stakeholders vary according to the nature of the system.

• A stakeholder’s interest in a system may arise from using the system,

benefiting from the system (in terms of revenue or other advantage),
being disadvantaged by the system (in terms, for instance, of cost or
potential harm), being responsible for the system, or otherwise being
affected by it.
06/09/2025 43
• Managers: People who have a responsibility for either the development budget
or operating budget of the proposed system. It is also a good plan to involve
senior policy makers who will take a view on whether the proposed
development conforms to the aims and philosophy of the company or
organization.

• Investors: People who either have made or are being invited to make a
contribution to the funding of the proposed system, or the organizations
responsible for dev eloping or operating the system.

06/09/2025 44
• System users: Clearly this is a very important group of stakeholders. They
have a direct interest in the capabilities provided by the new system or
service. Note that there may also be users who do not interact directly with
the system.

• For example, the users of the Hubble telescope are astronomers. They ask for
photographs to be taken in specific directions, and they receive the
information when it arrives, but they do not directly control the telescope
itself. Users of an existing system are also valuable sources of knowledge of
problems with that system. They can give invaluable insight into how they
would like to see the system improved.
06/09/2025 45
• Maintenance and Service staff: Although their prime responsibility is to keep the system
running once it has been delivered, they do have important requirements that the system
must address in order to help them do their job.

• Product disposers: This is an increasingly important role as environmental protection

legislation develops. Requirements from this source can have a massive impact on design
especially with respect to the materials employed.

• Training personnel: Like the maintenance staff, these people have a vested interest in
making the system easy to use and consequently easy to train people to use. These people
may also require the system to be able to work simultaneously in a mode where live data
and training data can be mixed without interfering with the safe operation of the system.

06/09/2025 46
• System buyers: For public services and other large systems, the person who
buys the system may not be involved directly with its development or operation.
They will, though, have an important role to play in scoping the system from the
point of view of cost versus perceived benefit. For product-based developments,
the buyer may be the actual user, e.g. mobile phone user, car driver etc.

• Sales and marketing: These people have a vital role to play in formulating the
capabilities for new systems, especially for product based developments,
because, for mass produced consumer products, it is not possible to have access
to all potential users.
06/09/2025 47
• Usability and efficiency experts: These people have a view on how the system
can be optimized to make it efficient in use. These factors include ergonomics,
ease of learning and, where relevant, ability to be used reliably under pressure
(e.g. in air traffic control).

• Operational environment experts: Usually a new system is not created to work

in a “green fields” situation; it will have to inter-operate with existing systems.
There may also be other environmental aspects such as emission control
where the system must not pollute the environment, and conversely, aspects
where the system must be able to tolerate the environment in which it is
placed (e.g. in extreme weather conditions, submersed in water etc.)
06/09/2025 48
• Government: Rules, regulations and laws determine and influence what a
system may or may not do.
• Standards bodies: Existing and future standards can affect the goals of a
proposed system. These may be international such as the GSM mobile
phone standards, national standards or internal company standards.
• Regulatory authorities: These organizations may require that certain
evidence be collected as part of a certification or authorization process.
Examples include the Rail Regulator in the UK and the Food and Drug
Administration (FDA) in the USA.

06/09/2025 49
 Actors in the RE process

ACTIONS

Establish Select Develop Evaluate

Understand prototyping
problem outline prototype prototype
requirements system

Req. engineer Software Req. engineer End-user

Req. engineer engineer Domain expert
Domain expert End-user Software
End-user Project manager engineer Req. engineer
Software engineer

ROLES

06/09/2025 50
Rol e Des cri pti on
Domain expert Responsible for providing information about the
application domain and the specific problem in that
domain which is to be solved.
System end-user Responsible for using the system after delivery
Requirements engineer Responsible for eliciting and specifying the system
requirements
Software engineer Responsible for developing the prototype software
system
Project manager Responsible for planning and estimating the
prototyping project

06/09/2025 51
 Cont…
• The Generic activities common to all processes
• Feasibility Study

• Requirements Elicitation

• Requirements Analysis

• Requirements Specification

• Requirements Validation

• Requirements Management

06/09/2025 52
 I. Feasibility Study
• Feasibility
• The practical extent to which a project can be performed successfully.

• Feasibility Study
• Determines whether the solution considered to accomplish the requirements is
practically workable in the software or not
• Decides whether or not the proposed system is worthwhile.

06/09/2025 53
 Types of Feasibility

• Commonly known types are

Technical feasibility
Operational feasibility
Economic feasibility.

06/09/2025 54
 (a) Technical Feasibility:
• Technical feasibility assesses the current resources (such as hardware and software) and technology,

which are required to accomplish user requirements in the software within the allocated time and

budget.

• Software development team ascertains whether the current resources and technology can be upgraded

or added in the software to accomplish specified user requirements. Technical feasibility performs the

tasks listed below:

• Analyzes the technical skills and capabilities of software development team members.

• Determines whether the relevant technology is stable and established or not.

• Ascertains that the technology chosen for software development has large number of users so that they can be

consulted when problems arise or improvements are required

06/09/2025 55
(b) Operational Feasibility
• Operational feasibility assesses the extent to which the required
software performs series of steps to solve business problems and user
requirements.

06/09/2025 56
(c) Economic Feasibility

• Economic feasibility determines whether the required software

is capable of generating financial gains for an organization or not. It
involves the cost incurred on software development team, estimated
cost of hardware and software, cost of performing feasibility study,
and so on. For this, it is essential to consider expenses made on
purchases (such as hardware purchase) and activities required to
carry out software development.

06/09/2025 57
 CHAPTER 3
REQUIREMENTS ELICITATION
• It is also known as Requirements capture or Requirements acquisition

• Process of collecting information about software requirements from

different individuals, such as users and other stakeholders.

• System developers and engineers work with customers and end-users to

find out the problem to be solved, the system services , the required
performance of the system, hardware constraints and so on.

06/09/2025 58
 Elicitation Techniques
• Techniques used to gather data
• Interviews
• Scenarios
• These are descriptions of a sequence of events happen in that business area
• Questionnaire
• Brainstorming
• Conference held around a table with 6-10 members and explain their ideas to be decided by voting
• Observation
• Ethnography
• Also known as Participant observation
• Prototype:
• Creating prototypes of software applications, i.e., incomplete version of the program being developed.
• representation or visualization of the actual system parts to gather requirements by presenting GUI
based functions.

• JAD(Joint Application Development)

• Same
06/09/2025 as Brainstorming but stakeholders and users are also participants. 59
A Generic Requirements Elicitation Process
• Objective setting
• The organizational objectives should be established including general goals of
the business, an outline description of the problem to be solved, why the
system is necessary and the constraints on the system.
• Background knowledge acquisition
• Background information about the system includes information about the
organization where the system is to be installed, the application domain of
the system and information about existing systems
• Knowledge organization
• The large amount of knowledge which has been collected in the previous
stage must be organized and collated.
• Stakeholder requirements collection
• System stakeholders are consulted to discover their requirements.
06/09/2025 60
06/09/2025 61
• The output from the requirements elicitation process should be a
draft document that describes the system requirements which is then
will be analyzed.

06/09/2025 62
III. REQUIREMENTS ANALYSIS &
NEGOTIATION
• Requirements Analysis

• The process of studying, specifying and refining the

customer and the user needs to arrive at a definition of
the problem domain and system requirements.

06/09/2025 63
• IEEE definition
• Requirements analysis
The process of studying and refining user needs to arrive at a
definition of a system, hardware, or software requirements.

06/09/2025 64
• Objective
• To establish an agreed set of requirements which are complete and
consistent.
• Discover missing, conflicting, ambiguous, overlapping and unrealistic
requirements.
• Develop analysis model to analyze the requirements in the software

 If there are any of the above problems, stakeholders must negotiate and
agree on modifications and simplifications to the system requirements.

06/09/2025 65
• System modelling supports the analysis and design process by
introducing a degree of formality into the way systems are defined.

• Pictures are used to help visualize some aspects of the development.

• Modelling provides a way of formalizing these representations, through

diagrams, by not only defining a standard syntax, but also providing a
medium for understanding and communicating the ideas associated
with system development.

06/09/2025 66
Activities Performed in Requirements Analysis

• Necessity checking
• The need for the requirement is analyzed. In some cases, requirements may be proposed
which don’t contribute to the business goals of the organization or to the specific problem to
be addressed by the system.

• Consistency and completeness checking

• The requirements are cross-checked for consistency and completeness. Consistency means
that no requirements should be contradictory; completeness means that no services or
constraints which are needed have been missed out.

• Feasibility checking
• The requirements are checked to ensure that they are feasible in the context of the budget
and schedule available for the system development.
06/09/2025 67
Activities during Requirements Negotiation

• Requirements discussion
• Requirements which have been highlighted as problematical are discussed and the
stakeholders involved present their views about the requirements.

• Requirements prioritization
• Disputed requirements are prioritized to identify critical requirements
and to help the decision making process.

• Requirements agreement
• Solutions to the requirements problems are identified and a compromise set of
requirements are agreed. Generally, this will involve making changes to some of the
requirements.
06/09/2025 68
 CHAPTER 4
Requirements Specification

06/09/2025 69
• Requirements Specification

• is the process of writing down the user and system

requirements using exact and detailed statements in a
Requirements Document called Software Requirements
Specification (SRS).

06/09/2025 70
 SRS Definition
• IEEE definition

• “a document that clearly and precisely describes each of the essential

requirements (functions, performance, design constraints, and quality
attributes) of the software and the external interfaces. Each requirement
is defined in such a way that its achievement can be objectively verified
by a prescribed method.”

06/09/2025 71
 Purposes served by SRS

• Feedback

• Decompose problem into components

• Validation

• Input to design

• Basis for agreement between user and organization

• Reduce the development effort

• Estimating costs and schedules

06/09/2025 72
 SRS Users
• System customers - to specify and verify whether requirements meet the
desired needs or not.

• Managers - to plan for the system development processes.

• System engineers - to understand what system is to be developed

• System Test Engineers - to develop validation test for the developed system.

• System maintenance engineers - to use the requirement and the relationship

between its parts.

06/09/2025 73
 Characteristics of SRS
• Complete
• Correct
• Unambiguous
• Ranked for importance/stability
• Modifiable
• Traceable
• Verifiable
• Consistent

06/09/2025 74
 Structure of SRS
• Organized into independent sections and subsections.

• Level of detail and information to be included in the SRS depends on

• the type of the system to be developed and the process model chosen for its
development.

• The most widely used standard is by IEEE

06/09/2025 75
06/09/2025 76
 CHAPTER 5
REQUIREMENTS VALIDATION

06/09/2025 77
Requirements Validation

• Process conducted to checking and validating all the issues related to

requirements in the SRS document.
• Validation objectives
• Certifies that the requirements document represent an acceptable description of
the system to be implemented.
• Checks a requirements document for
• Completeness and consistency
• Conformance to standards
• Requirements conflicts
• Technical errors
• Ambiguous requirements

06/09/2025 78
Requirements Validation Objective

• To ensure that the SRS reflects the actual requirements accurately and
clearly.

• Certify that the SRS contains an acceptable description of the system to

be implemented.

• Ensure that the actual requirements of the system are reflected in SRS

• Check requirements document for completeness, accuracy, consistency,

requirement conflict, conformance to standards, and technical errors.
06/09/2025 79
Analysis and Validation

• Analysis works with raw requirements as elicited from the system

stakeholders
• “Have we got the right requirements” is the key question to be answered at this
stage

• Validation works with a final draft of the requirements document i.e.

with negotiated and agreed requirements
• “Have we got the requirements right” is the key question to be answered at this
stage
06/09/2025 80
Validation inputs and outputs
Requirements
document List of problems

Organisational Requirements
knowledge validation Agreed actions

Organisational
standards

06/09/2025 81
Validation Inputs
• Requirements document
• Should be a complete version of the document, not an unfinished draft.
Formatted and organised according to organisational standards

• Organisational knowledge
• Knowledge, often implicit, of the organisation which may be used to judge the
realism of the requirements

• Organisational standards
• Local standards e.g. for the organisation of the requirements document
06/09/2025 82
Validation Outputs
• Problem list
• List of discovered problems in the requirements document

• Agreed actions
• List of agreed actions in response to requirements problems. Some problems
may have several corrective actions; some problems may have no associated
actions

06/09/2025 83
 Validation Techniques

1. Requirement Review

2. Requirements Testing / Test Case Generation

06/09/2025 84
1. Requirements Reviews
• Validating the requirements by a group of people(Review Team).

• A group of people read and analyse the requirements, look for

problems, meet and discuss the problems and agree on actions to
address these problems.

06/09/2025 85
Requirements review process

Distribute
Plan review documents

Prepare for Hold review

review meeting

Follow-up Revise
actions document

06/09/2025 86
 Review Activities
• Plan review
• The review team is selected and a time and place for the review meeting is chosen.
• Distribute documents
• The requirements document is distributed to the review team members
• Prepare for review
• Individual reviewers read the requirements to find conflicts, omissions, inconsistencies,
deviations from standards and other problems.
• Hold review meeting
• Individual comments and problems are discussed and a set of actions to address the
problems is agreed.
• Follow-up actions
• The chair of the review checks that the agreed actions have been carried out.
• Revise document
• The requirements document is revised to reflect the agreed actions. At this stage, it may be
accepted or it may be re-reviewed
06/09/2025 87
Review checklists
• Understandability
• Can readers of the document understand what the requirements mean?
• Redundancy
• Is information unnecessarily repeated in the requirements document?
• Completeness
• Does the checker know of any missing requirements or is there any
information missing from individual requirement descriptions?
• Ambiguity
• Are the requirements expressed using terms which are clearly defined? Could
readers from different backgrounds make different interpretations of the
requirements?
06/09/2025 88
 Review checklists
• Consistency
• Do the descriptions of different requirements include contradictions? Are there
contradictions between individual requirements and overall system requirements?
• Organisation
• Is the document structured in a sensible way? Are the descriptions of requirements
organised so that related requirements are grouped?
• Conformance to standards
• Does the requirements document and individual requirements conform to defined
standards? Are departures from the standards, justified?
• Traceability
• Are requirements unambiguously identified, include links to related requirements and
to the reasons why these requirements have been included?

06/09/2025 89
 Roles and Responsibilities in a Review
1. The Moderator(Review Leader)
• Determine type of review approach
• Disseminate documents before the meeting
2. The Author
• Writer of the document under review
3. The Scribe|Recorder
• Record each defect found and given suggestions and feedback.
4. The Reviewers
• Check the SRS for defects and further improvement.
5. The Manager
• Decide the execution of Reviews
• Determine if Review objective is met.
06/09/2025 90
Requirements problem example
• “4. EDDIS will be configurable so that it will comply with the
requirements of all UK and (where relevant) international copyright
legislation. Minimally, this means that EDDIS must provide a form for
the user to sign the Copyright Declaration statement. It also means
that EDDIS must keep track of Copyright Declaration statements which
have been signed/not-signed. Under no circumstances must an order
be sent to the supplier if the copyright statement has not been signed.”

06/09/2025 91
Problems
• Incompleteness
• What international copyright legislation is relevant?
• What happens if the copyright declaration is not signed?
• If a signature is a digital signature, how is it assigned?
• Ambiguity
• What does signing an electronic form mean? Is this a physical signature or a
digital signature?
• Standards
• More than 1 requirement. Maintenance of copyright is one requirement;
issue of documents is another

06/09/2025 92
2. Requirements Testing (Test Case Generation)

• A test case is a document that describes an input, action, or event

and its expected result, in order to determine whether the software
or a part of the software is working correctly or not.

• Generate a Test-case for each requirements and prepare a Test

Record Form to be filled in for each requirement which is tested.

06/09/2025 93
• Information to be included in Test Record Form
• The requirement’s identifier
• There should be at least one for each requirement.

• Related requirements
• These should be referenced as the test may also be relevant to these requirements.

• Test description
• A brief description of the test and why this is an objective requirements test. This should
include system inputs and corresponding outputs.

• Requirements problems
• A description of problems which made test definition difficult or impossible.

• Comments and recommendations

06/09/2025
• These are advice on how to solve requirements problems which have been discovered. 94
 CHAPTER 6
REQUIREMENTS MANAGEMENT

06/09/2025 95
 Definition
• Process of eliciting, documenting, organizing and controlling
changes to the requirements.
• To
• Identify,
• Control and
• Track requirements and changes on requirements.
• Managing changes to system’s requirements evolving because
of changes to system’s environment and as customers develop
a better understanding of their real needs.

06/09/2025 96
 • The principal concerns of requirements management are:

• Managing changes to agreed requirements

• Managing the relationships between requirements

• Requirements changes can occur while requirements

• Elicitation,
• Analysis and Validation and
• After the system has gone into Service

06/09/2025 97
Requirements change factors
• Requirements errors, conflicts and inconsistencies
• As requirements are analysed and implemented, errors and inconsistencies
emerge and must be corrected.
• Evolving customer/end-user knowledge of the system
• New requirements emerge ad stakeholders develop a better understanding of
the system.
• Technical, schedule or cost problems
• Problems may be encountered in implementing a requirement. It may be too
expensive or take too long to implement certain requirements.

06/09/2025 98
Requirements change factors
• Changing customer priorities
• Customer priorities change during system development as a result of a
changing business environment, the emergence of new competitors, staff
changes, etc.
• Environmental changes
• The environment in which the system is to be installed may change so that
the system requirements have to change to maintain compatibility
• Organisational changes
• The organisation which intends to use the system may change its structure
and processes resulting in new system requirements

06/09/2025 99
• From an evolution perspective, requirements fall into two classes
• Stable requirements are derive from the core activity of the organization and
application domain of the system. They change more slowly than volatile
requirements.
• Volatile requirements are specific to the instantiation of the system in a
particular environment and for a particular customer.

06/09/2025 100
Types of Volatile requirement
• Mutable requirements
• change because of changes to the environment in which the system is
operating
• Emergent requirements
• cannot be completely defined when the system is specified but which
emerge as the system is designed and implemented.
• Consequential requirements
• are based on assumptions about how the system will be used. When
the system is put into use, some of these assumptions will be wrong.
• The compatibility requirements
• depend on other equipment or processes.
06/09/2025 101
The Change Management Process
• Some requirements problem or change is identified.
• This could come from an analysis of the requirements, new customer needs,
or operational problems with the system. The requirements are analysed
using problem information and requirements changes are proposed.
• The proposed changes are analysed
• This checks how many requirements (and, if necessary, system components)
are affected by the change and roughly how much it would cost, in both time
and money, to make the change.
• The change is implemented.
• A set of amendments to the requirements document or a new document
version is produced. This should, of course, be validated using whatever
normal quality checking procedures are used.

06/09/2025 102
 Change Management Stages

Identified
problem
Problem analysis and Change analysis Change
change specification and costing implementation
Revised
requirements

06/09/2025 103
Change Request Rejection

• If the change request is invalid.

• This normally arises if a customer has misunderstood something about the
requirements and proposed a change which isn’t necessary.

• If the change request results in consequential changes which are

unacceptable to the user.

• If the cost of implementing the change is too high or takes too long.

06/09/2025 104
Advantages of Requirements
Management

• Better control of complex projects

• Improves software quality
• Reduced project costs and delays
• Improved team communications
• Easing compliance with standards and regulations

06/09/2025 105
 Traceability
• Traceability information is information which helps you assess the impact of
requirements change on the rest of the system.
• Types of traceability information
• Backward-from traceability : Links requirements to their sources in other documents or people.

• Forward-from traceability : Links requirements to the design and implementation components

• Backward-to traceability : Links design and implementation components backs to requirements

• Forward-to traceability : Links information from documents and other sources to relevant
requirements.

06/09/2025 106
Traceability Tables
• Traceability tables show the relationships between requirements or
between requirements and design components

• Requirements are listed along the horizontal and vertical axes and
relationships between requirements are marked in the table cells

• Traceability tables for showing requirements dependencies should be

defined with requirement numbers used to label the rows and
columns of the table.
06/09/2025 107
A traceability table
Depends -on
R1 R2 R3 R4 R5 R6
R1 * *
R2 * *
R3 * *
R4 *
R5 *
R6

06/09/2025 108
A Traceability list

Requirement Depends -on

R1 R3, R4
R2 R5, R6
R3 R4, R5
R4 R2
R5 R6

06/09/2025 109