Requirements Engineering

2015, tim.menzies@gmail.com,
http://creativecommons.org/licenses/by/4.0/
REQUIREMENTS
ENGINEERING
Requirements
Engineering
CSC 510
North Carolina State University
tim.menzies@gmail.com
February, 2015

REQUIREMENTS
ENGINEERING
Key points
• Requirements = early life cycle guesses
• And guessing is hard, particularly about the future
• More than just UML
• UML = constructs for the programmer stakeholders
• Need other notations for other stakeholders
• Ultra-light weight notations. Write fast, reason fast
• Requirements, done right, fuels planning
• and iterative development
• Stakeholders
• There are more than one (with conflicting views)
2

REQUIREMENTS
ENGINEERING 3

REQUIREMENTS
ENGINEERING
Requirements Engineering Defined
“The development and use of cost-
effective technology for the elicitation,
specification and analysis of the
stakeholder requirements which are to
be met by software intensive systems.”
[RENOIR]
4

REQUIREMENTS
ENGINEERING
Fred Brooks ...
“The hardest single part of
building a software system
is deciding precisely what
to build … No other part of
the work so cripples the
resulting system if it is
done wrong. No other part
is more difficult to rectify
later.”
5

REQUIREMENTS
ENGINEERING
Stakeholders
Software is for a purpose, for people.
But which people?
6

REQUIREMENTS
ENGINEERING
Stakeholders, examples:
Do all these folks want the same thing?
7

REQUIREMENTS
ENGINEERING
“one” thing is “many” things, depending
on stakeholder perspective.
8

REQUIREMENTS
ENGINEERING
9

REQUIREMENTS
ENGINEERING
10

REQUIREMENTS
ENGINEERING
Stakeholders have
different “non-functional
requirements”
11
Time
• Transactions / sec
• Response time
• Time to complete an operation
Space
• Main memory
• Auxiliary memory
• (Cache)
Usability
• Training time
• Number of choices
• Mouse clicks
Reliability
• Mean time to failure
• Downtime probability
• Failure rate
• Availability
Robustness
• Time to recovery
• % of incidents leading to
catastrophic failures
• Odds data corruption after failure
Portability
• % of non-portable code
• Runs on N operating systems
• Runs on desktop, tablet, mobile
Etc

REQUIREMENTS
ENGINEERING
Getting it wrong
Examples to make you tremble
12

REQUIREMENTS
ENGINEERING
Must have mobility access ramps
13

REQUIREMENTS
ENGINEERING
Must have external staircase
14

REQUIREMENTS
ENGINEERING
The Geneis crash landing
• NASA sample return probe
• collected a sample of solar wind
• returned it to Earth for analysis
• Then crash landed in Utah in 2004
• Landing chute did not deploy
• Design error
• Acceleration installed backwards
• Cost
• $164 million for spacecraft development and science instruments
• $45 million for operations and science data analysis.
• Mistake have been made worse by reuse
• Same design in the (already launched) Stardust cometary sample return craft
• Stardust landed successfully in 2006.
15

REQUIREMENTS
ENGINEERING
Johns-Manville Corporation
• Developed, manufactured and marketed asbestos
building materials based on the assumption that
asbestos, in the form of their products, was
environmentally safe to all exposed people.
• This high-level decision based on a false
assumption produced 52,000 lawsuits costing
approximately $2 billion in liabilities (company
went bankrupt).
16

REQUIREMENTS
ENGINEERING
Ford Pinto
• Manufactured in the 1970s
• The position of the fuel tank
mounting bolts was a good
design based on an assumption:
• There will be no rear impact
collisions!
• Assumption proved to be false.
• Ford spent $100 million in
litigation & recall services
17
http://en.wikipedia.org/wiki/File:Ford_Pinto_runab

REQUIREMENTS
ENGINEERING
Scope of Software Project Failures
WHY PROJECTS FAIL %
1. Incomplete Requirements 13.1
2. Lack of user involvement 12.4
3. Lack of resources 10.6
4. Unrealistic Expectations 9.9
5. Lack of executive support 9.3
6. Changing requirements 8.7
7. Lack of planning 8.1
8. Didn’t need it any longer 7.5
9. Lack of IT management 6.2
10. Technology illiteracy 4.3
Jim Johnson, The Standish Group International Project Leadership
Conference, May 1995, Chicago
18

