Requirements engineering

SOFTWARE ENGINEERING
 Requirements & Requirements Engineering

• The requirements for a system are the descriptions

of what the system should do.
• Requirements reflect the needs of customers for a
system that serves a certain purpose.
• The process of finding out, analyzing, documenting
and checking these services and constraints is
called requirements engineering (RE).

Coming up: An Agile Process 2

 User Requirements & System Requirements

• User requirements are statements, in a natural

language plus diagrams, of what services the
system is expected to provide to system users and
the constraints under which it must operate.
• System requirements are more detailed
descriptions of the software system’s functions,
services, and operational constraints.
• The system requirements document should define
exactly what is to be implemented. It may be part of
the contract between the system buyer and the
software developers.

Coming up: An Agile Process 3

 User Requirements & System Requirements

• write requirements at different levels of detail

because different readers use them in different
ways.

Coming up: An Agile Process 4

 Functional & Non functional requirements

• Functional requirements These are statements of

services the system should provide, how the
system should react to particular inputs, and how
the system should behave in particular situations.
• Non-functional requirements These are constraints
on the services or functions offered by the system.
They include timing constraints, constraints on the
development process, and constraints imposed by
standards. Non-functional requirements often apply
to the system as a whole, rather than individual
system features or services.

Coming up: An Agile Process 5

 Functional requirements

• The functional requirements for a system describe

what the system should do. These requirements
depend on the type of software being developed,
the expected users of the software, and the general
approach taken by the organization when writing
requirements.
• When expressed as user requirements, functional
requirements are usually described in an abstract
way that can be understood by system users.

Coming up: An Agile Process 6

 Functional requirements

• Functional requirements define the basic system

behavior. Essentially, they are what the system
does or must not do, and can be thought of in
terms of how the system responds to inputs.

Coming up: An Agile Process 7

 Functional requirements

• Think about a functional requirement that the

system loads a webpage after someone clicks on a
button. There should be a related non-functional
requirement specifying how fast the webpage must
load. Without it, the user experience and
perception of quality are at risk if they are forced to
wait too long, even though the functional
requirement is fully met.

Coming up: An Agile Process 8

Functional & Non functional requirements

Coming up: An Agile Process 9

 Requirement Document

• The software requirements document (sometimes

called the software requirements specification or
SRS) is an official statement of what the system
developers should implement.
• It should include both the user requirements for a
system and a detailed specification of the system
requirements. Sometimes, the user and system
requirements are integrated into a single
description.

Coming up: An Agile Process 10

 Requirement Document

• Requirements documents are essential when an

outside contractor is developing the software
system.
• However, agile development methods argue that
requirements change so rapidly that a
requirements document is out of date as soon as it
is written, so the effort is largely wasted.
• Rather than a formal document, approaches such
as Extreme Programming collect user requirements
incrementally and write these on cards as user
stories.

Coming up: An Agile Process 11

Users of Requirement Document

Coming up: An Agile Process 12

 Requirement Specification

• Requirements specification is the process of writing

down the user and system requirements in a
requirements document. Ideally, the user and
system requirements should be clear,
unambiguous, easy to understand, complete, and
consistent.
• The user requirements for a system should
describe the functional and nonfunctional
requirements so that they are understandable by
system users who don’t have detailed technical
knowledge.

Coming up: An Agile Process 13

 Natural language specification

• Natural language has been used to write

requirements for software since the beginning of
software engineering. It is expressive and
universal. It is also potentially vague, ambiguous,
and its meaning depends on the background of the
reader.
• As a result, there have been many proposals for
alternative ways to write requirements.
• However, none of these have been widely adopted
and natural language will continue to be the most
widely used way of specifying system and software
requirements.
Coming up: An Agile Process 14
 Structured specifications

• 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.
• Using structured specifications removes some of the
problems of natural language specification. Variability in
the specification is reduced and requirements are
organized more effectively.
Coming up: An Agile Process 15
 Requirements engineering processes

• requirements engineering processes may include

four high-level activities.
• These focus on assessing if the system is useful to
the business (feasibility study)
• discovering requirements (elicitation and analysis)
• Converting these requirements into some standard
form (specification)
• checking that the requirements actually define the
system that the customer wants (validation).

