REQUIREMENT ENGINEERING

JIMMA UNIVERSITY
JIMMA INSTITUTE OF TECHNOLOGY
SCHOOL OF COMPUTING AND INFORMATICS

CHAPTER TWO
REQUIREMENTS ENGINEERING PROCESS
 Requirements engineering processes
2

The processes used for RE vary widely depending

on the application domain, the people involved
and the organization developing the requirements.
However, there are a number of generic activities
common to all processes
 Requirements elicitation;
 Requirements analysis;
 Requirements validation;
 Requirements management.
In practice, RE is an iterative activity in which these
processes are interleaved.
Requirements engineering processes
3
 1. Feasibility studies
4
A feasibility study decides whether or not the
proposed system is worthwhile.
A short focused study that checks
 If the system contributes to organizational objectives;
 If the system can be implemented using current technology,
within given cost and schedule constraints;
 If the system can be integrated with other systems that are
already in place.
 Feasibility study implementation
5
Feasibility study involves information assessment
(what is required), information collection and report
writing.
Questions for people in the organization for
information assessment and collection:
 What if the system wasn’t implemented?
 What are current process problems?
 How will the proposed system help?
 What will be the integration problems?
 Is new technology needed? What skills?
 What facilities must be supported by the proposed system?
 Feasibility study report should make a recommendation about the
development to continue or not.
2. Requirements elicitation and analysis
6

Sometimes called requirements elicitation or

requirements discovery.
Involves technical staff working with customers to
find out about the application domain, the services
that the system should provide and the system’s
operational constraints.
May involve end-users, managers, engineer
involved in maintenance, domain experts, trade
unions, etc. These are called stakeholders.
 Requirements elicitation and analysis
7

Software engineers work with a range of system

stakeholders to find out about the application domain,
the services that the system should provide, the
required system performance, hardware constraints,
other systems, etc.
Stages include:
 Requirements discovery,
 Requirements classification and organization,
 Requirements prioritization and negotiation,
 Requirements specification (documentation).
The requirements elicitation & analysis Process
8
 E&A Process activities
9
Requirements discovery
 Interacting with stakeholders to discover their requirements.
Domain requirements are also discovered at this stage.
Requirements classification and organization
 Group related requirements and organizes them into coherent
clusters.
Prioritization and negotiation
 Prioritizing requirements and finding and resolving
requirements conflicts.
Requirements documentation
 Requirements are documented and input into the next round of
the spiral.
 A. Requirements discovery
10
 The process of gathering information about the proposed
and existing systems and distilling the user and system
requirements from this information.
 Interaction is with system stakeholders from managers to
external regulators.
 Sources of information include documentation, system
stakeholders and the specifications of similar systems.
 Approaches & Techniques of requirements discovery are:
 Interviewing
 Scenario
 Use-cases
 ethnography
 Interviewing
11
Formal or informal interviews with stakeholders are
part of most RE processes.
Types of interview
 Closed interviews based on pre-determined list of questions
 Open interviews where various issues are explored with
stakeholders.
Effective interviewing
 Be open-minded, avoid pre-conceived ideas about the
requirements and are willing to listen to stakeholders.
 Prompt the interviewee to get discussions going using a
springboard question, a requirements proposal, or by working
together on a prototype system.
 Scenarios
12

Scenarios are real-life examples of how

a system can be used.
They should include
A description of the starting situation;
 A description of the normal flow of events;

 A description of what can go wrong;

 Information about other concurrent activities;

 A description of the state when the scenario

finishes.
Scenario for collecting medical history
13
 Use cases
14

Use-cases are a scenario based technique in the UML

which identify the actors in an interaction and which
describe the interaction itself.
A set of use cases should describe all possible
interactions with the system.
High-level graphical model supplemented by more
detailed tabular description.
Sequence diagrams may be used to add detail to use-
cases by showing the sequence of event processing in
the system.
 Ethnography
15

A social scientist spends a considerable time observing

and analysing how people actually work.
People do not have to explain or articulate their work.
Social and organisational factors of importance may be
observed.
Ethnographic studies have shown that work is usually
richer and more complex than suggested by simple
system models.
Ethnography is effective for understanding existing
processes but cannot identify new features that should
be added to a system.
 B. Requirements classification and organization
16

The process of organizing overall structure of

the system.
Putting related requirements together, and
decomposing the system into sub components
of related requirements. Then, we define the
relationship between these components.
What we do here will help us in the decision of
identifying the most suitable architectural
design patterns.
 C. Requirements Prioritization and negotiation
17

The conflicts that may arise as a result of having

different stakeholders involved. Why? because it’s
hard to satisfy all parties, if it’s not impossible.
This activity is concerned with prioritizing
requirements and finding and resolving requirements
conflicts through negotiations.
Functions with higher priorities need higher attention
and focus.
 D. Requirements Specification (Documentation)
18

 The requirements are then documented.

It’s the process of writing down the user and system
requirements into a document.
The requirements should be clear, easy to understand,
complete and consistent.

There are different ways to specify the requirements.