REQUIREMENTS
ENGINEERING
Relative Cost to Fix an Error
Phase in Which Found Cost Ratio
Requirements 1
Design 3-6
Coding 10
Development testing 15-40
Acceptance testing 30-70
Operation 40-1000
Boehm’s analysis of 63 s/w development projects (IBM, GTE, TRW, etc.) to
Determine ranges in cost for errors created by false assumptions in req’ts phase
But not detected till later phases
19

REQUIREMENTS
ENGINEERING
Rules for Requirements
20

REQUIREMENTS
ENGINEERING
• Yagni !!
Rule1: Do not over- elaborate
21

REQUIREMENTS
ENGINEERING 22

REQUIREMENTS
ENGINEERING
Rule #2:
Plan to
re-plan
• Spiral model
(Boehm’84)
• With commit
partitions
• Place to say
Stop! Save
Money!
• Swim around
some, before
entering the
waterfall
23

REQUIREMENTS
ENGINEERING
How to define the commit partition?
• When writing “the” requirements documents
• Make it testable:
• Where possible, turn “shall” into “can”
• Not “the ATM will respond in 1 second”
• But “Can the ATM respond in 1 second?”
24

REQUIREMENTS
ENGINEERING
BTW: Connection Spiral to Agile
• Spiral: a few iterations before
waterfall
• Agile: small iterations before more
small iterations
• Value for BIG engineering
projects?
25

REQUIREMENTS
ENGINEERING
Requirements
Notations
26

REQUIREMENTS
ENGINEERING
Some Requirements Notations
• Main thing to note:
• Miles and miles above UML diagrams
• At the requirements layer
• Details of classes, states, etc
• Are tiny peripheral details
• Q: Why?
• A: Language levels
• When you talk to programmers
• They want to talk “what” and “how”
• When you talk to high-end business users
• They want to talk about “why” and “why not”
27

REQUIREMENTS
ENGINEERING
Caveat Emptor
(buyer beware)
• Automatic analysis of requirement notations is a bleeding
edge research task
• Later in this talk “Writing Requirements”:
• Simple review procedures for requirements (e.g. manual
checklists)
28

REQUIREMENTS
ENGINEERING
Example #1: DDP
Requirements engineering at JPL
• Team X
• Dozens of experts in propulsion, communications, guidance control
• Meet for week-long sessions to thrash out possibilities for NASA's
next deep space mission.
• Groups sitting at one side of the room to make decisions that
impact sitting somewhere else.
29

REQUIREMENTS
ENGINEERING
Example #1:
DDP @ NASA
• DDP: graphical notation of
• requirements being explored,
• risks that everyone thinks
might damage those
requirements,
• mitigations that might be put in
place to reduce those risks.
• After a few days, those
diagrams can very complex,
• particularly if you are seeking
• the least cost combination of
mitigations
• that retire the most risks
• enabling more requirements
30

REQUIREMENTS
ENGINEERING
Example #1:
DDP @ NASA
• Enter multi-
objective
optimization
• New optimizer:
• KEYS and
KEYS2
• Menzies et al.
2010
31

REQUIREMENTS
ENGINEERING
Example #2: Feature maps
• Design product line
[Kang’90]
• Add in known constraints
• E.g. “if we use a camera
then we need a high
resolution screen”.
• Extract products
• Find subsets of the product
lines that satisfy
constraints.
• If no constraints, linear time
• Otherwise, can defeat
state-of-the-art optimizers
[Pohl et at, ASE’09]
[Sayyad, Menzies ICSE’13].
32
Cross-Tree
Constraints

REQUIREMENTS
ENGINEERING
WHY?
• We don’t deliver code
• We deliver features
• Welcome to the user view
33

REQUIREMENTS
ENGINEERING
WHY?
• Software is changing
• product-based to app-based,
• Before
• Vendors locked in their user base via some complete solution to all their
anticipated needs (e.g. Microsoft Office).
• Large software platforms are very complex and, hence, very slow to change.
• Enter smart phones and tablet-based software,
• users can choose from large numbers of small apps from different vendors,
• each performing a specific small task.
• App-orientedsoftware engineering,
• vendors must quickly and continually reconfigure their apps in order to retain
and extend their customer base.
• demands a new style of feature-based analysis
• Feature maps are a lightweight method for defining a space of
options
• And assessing the value of a particular subset of those options.
34

