requirements engineering
Post on 15-Jul-2015
706 Views
Preview:
TRANSCRIPT
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
Requirements EngineeringCSC 510North Carolina State University
tim.menzies@gmail.com
February, 2015
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING 3
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
StakeholdersSoftware is for a purpose, for people.But which people?
6
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
Stakeholders, examples:Do all these folks want the same thing?
7
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
Stakeholders, examples:“one” thing is “many” things, depending on stakeholder perspective.
8
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
Stakeholders, examples:Do all these folks want the same thing?
9
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
Stakeholders, examples:Do all these folks want the same thing?
10
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
Getting it wrong
Examples to make you tremble
12
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
Must have mobility access ramps
13
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
Must have external staircase
14
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
Rules for Requirements
20
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
• Yagni !!
Rule1: Do not over- elaborate
21
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING 22
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
Rule #2: Plan tore-plan• Spiral model
(Boehm’84)
• With commit partitions• Place to say
Stop! SaveMoney!
• Swim aroundsome, before entering the waterfall
23
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
BTW: Connection Spiral to Agile• Spiral: a few iterations before
waterfall• Agile: small iterations before more
small iterations• Value for BIG engineering
projects?
25
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
RequirementsNotations
26
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
Example #1: DDP @ NASA
• Enter multi-objectiveoptimization
• New optimizer:• KEYS and
KEYS2• Menzies et al.
2010
31
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
Example #2: Feature mapsWHY?• We don’t deliver code
• We deliver features
• Welcome to the user view
33
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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]
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING 42
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING 43
Oh yeah,we forgot…it has to run fast
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
https://www.dropbox.com/s/7r6tur89avysiyw/Screenshot%202015-02-16%2010.57.39.png?dl=0
44
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING 45
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
writIng REquirements
46
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
Parts of a Req’ts Document
• Product Constraints
• Functional Requirements
• Non-functional Requirements
• Project Issues
• User Stories
50
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING 56
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
ReviewingREquirements
“Testing” things that do not yet execute
59
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING 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?)
Actualsystemrequirements
Actual log of topics addressed in requirements meeting
Not everything is a requirement
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
Is there more than one design?
61
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
Requirements:Bad IDEA?
68
The dissenting view
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING 69
Beware “analysis paralysis”
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
Fans of agile say…• Experience tells you more than excessive initial analysis
70
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
Assessing any of the following in a rigorous manner is an open research issue
• Completeness
• Comprehensibility
• Testability
• Consistency
• Unambiguity
• Writeability
• Modifiability
• Implementability
71
2015, tim.menzies@gmail.com, http://creativecommons.org/licenses/by/4.0/
REQUIREMENTSENGINEERING
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
top related