The most two common ways are the natural (a way of
writing the requirements in normal plain text) and structured
(a way of writing the requirements in more formal and
structured form) languages.
 Problems of requirements analysis
19

Stakeholders don’t know what they really want except

in most general.
Stakeholders express requirements in their own terms.
Different stakeholders may have deferent
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 change.
 3. Requirements validation
20

Concerned with demonstrating that the

requirements define the system that the customer
really wants.
Requirements error costs are high so validation is
very important.
 Fixing a requirements error after delivery may cost up to 100
times the cost of fixing an implementation error.
 Requirements checking
21

Validity: Does the system provide the functions

which best support the customer’s needs?
Consistency: Are there any requirements conflicts?
Completeness: Are all functions required by the
customer included?
Realism: Can the requirements be implemented
given available budget and technology
Verifiability: Can the requirements be checked?
 Requirements validation techniques
22

Requirements reviews
 Systematic manual analysis of the requirements.
Prototyping
 Using an executable model of the system to check
requirements.
Test-case generation
 Developing tests for requirements to check testability.
 If test is difficult or impossible to design for the requirement
means it is difficult to implement that requirement
 Requirements reviews
23

Regular reviews should be held while the

requirements definition is being formulated.
Both client and contractor staff should be involved in
reviews.
Reviews may be formal (with completed documents)
or informal. Good communications between
developers, customers and users can resolve
problems at an early stage.
 Review checks
24

Verifiability:
Is the requirement realistically testable?
Comprehensibility:
Is the requirement properly understood?
Traceability:
Is the origin of the requirement clearly stated?
Adaptability:
Can the requirement be changed without a large impact on other
requirements?
 4. Requirements management
25
Requirements management is the process of managing
changing requirements during the requirements
engineering process and system development.
New requirements emerge as a system is being developed
and after it has gone into use.
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 evolution
26
 Requirements management planning
27
Establishes the level of requirements management detail
that is required.
Requirements management decisions:
 Requirements identification Each requirement must be uniquely
identified so that it can be cross-referenced with other requirements.
 A change management process This is the set of activities that assess
the impact and cost of changes.
 Traceability policies These policies define the relationships between
each requirement and between the requirements and the system
design that should be recorded.
 Tool support Tools that may be used range from specialist
requirements management systems to spreadsheets and simple
database systems.
 Requirements change management
28
Deciding if a requirements change should be accepted
 Problem analysis and change specification
 During this stage, the problem or the change proposal is analyzed to check
that it is valid. This analysis is fed back to the change requestor who may
respond with a more specific requirements change proposal, or decide to
withdraw the request.
 Change analysis and costing
 The effect of the proposed change is assessed using traceability information
and general knowledge of the system requirements. Once this analysis is
completed, a decision is made whether or not to proceed with the
requirements change.
 Change implementation
 The requirements document and, where necessary, the system design and
implementation, are modified. Ideally, the document should be organized so
that changes can be easily implemented.
Requirements change management
29
The challenge of writing better requirements
30

The requirements writing process

o The requirements writing process within the system life cycle
 The challenge of writing better requirements
31
 Identify the stakeholders
oTry to find the person or people to talk to first.
o Then identify names and roles involved in the system.
o Arrange to meet those people with roles , and repeat the identification
process until you have a complete list of stakeholders.
 Gather the requirements
o After having an accurate list of stakeholders, requirements gathering can
be made using
• interviews
• Workshops
• prototypes
• other techniques for working directly with users
• Or you can scan documentary sources to locate possible
requirements
 The challenge of writing better requirements
32
 Organize the requirements
o Requirements as gathered are invariably incomplete. The might contain
mistakes, design choices, and ambiguities.
o Decisions need to be made; context and organization need to be provided.

o You can begin by structuring the requirements into a hierarchy-

scenarios.
 Check the requirements
o Formal reviews are immensely important in improving the quality of

requirements, but they are time-consuming.

o informal meetings and discussions can get much of the checking done

before a review.
o working closely with users makes eases the review process.

 Review and baseline the requirements

 Enduring vs Volatile requirements.
33

 Enduring requirements. Stable requirements derived

from the core activity of the customer organization. E.g. a
hospital will always have doctors, nurses, etc. May be
derived from domain models

 Volatile requirements. Requirements which change

during development or when the system is in use.
 Model of requirements evolves
34
time

initial final
analysis high-level
model view

design objects
Detailing and implementing
design model. Changing and
adapting of high-level view. implementation
• requirements themselves change
• our view / model of them changes
 Model of requirements evolves
35

o Idealistic approach:
 The analysis model is stable after the analysis phase. It can be
seamlessly extended into a design model.
 The initial analysis model is also the high-level view of the final system.
o One-model approach :
 The goal is one single model, maybe on several abstraction levels; no real
separation between analysis and design.
 The model always undergoes changes and is never really stable.
 The initial analysis model is either discarded or changed into the final
high-level view.
o Two-model approach
 Two separate models are made: an (initial) analysis model and a final
high-level view of the system.
 These models are not identical; they may even use different notations.
Links provide necessary traces.
Any Question?