REQUIREMENTS
ENGINEERING
They can get big
• This model: 10 features, 8 rules
• [www.splot-research.org]:
ESHOP: 290 Features, 421
Rules
• LINUX kernel variability project
LINUX x86 kernel
6,888 Features; 344,000 Rules
35
Cross-Tree Constraints

REQUIREMENTS
ENGINEERING
Reasoning on feature maps: 2,3,4,5
goals
36
Software engineering = navigating the user goals:
1. Satisfy the most domain constraints (0 #violations 100%)≤ ≤
2. Offers most features
3. Build “stuff” In least time
4. That we have used most before
5. Using features with least known defects
Binary goals= 1,2
Tri-goals= 1,2,3
Quad-goals= 1,2,3,4
Five-goals= 1,2,3,4,5

REQUIREMENTS
ENGINEERING
HV = hypervolume of dominated region
Spread = coverage of frontier
% correct = %constraints satisfied
37
Abdel Salam Sayyad, Tim Menzies, Hany Ammar:
On the value of user preferences in search-based software engineering: a case study in software product lines. ICSE 2013: 492-501
Example in bi-goal space
Note: example on next slide reports
HV, spread for bi, tri, quad, five objective space
Reasoning , performance measures

REQUIREMENTS
ENGINEERING
HV = hypervolume of dominated region
Spread = coverage of frontier
% correct = %constraints satisfied
38
Very similarVery different, particularly in % correct
Abdel Salam Sayyad, Tim Menzies, Hany Ammar:
On the value of user preferences in search-based software engineering: a case study in software product lines. ICSE 2013: 492-501
Continuous
dominance
Binary
dominance
ESHOP: 290 features, 421 rules
[Sayyad, Menzies ICSE’13]

REQUIREMENTS
ENGINEERING
State of the Art
39
Features
9
290
544
6888
Pohl ‘11Pohl ‘11 Lopez-
Herrejon
‘11
Lopez-
Herrejon
‘11
Henard ‘12Henard ‘12
Sayyad,
Menzies’13
a
Sayyad,
Menzies’13
a
Velazco
‘13
Velazco
‘13
Sayyad,
Menzies’13b
Sayyad,
Menzies’13b
Johansen
‘11
Johansen
‘11
Benavides ‘05Benavides ‘05
White ‘07, ‘08, 09a, 09b,
Shi ‘10, Guo ‘11
White ‘07, ‘08, 09a, 09b,
Shi ‘10, Guo ‘11
Objectives
Multi-goalSingle-goal
300,000+
clauses

REQUIREMENTS
ENGINEERING
Correct solutions after 30 minutes
for the large Linux Kernel model
40
From IBEA
From Z3
Abdel Salam Sayyad Joseph Ingram Tim Menzies Hany Ammar,
Scalable Product Line Configuration: A Straw to Break the Camel’s Back , IEEE ASE 2013
130 of
6888
features
130 of
6888
features
5704 of
6888
features

REQUIREMENTS
ENGINEERING
Example #3: Another requirements
ontology: Mylopoulos et al.
Nodes
• Goals
• Goal ependencies are used to represent
delegation of responsibility for fulfilling a
goal;
• Softgoal:
• Subjective criteria, things we strive to
achieve to some degree.
• May be traded off if necessary
• Depender (D), dependee (d)
• Task dependencies are used in situations
where the dependee is required to
perform a given activity;
• Resource dependencies require the
dependee to provide a resource to the
depender
Edges
• Edges
• Dependency (D to d)
• Part-of (decomposition)
• Means-end link
41

REQUIREMENTS
ENGINEERING 42

REQUIREMENTS
ENGINEERING 43
Oh yeah,
we forgot…
it has to run fast

REQUIREMENTS
ENGINEERING
https://www.dropbox.com/s/7r6tur89avysi
yw/Screenshot%202015-02-
16%2010.57.39.png?dl=0
44

REQUIREMENTS
ENGINEERING 45

REQUIREMENTS
ENGINEERING
writIng REquirements
46

REQUIREMENTS
ENGINEERING
The Requirements Document
• The official statement of what is required of the
system developers
• Should include both a definition and a
specification of requirements
• It is NOT a design document
• As far as possible, it should set of WHAT the
system should do rather than HOW it should do it
• Also, it should have tests that can be applied
incrementally
• See “commit partition”, below
47

REQUIREMENTS
ENGINEERING
Requirements Document Structure (1)
• Introduction
• Describe need for the system and how it fits with business
objectives
• Glossary
• Define technical terms used
• System models
• Define models showing system components and
relationships
• Functional requirements definition
• Describe the services to be provided
• User stories go here
• Add in notes for the commit partition here
48

REQUIREMENTS
ENGINEERING
Requirements Document Structure (2)
• Non-functional requirements definition
• Define constraints on the system and the development process
• Constraints
• System evolution
• Define fundamental assumptions on which the system is based
and anticipated changes
• Requirements specification
• Detailed specification of functional requirements
• Appendices
• System hardware platform description
• Database requirements (as an ER model perhaps)
• Index
49

REQUIREMENTS
ENGINEERING
Parts of a Req’ts Document
• Product Constraints
• Functional Requirements
• Non-functional Requirements
• Project Issues
• User Stories
50

REQUIREMENTS
ENGINEERING
Product Constraints
restrictions & limitations that apply to the product & problem
1. Purpose of Product - the reason for building it and the
business advantage if we do so
2. Stakeholders - the people with an interest in the product
3. Users - the intended end-users, & how they affect the
product’s usability
4. Requirements Constraints - limitations on the project &
restrictions on product’s design
5. Naming Conventions & Definitions - vocabulary of the
product
6. Relevant Facts - outside influences that make some
difference to this product
7. Assumptions - that the developers are making
51

REQUIREMENTS
ENGINEERING
Constraints Are:
• global requirements that shape the requirements
• apply to the entire product
• The users of a product are a constraint since they
dictate usability of the product:
• Constraints may also be placed on the eventual
design and construction of the product:
Passengers on board an aircraft will use the product.
The product shall run on the company’s existing UNIX
machines.
52

REQUIREMENTS
ENGINEERING
Functional Requirements
the functionality of the product
8. Scope of the Product - defines the product
boundaries and its connections to adjacent systems
9. Functional & Data Requirements - things the
product must do and the data manipulated by the functions
53

REQUIREMENTS
ENGINEERING
Functional Requirements Are:
• Things the product must do
• An action that the product must take to provide
functionality for its user
• Arise from the fundamental reason for the
product’s existence
-> Something systems must do if it is to be useful within
the context of the customer’s business needs.
The product shall produce an amended de-icing schedule when a
change to a truck status means that previously scheduled work
cannot be carried out as planned.
54

REQUIREMENTS
ENGINEERING
Non-Functional Requirements
the products qualities
10. Look & Feel Reqt’s - the intended appearance
11. Usability Reqt’s - based on the intended users
12. Performance Reqt’s - how fast, big, accurate, safe
reliable, etc.
13. Operational Req’ts - the product’s intended operating
envt.
14. Maintainability & Portability Reqt’s - how changeable
the product must be
15. Security Reqt’s - the security, confidentiality & integrity of
the product
16. Cultural & Political Reqt’s - human factors
17. Legal Reqt’s - conformance to applicable laws
55

REQUIREMENTS
ENGINEERING 56

REQUIREMENTS
ENGINEERING
Non-Functional / Quality Requirements
Are:
• properties, or qualities, that the product must have
• may be critical to the product’s success
• some NFRs may simply enhance the product:
• NFRs are usually attached to the product’s functionality
• E.g., how it will behave, qualities it is to have, how big or fast it should be
The product shall determine ‘friend or foe’ in less than 0.25
seconds.
The product shall use company colors, standard company logos
and standard company typefaces.
57

REQUIREMENTS
ENGINEERING
Project Issues
apply to the project that builds the product
18. Open Issues - as yet unresolved issues w/ a possible
bearing on the product’s success
19. Off-the-Shelf Solutions - components that may be used
instead of building something
20. New Problems - caused by the introduction of new
product
21. Tasks - things to be done to bring the product into
production
22. Cutover - tasks to convert from existing systems
23. Risks - the risks the project is most likely to face
24. Costs - early estimates of cost or effort needed to build it
25. User Documentation - plan for building user
documentation
26. Waiting Room - req’ts to be included in future releases
58

REQUIREMENTS
ENGINEERING
Reviewing
REquirements
“Testing” things that do not yet execute
59

REQUIREMENTS
ENGINEERING 60
Definition
of user-
level demos
Non-functional requirements Things talked about, but
need not be in this system
(maybe ideas for other
development, another
time?)
Actual
system
requirements
Actual log of topics addressed
in requirements meeting
Not everything is
a requirement

REQUIREMENTS
ENGINEERING
Is there more than one design?
61

REQUIREMENTS
ENGINEERING
Is there more than one design?
• Assessing options of criteria
• predictability (1), security (2), adaptability (3), coordinability (4),
cooperativity (5), availability (6), integrity (7), modularity (8), or
aggregability (9)
• Which is best? Dunno. Ask your stakeholders!
• But add value to their discussions
• Give them considered conclusions to aid their decisions
62

REQUIREMENTS
ENGINEERING
Requirements Checking
• Validity
• Does the system provide the functions which best
support the customer’s needs?
• Consistency
• Are there any requirements conflicts?
• Completeness
• Are all functions required by the customer included?
• Realism
• Can the requirements be implemented given available
budget and technology
63

REQUIREMENTS
ENGINEERING
Requirements Review Checks
• Verifiability
• Is the requirement realistically testable?
• Comprehensibility
• Is the requirement properly understood?
• Traceability
• Is the origin of the requirement clearly stated?
• Adaptability
• Can the requirement be changed without a large impact
on other requirements?
64

REQUIREMENTS
ENGINEERING
Check for ambiguity in Stating
Requirements
• Missing requirements
• (e.g. structure, functions, physical env’t.)
• Ambiguous words
• E.g., small does not adequately specify the size of the group
• E.g., group implies that the people will interact, but it’s not clear how
• Introduced elements
• E.g., Structure - “create a means” or “design a structure”
[Gause and Weinberg 1989]
65

REQUIREMENTS
ENGINEERING
Exploring to Remove Ambiguity
(What explorers do)
• Move in some direction
• Look at what they find there
• Record what they find
• Analyze their findings in terms of where they
want to be
• Use their analysis and recordings of what they
find to choose the next direction
• Go back to step 1 and continue exploring
66

REQUIREMENTS
ENGINEERING
Identify the Requirements
“Classes”
• Enduring requirements
• Stable requirements derived from the core activity of the
customer organization.
• E.g. a hospital will always have doctors, nurses, etc.
• May be derived from domain models
• Volatile requirements
• Requirements which change during development or when
the system is in use.
• In a hospital, requirements derived from health-care policy
67

REQUIREMENTS
ENGINEERING
Requirements:
Bad IDEA?
68
The dissenting view

REQUIREMENTS
ENGINEERING 69
Beware “analysis paralysis”

REQUIREMENTS
ENGINEERING
Fans of agile say…
• Experience tells you more than excessive initial analysis
70

REQUIREMENTS
ENGINEERING
Assessing any of the following
in a rigorous manner is an
open research issue
• Completeness
• Comprehensibility
• Testability
• Consistency
• Unambiguity
• Writeability
• Modifiability
• Implementability
71

REQUIREMENTS
ENGINEERING
As to the real value of requirements….
• Ideally, we look before we leap
• Find best ways to do proceed
• And we don’t get it wrong
• In reality, our initial peeks are wrong
• Need extensive modification
• If you want God to laugh, tell her your plans
• Recent research says requirements are an illusion
• Cognitive phenomena including anchoring bias, fixation and confirmation bias
• Misrepresenting decisions as requirements in situations where no real requirements
are evident.
• Misrepresenting an incidental feature as a requirement will reduce exploration of the
design space, curtailing innovation
• Nevertheless, sometime in your career,
• you will be asked “how do we start?”
• Welcome to the black art of requirements engineering
72

Requirements Engineering

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (7)

Similar to Requirements Engineering

Similar to Requirements Engineering (20)

More from CS, NcState

More from CS, NcState (20)

Recently uploaded

Recently uploaded (20)

Requirements Engineering