CHAPTER THREE

REQUIREMENT ELICITATION
 An overview of requirements elicitation
• A requirement is:
o a feature that the system must have
o or a constraint that it must satisfy to be accepted by
the client
• Requirements engineering aims at defining the
requirements of the system under construction.
• Requirements engineering includes two main
activities;
i. requirements elicitation: which results in the
specification of the system that the client understands, and
ii. Analysis: which results into an analysis model that the
developers can unambiguously interpret
 An overview of requirements elicitation

• Requirements elicitation is
– about communication among developers, clients, and
users for defining a new system.
• Failure to communicate and understand each
others’ domain results in a system that is
difficult to use or that simply fails to support the
user’s work.
– Errors introduced during requirements elicitation are
expensive to correct, as they are usually discovered
late in the process, often as late as delivery.
system specification
– is the result(output) of the Requirements elicitation and
– serves as a contract between the client and the developers
• 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
– 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.
Methods for eliciting information/requirement
1. Joint Application Design (JAD)
– focuses on building consensus among developers, users, and clients
by jointly developing the system specification.
2. Knowledge Analysis of Tasks (KAT)
– focuses on eliciting information from users through observation.
3. Usability testing
– focuses on validating the requirements elicitation model with the user
through a variety of methods.
 Requirements elicitation concepts
Functional requirements
Describe the interactions between the system and
its environment independent of its implementation
– What inputs the system should accept
– What outputs the system should produce
– What data the system should store that other
systems might use
– What computations the system should perform
• The environment includes the user and any other
external system with which the system interacts
 Nonfunctional requirements
• describe user-visible aspects of the system that are not directly related with the
functional behavior of the system
• Include qualitative 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).
 Throughput
 Resource usage
 Reliability
 Availability
 Recovery from failure
 Allowances for maintainability and enhancement
 Allowances for reusability
 Levels of description
• It is necessary to describe the environment in which the system
will operate because:
– Developers usually do not initially know and understand the operating
environment and need to check their understanding with the users
– the environment is likely to change, and thus, developers should capture all
the assumptions they make about the environment
• There are four levels of description, which can uniformly be
described with use cases
1. Work division
• work processes of the users that are relevant to the system
• focus on defining the boundaries between the users and the
system
2. Application-specific system functions:
• the functions that the system provides that are related to the
application domain.
 Levels of description….
3. Work-specific system functions
• supporting functions of the system that are not directly related
with the application domain
– Eg:function like file mgt , grouping, undo etc
• These use cases will be extended during system design
– When discussing known boundary conditions, such as system
initialization, shutdown, and exception handling policies
4. Dialog
• This set of use cases describes the interactions between the users
and the user interface of the system
Correctness, completeness, consistency, clarity, and realism
• Requirements are continuously validated with the client and the
user.
• Requirement validation involves checking if the specification is
correct, complete, consistent, unambiguous, and realistic
• A specification is
1. Correct :
– it represents the client’s view of the system
– everything in the requirements model accurately represents an aspect of
the system
2. Complete
– if all possible scenarios through the system are described, including
exceptional behavior
3. Consistent
– if it does not contradict itself
4. Unambiguous:
– if exactly one system is defined (i.e,it is not possible to interpret
the specification two or more different ways).
5. Realistic
– if the system can be implemented within constraints
• The correctness and completeness of a system
specification are often difficult to establish, especially
before the system exists
• system specification serves as a contractual basis
between the client and the developers,
– the system specification must be carefully reviewed by both
parties
 Verifiability and traceability
Verifiable:
• The specification is verifiable if, once the system is built, a
repeatable test can be designed to demonstrate that the system
fulfills the requirement
• For example,
– a mean time to failure of a hundred years for SatWatch would be difficult to
achieve (assuming it is realistic in the first place)
• Examples of non verifiable requirements
 The product shall have a good user interface (good is not defined).
 The product shall be error free (requires large amount of resources to
establish).
 The product shall respond to the user with 1 second for most cases (“most
cases” is not defined).
Traceable:
• A system specification is traceable if each system function can be
traced to its corresponding set of requirements
• facilitates the development of tests and the systematic validation of
 Requirements elicitation activities.
