REQUIREMENTS

ENGINEERING
Lecture 4

1
Content
■ Introduction
■ Requirements engineering process
■ Requirements elicitation
■ Requirements specification
■ Requirements validation
■ Requirements change
■ Functional and Non-functional requirements

2
References
■ SOFTWARE PRODUCT MANAGEMENT Course
Specialization, Coursera, University of Alberta
■ Software Engineering, Ian Sommerville, 10th edition,
2016
■ Specifying Effective Non-Functional Requirements,
John Terzakis Intel Corporation June 24, 2012 ICCGI
Conference
■ http://www.scaledagileframework.com/nonfunctiona
l-requirements/
■ http://ieeexplore.ieee.org/document/7321200/
■ https://www.inf.ed.ac.uk/teaching/courses/inf2c-
se/Lectures/metrics.pdf
3
Why a requirement?
■ A specific description of your client’s needs

■ According to IEEE a requirement is:

1. A condition or capability needed by a user to
solve a problem or achieve an objective.
2. A condition or capability that must be met or
possessed by a system or system component to
satisfy a contract, standard, specification, or
other formally imposed documents.
3. A documented representation of a condition
or capability as in (1) or (2).
4
Requirements engineering
activities
1. Requirements elicitation
2. Requirements specification
3. Prioritizing requirements
4. Analyzing requirements
5. Requirements validation
6. Requirements
management/change

5
Plan-driven vs. Agile processes

6
Eliciting requirements
■ Eliciting vs. gathering
■ Interactive and investigative
■ Performed by software product manager and
client

■ Goal:
– to distinguish between “needs” and “wants”;
– feasibility and realistic expectations

7
Expressing requirements
■ Representing requirements in a structured
way
■ Representations include
– Use cases
– User stories
– Storyboards

8
Prioritizing requirements
■ MoSCoW method: “Must have”, “Should have”, “Could
have” and “Would like but won’t get.”
■ Helper questions:
-What requirements must be completed for the
project and product to be successful?
- What requirements should be done? In other words,
what is important but is not as time-critical or could
be satisfied another way or at a later time on the
project?
- What could be done to improve the project or
product but is not necessary? These priorities are
usually only included if both time and resources allow
for it.
9
Analyzing and managing
requirements
■ Analysis = Examine requirements to ensure
clearness, completeness and consistency
■ Constant process
■ Manage = organize and re-organize
requirements; keep track of priorities,
analyses and changes in requirements
■ Ensure that other processes are correlated to
the requirements (coding, testing, change
logs)

10
Types of requirements
■ Business requirements
■ Business rules
■ User requirements
■ Functional requirements
■ Non-functional requirements
■ External interfaces
■ Physical product settings
■ Development constraints

11
Business requirements and business
rules
■ Requirements related to the purpose of the project
(what is the business objective of the project?)
Ex. “The client needs to reduce errors in orders made to
their company by 25% by the end of next year to raise
their yearly revenue by $10,000.”
■ Rules = constraints on the project usage (i.e. budgets,
policies, guidelines, regulations)
Ex.
– Government or legal regulations
– Privacy policies
– Brand uniformity requirements
12
User requirements
■ Tasks that users can accomplish with the
product, or what the product can do for the
user
■ Expressed as:
– Use cases
– User stories
– Storyboards
– Scenarios

Are discussed in more detail next

13
Functional requirements
■ Behaviors that the developed product should do or
support.
■ Usually expressed as
– Description of inputs and where they come from.
– Description of outputs and where they go to.
– Information about the information needed for the
computation and other entities used.
– Description of the action to be taken.
– Pre and post conditions (if appropriate).
– The side effects (if any) of the function.

14
Example requirements for an
insulin pump software system
3.2 The system shall measure the blood sugar and deliver
insulin, if required, every 10 minutes. (Changes in blood
sugar are relatively slow so more frequent measurement is
unnecessary; less frequent measurement could lead to
unnecessarily high sugar levels.)

3.6 The system shall run a self-test routine every minute

with the conditions to be tested and the associated actions
defined in Table 1. (A self-test routine can discover
hardware and software problems and alert the user to the
fact the normal operation may be impossible.)

15
A structured specification of a
requirement for an insulin pump

16
A structured specification of a
requirement for an insulin pump

