Chapter 3:Requirements

Elicitation
By: Tsega A.(MSc)
 Overview

Requirements 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 which is called a
requirements specification.

The requirements specification is structured and formalized
during analysis to produce an analysis model and serves as a
contract between the client and developers.

Both requirements specification and analysis model represent the
same information. They differ only in the language they use.
 The first one is written in natural language and the second one
is expressed in a formal or semi-formal notation.
 The first supports communication between clients and users
and the second supports communication among developers.

Requirements elicitation and analysis focus only on
the user’s view of the system.

For example,
 the system functionality,
 the interaction between the user and the system,
 the errors that the system can detect and handle,
 and the environmental conditions in which the system
functions are part of the requirements.

The system structure, the implementation technology
selected to build the system, the system design, the
development methodology, and other aspects not
directly visible to the user are not part of the
requirements.
 Activities in Requirement
Elicitation

Identifying actors: During this activity, developers identify
the different types of users the future system will support.

Identifying scenarios: During this activity, developers
observe users and develop a set of detailed scenarios for
typical functionality provided by the future system.
 Scenarios are concrete examples of the future system in use.

Identifying 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.
 Whereas scenarios are concrete examples illustrating a single
case, use cases are abstractions describing all possible cases.

Refining use cases: During this activity,
developers ensure that the requirements
specification is complete by detailing each
use case and describing the behavior of
the system in the presence of errors and
exceptional conditions.

Identifying relationships among use
cases: During this activity, developers
identify dependencies among use cases.

Identifying nonfunctional requirements:
During this activity, developers, users, and
clients 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, the resources it consumes,
its security, and its quality.
Requirements Elicitation Concepts


Functional Requirements:

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.

Nonfunctional requirements:

describe aspects of the system that are
not directly related to the functional
behavior of the system.

include a broad variety of requirements
that apply to many different aspects of the
system, from usability to performance.

Here are the categories of non functional
requirements:

Usability is the ease with which a user can
learn to operate, prepare inputs for, and
interpret outputs of a system or component.
Usability requirements include, for example,
 conventions adopted by the user interface,
 the scope of online help, and the level of user
documentation.
 Often, clients address usability issues by
requiring the developer to follow user interface
guidelines on color schemes, logos, and fonts.

Reliability is the ability of a system or component to
perform its required functions under stated conditions for
a specified period of time. Reliability requirements
include,
 for example, an acceptable mean time to failure and
the ability to detect specified faults or to withstand
specified security attacks.
 Dependability includes

reliability,

robustness (the degree to which a system or
component can function correctly in the presence
of invalid inputs or stressful environment
conditions), and

Performance requirements are concerned with
quantifiable attributes of the system, such as
response time (how quickly the system reacts to a
user input),

Throughput (how much work the system can
accomplish within a specified amount of time),
 availability (the degree to which a system or component
is operational and accessible when required for use),
 and accuracy.
 Completeness, Consistency, Clarity, and
Correctness

Requirements are continuously validated with the client and
the user.

Requirement validation involves checking that the
specification is complete, consistent, unambiguous, and
correct.

It is complete if all possible scenarios through the system
are described, including exceptional behavior (i.e., all
aspects of the system are represented in the requirements
model).

The requirements specification is consistent if it does not
contradict itself.

The requirements specification is unambiguous if exactly
 Realism, Verifiability, and Traceability

The requirements specification is realistic if the system can be implemented
within constraints.

The requirements specification is verifiable if, once the system is built,
repeatable tests can be designed to demonstrate that the system fulfills the
requirements specification.

The following requirements are 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.

A requirements specification is traceable if each requirement can be traced
throughout the software development to its corresponding system functions,
and if each system function can be traced back to its corresponding set of
 Requirements Elicitation
Activities

mapping a problem statement into a requirements
specification that represent as a set of actors, scenarios,
and use cases.

It also discusses heuristics and methods for eliciting
requirements from users and modeling the system in
terms of these concepts.

Requirements elicitation activities include:
 Identifying Actors
 Identifying Scenarios
 Identifying Use Cases
 Identifying Relationships Among Actors and Use Cases
 Identifying Initial Analysis Objects.
 Identifying Nonfunctional Requirements.

Identifying Actors:

Actors represent external entities that interact
with the system.

An actor can be human or an external system. In
the SatWatch example, the watch owner, the
GPS satellites, and the WebifyWatch serial
device are actors.

Identifying Scenarios:

A scenario is a concrete, focused, informal description of a
single feature of the system from the viewpoint of a single
actor.

Scenarios cannot (and are not intended to) replace use
cases, as they focus on specific instances and concrete
events (as opposed to complete and general descriptions).

However, scenarios enhance requirements elicitation by
providing a tool that is understandable to users and clients.

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.

A use case is initiated by an actor. After its initiation, a use case
may interact with other actors, as well.

A use case represents a complete flow of events through the
system

