Software Requirements Engineering

Week # 4

Introduction to Requirements Management

Dr. Azhar Imran Mudassir

Assistant Professor
Department of Creative Technologies
Air University, Islamabad
Table of Contents

 Software requirements
 Requirements management
 The problem domain
 The solution domain
What is Requirements Management (RM)?
► A systematic approach for
► eliciting,
► organizing, and
► documenting
the requirements of the system, and

► A process that establishes and maintains agreement between the

customer and the project team on the changing requirements of
the system.

5
Intro. to Req.s Managements 4/10/2021
RM Processes

Start?
Elicitation

Validation
(Negotiation / Analysis
Agreement)

End Specification
(Documentation)
6
Intro. to Req.s Managements
Key Concepts in RM
► The ability to elicit the requirements from users and
stakeholders is a crucial skill.

► Since hundreds, if not thousands, of requirements are

likely to be associated with a system, it's important to
organize them.

► documenting the requirements is necessary to support

effective communication among the various stakeholders.

► Validation: is necessary to ensure the accuracy and

completeness

Intro. to Req.s Managements 6

Formal Requirements Management
► Organized and formal processes of requirements management
can be found in
► Capability Maturity Model (CMM)
► ISO 9000 for quality management standards

Intro. to Req.s Managements 7

 RM for all Types of Software Apps
► IS: Information systems and other applications developed for
use within a company, e.g., the payroll system of a certain
company

► ISV: Software developed and sold as commercial products.,

g. MS Office ®
► Companies developing this type of software are referred
to as independent software vendors (ISVs).

► Embedded applications: Software that runs on computers

embedded in other devices, machines, or complex systems,
e.g. software in cell phones, automobile

8
Intro. to Req.s Managements
 The Road Map

► Many questions will arise during the journey to develop quality

software. E.g.,
► Is this a need or a want?
► Is this a nice-to-have or a must-have?
► Do we have to program in Java? Says who?
► Who doesn't like the new system,
► and where was that person when we visited here before?

9
Intro. to Req.s Managements
The Road Map
► In order to navigate successfully, we'll need to understand: -
► where we are at any point in time,
► whom we are meeting,
► what language they are speaking, and
► what information we need from them to complete our journey
successfully.

10
Intro. to Req.s Managements
Problem Domain vs Solution Domain
► Problem domain is related to the
► Stakeholder needs

► Solution domain is related to the

► Features of the system
► Software requirements

► Let's start in the "land of the problem.“…

11
Intro. to Req.s Managements
The Problem Domain
► Most successful requirements journeys begin with a trip to the
land of the problem.

► The problem domain is the home of real users and other

stakeholders, people whose needs must be addressed in order
for us to build the perfect system.

► These users have business or technical problems that they

need our help to solve.

► Therefore, it becomes our problem to understand their

problems, in their culture and their language, and to build
systems that meet their needs.

13
Intro. to Req.s Managements
The Problem Domain
► Within the problem domain, we use a set of team skills to
understand the problem to be solved.

► It is also our responsibility to understand the needs of users

and other stakeholders whose lives will be affected by our
solution.

13
Intro. to Req.s Managements
Moving Toward the Solution domain
► The journey through the problem domain is not necessarily
difficult, and the artifacts collected there are not many.

► In this solution space, we focus on defining a solution to the

user's problem; this is the area of computers, programming,
operating systems, networks, and processing nodes.

► Here, we can apply the skills we have learned much more

directly.

http://www.quora.com/What-does-the-word-artifacts-mean-in-software-engineering

14
Intro. to Req.s Managements
Moving Toward the Solution domain
► First we create a definition of a system and the software
requirements that will drive its design and
implementation.
► A definition of a system = features of the system

15

Intro. to Req.s Managements

Features of the System
► A feature is a service provided by the system that fulfils
one or more stakeholder needs.

► These are simple descriptions, in the user's language.

► Examples:
► "The car will have power windows."
► "The program will allow Web-enabled entry of sales
orders."

16
Intro. to Req.s Managements
Software Requirements

► Once we have established the feature set and have

gained agreement with the customer, we move to
defining the more specific requirements needed in the
solution.

► Then we can be certain that the system we develop will

deliver the features we promised.

17
Intro. to Req.s Managements
Overview of the Problem Domain and the
Solution Domain

18
Intro. to Req.s Managements
Summary
► A requirement is a capability that is imposed on the system.
► Requirements management is a process of systematically
eliciting, organizing, and documenting requirements for a
complex system.
► Our challenge is to understand users' problems in their
culture and their language and to build systems that meet
their needs.
► A feature is a service that the system provides to fulfill one
or more stakeholder needs.
► After defining features, we define more specific
requirements needed in the solution.

19

Intro. to Req.s Managements