17
Non-functional requirements
■ Describe how well a product must perform (aka
quality requirements)
■ Ex.: accuracy, dependability, security, usability,
efficiency, performance, and maintainability.

Product requirement
The Mentcare system shall be available to all clinics during
normal working hours (Mon–Fri, 08.30–17.30). Downtime
within normal working hours shall not exceed five seconds in
any one day.
Organizational requirement
Users of the Mentcare system shall authenticate themselves
using their health authority identity card.
External requirement
The system shall implement patient privacy provisions as set
out in HStan-03-2006-priv.
18
Types of Non functional
requirements

19
Metrics for specifying NF
requirements

20
External interfaces
■ Related to how the product is situated within a
larger system.
■ Concerned with the relationship of the
product to other entities outside the product.
■ Ex. a software application that retrieved
information from a remote database to display
to users sits between the entities of the
database and the end-user
■ Can be represented within data flow diagrams
that show all the components of a product,
including outside entities
21
Physical Setting and Development
Constraints
■ Physical setting requirements refer to how the
product needs to be designed in order to function in its
physical environment.
Ex. if a product was being developed for underwater
exploration, it would need to be waterproof.
■ Development constraints affect everything from
implementation technology, conventions,
documentation, and the process used to develop the
product.
Ex. devices or platforms to be supported, how much
memory, bandwidth, or processing power the product is
limited to using.
22
Changing Requirements,
Controlling Scope
■ Vision - outlines the value of a product to the
client and its place within the wider market.
■ Changes to the project should not change the
purpose of the product (the vision)!
■ Scope – outlines what the project can
realistically achieve
■ Scope creep - the scope of a project grows as
the result changing requirements.
Consequently, the likelihood of project
success usually significantly lowers over time.
23
Scope creep
■ Ex. The vision of a project is designing a game to teach
cardiopulmonary resuscitation (CPR) to users.
■ Vision change? Design a game as a flight simulator to teach
airplane piloting
■ Scope change? Switch the platform on which the game is
designed once the development started

■ Strategies for defending against scope creep include:

– Making expectations clear between client and team.
– Drawing the scope with the client through tools such as use
case diagrams.
– Asking the client to prioritize requirements so that the most
important ones can be developed early.
– Verifying if in scope when refining requirements to avoid
spending excess time working on unnecessary requirements
or capabilities better suited to later releases. 24
Requirements and Design
■ Both can be addressed at the same time
⇒ Danger of adding unnecessary constraints on
the product (blur requirements and design)
⇒ Strategies for avoiding that:
– Is the solution just a possible option?
– Is the solution the only one possible?
– Is the solution addressing the wrong
problem?
– Is the solution just to attract developer
interest?
– Is the client more “solution focused”?
25
User considerations
■ End-user
■ Stakeholders
⇒ UI design issues:
– Users have an inability to express what
they need
– Users are biased by previous experiences
– Developers sometimes have trouble seeing
through a user’s point of view because of
their advanced knowledge of technology

26
Use-cases

27
Wireframes

■ a basic visual representation

of the product
■ Used for:
– getting an idea for what will be developed
– demonstrating ideas to clients or users and
encouraging their feedback and involvement
– communication among the development team
– helping the client or users communicate with
the software product manager and team (some
people may find it easier to sketch out their
ideas to describe them)
28
Storyboards
■ visual representations of an interaction with the
software product.

29
Or, more detailed

30
Requirements in agile practices
■ User stories - “As a ‘who,’ I want to ‘what,’ so
that ‘why.’”
“As a customer, I want to be able to identify
dietary restrictions, so that I know I can eat the
food I order.”
■ Good User Stories
– Independent
– Negotiable
– Valuable
– Estimable
– Small
– Testable 31
Example
■ Epic user story: “As a customer, I want to pay for my
bill, so I can settle what I owe quickly.”