Describing the flow of events of a use case enables developers
and clients to discuss the interaction between actors and system.

This results in many decisions about the boundary of the system,
that is, about deciding which actions are accomplished by the actor
and which actions are accomplished by the system.
Identifying Relationships among Actors and Use Cases:

Relationships among actors and use cases enable the
developers and users to reduce the complexity of the model
and increase its understandability.

We use communication relationships between actors and use
cases to describe the system in layers of functionality.

We use extend relationships to separate exceptional and
common flows of events.

We use include relationships to reduce redundancy among use
cases.
Identifying Initial Analysis Objects:

During requirements elicitation, participating objects
are generated for each use case.

If two use cases refer to the same concept, the
corresponding object should be the same.

If two objects share the same name and do not
correspond to the same concept, one or both
concepts are renamed to acknowledge and
emphasize their difference.

This consolidation eliminates any ambiguity in the
terminology used.

Heuristics for identifying initial analysis objects:
 Terms that developers or users must clarify to understand
the use case
 Recurring nouns in the use cases (e.g., Incident)
 Real-world entities that the system must track (e.g.,
FieldOfficer, Resource)
 Real-world processes that the system must track
(e.g.EmergencyOperationsPlan)
 Use cases (e.g., ReportEmergency)
 Data sources or sinks (e.g., Printer)
 Artifacts with which the user interacts (e.g., Station)
Identifying Nonfunctional Requirements:

Nonfunctional requirements describe aspects of
the system that are not directly related to its
functional behavior.

span a number of issues, from user interface look
and feel to response time requirements to security
issues.

Nonfunctional requirements are defined at the
same time as functional requirements because
they have as much impact on the development
and cost of the system.
 Managing Requirements
Elicitation
Negotiating Specifications with Clients: Joint Application
Design(JAD):

JAD is a requirements method developed at IBM at the end of the
1970s.

Users, clients, developers, and a trained session leader sit
together in one room to present their viewpoints, listen to other
viewpoints, negotiate, and come to a mutually acceptable solution.

The outcome of the workshop, the final JAD document, is a
complete requirements specification document that includes
definitions of data elements, work flows, and interface screens.

Because the final document is jointly developed by the
stakeholders, the final JAD document represents an agreement
among users, clients, and developers, and thus minimizes
requirements changes later in the development process.
 Maintaining Traceability

Traceability is the ability to follow the life of a requirement.

includes tracing where the requirements came from (e.g., who
originated it, which client need does it address)

to which aspects of the system and the project it affects

Traceability enables developers to show that the system is complete,
testers to show that the system complies with its requirements,
designers to record the rationale behind the system, and maintainers
to assess the impact of change.

The simplest approach to maintaining traceability is to use cross-
references among documents, models, and code artifacts.

Each individual element (e.g., requirement, component, class,
operation, test case) is identified by a unique number.

Dependencies are then documented manually as a textual cross-
reference containing the number of the source element and the
number of the target element.
 Documenting Requirements
Elicitation

The results of the requirements elicitation and the
analysis activities are documented in the Requirements
Analysis Document (RAD).

This document completely describes the system in terms
of functional and nonfunctional requirements.

The audience for the RAD includes the client, the users,
the project management, the system analysts (i.e., the
developers who participate in the requirements), and the
system designers (i.e., the developers who participate in
the system design).

The first part of the document, including use cases and
nonfunctional requirements, is written during
requirements elicitation.

The first section of the RAD is an Introduction. Its purpose is to
provide a brief overview of the function of the system and the
reasons for its development, its scope, and references to the
development context.

The second section, Current system, 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
current system.

Otherwise, this section describes how the tasks supported
by the new system are accomplished now.

The third section, Proposed system, documents the requirements
elicitation and the analysis model of the new system. It is divided
into four subsections:

Overview presents a functional overview of the system.

Functional requirements describes the high-level
functionality of the system.

Nonfunctional requirements describes user-level
requirements that are not directly related to functionality.
 This includes usability, reliability, performance, supportability,
implementation, interface, operational, packaging, and legal
requirements.

System models describes the scenarios, use cases, object
model, and dynamic models for the system.
 This section contains the complete functional specification, including
mock-ups illustrating the user interface of the system and navigational
paths representing the sequence of screens.
 The subsections Object model and Dynamic model are written during the
Analysis activity.
 Requirements Analysis Document

1. Introduction 
3.3 Nonfunctional

1.1 Purpose of the system
requirements

1.2 Scope of the system 
3.3.1 Usability

1.3 Objectives and 
3.3.2 Reliability
success criteria of the
project 
3.3.3 Performance

1.4 Definitions, acronyms, 
3.3.4 Supportability
and abbreviations

1.5 References

3.3.5 Implementation

1.6 Overview 
3.3.6 Interface

2. Current system 
3.3.7 Packaging

3. Proposed system

3.1 Overview

3.3.8 Legal

3.2 Functional  3.4 System models
requirements
 3.4.1 Scenarios