LECTURE 5: Requirements Engineering

Ivan Marsic
Rutgers University
 Topics

 Requirements Engineering Components

 Requirements and User Stories
 Agile Methods for Effort Estimation and Work
Organization
 Requirements Analysis
 Acceptance Tests
 Types of Requirements

2
 Software Requirements
 A requirement specifies the business functions that the user will be able
to perform using the system-to-be in different “situations” or “contexts”,
and the kind of experience the user will have during this work
– Other concerns, such as how the system will manage the resources (computing,
network, …), how the system will manage and protect user’s data, etc.
 User requirements will often be high-level, vague and incomplete. They
are more like high-level goals, or business goals, rather than software
requirements needed by the developer
 When trying to achieve a given high-level goal, we will need to
consider what matters, what are the important parameters, so that we
can derive the detailed technical requirements
 Only based on deeper understanding of detailed issues, we can
identify important "scenarios" or "situations" and identify what
parameters should be considered in each situation
 Then using these parameters, we decide what the system should do, or
how to respond to this situation (i.e., inputs)

3
 Requirements Process

Aspect-Oriented
Requirements

Object-Oriented
Analysis & Design

Requirements Requirements Requirements

gathering analysis specification

Structured
Analysis & Design

Agile Development
User Stories

4
 Requirements Engineering
Components
 Requirements gathering
– (a.k.a. “requirements elicitation”) helps the customer to
define what is required: what is to be accomplished,
how the system will fit into the needs of the business,
and how the system will be used on a day-to-day basis
 Requirements analysis
– refining and modifying the gathered requirements
 Requirements specification
– documenting the system requirements in a semiformal
or formal manner to ensure clarity, consistency, and
completeness
5
Practical Requirements Engineering

 Test your idea in practice and use the result in

further work, iterating through these creative
and evaluative steps until a solution is
reached
– No one can know all the constraints for a solution
before they go through the solving experience
 Define the criteria for measuring the success
(“acceptance tests”)
 Avoid random trial-and-error by relying on
domain knowledge (from publications or
customer expertise)
6
 Requirements and Specification

Problem domain Software (Solution) domain

Describes
problem

Specifi
Requirements Program
Customer cation

Specifies

Analyzes Develops

We receive “customer
problem statement,” Software Engineer

not the requirements!

 Requirements Derivation
Detecting that a problem exists is different from defining the problem and
its causes, and solution constraints.
Depending on the cause, the solution will be different.
Requirements are determined by:
 Judgment about customer’s business needs and causes preventing
their achievement
 Conditions on solutions imposed by real-world constrains:
– Physical
– Social/Cultural
– Legal
– Financial
– …
 Threats created by adversaries

 Requirements are not simply desires!

 Requirements are desires adjusted to real-world constraints and threats

8
 Problem Analysis Examples
 Traffic Monitoring:
– Problem: User is delayed to work and needs help
– Cause A: Traffic is unpredictable (predictably high if repeated delays?!)
– Cause B: User is unfamiliar with the route
– Cause C: User has a habit of starting late
 Restaurant Automation:
– Problem: Restaurant is operating at a loss and customers are unhappy
– Cause A: Staff is encumbered with poor communication and clerical duties, resulting in
inefficiencies
– Cause B: The menu does not match the likeliest customer’s taste
– Cause C: Staff is misbehaving with customers or mismanaging the food supplies
 Health Monitoring:
– Problem: User is leading unhealthy lifestyle and experiencing health problems
– Cause A: User is trying to be active but unsure about sufficient level of activity
– Cause B: User is trying to be active but too busy with other duties
– Cause C: User cannot find affordable solutions for active lifestyle
– Cause D: User has poor sleep
– Cause E: User is aware of issues but not motivated to act

9
Problem Example: Safe Home Access

 Problem detected:
difficult access or unwanted intrusion
(plus: operating household devices and
minimizing living expenses)
 Analysis of the Causes:
– User forgets to lock the door or turn off the devices
– User loses the physical key
– Inability to track the history of accesses
– Inability to remotely operate the lock and devices
– Intruder gains access
 System Requirements: based on the selected
causes

10
 Requirements as User Stories

As a tenant, I can unlock the doors to enter my apartment.

user-role capability business-value

(benefactor)

 Preferred tool in agile methods.

 Focus on the user benefits, instead on system features as in older,