Coming up: An Agile Process 16

 Requirements engineering processes

• in practice, requirements engineering is an iterative

process in which the activities are interleaved.
• Figure shows this interleaving. The activities are
organized as an iterative process around a spiral,
with the output being a system requirements
document.
• The amount of time and effort devoted to each
activity in each iteration depends on the stage of
the overall process and the type of system being
developed.

Coming up: An Agile Process 17

Coming up: An Agile Process 18
 Requirements elicitation and analysis

• After an initial feasibility study, the next stage of the

requirements engineering process is requirements
elicitation and analysis.
• In this activity, software engineers work with
customers and system end-users to find out about
the application domain, what services the system
should provide, the required performance of the
system, hardware constraints, and so on.

Coming up: An Agile Process 19

A process model of the elicitation and
analysis process

Coming up: An Agile Process 20

 Requirements elicitation and analysis

• Requirements discovery This is the process of

interacting with stakeholders of the system to
discover their requirements. Domain requirements
from stakeholders and documentation are also
discovered during this activity.
• Requirements classification and organization This
activity takes the unstructured collection of
requirements, groups related requirements, and
organizes them into coherent clusters.

Coming up: An Agile Process 21

 Requirements elicitation and analysis

• Requirements prioritization and negotiation when

multiple stakeholders are involved, requirements
will conflict. This activity is concerned with
prioritizing requirements and finding and resolving
requirements conflicts through negotiation.
• Requirements specification The requirements are
documented and input into the next round of the
spiral. Formal or informal requirements documents
may be produced,

Coming up: An Agile Process 22

 Requirements discovery

• Requirements discovery is the process of gathering

information about the required system and existing
systems, and distilling the user and system
requirements from this information.
• Sources of information during the requirements
discovery phase include documentation, system
stakeholders, and specifications of similar systems.
• You interact with stakeholders through interviews
and observation and you may use scenarios and
prototypes to help stakeholders understand what
the system will be like.

Coming up: An Agile Process 23

 Interviewing

• Formal or informal interviews with system

stakeholders are part of most requirements
engineering processes.
• In these interviews, the requirements engineering
team puts questions to stakeholders about the
system that they currently use and the system to
be developed.
• Requirements are derived from the answers to
these questions.

Coming up: An Agile Process 24

 Interviewing

• Interviews may be of two types:

• 1. Closed interviews, where the stakeholder
answers a pre-defined set of questions.
• 2. Open interviews, in which there is no pre-defined
agenda.
• The requirements engineering team explores a
range of issues with system stakeholders and
hence develop a better understanding of their
needs.

Coming up: An Agile Process 25

 Interviewing

• Interviews may be of two types:

• 1. Closed interviews, where the stakeholder
answers a pre-defined set of questions.
• 2. Open interviews, in which there is no pre-defined
agenda.
• The requirements engineering team explores a
range of issues with system stakeholders and
hence develop a better understanding of their
needs.

Coming up: An Agile Process 26

 Interviewing

• Interviews are good for getting an overall

understanding of what stakeholders do, how they might
interact with the new system, and the difficulties that
they face with current systems. People like talking
about their work so are usually happy to get involved in
interviews.
• However, interviews are not so helpful in
understanding the requirements from the application
domain. Interviews are also not an effective technique
for eliciting knowledge about organizational
requirements and constraints because there are subtle
power relationships between the different people in the
organization
Coming up: An Agile Process 27
 Scenarios

• People usually find it easier to relate to real-life

examples rather than abstract descriptions. They
can understand and criticize a scenario of how they
might interact with a software system.
• Requirements engineers can use the information
gained from this discussion to formulate the actual
system requirements.
• A scenario starts with an outline of the interaction.
During the elicitation process, details are added to
this to create a complete description of that
interaction.

Coming up: An Agile Process 28

 Scenarios

• At its most general, a scenario may include:

• 1. A description of what the system and users
expects 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 this
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.
Coming up: An Agile Process 29
 Use cases

• Use cases are a requirements discovery technique

that were first introduced in the Objectory method
• They have now become a fundamental feature of the
unified modeling language. In their simplest form, a
use case identifies the actors involved in an
interaction and names the type of interaction.
• This is then supplemented by additional information
describing the interaction with the system.
• Use cases are documented using a high-level use
case diagram. The set of use cases represents all of
the possible interactions that will be described in the
system requirements.
Coming up: An Agile Process 30
Use cases

