Chapter 3
Requirements Elicitation
Requirement: A feature the system must have and A constraint the
system must satisfy.
Overview of requirements elicitation
Requirement’s elicitation focuses on describing the purpose
of the system.
The client, the developers, and the users identify a problem
area and define a system that addresses the problem.
Definition of the system in terms understood by customer
(“Requirements specification”).
Requirement Elicitation is also called as Requirement
Gathering, in which requirements are collected from User,
Stakeholders, and Customer to build the system.
Requirements elicitation techniques include interviews,
questionnaires, task analysis, domain analysis, user
observation, use cases, role playing and prototyping by using
this practices quality of the requirements are satisfied.
Compiled By Martha. M. (MSc.) 2
Cont...
The system specification supports the communication with the
client and users.
The analysis model supports the communication among
developers.
Both system specification and analysis are attempt to accurately
represent the external aspects of the system.
Requirements elicitation/specification and analysis occur
concurrently and iteratively.
Compiled By Martha. M. (MSc.) 3
Compiled By Martha. M. (MSc.) 4
Requirements Elicitation Concepts
The main requirements elicitation concepts are:
Functional requirements
Nonfunctional and pseudo-requirements
Levels of descriptions
Correctness, completeness, consistency, clarity, and
Realism.
Verifiability and traceability.
Compiled By Martha. M. (MSc.) 5
Functional Requirements
Describes functionality of system or system services (what
system should do).
And also describe the interactions between the system and its
environment independent of its implementation.
The environment includes the user and any other external system
with which the system interacts.
For example, functional requirements for wrist watch, a watch
that resets itself without user intervention and displays the
time based on its current location.
Another example for system functional requirements are:
The SW system take an Input and
Provide Output based on input,
And also may be searching data based your request form the specified
database in system.
Compiled By Martha. M. (MSc.) 6
Non-functional requirements
describe user-visible aspects of the system that are not directly
related with the functional behavior of the system.
It include quantitative constraints such as response time (i.e.,
how fast the system reacts to user commands).
Example of non-function requirements of system:
Usability:- the system is easy to use.
Reliability:- robustness (ability of a system to maintain a function)
Performance:- response time, scalability, throughput
Supportability:-Adaptability, Maintainability.
System development process and usage documentation.
Compiled By Martha. M. (MSc.) 7
Pseudo-requirements
Pseudo-requirements are 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.
Example pseudo requirement for wrist watch will be java
language.
Compiled By Martha. M. (MSc.) 8
Levels of description
Requirements describe a system and its interaction with the
surrounding environment, such as the users, their work
processes, and other systems.
Most requirements analysis methods have focused on
describing the system. When using use cases and scenarios, it
becomes apparent.
In general, there are four levels of description, which can
uniformly be described with use cases.
Compiled By Martha. M. (MSc.) 9
Correct, Complete, Consistency, Clarity, and Realism
• Requirements are continuously validated with client and user.
• Validation is a critical step in the development process, given
that both the client and the developer are dependent on the
system specification.
• Requirement validation involves checking if the specification
is:-
correct (everything in the requirements accurately represents
an aspect of the system),
complete (all aspects of the system are represented in the
requirements),
Consistent (the system requirements don’t contradict itself),
Unambiguous (if exactly one system is defined), and
realistic(the system can be implemented within constraints).
Compiled By Martha. M. (MSc.) 10
Verifiability and Traceability
• They are desirable properties of a system specification.
• The specification is verifiable if, once the system is built;
• a repeatable test can be designed to demonstrate that the system
fulfills the requirement.
• A system specification is traceable if each system function can
be traced to its corresponding set of requirements.
Compiled By Martha. M. (MSc.) 11
Requirements Elicitation Activities
Identifying:
• actors:- Actors represent external entities that interact with the
system. Developers identify the d/t types of users the future
system will support.
• scenarios:- Scenarios:- is “a narrative description of what
external environment or people do when during interacting
with system. Developers observe users and develop a set of
detailed scenarios for typical functionality provided by the
future system.
• use cases:- once developers and users agree on a set of
scenarios, developers derive from the scenarios a set of use
cases that completely represent the future system.
Compiled By Martha. M. (MSc.) 12
• Refining use cases:- developers ensure that the system
specification is complete, by detailing each use case and
describing the behavior of the system in the presence of errors
and exceptional conditions.
• relationships among use cases: developers consolidate the use
case model by eliminating redundancies. This ensures that the
system specification is consistent.
• nonfunctional requirements:- developers and users agree on
aspects that are visible to the user but not directly related to
functionality. These include constraints on the performance of
the system, its documentation, resources it consumes, its
security & quality.
Developers interact the most with users and clients during
requirements elicitation.
Compiled By Martha. M. (MSc.) 13
Identify Actors
Questions whose answers identify the actors:
• Which user groups does the system support to do their work?
• Which user groups execute the system’s primary functions?
• Which user groups execute the system’s secondary functions?
• E.g., maintain or administer the system
• With which external systems does the system interact?
• E.g., hardware or software
Compiled By Martha. M. (MSc.) 14
Identify Scenarios
Scenario
• A description of what actors do as they use the system
• For each scenario, there is a:
• Use case
• Acceptance test case
Questions for identifying scenarios:
• What tasks to the actors want the system to perform?
• What data does the actor need?
• Who creates, modifies, removes that data?
Compiled By Martha. M. (MSc.) 15
Elements of a Scenario Description
• Scenario name WarehouseOnFire
• Actor instances Bob, Alice: FieldOfficer
John: Dispatcher
• Flow of events 1. Bob, driving in patrol car: notices smoke
coming out of warehouse. Partner Alice
activates Report Emergency from laptop.
2. Alice enters building’s address, location,
emergency level. Requests fire unit,
paramedics. Confirms input. Awaits ack.
3. John is alerted by his workstation’s beep.
Acks report. Allocates fire & paramedic units
to Incident site; returns ETA to Alice.
4. Alice receives ack and ETA(estimated arrival time) .
Compiled By Martha. M. (MSc.) 16
Identify Use Cases
• A scenario is an instance of a use case.
• Partition the set of scenarios into use cases.
• Keep this set compact
• Modify scenarios to increase their uniformity.
• Use case format follows.
Compiled By Martha. M. (MSc.) 17
Elements of a Use Case Description
• Use case name: ReportEmergency
• Actor[s]: Initiated by FieldOfficer, Communicates with
Dispatcher
• Entry conditions: FieldOfficer initiates ReportEmergency
function on her laptop
• Flow of events: 1. FieldOfficer fills form: select emergency
level, type, location, description, possible responses. Submits form;
2. Dispatcher acks report. Creates Incident
in DB: Invoke OpenIncident use case.
Selects response; Sends ETA.
• Exit conditions: FieldOfficer receives ETA.
• Special requirements: Ack report within 30 sec. Send ETA
within 30 more sec.
Compiled By Martha. M. (MSc.) 18
Identify Relationships among Actors & Use Cases
• Access control – which actors access which functionality – is
represented with use cases.
• Heuristics:
• Use extend relation for exceptions, optional, or rare behavior.
• Use include relation for behavior common to 2 or more use
cases.
Compiled By Martha. M. (MSc.) 19
Identify Nonfunctional Requirements
Investigate the following:
• User interface – level of expertise of user
• Documentation – User manual? The system design should be
documented. What about development process?
• Performance characteristics. How responsive should the system
be? How many concurrent users should it support?
• Error handling – How should the system handle exceptions?
Which exceptions should the system handle?
• Physical environment. Where will the system be deployed?
• Physical security: Should the system be protected against
external intrusions or against malicious users?
• Resource – constraints on memory, etc.
Compiled By Martha. M. (MSc.) 20
Managing Requirements Elicitation
• It is process of eliciting information from the users and
negotiating an agreement with a client.
I. Eliciting Information from Users: Knowledge Analysis of
Tasks (KAT)
• Task analysis was used to identify how people should be
trained.
• Task analysis has become important in the field of (HCI) for
identifying and describing the user tasks that a system should
support.
• Task analysis is based on the assumption that it is in efficient
to ask users to describe what they do and how they do it.
• It uses observation as an alternative to build an initial task
model.
Compiled By Martha. M. (MSc.) 21
KAT can be summarized by five the following steps:
1. Identifying objects and actions: Object and actions associated
with objects are identified using object-oriented analysis tech, such as
analyzing textbooks, manuals, rule books, reports, interviewing the task
performer, observing the task performer.
2. Identifying procedures: A procedure is a set of actions/series of
steps that to perform task during system development.
3. Identifying goals and sub-goals: A goal is a state to be achieved
for the task to be successful. Goals are identified through interview
during the performing a task. Sub-goals are identified by decomposing
goals.
4. Identifying importance: Each identified element is necessary for
accomplishing a goal
5. Constructing a model of the task: Corresponding goals, procedures,
and objects are related using a textual notation or a graph. Finally, the
model is validated with the task performer.
Compiled By Martha. M. (MSc.) 22
cont.
• Task analysis and KAT are not requirements elicitation methods.
• But they provide techniques for eliciting and describing application
domain knowledge.
In generally, Task analysis and KAT, its process of understanding the
work flow of the existing system by task performer.
Compiled By Martha. M. (MSc.) 23
ii. Negotiating specifications with clients: Joint Application
Design
• Joint Application Design (JAD) is effectiveness lies in that 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.
• The outcome of the workshop, the final JAD document, is a
complete system specification document that includes definitions of
data elements, work flows, and interface screens.
• Thus minimizes requirements changes later in the development
process.
Compiled By Martha. M. (MSc.) 24
iii. Validating Requirements: Usability Testing
• Finds problems with the system specification by letting the user
explore the system or only part of the system.
• There are three types of usability tests:
Scenario test: allows rapid and frequent feedback from
the user to developer.
Prototype test: presents an interface for most use cases
(without providing much or any functionality).
Product test: present functionality of the system. It can
only be conducted once most of the system is developed.
Compiled By Martha. M. (MSc.) 25
iv. Documenting Requirements Elicitation
• The results of the requirements elicitation activity and the
analysis activity are documented in the Requirements Analysis
Document (RAD).
• This document completely describes the system in terms of
functional and nonfunctional requirements and serves as a
contractual basis between the client and the developers.
• The audience for the RAD includes the client, users, project
management, system analysts (i.e. developers who
participate in the requirements), and system designers (i.e., the
developers who participate in the system design).
Compiled By Martha. M. (MSc.) 26
The first section of the RAD: Introduction
• It is provide a brief overview of functionality of the system and
the reasons for its development, its scope, and references to the
development context (e.g., related statement of the problem,
references to existing systems, feasibility studies). The
introduction also includes the objectives and success criteria of
the project.
The second section of the RAD: Current system
• It describes the current state of affairs. If the new system will
replace an existing system, this section describes the
functionality and the problems of the existing/current system.
Compiled By Martha. M. (MSc.) 27
The third section of RAD: Proposed system
• It documents the requirements elicitation and the analysis model of
the new system. It is divided into five subsections:
Overview presents a functional overview of the system.
Functional requirements described in natural language that is highlevel
functionality of the system.
A nonfunctional requirement describes user-level requirements that
are not directly related to functionality. This includes performance,
security, modifiability, error handling, hardware platform, and physical
environment.
Pseudo-requirements describe design and implementation constraints
imposed by the client. This includes the specification of the deployment
platform, implementation language, or database management system.
System models describe the scenarios, use cases, object model and
dynamic models describing the system. This section contains the complete
functional specification of the system, including mock-ups and
navigational charts illustrating the user interface of the system.
Compiled By Martha. M. (MSc.) 28
The following is an example template for a RAD:
Compiled By Martha. M. (MSc.) 29
Compiled By Martha. M. (MSc.) 30