IEEE Standard 830 type “requirements”.
 User stories are less formal and emphasize automated acceptance tests.
11
Example User Story Requirements
Identifier User Story Size

REQ-1 As an authorized user, I will be able to keep the doors by default always locked. 4 points
REQ-2 As an authorized user, I will be able to unlock the doors using a valid key. 7 points
An intruder will not be able to unlock the doors by guessing a valid key;
REQ-3 7 points
the system will block upon a “dictionary attack.”
REQ-4 The door will be automatically locked after being open for a defined period of time. 6 pts
REQ-5 As a user, I will have the door keypad backlit when dark for visibility. 3 pts
REQ-6 Anyone will be able to lock the doors on demand. 2 pts

REQ-7 As a landlord, I will be able at runtime to manage user authorization status. 10 pts
As an authorized user, I will be able to view the history of accesses and investigate
REQ-8 6 pts
“suspicious” accesses.
As an authorized user, I will be able to configure the preferences for activation of
REQ-9 6 pts
household devices.

 Note no priorities for user stories

 Story priority is given by its order of appearance on the work backlog
(described later)
 Estimated size points (last column) will be described later (also see 1st lecture) 12
Compare to IEEE-830 Style Requirements
https://en.wikipedia.org/wiki/Software_requirements_specification

Identifier Priority Requirement

The system shall keep the door locked at all times, unless commanded otherwise by
REQ-1 5 authorized user. When the lock is disarmed, a countdown shall be initiated at the end
of which the lock shall be automatically armed (if still disarmed).
REQ-2 2 The system shall lock the door when commanded by pressing a dedicated button.
REQ-3 5 The system shall, given a valid key code, unlock the door and activate other devices.
The system should allow mistakes while entering the key code but resist “dictionary attacks” and
REQ-4 4
sound the alarm bell and block.
REQ-5 2 The system shall maintain a history log of all attempted accesses for later review.
REQ-6 2 The system should allow adding new authorized persons at runtime or removing existing ones.
The system shall allow configuring the preferences for device activation when the user provides a
REQ-7 2
valid key code, as well as when a burglary attempt is detected.
The system should allow searching the history log by specifying one or more of these parameters:
REQ-8 1 the time frame, the actor role, the door location, or the event type (unlock, lock, power failure, etc.).
This function shall be available over the Web by pointing a browser to a specified URL.
The system should allow filing inquiries about “suspicious” accesses. This function shall be
REQ-9 1
available over the Web.

REQ-10 1 The system should backlit the door keypad when dark.

 IEEE Standard 830 style requirements are more formal and cover more scenarios and details
 When prioritizing requirements, “important” and “urgent” aspects can be confused
 It is also difficult to assign a numeric value of priority to each requirement 13
– It requires more mental effort than just rank-ordering the requirements in a linear sequence
 Requirements Analysis
 Requirement REQ-3 states that intruders will not be able to
succeed with a “dictionary attack,” but many details
need to be considered and many parameters
determined (“business policies”)
– What distinguishes user’s mistakes from “dictionary attacks”
• The number of allowed failed attempts, relative to a predefined threshold value
– The threshold shall be small, say three  business policy!
– How is the mechanical lock related to the “blocked” state?
• Can the user use the mechanical key when the system is “blocked”?
 Requirement REQ-5 states that the keypad should be
backlit when dark
– Is it cost-effective to detect darkness vs. keep it always lit?
 Etc.
Requirements analysis should not be exhaustive,
but should neither be avoided.

14
 From Requirements
to Business Policies
Explicit identification of business policies is important for
two reasons:
1. Making the need for BP explicit allows involving
other stakeholders, particularly the customer, in
decision making about the BP solutions to adopt
2. Helps to anticipate potential future changes in the
policies, so mechanisms can be implemented in the
code that localize the future changes and allow
quick substitution of implemented business policies

These issues too important to be left to the programmer

to make ad-hoc decisions and hard-code them.

15
Requirements Analysis Activities
 Not only refinement of customer requirements,
but also feasibility and how realistic
 Needs to identify the points where business
policies need to be applied.
 Explicit identification of business policies (BP) is