• methods for extracting requirements from users and modeling the
system in terms of use cases, actors, scenario concepts
1. Identifying actors
• Actors represent external entities that interact with the system.
• An actor can be human or an external system.
– Eg for satwatch, watch owner and GPS satellitey are actors
– They all interact and exchange information with the SatWatch
– the watch owner wears and looks at her watch;
– the watch monitors the signal from the GPS satellites;
– the WebifyWatch downloads new data into the watch
– SatWatch interacts with GPS to compute its position
– WebifyWatch upgrades the data contained in the watch to reflect changes in
time policy (e.g., changes in daylight savings time start and end dates).
• Questions for identifying actors
 Which user groups are supported by the system to perform
their work?
 Which user groups execute the system’s main functions?
 Which user groups perform secondary functions, such as
maintenance and administration?
 Will the system interact with any external hardware or
software system?
• consolidate this list into a small number of actors, who are
different from the point of view of the usage of the system
Questions for identifying scenarios
• What are the tasks that the actor wants the system to perform?
• What information does the actor access? Who creates that data?
Can it be modified or removed? By whom?
• Which external changes does the actor need to inform the system
about? How often? When?
• Which events does the actor need to be informed by the system
about? With what latency?

• Once developers identified and described actors and scenarios,

developers formalize scenarios into use cases
– results in a shared understanding of the user work processes
and the scope of the system
 Identifying use cases
• A scenario is an instance of a use case
– a use case specifies all possible scenarios for a given piece of
functionality
– represents a complete flow of events
• A use case is initiated by an actor
– After its initiation, a use case may interact with other actors as
well
Refining use cases
 Identifying nonfunctional
Non functional requirements
 describe user-visible aspects of the system that
Are not directly related to the functional behavior of the system
Nonfunctional requirements can be elicited by investigating the
following issues.
User interface and human factors.
Documentation:
– Should only user documentation be or technical documentation for
maintenance
Hardware considerations.
– Are there hardware compatibility requirements? Will the system interact
with other hardware systems?
Performance characteristics.
– How responsive should the system be? How many concurrent users should it
support? What is a typical or extreme load?
Error handling and extreme conditions
Quality issues.
– How reliable/available/robust should the system be? What is the client’s
System modifications.
– What is the anticipated scope of future changes? Who will perform the
changes?
Physical environment.
– Are there external factors such as weather conditions that the system
should withstand?
Security issues
– Should the system be protected against external intrusions or against
malicious users? To what level?
Resource issues
– What are the constraints on the resources consumed by the system?
 Managing requirements elicitation
• Use case modeling by itself does not constitute requirements elicitation
– It only models the elicited requirements
• methods for eliciting information from the users are
1. Knowledge Analysis of Tasks
– based on the assumption that it is inefficient to ask users to describe what they do and how they
do it

• is concerned with collecting data from a variety of sources

Example
– protocol analysis,
– standard procedures,
– textbooks, interviews),
• analyzing these data to identify individual elements involved in
the task
– (e.g., objects, actions, procedures, goals, and subgoals),

• Finally constructing a model of the overall knowledge used by

2. Joint Application Design(JAD)
• the requirements elicitation work is done in one single workshop
session in which all stakeholders participate.
 Users,
 clients,
 developers,
 and a trained session leader
• sit together in one room to present their viewpoint, listen to other
viewpoints, negotiate, and agree on a mutually acceptable solution
• JAD document
– The output of JAD workshop which contains all agreed up on specifications
 3. Validating requirements: Usability testing
• Helps to finds problems with the system specification
– by letting the user explore the system or only part of the system
– the look and feel of the user interface
• the basic elements of usability testing include
 development of test objectives
 use of a representative sample of end users
 use of the system in the actual or simulated work environment
 involvement of end users
 probing of the users by the person performing the usability test
 recommendations on how to improve the system
 There are three types of usability tests:
1. Scenario test
– users are presented with a visionary scenario of the system
2. Prototype test
– users are presented with a piece of software that practically implements the
system(some use cases).
– provide a realistic view of the system to the user but expensive to build
3. Product test
– functional version of the system is used in place of the prototype

• Usability test also helps the identification of useful features for

– novice and expert users,
– when is help needed, and what type of training information is
required.
 Documenting requirements elicitation
• The results of the requirements elicitation and the analysis activity
are Requirements Analysis Document (RAD)
RAD
– describes the system in terms of functional and nonfunctional requirements
– as a contractual basis between the client and the developers.
RAD components