Requirements Elicitation – 1

Lecture # 9

1
 Requirements Engineering Process

Requirements Requirements
Requirements Requirements
Elicitation Analysis and
Specification Validation
Negotiation

User Needs,
Domain Information, Agreed
Existing System Requirements Requirements
Information, Regulations, Document
Standards, Etc.
2
 Requirements Elicitation - 1
• Elicit means to gather, acquire, extract,
and obtain, etc.
• Requirements elicitation means
gathering requirements or discovering
requirements

3
 Requirements Elicitation - 2
• Activities involved in discovering the
requirements for the system

4
Basics of Knowledge Acquisition
These are the sources of knowledge
acquisition
• Reading
• Listening
• Asking
• Observing
5
 Requirements Elicitation
Techniques
• Individual
• Group
• Modeling
• Cognitive

6
 Problems in Requirements
Elicitation
• Problems of scope
• Problems of understanding
• Problems of volatility

7
 Problems of Scope
• The boundary of the system is ill-
defined
• Unnecessary design information may
be given

8
 Problems of Understanding - 1
• Users have incomplete understanding
of their needs
• Users have poor understanding of
computer capabilities and limitations
• Analysts have poor knowledge of
problem domain

9
 Problems of Understanding - 2
• User and analyst speak different
languages
• Ease of omitting “obvious”
information
• Conflicting views of different users
• Requirements are often vague and
untestable, e.g., “user-friendly” and
“robust”
10
 Problems of Volatility
• Requirements evolve over time and
hence there are some requirements
which are bound to change during the
system development process due to one
reason or the other.

11
 Contexts in Requirements
Elicitation Process
It is important to consider the context in
which requirements are being elicited.
Requirements elicitation process may be
followed in the following contexts
• Organization
• Environment
• Project
• Constraints imposed by people 12
 Contexts in Requirements
Elicitation Process - 1
• Organization
– Submitters of input
– Users of output
– Ways in which the new system change
the business process

13
 Contexts in Requirements
Elicitation Process - 2
• Environment
– Hardware and software
– Maturity of the target system domain
– Certainty of the target system’s interfaces
to the larger system
– The target system’s role in the larger
system
14
 Contexts in Requirements
Elicitation Process - 3
• Project
– The attributes of the different stakeholder
communities, such as the end users,
sponsors, developers, and requirements
analysts. Examples of such attributes are:
• Management style
• Management hierarchy
• Domain experience
• Computer experience
15
 Contexts in Requirements
Elicitation Process - 4
• The constraints imposed by the people
– They are involved in the elicitation
process, e.g., managerial constraints
concerning cost, time, and desired quality
in the target system

16
 Requirements Elicitation
Guidelines - 1
• Assess the business and technical feasibility
for the proposed system
• Identify the people who will help specify
requirements and understand their
organizational bias
• Define the technical environment
• Identify “domain constraints” that limit the
functionality or performance of the system 17
 Requirements Elicitation
Guidelines - 2
• Define one or more requirements elicitation
methods (interviews, focus groups, team
meetings)
• Solicit participation from many people so
that requirements are defined from different
points of view; be sure to identify the
rationale for each requirement that is
recorded
18
 Requirements Elicitation
Guidelines - 3
• Identify ambiguous requirements as
candidates for prototyping
• Create usage scenarios to help
customers/users better identify
requirements

19
 Ethnomethodology
• Looks for behaviors that may be different in
a specific culture but which have the same
underlying purpose or meaning
• Conversational analysis
• Measurement of body system functions
• Non-verbal behavior studies
• Detailed video analysis
20
 Requirements and Psychology
• Errors in statements can happen in two
places
– Perception of facts – reality
– Linguistic representation of one of these
perceptions – personal reality
• To remove these errors, requirements
should be reviewed (during and after
elicitation)
21
 Use Case Modeling
• Define actors and black-box use cases
• The functional requirements of the
system are defined in terms of use
cases and actors
• The use case descriptions are a
behavioral view

22
 Summary - 1
• Introduced the concept of elicitation and
requirements elicitation process
• Basics of knowledge acquisition (reading,
listening, asking, & observing)
• Knowledge acquisition techniques
(individual, group, modeling, cognitive)
• Elicitation problems (scope,
understandability, volatility)
23
 Summary - 2
• Context (organization, environment,
project, constraints imposed by people)
• Guidelines for knowledge acquisition

24
 References
• ‘Requirements Engineering: Processes
and Techniques’ by G. Kotonya and I.
Sommerville, John Wiley & Sons,
1998

25