important for two reasons:
1. Making the need for BP explicit allows involving other
stakeholders in decision about the solutions to adopt—
Helps to involve others, particularly the customer, in
decision making about each policy to adopt
2. Helps to anticipate potential future changes in the policies,
so mechanisms can be implemented in the code that
localize the future changes and allow quick substitution of
business policies

16
 Types of Requirements

 Functional Requirements
 Non-functional requirements (or quality
requirements)
– FURPS+
– Functionality (security), Usability, Reliability,
Performance , Supportability

 User interface requirements

17
 User Interface Requirements
 Do not waste your time and your customer’s time
by creating elaborate screen shots with many
embellishments, coloring, shading, etc., that
serves only to distract attention from most
important aspects of the interface
 Hand-drawing the proposed interface forces you
to economize and focus on the most important
features
 Only when there is a consensus that a good
design is reached, invest effort to prototype the
interface

https://arstechnica.com/gadgets/2018/01/with-ink-to-code-microsoft-is-turning-back-of-napkin-sketches-into-software/ 18
 Example: Safe Home Access
User interface requirement:
The UI must be simple for occasional visitors who will not have time to familiarize or to study user’s documentation.

Initial design of the door keypad:

Analysis:
 If “Unlock” button is not available, then the
system could simply take the first N digits
and validate as the key.
 If “Unlock” button is available, then the
system could take the last N digits and
validate as the key (and ignore any number
>N of previously entered digits).
 The advantage of the latter approach is
that it allows correcting for unintentional
mistakes during typing, so the legitimate user
can have more opportunities to attempt.
 Note that this feature will not help the
19
burglar trying a dictionary attack.
 Example: Safe Home Access
Redesigned door keypad: includes the “Unlock”&“Lock” buttons

Analysis:
 When a user types in the key and the
system reports an invalid key, the
user may not know whether the
problem is in his fingers or in his
memory: “did I mistype the correct
key, or I forgot the key?”
 To help the user in such a situation,
we may propose to include a
numerical display that shows the
digits as the user types. 20
 Example: Safe Home Access
Re-redesigned door keypad: includes the keycode display

Analysis:
 There are several issues to consider
about the display feature:
• How much this feature would increase
the overall cost?
• Would the display make the door device
bulky and inconvenient to install?
• Would it be significantly more sensitive to
rain and other elements?
• Would the displayed information be
helpful to an intruder trying to guess a
valid key?
21
 Tools for Requirements Eng.

 Tools, such as user stories and use cases,

used for:
– Determining what exactly the user needs
(“requirements analysis”)
– Writing a description of what system will do
(“requirements specification”)
 Difficult to use the same tool for different tasks
(analysis vs. specification)

22
 Acceptance Tests

 Means of assessing that the project success

criteria
– The requirements are met as expected
 Conducted by the customer throughout the
project, not only at the end
 An acceptance test describes whether the
system will pass or fail the test, given specific
input values
 We cannot ever guarantee 100% coverage of all
usage scenarios, but systematic approach can
increase the expected degree of coverage

23
 Acceptance Tests
 Each requirement describes for a given “situation”
(i.e., system inputs), the output or behavior the
system will produce
– The “output” represents the user’s need or business goal
 An acceptance test specifies a set of scenarios for
determining whether the (part of the) system meets
the customer requirements
 An acceptance test case specifies, for a given
“situation” or “context” (defined by current system
inputs), the output or behavior the system will
produce in response

 [See examples in Appendix G of the lecture notes]

24
 Agile Methods for Effort
Estimation and Work Organization
 Recall “hedge pruning points” from the first
lecture
 Size points assigned to each user story
 Total work size estimate:
– Total size =  (points-for-story i), i = 1..N
 Velocity (= productivity) estimated from
experience
Path size
 Estimate the work duration
Travel velocity
Project duration = 25
Agile Estimation of Project Effort
1) Prune Section 6 1 day (2pts) 2 points per day
2) Prune Section 4 1.5 days (3pts)
1 = 4 pts (2 days)
3) Prune Section 1 2 days (4pts) 2 = 7 pts (3.5 days)
3 = 10 pts (5 days)
4 = 3 pts (1.5 days)
4) Prune Section 5 2 days (4p) 5 = 4 pts (2 days)
5) Prune Section 2 3.5 days (7p) 6 = 2 pts (1 day)
7 = 4 pts (2 days)
8 = 7 pts (3.5 days)
6) Prune Section 7 2 days (4p)
21 days
Estimated work duration 7) Prune Section 8 3.5 days (7p)
Work backlog
1) Prune Section 6 1 day (2pts) 8) Prune Section 3 5 days (10p)

