CHAPTER 3

Requirement Elicitation
BY: S E N B E T U A .
N OV 2 0 2 2
J KU, J I N KA , E T H I O P I A

1
 What is Requirement?
• The requirements for a system are the descriptions of the services provided by the
system and its operational constraints.
• These requirements reflect the needs of customers for a system.
• The process of finding out, analyzing, documenting and checking these services and
constraints is called requirements engineering.
• There are different levels of abstraction for the term Requirement.
• Some of the problems that arise during the requirements engineering process are a
result of failing to make a clear separation between the different levels of
description.

Basics of software engineering 12/22/2024 2

 Continued…
• The different levels of the term requirement abstraction can be distinguished using
the following terms:-
User requirements:- are statements in natural languages plus diagrams of what
services the system is expected to provide and the constraints under which it must
operate.
System requirements:-set out the system’s functions, services and operational
constraints in detail. define exactly what is to be implemented.
• So it is good to have different levels of system description to communicate with
different kind of readers about the system.

Basics of software engineering 12/22/2024 3

 Types of requirements
• Functional requirements: Statements of services that the system should provide, how the
system should react to particular inputs and how the system should behave in particular
situations.
Examples of functional requirement:
• Requirement #1:
The system shall solve a quadratic equation using the following formula. X=(- b + sqrt (b 2 - 4
* a * c))/2 * a
Requirement #2:
The user shall be able to search either the entire database of patients or select a subset from it
(admitted patients or patients with asthma, etc)
Requirement #3:
The system shall provide appropriate viewers for the user to read documents in the document
Basics of software engineering 12/22/2024 4
 Continued…
• Nonfunctional requirements: describe user-visible aspects of the system that are
not directly related with the functional behavior of the system.
Nonfunctional requirements include quantitative constraints, such as response
time (i.e., how fast the system reacts to user commands) or accuracy (i.e., how
precise are the system’s numerical answers).
• Pseudo requirements: requirements imposed by the client that restrict the
implementation of the system.
 Typical pseudo requirements are the implementation language and the
platform on which the system is to be implemented.

Basics of software engineering 12/22/2024 5

 3.2 Requirements engineering processes
• Requirements engineering aims at defining the requirements of the system under
construction.
• Requirements engineering includes two main activities; requirements elicitation,
which results in the specification of the system that the client understands, and
analysis, which results into an analysis model that the developers can
unambiguously interpret.
• The processes used for RE vary widely depending on the application domain, the
people involved and the organization developing the requirements.

Basics of software engineering 12/22/2024 6

 Continued…
• However, the Requirement Engineering process consists four high-level(generic)
sub process.
Feasibility study:- assessing whether the system is useful to the business
Requirements elicitation and analysis (Requirement discovery and
Requirement specification )
Requirements validation:- Checking that the requirements actually define the
system that the customer wants.
Requirements management:- planning and managing requirement change

Basics of software engineering 12/22/2024 7

 The requirements engineering process
Feasibility Studies
• 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 engineered using current technology and within budget;
If the system can be integrated with other systems that are used.

Basics of software engineering 12/22/2024 8

 Requirement Elicitation and analysis
• 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, engineers involved in maintenance, domain
experts, trade unions, etc.
• These are called stakeholders.
• Requirements elicitation is about communication among developers, clients, and
users for defining a new system.
• Requirements elicitation is the more challenging of the two because it requires the
collaboration of several groups of participants with different backgrounds.
Basics of software engineering 12/22/20249
 Continued…
• The client, the developers, and the users identify a problem area and define a
system that addresses the problem.
• Such a definition is called a system specification.
• The system specification is structured and formalized during analysis to produce
an analysis model.
• Both system specification and analysis model represent the same information.
• They differ only in the language and notation they use.

Basics of software engineering 12/22/2024 10

 Continued…
• The system specification is written in natural language, whereas the analysis
model is usually expressed in a formal or semiformal notation.
• The system specification supports the communication with the client and users.
• The analysis model supports the communication among developers.
• They are both models of the system in the sense that they attempt to accurately
represent the external aspects of the system.
• Given that both models represent the same aspects of the system.
• Requirements elicitation and analysis occur concurrently and iteratively.

Basics of software engineering 12/22/2024 11

 Problems of requirements elicitation and analysis
• Stakeholders don’t know what they really want.
• Stakeholders express requirements in their own terms.
• Different stakeholders may have conflicting 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.

Basics of software engineering 12/22/2024 12

 Elicitation and Analysis Process activities
• Requirements discovery
Interacting with stakeholders to discover their requirements.
The process of gathering information about the proposed and existing systems and distilling the
user and system requirements from this information.
Sources of information include documentation, system stakeholders and the specifications of
similar systems.
• Requirements classification and organization
Groups related requirements and organizes them into coherent clusters.
• Prioritization and negotiation
Prioritizing requirements and resolving requirements conflicts.
• Requirements documentation
Basics of software engineering
Requirements are documented.
12/22/2024 13
 Continued…
Once the requirement specification is done, we need to do the following activities
to have the analysis model.
Identifying actors
Identifying scenarios
Identifying use cases
Refining use cases
Identifying relationships among use cases
Identifying participating objects
Identifying nonfunctional requirements