■ User stories:
– “As a customer, I want to be able to see a bill, with
all of the items in that order, so I can see how
much my order will cost.”
– “As a customer, I want to be able to select a “pay
now” option when I view my bill, so I can pay the
bill immediately.”
– “As a customer, I want to be able to enter my
payment details for VISA and MasterCard credit
cards, so I can pay using a convenient method.”
32
Acceptance test
■ Set of acceptance criteria – specific conditions determined by
the client’s specific needs.
■ “As a customer, I want to be able to enter my payment details
using VISA and MasterCard credit cards so I can pay using a
convenient method”
– Payment can be made using a VISA credit card.
■ Insert a VISA card into a chip reader.
■ Enter the VISA’s PIN number.
■ Confirm the payment was accepted.
– Payment can be made using a MasterCard credit card.
– Payment can be made using an online financial service.
– When paying with a credit card, filling in the “card number”
field auto-detects the card type.
– The customer sees only the relevant input fields, depending
on the selected payment method.
33
Product backlog
■ List of software features
■ Features in product backlogs include
– work tasks (physical jobs that must be
done on the project but are not necessarily
related to developing product features),
– knowledge tasks (work for parts of the
project that need to be learned),
– bugs (errors in product code),
– user stories.
■ User stories are grouped in units of work to be
done in sprints
34
Story maps
■ Present product backlogs in a visual manner, with
user stories grouped into specific functional
categories
■ Sets of columns, each representing a category for
grouping user stories
■ Within a column, user stories are prioritized

35
Criteria for user stories
■ Correct
■ Complete
■ Clear
■ Consistent
■ Feasible
■ Traceable

36
Ambiguity
■ Ambiguity occurs when a word or statement
has multiple meanings or there is doubt about
the meaning.
■ These problems (and others) create ambiguity:
– Vagueness
– Subjectivity
– Optionality
– Under-specification
– Under-reference

37
Ambiguous examples
■ Vagueness:
“The system must pass between 96-100% of the test cases using
current standards for video encoding before launch.”
■ Subjectivity:
“The debug code must easily and seamlessly integrate with the
validation test automation software.”
■ Optionality:
“The software should be tested under as many OSes as possible.”
■ Under-specification:
“The software must support 802.11n and other network protocols”
■ Under-reference:
“Users must be able to complete all previously-defined operations in
under 5 minutes 80% of the time.”
38
Ambiguous requirements
■ Categories of ambiguous words
– Indirect Words
– Vague Words
– Persuasion Words
– Completion Words
– Qualifiers
– Comparatives
– Quantities
– Pronouns
– Positional Words
– Temporal Words
– Joining word
39
40
41
42
Weak words in NFR
■ Quick, Quickly ■ Frequently
■ Easy, Easily ■ Intuitive
■ Timely ■ Feel, Feeling
■ Fast ■ Friendly, User-friendly
■ Normal ■ Secure
■ Reliable ■ Immediate
■ State-of-the-art ■ Fast
■ Effortless

How do you measure these???

43
Techniques for specifying
NFRs
■ Planguage [Competitive Engineering, Tom
Gilb, Butterworth-Heinemann, 2005]
■ Scenarios [Software Architecture in
Practice, Second Edition, Len Bass, Paul
Clements, Rick Kazman, Addison Wesley,
2003]
■ Softgoal Interdependecy Graphs (SIGs)
[Softgoal Interdependency Graphs, Chung L.,
Nixon B.A., Yu E., Mylopoulos J. (2000). In:
Non-Functional Requirements in Software
Engineering. International Series in Software
Engineering, vol 5. Springer, Boston, MA]
44
Planguage
■ Informal, but structured, keyword-driven
planning language
■ Can be used to create all types of
requirements
■ Is a combination of the words Planning and
Language
■ Is an example of a Constrained Natural
Language

45
Basic keywords and definitions
■ Tag: A unique, persistent identifier
■ Gist: A brief summary of the requirement or area
addressed
■ Requirement: The text that details the requirement
itself
■ Rationale: The reasoning that justifies the requirement
■ Priority: A statement of priority and claim on
resources
■ Stakeholders: Parties materially affected by the
requirement
■ Status: The status of the requirement (draft, reviewed,
committed, etc.)
46
Basic keywords and definitions

■ Owner: The person responsible for implementing the

requirement
■ Author: The person that wrote the requirement
■ Revision: A version number for the statement
■ Date: The date of the most recent revision
■ Assumptions: All assumptions or assertions that could
cause problems if untrue now or later
■ Risks: Anything that could cause malfunction, delay, or other
negative impacts on expected results
■ Defined: The definition of a term (better to use a glossary)

