requirements engineering

2015, [email protected], http://creativecommons.org/licenses/by/4.0/

REQUIREMENTSENGINEERING

Requirements EngineeringCSC 510North Carolina State University

[email protected]

February, 2015



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


REQUIREMENTSENGINEERING 3



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



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



StakeholdersSoftware is for a purpose, for people.But which people?

6



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

7



Stakeholders, examples:“one” thing is “many” things, depending on stakeholder perspective.

8




9




10



Stakeholders havedifferent “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



Getting it wrong

Examples to make you tremble

12



Must have mobility access ramps

13



Must have external staircase

14



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



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



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_runabout_(1).jpg

http://en.wikipedia.org/wiki/File:Ford_Pinto_runabout_(1).jpg



Scope of Software Project Failures

WHY PROJECTS FAIL %1. Incomplete Requirements 13.12. Lack of user involvement 12.43. Lack of resources 10.64. Unrealistic Expectations 9.95. Lack of executive support 9.36. Changing requirements 8.77. Lack of planning 8.18. Didn’t need it any longer 7.59. Lack of IT management 6.210. Technology illiteracy 4.3

Jim Johnson, The Standish Group International Project LeadershipConference, May 1995, Chicago

18



Relative Cost to Fix an ErrorPhase in Which Found Cost Ratio

Requirements 1

Design 3-6Coding 10

Development testing 15-40

Acceptance testing 30-70Operation 40-1000

Boehm’s analysis of 63 s/w development projects (IBM, GTE, TRW, etc.) toDetermine ranges in cost for errors created by false assumptions in req’ts phaseBut not detected till later phases

19



Rules for Requirements

20



• Yagni !!

Rule1: Do not over- elaborate

21



Rule #2: Plan tore-plan• Spiral model

(Boehm’84)

• With commit partitions• Place to say

Stop! SaveMoney!

• Swim aroundsome, before entering the waterfall

23



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



BTW: Connection Spiral to Agile• Spiral: a few iterations before

waterfall• Agile: small iterations before more

small iterations• Value for BIG engineering

projects?

25



RequirementsNotations

26



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



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



Example #1: DDPRequirements 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



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



Example #1: DDP @ NASA

• Enter multi-objectiveoptimization

• New optimizer:• KEYS and

KEYS2• Menzies et al.

2010

31



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



Example #2: Feature mapsWHY?• We don’t deliver code

• We deliver features

• Welcome to the user view

33



Example #2: Feature mapsWHY?• 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



Example #2: Feature mapsThey 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



Example #2: Feature mapsReasoning 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 features3. Build “stuff” In least time4. That we have used most before5. Using features with least known defects

Binary goals= 1,2Tri-goals= 1,2,3Quad-goals= 1,2,3,4Five-goals= 1,2,3,4,5



HV = hypervolume of dominated regionSpread = 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

Example #2: Feature mapsReasoning , performance measures



HV = hypervolume of dominated regionSpread = coverage of frontier% correct = %constraints satisfied

38

Very similar Very 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

Continuousdominance

Binary dominance

ESHOP: 290 features, 421 rules[Sayyad, Menzies ICSE’13]



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



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 of6888 features

130 of6888 features

5704 of6888 features



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



Oh yeah,we forgot…it has to run fast



https://www.dropbox.com/s/7r6tur89avysiyw/Screenshot%202015-02-16%2010.57.39.png?dl=0

44



writIng REquirements

46



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 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 Document Structure (2)• Non-functional requirements definition

• Define constraints on the system and the development process• Add in notes for the commit partition here

• Constraints• Add in notes for the commit partition here

• 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



Parts of a Req’ts Document

• Product Constraints

• Functional Requirements

• Non-functional Requirements

• Project Issues

• User Stories

50



Product Constraintsrestrictions & 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



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



Functional Requirementsthe 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



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



Non-Functional Requirementsthe 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



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



Project Issuesapply 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



ReviewingREquirements

“Testing” things that do not yet execute

59



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?)

Actualsystemrequirements

Actual log of topics addressed in requirements meeting

Not everything is a requirement



Is there more than one design?

61



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 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 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



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



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



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:Bad IDEA?

68

The dissenting view



Beware “analysis paralysis”



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

70



Assessing any of the following in a rigorous manner is an open research issue

• Completeness

• Comprehensibility

• Testability

• Consistency

• Unambiguity

• Writeability

• Modifiability

• Implementability

71



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

Education

stakeholder requirements

uml uml

programmer stakeholders

reason fast requirements

software system

software intensive systems

resulting system

stakeholder perspective