UNIT -2
Chapter 8
Understanding Requirements
Presented by
[Link]
Assistant Professor,
CSE
1
2
Requirements Engineering Processes
Definition: The broad spectrum of tasks and techniques that lead
to an understanding of requirements is called requirements
engineering.
Sometimes called requirements elicitation or requirements
discovery
Processes used to discover, analyse and validate system requirements
are called RE processes.
begins during the communication activity and continues into the
modeling activity
must be adapted to the needs of (4p’s) the process, the project, the
product, and the people doing the work.
4
5
6
Requirements Engineering
Tasks
It encompasses seven distinct tasks: inception, elicitation,
elaboration, negotiation, specification, validation, and
management
§ Inception—Establish a basic understanding of the problem
and the nature of the solution.
§ Elicitation—Draw out the requirements from stakeholders.
§ Elaboration—Create an analysis model that represents
information, functional, and behavioral aspects of the
requirements.
§ Negotiation —Agree on a deliverable system that is realistic
for developers and customers.
§ Specification—Describe the requirements formally or
informally.
§ Validation—Review the requirement specification for errors,
ambiguities, omissions, and conflicts.
§ Requirements management—Manage changing
requirements.
7
Requirements Engineering
Tasks
Inception—establish a basic understanding of
the problem, the people who want a solution,
the nature of the solution that is desired, and
the effectiveness of preliminary communication
and collaboration between the other
stakeholders and the software team.
8
9
10
11
The formality and format of a specification varies with the size
and the complexity of the software to be built.
12
13
14
⚫ These activities are identical to the software
configuration management (SCM) techniques
15
16
17
RE Process
18
19
20
21
22
23
24
25
Nonfunctional
Requirements
Described as a quality attribute, a
performance attribute, a security attribute,
or a general constraint on a system.
A technique called quality function
deployment (QFD),Quality function
deployment attempts to translate unspoken
customer needs or goals into system
requirements.
it is possible to define a two-phase approach
that can assist a software team and other
stakeholders in identifying non-functional
requirements.
26
During the first phase
A set of software engineering guidelines
are established for the system to be built.
It includes
✔ Best practices
✔ architectural style
✔ use of design patterns
✔ A list of NFRs (requirements that address usability,
testability, security or maintainability)
✔ A simple relationship matrix (table which contains NFR as
column labels and S/w guidelines as row labels)
✔ It helps the team to assess whether each pair of guidelines
is complementary , overlapping , conflicting , or
independent .
27
During the second phase
the team prioritizes each nonfunctional
requirement by creating a homogeneous set
of nonfunctional requirements using a set of
decision rules [Hne11] that establish which
guidelines to implement and which to reject
28
Traceability
It refers to documented links
between software
engineering work products
(e.g., requirements and test
cases).
A traceability matrix allows a
requirements engineer to
represent this relationship
Rows of the traceability matrix
are labeled using requirement
names and columns can be
labeled with the name of a
software engineering work
product
A matrix cell is marked to
indicate the presence of a link
between the two. 29
Example Requirement
Traceability matrix.
30
31
This approach is sometimes called a facilitated
application specification technique (FAST).
32
A one- or two-page “product request” is generated during
inception
33
Example Product request -
Safe home application by a
marketing person
Our research indicates that the market for
home management systems is growing at a
rate of 40 percent per year. The first
SafeHome function we bring to market
should be the home security function. Most
people are familiar with “alarm systems” so
this would be an easy sell.
The home security function would protect
against and/or recognize a variety of
undesirable “situations” such as illegal
entry, fire, flooding, carbon monoxide
levels, and others. It’ll use our wireless
sensors to detect each situation, can be
programmed by the homeowner, and will
automatically telephone a monitoring
agency when a situation is detected.
34
Collaborative requirement
gathering...
If only one user defines all requirements
then acceptance risk is high
So requirements are elicited from a
representative cross section of users.
But even with additional information,
ambiguity is present, omissions are likely
to exist, and errors might occur.
The proceeding Functional description will
suffice
35
Collaborative requirement
gathering...
While reviewing- product request
each attendee is asked to make a list of objects
that are part of the environment that
surrounds the system, other objects that are to be
produced by the system, and objects that are used
by the system to perform its functions.
And each attendee is asked to make another list of
services (processes or functions) that manipulate
or interact with the objects
Finally, lists of constraints (e.g., cost, size,
business rules) and performance criteria (e.g.,
speed, accuracy) are also developed.
36
Object s and services in
Safehome
Objects described for SafeHome
might include the control panel,
smoke detectors, window and
door sensors, motion
detectors, an alarm, an event (a
sensor has been activated), a
display, a PC, telephone
numbers, a telephone call, and
so on.
The list of services might include
configuring the system, setting
the alarm, monitoring the
sensors, dialing the phone,
programming the control
panel, and reading the display 37
Collaborative requirement
gathering...
An object or service described on a list will require
further explanation. To accomplish this,
stakeholders develop mini-specifications for entries
on the lists or by creating a use case that involves
the object or service
The mini-specs are presented to all stakeholders
for discussion. Additions, deletions, and further
elaboration are made.
During all discussions, the team may raise an issue
that cannot be resolved during the meeting. An
issues list is maintained so that these ideas will be
acted on later
38
The mini-spec for the
SafeHome object Control Panel
The control panel is a wall-mounted unit that
is approximately 230 x 130 mm in size.
The control panel has wireless connectivity to
sensors and a PC. User interaction occurs
through a keypad containing 12 keys. A 75 x
75 mm OLED color display provides user
feedback. Software provides interactive
prompts, echo, and similar functions
39
For Non functional
requirements
Among the questions that must be answered
[Lag10] are as follows:
• Can we build the system?
• Will this development process allow us to
beat our competitors to market?
• Do adequate resources exist to build and
maintain the proposed system?
• Will the system performance meet the
needs of our customers?
40
41
42
43
44
45
46
47
Agile Requirements
Elicitation
Requirements are elicited by asking
all stakeholders to create user
stories .
User stories can be written on small
note cards, making it easy for
developers to select and manage a
subset of requirements to
implement for the next product
increment.
Small notes are used by the
developers to shift their focus to
communicate with the stakeholders
on selected requirements (not on
agenda) 48
Agile Requirements
Elicitation
Even though its attractive, overall business
goal and non functional requirement is often
lacking
rework is required to accommodate
performance and security issues
user stories may not provide a sufficient basis
for system evolution
49
Service-Oriented Methods
views a system as an aggregation of
services
A service can be “as simple as providing
a single function, for example, a
request/ response-based mechanism.
Ex Web services API
Requirements elicitation in
service-oriented development focuses
on the definition of services to be
rendered by an application.
A touchpoint represents an opportunity
for the user to interact with the system
to receive a desired service.
50
Service-Oriented Methods
Most service design methods emphasize
understanding the customer, thinking
creatively, and building solutions quickly
To achieve these goals, requirements
elicitation can include ethnographic
studies, innovation workshops, and early
low-fidelity prototypes.
Analysts need strategies to discover and
document requirements about the
desired qualities of new user
experiences. User stories are helpful in
this regard. (user brand and
stakeholder’s perception) 51
Eliciting Requirements
52
Developing Use cases
53
Primary and Secondary
actors
Primary actors interact to achieve
required system function and derive the
intended benefit from the system. They
work directly and frequently with the
software.
Secondary actors support the system so
that primary actors can do their work
Once actors have been identified, use cases
can be developed. Jacobson suggests a
number of questions that should be
answered by a use case:
54
Each scenario answers the
following questions:
55
Safe Home application
✔ Four actors:
✔ homeowner(a user),
✔ setup manager (likely
the same person as
homeowner, but
playing a different role),
✔ sensors (devices
attached to the system),
✔ the monitoring and
response subsystem
(the central station that
monitors the SafeHome
home security function). 56
Safe home application
we consider only the homeowner actor. The
homeowner actor interacts with the home
security function in a number of different
ways using either the alarm control panel or a PC.
The homeowner
✔ (1) enters a password to allow all other
interactions,
✔ (2) inquires about the status of a security zone,
✔ (3) inquires about the status of a sensor,
✔ (4) presses the panic button in an emergency,
✔ (5) activates/deactivates the security system.
57
Use Case template
58
59
Use-Case Diagram
60
Develop a complete use case for
Making a withdrawal at an
ATM.
Primary actor: Withdrawal person
Goal in context: To get the money from the
ATM
Preconditions: ATM is still work and
withdrawal person hold his/her card.
Trigger: The withdrawal person inserts the
card into the card slot.
Scenario:
✔ Withdrawal person: inserts the card into the
slot.
✔ Withdrawal person: enters the password.
✔ Withdrawal person: selects “withdraw”.
✔ Withdrawal person: take money.
✔ Withdrawal person: selects “exit”.
61
✔ Withdrawal person: removed card.
Exceptions:
✔ Card not being valid or ATM machine does
not have the required cash.
✔ Password is incorrect: homeowner re-enters
correct password.
✔ Withdraw is selected: the cash in the ATM is
insufficient withdrawal person can’t get the
money.
✔ Exit is selected: there is something wrong in
the machine and the card can’t come out.
Priority: Must be implemented.
When available: First increment.
Frequency of use: Many times, per day.
Channel to actor: Via operation panel.
Secondary actors: Record database
Channels to secondary actors:
Record database: Internet
62
Use case diagram
63
1. What do use case “exceptions” represent?
It represent some error conditions the actor might
encounter while using some function the system
provided.
2. Write a user story for Making a withdrawal at an
ATM
As a customer, I want to withdraw cash from my
account in an ATM so that I can withdraw money
without going to the bank and stand in a line. In
this case, I will make sure that my account has that
much of money and my card is valid and the ATM
must have cash. When I make a cash transaction,
ensure that my account is debited and ATM will
dispense me with cash.
64
Analysis model is a snapshot
of requirements at any given
time
Analysis model is to provide a
description of the required
informational, functional, and
behavioral domains for a
computer-based system
65
Elements of the Analysis
Model
A number of different modes of
representation to depict the
analysis model from different view
points
An approach that has a higher
probability of uncovering
omissions, inconsistencies, and
ambiguity.
A set of generic elements is
common to most analysis models.
66
67
Scenario based elements - Use case
diagram for hospital reception
module
68
69
Class-based elements
classes—a collection of things that have
similar attributes and common behaviors
70
Class
Diagram
71
Behavioral elements
The state diagram is one method for
representing the behavior of a system by
depicting its states and the events that cause
the system to change state.
A state is any observable mode of
behavior.
In addition, the state diagram indicates what
actions (e.g., process activation) are taken as
a consequence of a particular event
72
State Diagram
73
State chart diagram for ATM
transaction
74
75
Agile Requirements
Engineering
The agile process encourages the early
identification and implementation of the
highest priority product features
Addresses some common issues in Agile
projects
high requirements volatility, incomplete
knowledge of development technology,
and customers not able to articulate
their visions until they see a working
prototype
The agile process interleaves requirements
engineering and design activities.
76
Requirements for Self-Adaptive
Systems
Self-adaptive systems can reconfigure
themselves, augment their functionality, protect
themselves, recover from failure, and
accomplish all of this while hiding most of their
internal complexity from their users
An example of a self-adaptive system is a
“location aware” app that adapts its behavior to
the location of the mobile platform on which it
resides
77
What are the characteristics
of a self adaptive system?
It encompass the notion of variability or
flexibility while at the same time specifying
either a functional or quality aspect of the
software product.
Variability might include timing uncertainty,
user profile differences (e.g., end users
versus systems administrators),
behavior changes based on problem
domain (e.g., commercial or educational),
or predefined behaviors exploiting system
assets.
78
79
Negotiating Requirements
Fricker and his colleagues suggest replacing the
traditional handoff of requirements specifications
to software teams with a bidirectional
communication process called handshaking
Handshaking allows detailed requirements to be
delegated to software teams.
The teams need to elicit requirements from
customers (e.g., product users and domain )
Handshaking tends to improve identification,
analysis, and selection of variants and promotes
win-win negotiation.
80
81
82