47
Additional Planguage
Keywords for NFR
■ Ambition: A description of the goal of the requirement
(this replaces the Requirement keyword used in FR)
■ Scale: The scale of measure used to quantify the
requirement (e.g., time, temperature, speed)
■ Meter: The process or device used to establish location
on a Scale (e.g., watch, thermometer, speedometer)
■ Minimum (Must): The minimum level required to avoid
political, financial, or other type of failure
■ Target (Goal): The level at which good success can be
claimed
■ Outstanding (Stretch): A feasible stretch goal if
everything goes perfectly 48
Example
■ Tag: Menu Complexity
■ Ambition: Make Accessing Desired type of
food easier
■ Scale: Number of menus
■ Meter: Measured from the login menu to
display of the most specific type of food
■ Minimum: 4
■ Target: 3
■ Outstanding: 2

49
Scale types
■ Natural: Scales with obvious association to the
measured quality
Ex. time (seconds), number of users
■ Constructed: A scale built to directly measure a
quality
Ex. 5-point scale to measure perceived sound quality; 10-
point scale created to register user satisfaction
■ Proxy: An indirect measure of a quality
Ex. An in-field MTTF goal predicted using pre-release
reliability test results; “Critical” defect prediction for first
year of released software based on defect trending
during Beta testing
50
Scale examples
■ Time
– Transactions / sec
– Response time
– Time to complete an operation
■ Space
– Main memory
– Auxiliary memory
– (Cache)
■ Usability
– Training time
– Number of choices
– Mouse clicks 51
More examples
■ Reliability
– Mean time to failure
– Downtime probability
– Failure rate
– Availability
■ Robustness
– Time to recovery
– % of incidents leading to catastrophic failures
– Data corruption probability after a failure
■ Portability
– % of non-portable code
– Number of platforms where software can run

52
Meter

■ The process or device used to establish

location on a Scale
■ Most meters have an obvious association with
the scale they are measuring (e.g., time with a
stop watch)
■ Some meters may require a process or test
procedure to be utilized or created

53
Examples of meters
■ Natural:
– a stopwatch,
– log of authenticated user
■ Constructed:
– user satisfaction survey
■ Proxy:
– stress testing of pre-production software, analyzing
results and predicting the Mean Time to Failure
(MTTF);
– Validation testing of Beta software, analyzing
results and predicting the number of critical defects
in the first year of customer release
54
Examples of paired scales and
meters
■ Tag: Response Time
■ Scale: Time in seconds
■ Meter: Measured from mouse click to display of next menu
■ Tag: Software Maintainability
■ Scale: Average engineering time from report to closure of
defects
■ Meter: Analysis of 30 consecutive defects reported and
corrected during product development
■ Tag: Market Share
■ Scale: % of Total Available Market
■ Meter: Quarterly market survey
55
Minimum, Target &
Outstanding Keywords
■ Minimum: The minimum level required to avoid political,
financial, or other type of failure
■ Target: The level at which good success can be claimed
■ Outstanding: A stretch goal if everything goes perfectly
Note!
■ Development and testing is typically focused on
achieving the Target level
■ Values not meeting at least the Minimum level mean
the NFR has not been correctly implemented
(verification has failed)
■ At least one of these keywords should be specified for
a NFR 56
Landing zone

57
Order processing must be fast
■ Tag: Order Processing Time
■ Ambition: Don’t make the users wait too long
for order processing
■ Scale: Time
■ Meter: Measured from the user clicking on the
“Submit Order” icon to the display of the
“Order Complete” message on the order entry
menu
■ Minimum: 5 seconds
■ Target: 4 seconds
■ Outstanding: 3 seconds 58
For you to specify (homework)

■ The software must support at least 25 users

■ Make the web site software reliable
■ The configuration software should be
intuitive to use
■ The audio software must reproduce music
nearly perfectly

59
Scenarios
Elements
– source of stimulus [the entity (human or another
system) that generated the stimulus or event.] who?
– stimulus [a condition that determines a reaction of
the system.] what?
– environment [the current condition of the system
when the stimulus arrives.] when?
– artifact [is a component that reacts to the stimulus.
It may be the whole system or some pieces of it.]
where?
– response [the activity determined by the arrival of
the stimulus.] which?
– response measure [the quantifiable indication of the
response.] how?

60
General Scenario

61
Concrete Scenario

62
Performance
■ Performance refers to the time it takes the
system to respond to an event. The event can
be fired by:
– a user,
– another system,
– the system itself.