2) Prune Section 4 1.5 days (3pts)

Items pulled by the team into an iteration
3) Prune Section 1 2 days (4pts)
4) Prune Section 5 2 days (4pts)

5) Prune Section 2 3.5 days (7pts)

6) Prune …

Work items
21 days

1st iteration 2nd iteration n-th iteration

5 days
List prioritized by the customer Estimated completion date Time
 Example User Stories
Identifier User Story Size

REQ-1 As an authorized user, I will be able to keep the doors by default always locked. 4 points
REQ-2 As an authorized user, I will be able to unlock the doors using a valid key. 7 points
An intruder will not be able to unlock the doors by guessing a valid key;
REQ-3 7 points
the system will block upon a “dictionary attack.”
REQ-4 The door will be automatically locked after being open for a defined period of time. 6 pts
REQ-5 As a user, I will have the door keypad backlit when dark for visibility. 3 pts
REQ-6 Anyone will be able to lock the doors on demand. 2 pts

REQ-7 As a landlord, I will be able at runtime to manage user authorization status. 10 pts
As an authorized user, I will be able to view the history of accesses and investigate
REQ-8 6 pts
“suspicious” accesses.
As an authorized user, I will be able to configure the preferences for activation of
REQ-9 6 pts
household devices.

27
Agile Estimation of Project Effort

1) Default Locked 8 day (4pts) 1 point per 2 days

2) Unlock 14 days (7pts)
R1 = 4 pts (8 days)
3) Prevent Attack 14 days (7pts) R2 = 7 pts (14 days)
Estimated work duration R3 = 7 pts (14 days)
To-do List R4 = 6 pts (12 days)
4) Autolock 12 days (6p) R5 = 3 pts (6 days)
1) ST-4: Unlock 11 days (6pts) R6 = 2 pts (4 days)
5) Backlit 6 days (3p)
R7 = 10 pts (20 days)
2) ST-2: Lock 4 days (2pts)
Items pulled by developers into an iteration R8 = 6 pts (12 days)
3) ST-5: Manage Users 14 days (8pts) R9 = 6 pts (12 days)
6) Lock 4 days (2p)
4) ST-7: Set Preferences 10 days (6pts) 7) Manage Users 20 days (10p) 102 days
5) ST-6: View History 7 days (4pts)

6) ST-_: 8) View History 12 days (6p)

9) Set Preferences 12 days (6p)

Work items
Work in progress
102 days

1st iteration 2nd iteration n-th iteration

30 days
List prioritized by the customer Estimated completion date Time
Agile Prioritization of Work
 Instead of
assigning
priorities, the
customer
Work backlog
creates an
ordered list of
1) ST-4: Unlock 11 days (6pts)
user stories

2) ST-2: Lock 4 days (2pts)
Developers
Items pulled by developers into an iteration
3) ST-5: Manage Users 14 days (8pts)
4) ST-7: Set Preferences 10 days (6pts) simply remove
5) ST-6: View History 7 days (4pts) the top list
6) ST-_: items and work
on them in the
next iteration
117 days

1st iteration

30 days
List prioritized by the customer Estimated completion date Time

29
Tradeoff between Customer Flexibility
and Developer Stability
 Items pulled by
Step 1: developers into an
Remove from the backlog iteration are not
user stories scheduled for subject to further
the next iteration customer prioritization
Work backlog  Developers have a
• ST-4: Unlock 11 days (6pts) steady goal until the
1) ST-5: Manage Users 14 days (8pts)
• ST-2: Lock 4 days (2pts) end of the current
2) ST-7: Set Preferences 10 days (6pts) iteration
3) ST-6: View History 7 days (4pts)
 Customer has
4) ST-_: flexibility to change
Step 2: priorities in response to
Shift remaining user changing market
stories to the top of the forces
backlog and allow
customer re-prioritization 117 days

1st iteration

30 days
Work iteration currently in progress Estimated completion date Time

30
How To Combine the Part Sizes?

B
A

(b) C
City C

City B
B

A C
City A (a) (c)

Costs are not always additive

But, solution (c) is not necessarily “cheaper” than (b) …
31
 Additional Costs