Coming up: An Agile Process 31

 Ethnography

• Ethnography is an observational technique that can

be used to understand operational processes and
help derive support requirements for these
processes.
• An analyst immerses himself in the working
environment where the system will be used.
• The day-to-day work is observed and notes made
of the actual tasks in which participants are
involved. The value of ethnography is that it helps
discover implicit system requirements that reflect
the actual ways that people work, rather than the
formal processes defined by the organization.
Coming up: An Agile Process 32
 Requirements validation

• Requirements validation is the process of checking

that requirements actually define the system that
the customer really wants.
• It is concerned with finding problems with the
requirements.
• 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.

Coming up: An Agile Process 33

 Requirements validation

• During the requirements validation process,

different types of checks should be carried out on
the requirements in the requirements document.
These checks include:
• Validity checks
• Consistency checks
• Realism checks
• Verifiability

Coming up: An Agile Process 34

 Requirements validation

• There are a number of requirements validation

techniques that can be used individually or in
conjunction with one another
• Requirements reviews
• Prototyping
• Test-case generation

Coming up: An Agile Process 35

 Requirements management

• The requirements for large software systems are

always changing. One reason for this is that these
systems are usually developed to address ‘wicked’
problems—problems that cannot be completely
defined.
• Because the problem cannot be fully defined, the
software requirements are bound to be incomplete.
• During the software process, the stakeholders’
understanding of the problem is constantly changing.
• The system requirements must then also evolve to
reflect this changed problem view.

Coming up: An Agile Process 36

 Requirements management

• There are several reasons why change is

inevitable:
• 1. The business and technical environment of the
system always changes after installation. New
hardware may be introduced, it may be necessary
to interface the system with other systems,
business priorities may change
• 2.The people who pay for a system and the users
of that system are rarely the same people. System
customers impose requirements because of
organizational and budgetary constraints. These
may conflict with end-user requirements
Coming up: An Agile Process 37
 Requirements management

• 3. Large systems usually have a diverse user

community, with many users having different
requirements and priorities that may be conflicting or
contradictory.
• The final system requirements are inevitably a
compromise between them and, with experience, it
is often discovered that the balance of support given
to different users has to be changed.

• Requirements management is the process of

understanding and controlling changes to system
requirements.
Coming up: An Agile Process 38
 Requirements management planning

• Planning is an essential first stage in the

requirements management process.
• The planning stage establishes the level of
requirements management detail that is required.
During the requirements management stage, you
have to decide on:
• 1. Requirements identification
• 2. A change management process
• 3. Traceability policies
• 4. Tool support

Coming up: An Agile Process 39

 Requirements management planning

• 1. Requirements identification Each requirement

must be uniquely identified so that it can be cross-
referenced with other requirements and used in
traceability assessments.
• 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.

Coming up: An Agile Process 40

 Requirements management planning

• 4. Tool support Requirements management

involves the processing of large amounts of
information about the requirements.
• Tools that may be used range from specialist
requirements management systems to
spreadsheets and simple database systems.

Coming up: An Agile Process 41

 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.
• Change management is essential because you need
to decide if the benefits of implementing new
requirements are justified by the costs of
implementation.
• The advantage of using a formal process for change
management is that all change proposals are treated
consistently and changes to the requirements
document are made in a controlled way.

Coming up: An Agile Process 42

 Requirements change management
• There are three principal stages to a change
management process:
• 1. Problem analysis and change specification: The
process starts with an identified requirements problem
or, sometimes, with a specific change proposal.
During this stage, the problem or the change proposal
is analyzed to check that it is valid.
• 2. Change analysis and costing The effect of the
proposed change is assessed. The cost of making the
change is estimated both in terms of modifications to
the requirements document and, if appropriate, to the
system design and implementation.
Coming up: An Agile Process 43
 Requirements change management
• 3. Change implementation The requirements
document and, where necessary, the system design
and implementation, are modified.
• You should organize the requirements document so
that you can make changes to it without extensive
rewriting or reorganization.

Coming up: An Agile Process 44