LECTURE 6: Requirements Engineering

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”, 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
 To achieve a high-level goal, we must consider what matters, what
are the important parameters, to 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

The requirements engineering process in

different methodologies. 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,

which the customer can provide or found in professional publications

6
 Requirements and Specification

Problem domainSoftware (Solution) domain

Describes
problem

Specifi
Requirements Program
Customer cation

Specifies

Analyzes Develops

Software Engineer

We receive “customer problem statement,” 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 competitors
 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 burdened with poor communication and clerical duties, resulting in
inefficiencies
– Cause B: The menu does not match the possible 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

 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
A User Story is a requirement expressed from the perspective of an end-user goal.
User Stories follow the same format. They are assembled in a Prioritised Requirements
List.

The format of the User Story is as follows:

As a < role>, I need, So that

These two examples demonstrate User Stories at different levels.

At a project level
As a Manager, I need to improve customer service So that we retain our customers.

At a detailed level
As an Investor, I need to see a summary of my investment accounts, So that I can
decide where to focus my attention.
As a tenant, I can unlock the doors to enter my apartment.

user-role capability business-value

(benefactor)

11
 Requirements as User Stories
 A User Story is a well-expressed requirement. Its format has become the
most popular way of expressing requirements in Agile for many reasons:
• It focuses on the viewpoint of a role who will use or impacted by the solution
• It defines the requirement in language that has meaning for that role
• It helps to clarify the true reason for the requirement
• It helps to define high level requirements without necessarily going into low level
detail too early
 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.

12
User Story – the Card Example
From the PRL, User Stories are often printed onto physical cards, for planning
purposes and to help the Solution Development Team monitor progress.

The Front of the Card:

Story Identifier: STK001
Story Name: Customer Order
Description: As a Customer, I need to place an order so that I can have food
delivered to my house.
The Back of the Card
Confirmation: Acceptance Criteria examples:
Functional:
- Can I save my order and come back to it later?
- Can I change my order before I pay for it?
- Can I see a running total of the cost of what I have chosen so far?
Non-functional: availability:
- Can I place an order at any time (24 hours per day or 24/7/365)?
- Can I view the order at any time up to and including delivery? 13
 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 (Customer Benefit, Opportunity Size, Competitive
Positioning)
 Story priority is given by its order of appearance on the work backlog (described later)
 Estimated size points (last column) will be described later
14
 Compare to IEEE-830 Style Requirements
Requirements prioritization: From critical to trivial

Identifie Priorit Requirement

r y
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
– It requires more mental effort than just rank-ordering the requirements in a linear sequence 15
 Analyst’s Task: Three Descriptions
Not only refinement of customer requirements, but also feasibility and how
realistic
The requirement
The problem domain
What user wants: The specification
How problem
When valid keycode entered +
Unlock pressed, open the lock; domain behaves: What software-to-be
Automatically lock after a period
of time.
will do (at interface):
Locked If entered number matches one of
stored numbers + Button-1 pressed,
Electromechanical lock
HIGH VOLTAGE / put HIGH voltage on Output-port-1;
Start a timer countdown;
When the timer expires,
LOW VOLTAGE /
put LOW voltage on Output-port-1.
Unlocked

Concern:
It is not obvious that this is the
only or even “correct” solution to
the requirement-posed problem.
Problem Frames tell us what each description should contain and how to verify the concern.
 Types of Requirements

1. Functional Requirements
2. Non-functional requirements (or quality requirements)
– The term FURPS+ refers to the non-functional system properties:
• Functionality (security), Usability, Reliability, Performance , Supportability
3. 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.
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 burglar trying a
dictionary attack.

Initial design of the door keypad

19
 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
 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 here. 23
 Sizing the Problem
Work Estimation Strategy
1.Make initial guess for a little part of the work
2.Do a little work to find out how fast you can go
3.Make correction on your initial estimate
4.Repeat until no corrections are needed or work is completed

Step 1: Divide the

  problem into small &
similar parts
 Step 2: Estimate relative
sizes of all parts
Size(  ) = 4

Size(  ) = 7
 Size(  ) = 10
Size(  ) = 3
Size(  ) = 4
Size(  ) = 2
 
 Size(  ) = 4
Size(  ) = 7
Agile Methods for Effort Estimation and Work Organization

 3. Total work size estimate:

 (points-for-story
– Total size =  i), i = 1..N
 4. Velocity (= productivity) estimated from experience

 5. Estimate the work duration

Path size
Project duration =
Travel velocity

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)
6 = 2 pts (1 day)
5) Prune Section 2 3.5 days (7p)
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
 Agile Prioritization of Work
 Instead of assigning priorities, the customer creates an ordered list of user stories
 Developers simply remove the top list items and work on them in the next iteration

Work backlog
1) ST-4: Unlock 14 days (7pts)
2) ST-2: Lock 6 days (3pts)
Items pulled by developers into an iteration
3) ST-5: Manage Users 14 days (8pts)
4) ST-7: Set Preferences 10 days (6pts)

5) ST-6: View History 7 days (4pts)

6) ST-_:

117 days

1st iteration

20 days
List prioritized by the customer Estimated completion date Time

29
Tradeoff between Customer Flexibility and Developer Stability
 Items pulled by developers into an iteration are not subject to further customer
prioritization
 Developers have a steady goal until the end of the current iteration
 Customer has flexibility to change priorities in response to changing market forces

Step 1:
Remove from the backlog
user stories scheduled for
the next iteration
Work backlog
• ST-4: Unlock 14 days (7pts)
• ST-2: Lock 6 days (3pts)
1) ST-5: Manage Users 14 days (8pts)
2) ST-7: Set Preferences 10 days (6pts)

3) ST-6: View History 7 days (4pts)

4) ST-_:

Step 2:
Shift remaining user
stories to the top of the
backlog and allow
customer re-prioritization 117 days

1st iteration

30 days
Work iteration currently in progress Estimated completion date Time
30
 References

 Software Engineering, Ivan Marsic, 2020