Basics of software engineering 12/22/2024 14

 Specific elicitation techniques
• Interviews
• Scenarios
• Observations and social analysis
• Requirements reuse
• Prototyping
 Interviews
• The requirements engineer or analyst discusses the system with different
stakeholders and builds up an understanding of their requirements.
• Types of interview
Closed interviews. The requirements engineer looks for answers to a pre-
defined set of questions
Open interviews There is no predefined agenda and the requirements engineer
discusses, in an open-ended way, what stakeholders want from the system.
 Interviewing essentials
• Interviewers must be open-minded and should not approach the interview with
pre-conceived notions about what is required
• Stakeholders must be given a starting point for discussion.
• This can be a question, a requirements proposal or an existing system
• Interviewers must be aware of organisational politics - many real requirements
may not be discussed because of their political implications
 Interview Steps
• Prepare
• Conduct
Opening
Body
Closing
• Follow through
 Scenarios
• Scenarios are stories which explain how a system might be used. They should
include
a description of the system state before entering the scenario
the normal flow of events in the scenario
exceptions to the normal flow of events
information about concurrent activities
a description of the system state at the end of the scenario
• Scenarios are examples of interaction sessions which describe how a user interacts
with a system
• Discovering scenarios exposes possible system interactions and reveals system
facilities which may be required
 Scenarios and OOD
• Scenarios are an inherent part of some object-oriented development methods
• The term use-case (i.e. a specific case of system usage) is sometimes used to refer
to a scenario
• There are different views on the relationship between use-cases and scenarios:
A use-case is a scenario
A scenario is a collection of use-cases.
Therefore, each exceptional interaction is represented as a separate use-case
 Observation and social analysis
• People often find it hard to describe what they do because it is so natural to them.
• Sometimes, the best way to understand it is to observe them at work
• Ethnography is a technique from the social sciences which has proved to be
valuable in understanding actual work processes
• Actual work processes often differ from formal, prescribed processes
• An ethnographer spends some time observing people at work and building up a
picture of how work is done
 Ethnography guidelines
• Assume that people are good at doing their job and look for non-standard ways of
working
• Spend time getting to know the people and establish a trust relationship
• Keep detailed notes of all work practices.
• Analyse them and draw conclusions from them
• Combine observation with open-ended interviewing
• Organise regular de-briefing session where the ethnographer talks with people
outside the process
• Combine ethnography with other elicitation techniques
 Requirements reuse
• Reuse involves taking the requirements which have been developed for one
system and using them in a different system
• Requirements reuse saves time and effort as reused requirements have already
been analysed and validated in other systems
• Currently, requirements reuse is an informal process but more systematic reuse
could lead to larger cost savings
 Reuse possibilities
• Where the requirement is concerned with providing application domain
information.
• Where the requirement is concerned with the style of information presentation.
• Reuse leads to a consistency of style across applications.
• Where the requirement reflects company policies such as security policies.
 Prototyping
• A prototype is an initial version of a system which may be used for
experimentation
• Prototypes are valuable for requirements elicitation because users can
experiment with the system and point out its strengths and weaknesses.
• They have something concrete to criticise
• Rapid development of prototypes is essential so that they are available early in
the elicitation process
 Prototyping benefits
• The prototype allows users to experiment and discover what they really need to
support their work
• Establishes feasibility and usefulness before high development costs are incurred
• Essential for developing the ‘look and feel’ of a user interface
• Can be used for system testing and the development of documentation
• Forces a detailed study of the requirements which reveals inconsistencies and
omissions
 Requirements validation
• 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.

Basics of software engineering 12/22/2024 27

 Requirements checking/assuring
• 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?

Basics of software engineering 12/22/2024 28

 Requirements validation techniques
• 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.

Basics of software engineering 12/22/2024 29

 Requirements reviews(one of the techniques)
• 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.

Basics of software engineering 12/22/2024 30

 Review checks
• 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?

Basics of software engineering 12/22/2024 31

 Requirements Management
• Requirements management is the process of managing changing requirements
during the requirements engineering process and system development.
• Requirements are inevitably incomplete and inconsistent.
New requirements emerge during the process as business needs change and a
better understanding of the system is developed;
Different viewpoints have different requirements and these are often
contradictory.

Basics of software engineering 12/22/2024 32

 Requirements changes
• The priority of requirements from different viewpoints changes during the
development process.
• System customers may specify requirements from a business perspective that
conflict with end-user requirements.
• The business and technical environment of the system changes during its
development.

Basics of software engineering 12/22/2024 33

 Requirements evolution

Basics of software engineering 12/22/2024 34

 Enduring and volatile requirements(from
requirement change perspective)
• 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.
In a hospital, requirements derived from health-care policy

Basics of software engineering 12/22/2024 35

 Requirements change management
• Should apply to all proposed changes to the requirements.
• Principal stages
Problem analysis. Discuss requirements problem and propose change;
Change analysis and costing. Assess effects of change on other
requirements;
Change implementation. Modify requirements document and other
documents to reflect change.

Basics of software engineering 12/22/2024 36

End of the chapter!
Thank you!
?
37