63
Performance scenario
■ Source of stimulus: The stimuli arrive either from
external (possibly multiple) or internal sources.
■ Stimulus: The stimuli are the event arrivals. The arrival
pattern can be characterized as periodic, stochastic, or
sporadic.
– Periodic means that the events arrive in regular
intervals of time
– Stochastic means that the arrival of events is based
on some probabilistic distribution
– Sporadic means that the events arrive rather
randomly.
■ Artifact. The artifact is always the system's service,
which has to respond to the event.
■ Environment. The system can be in various operational
modes, such as normal, emergency, or overload. The
response varies depending on the current state of the
system. 64
Performance scenario
■ Response. The system must process the arriving events. This
may cause a change in the system environment (e.g., from normal
to overload mode). The response of the system can be
characterized by:
– latency (the time between the arrival of the stimulus and the
system's response to it),
– deadlines in processing (a specific action should take place
before another),
– throughput of the system (e.g., the number of transactions
the system can process in a second),
– jitter of the response (the variation in latency),
– number of events not processed because the system was
too busy to respond,
– lost data because the system was too busy.
■ Response measure. Response measures include the time it
takes to process the arriving events (latency, or deadlines by
which the events must be processed), variations in this time
(jitter), the number of events that can be processed within a
particular time interval (throughput), and the characterization of
the events that cannot be processed (miss rate, data loss).

65
POS Case Study
■ Scenario(s): The POS system scans a new
item, item is looked up, total price updated
within two seconds
■ Stimulus Source : End user
■ Stimulus: Scan item, fixed time between
events for limited time period
■ Environment: Development time
■ Artefact (If Known): POS system
■ Response: Item is looked up, total price
updated
■ Response Measure: Within two seconds
66
Throughput
■ Measure of the amount of work an application
must perform in unit time
– Transactions per second (TPS)
– Messages per second (MPS)
■ Is required throughput:
– Average?
– Peak?
■ Many system have low average but high peak
throughput requirements

67
Response time
■ Measure of the latency an application exhibits
in processing a request
■ Usually measured in (mili)seconds
■ Often an important metric for users
■ Is required response time:
– Guaranteed?
– Average?

■ E.g. 95% of responses in sub-4 seconds, and

all within 10 seconds
68
Deadlines
■ ‘something must be completed before some
specified time’
– Payroll system must complete by 2am so
that electronic transfers can be sent to
bank
– Weekly accounting run must complete by
6am Monday so that figures are available
to management

■ Deadlines often associated with batch jobs in

IT systems.
69
Attention!
■ What is a
– Transaction?
– Message?
– Request?
■ All are application specific measures.
■ System must achieve 100 mps throughput
– BAD!!
■ System must achieve 100 mps peak
throughput for PaymentReceived messages
– GOOD!!!
70
Softgoals Interdependency
Graphs (SIGs)
A graphical representation
(Chung et al. 2000)
- models non-functional
requirements by
decomposing them on
other non-functional
requirements;
- Specifying the
interdependencies among
them, and
- determining how to
operationalize them.
71
 Application Example
Formal definition of Softgoal weight
Graph G = <g0, S, O, D, Pw, Cw, Aw>
g0 = root goal
S = set of softgoals of G
O = set of operationalization softgoals
D = defines dependency relationships between S and O
Pw = priority weights for the decomposition of softgoals
Pw = <W1, …, Wk>, Wi = weight for subgoal i, ∑i=1, kWi= 1
Cw = contribution weights between parent and child subgolas
(i.e. +2, +1, -1, -2)
Aw = achievement weights of softgoals.
Aw(g) = ∑h in Child(g)Pw(h)*Cw(h)*Aw(h)

Kobayashi, N., Morisaki, S., Atsumi, N. and Yamamoto, S., 2016. Quantitative Non Functional Requirements evaluation
using softgoal weight. J. Internet Serv. Inf. Secur., 6(1), pp.37-46. 72
Evaluating the impact of solutions on
the ID media requirements

(1/6+1/3+1/3+1/6)/4+(1/3+1/3 -(1/6+1/3+1/3+1/6)/4 -
+1/3)/2+(-1)/4 = 1/2 (1/3+1/3+1/3)/2+1/4 = -1/2
73
Automotive example

74
Wrap-up
■ Requirements Engineering is a continuous
process
■ Needs to be correctly managed
■ Several ways to represent requirements
– Functional
– Non-functional
■ Important to specify success criteria of the
requirements

75
Quiz time

■ Let’s switch to Moodle

76