Highway traffic-circle interchange Traffic signs

32
 Problem Decomposition

System requirements provide the “projection axes” for problem decomposition33

—different subsets of requirements identify different sub-systems.
Software Engineering Problems
 We assume that the computer/software helps the user to
achieve a business goal in the problem domain
 Problem domains can be virtual (e.g., text documents,
relational databases), or physical world (a device to
control, a person to notify and prompt to action)
 Problem types:
1. Transforming one virtual object to another (document format
conversion, e.g., from MS Word to PDF)
2. Modifying a virtual object (e.g., document editing)
3. Automatically controlling behavior of a physical object (e.g.,
thermostat)
4. Manually controlling behavior of a physical object (e.g., drone flying)
5. Observing behavior of a physical object (e.g., traffic monitoring)

34
 Typical System Requirements
 REQ-1: Map/transform input data to output data
as said by given rules
 REQ-2: Support repository (or document) editing,
where “repository” is a collection of data items
 REQ-3: Automatically control a physical
object/device
 REQ-4: Interactively control a physical
object/device
 REQ-5: Monitor and display information about an
object
 Only a “5-dimensional” problem
space!
(Problem complexity can vary independently along each
dimension)
Note:
These “typical requirements” will be discussed further under “Problem Frames”
 Typical Software Eng. Problems
1. User works with computer system 1.a) System transforms input document to output document
(problem domain is “virtual”, not physical)
REQ-1: Map input data to
output data as said by given
rules IN doc System OUT doc

1.b) User edits information stored in a repository

User System
System

REQ-2: Allow repository editing,

where “repository” is a collection of Repository
data User

2. Computer system controls the (physical) problem domain

(user not involved) REQ-3: Automatically
control a physical
object/device
System Problem domain

3. Computer system intermediates between 3.a) System observes the problem domain and displays informatio
the user and the problem domain
REQ-5: Monitor and
display information about
an object User System Problem domain

User System Problem domain 3.b) System controls the problem domain as commanded by the us

REQ-4: Interactively 36
control a physical
object/device User System Problem domain
 Decomposition:
Projection vs. Partitioning

Projection: :Partitioning

Projection-based decomposition helps us understand the 37

components in the context of their use, relative to other parts of
 5-dimensional Problem Space
 The five elementary problem
types represent the coordinate
(“Simple workpieces”)

Software
system of the problem space
(“Required behavior”)

Simple editing
Autonomous control

problem
to solve
 The “axis” projections represent
the degree to which the whole
problem contains a
subproblem of this type
 Each subproblem can be
analyzed independently and
eventually recombined into the
whole problem
 The structure of the solution
should be selected to fit the
problem structure

38
 Example: Problem Decomposition
[ Case Study 1: Safe Home Access ]

 REQ1: keep door locked and auto-lock Required Behavior

 REQ2: lock when “LOCK” pressed

Commanded Behavior
 REQ3: unlock when valid key provided
 REQ4: allow mistakes but prevent dictionary attacks

 REQ5: maintain a history log Information Display (database is the “display”)

 REQ6: adding/removing users at runtime Simple Editing

 REQ7: configuring device activation preferences

Simple Editing
 REQ8: inspecting the access history
Information Display
 REQ9: filing inquiries
Simple Editing
 Example: Problem Decomposition
[ Case Study 2: Investment Fantasy League ]
 REQ1: view market prices and volumes Information Display
– Domains: exchange, display
 REQ2: place a trade Simple Editing
– Domains: investor, tradable-securities, pending-trades
 REQ3: execute trades when conditions matched Required Behavior
– Domains: exchange, pending-trades
 REQ4: generate periodic report Transformation
– Domains: portfolio, report
 REQ5: generate leaderboard
Transformation
– Domains: all-portfolios, leaderboard
 REQ6: view leaderboard
Information Display
– Domains: leaderboard, display
 REQ7: start a trading group/clique
Simple Editing
– Domains: investor, group
 REQ8: invite to a trading group/clique
– Domains: investor, friends, group
Commanded Behavior
 Problem Domains &
Their Interactions
Software-to-be

Information Physical
(lexical) (causal)
domain domain Human
(biddable)
domain

Information controls physical world People control physical world Information observed from physical world

41
People create/edit information Information transformed/summarized People interact/collaborate
42
43