Requirements engineering

SOFTWARE ENGINEERING
 Requirements engineering processes

• requirements engineering processes may include

four high-level activities.
– Requirements elicitation.
– Requirements analysis and negotiation.
– Requirements specification.
– Requirements validation.

Coming up: An Agile Process 2

 Requirements Engineering Process

Requirements
Requirements Requirements Requirements
Analysis and
Elicitation Specification Validation
Negotiation

User Needs,
Domain Information, Agreed
Existing System Requirements Requirements
Information, Regulations, Document
Standards, Etc.

3
 Requirements engineering processes

• Elicit means to gather, acquire, extract, and obtain,

etc.
• Requirements elicitation is the practice of
researching and discovering the requirements of a
system from users, customers, and other
stakeholders.[1] The practice is also sometimes
referred to as "requirement gathering".

Coming up: An Agile Process 4

 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 5

A process model of the elicitation and
analysis process

Coming up: An Agile Process 6

 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 7

 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 8

 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 9

 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 10

 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 11

 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 12

 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 13
 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 14

 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 15
 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 16
Use cases

Coming up: An Agile Process 17

 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 18
 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 19

 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 20

 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 21

 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 22

 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 23
 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 24
 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 25

 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 26

 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 27

 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 28

 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 29
 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 30