daniel m. berrydberry/atre/slides/iceberg... · 2015. 5. 1. · ` la barry boehm [1988b] determine...
TRANSCRIPT
The RequirementsIceberg and VariousIcepicks Chipping atIt
Daniel M. Berry
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 1
Requirements
Client’sView
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 2
The Boring Title
Requirements Engineering (RE):the Problems and anOverview of Research
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 3
Outline
Lifecycle ModelsRE is HardWhy Important to Do RE EarlyMyths and RealitiesWhere Do Requirements Come From?Formal Methods Needed?Requirements and Other EngineeringBottom LineRE Lifecycle
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 4
Outline, Cont’d
Overview of ResearchEarlier and LaterElicitationAnalysisNatural Language ProcessingToolsChangesEmpirical Studies
Future
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 5
Traditional Waterfall Lifecycle
a la Win Royce [1970]
Realization
Operation
Integration
Design
Specifications
Requirements
Where is testing?
Only one slight problem: It does not work!
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 6
Problems with Waterfall Model
The main problem, from the requirementspoint of view, of the waterfall model is thefeeling it conveys of the sanctity andunchangeability of the requirements, assuggested by the following drawing by BarryBoehm [1988a].
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 7
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 8
Problems with Waterfall, Cont’d
This view does not work becauserequirements always change:
g partially from requirements creep (but goodproject management helps)
g partially from mistakes (but prototypingand systematic methods help)
g partially because it is inherent in softwarethat is used (the concept of E-type systemsis discussed later!)
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 9
Fred Brooks about Waterfall
In ICSE ’95 Keynote, Brooks [1995a] says “TheWaterfall Model is Wrong!”
g The hardest part of design is deciding whatto design.
g Good design takes upstream jumping atevery cascade, sometimes back more thanone step.
ICSE ’95 was in Seattle, Washington!
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 10
Fred Brooks also says:
“There’s no silver bullet!” [Brooks 1987]
g Accidentsprocessimplementation
i.e., details
g EssenceRequirements
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 11
“No Silver Bullet” (NSB)
g The essence of building software isdevising the conceptual construct itself.
g This is very hard.
- arbitrary complexity- conformity to given world- changes and changeability- invisibility
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 12
NSB, Cont’d
g Most productivity gain came from fixingaccidents
- really awkward assembly language- severe time and space constraints- long batch turnaround time- clerical tasks for which tools are helpful
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 13
NSB, Cont’d
g However, the essence has resisted attack!
We have the same sense of beingoverwhelmed by the immensity of theprogramming problem and theseemingly endless details to take careof,
and we produce the same kind of poorlydesigned software that makes the samekind of stupid mistakes
as 40 years ago!
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 14
Brooks, Cont’d
Brooks adds, “The hardest single part ofbuilding a software system is decidingprecisely what to build.... No other part of thework so cripples the resulting system if it isdone wrong. No other part is more difficult torectify later.”
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 15
Real Life
We see similar requirement problems in real-life situations not at all related to software.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 16
Contracts
We all know how hard it is to get a contractjust right ...
to cover all possible unanticipated situations.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 17
Houses
We all know how hard it is to get a house planjust right before starting to build the house.
Contractors even plan on this; they underbidon the basic plan, expecting to be able toovercharge on the inevitable changes theclient thinks of later [Berry 1998].
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 18
Homework Assignments
We all know how hard it is to get thespecification of a programming homeworkassignment right, especially when theinstructor must invent new ones for every runof the course.
There is a continual stream of updates to theassignment.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 19
SE Lifecycle and Reqs Changes
Thus, the SE lifecycle must be prepared todeal with ever-changing requirements.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 20
More Realistic Lifecycle Model
Spiral Model a la Barry Boehm [1988b]Determine objectives, alternatives,
next level product
Develop, verify
Benchmarks
Models,
Simulations,
Risk analysis
identify, resolve risks
Evaluate alternatives;
Plan next phase
constraints
One may even follow the waterfall in each 360°sweep of the spiral.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 21
Spiral Model
That is, the requirements and theimplementation are developed incrementally.
That requirements are changing is planned.
But still, where is testing?
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 22
V Model
Some describe one such sweep not as awaterfall, but as a V
1.
2.
3.
4.
5.
6.
7. 8.
9.11.
12.
10.
softwarerequirements
preliminarydesign
detaileddesign
coding
unit testplanning
integrationtest
softwaresystem test
planning
systemtesting
integrationtesting
unittesting
deliveryproductiondeployment
maintenanceand
enhancementplanning
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 23
Planned Testing
The V model
g tries to indicate different volumes ofinformation flow
g puts test planning and testing into itsproper place, i.e., everywhere !
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 24
More Unrealism in Waterfall
The Waterfall model imples also that all stepsare equally systematic:
Realization
Operation
Integration
Design
Specifications
Requirements
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 25
REAL Lifecycle for One Sweep
ClientIdeas
ReqsSpecs
Design Code
More haphazard More systematic
More difficult than thought to be
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 26
Requirements Engineering
That wavy line between Client Ideas andRequirements Specifications is RE.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 27
IEEE Definition of Requirement
1. a condition or capability needed by a userto solve a problem or achieve an objective
2. a condition or capability that must be metor possessed by a system or systemcomponent to satisfy a contract, standard,specification, or other formally imposeddocument
3. a documented representation of acondition or capability as in (1) or (2)
[IEEE 1998]
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 28
Kinds of Requirements
g functional—what the system should dog non-functional—constraints on system or
process, quality requirements
Some non-functional requirements (NFR) arenot specifiable, e.g., user friendliness.
It is often difficult to distinguish the two, e.g.,a response time.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 29
Loucopoulos’s Definition of RE
Loucopoulos and Karakostas [1995]:
RE is a systematic process ofg developing requirements through an
iterative cooperative process of analyzingthe problem,
g documenting the resulting observations ina variety of representation formats, and
g checking the accuracy of theunderstanding gained.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 30
Hsia’s Definition of RE
RE is all activities which are related tog identifying and documenting customer and
user needs,g creating a document that describes the
external behavior and associatedconstraints that will satisfy those needs,
g analyzing and validating the requirementsdocument to insure consistency,completeness and feasibility, and
g evolution of these needs.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 31
Zave’s Definition of RE
Pamela Zave [1997]:
RE is the branch of SE concerned with real-world goals for, functions of, and constraintson software systems. It is also concerned withthe relationship of these factors to precisespecifications of software behavior, and totheir evolution over time and across softwarefamilies.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 32
Zave’s Definition of RE, Cont’d
Important aspects of definition [Nuseibeh &Easterbrook 2000]:
g real-world goalsf whatf why
g precise specifications, basis forf analyzing requirementsf validating with stakeholdersf defining what is to be builtf verifying implementation
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 33
Zave’s Definition of RE, Cont’d
g evolutionf over time for a changing worldf across families with partial reuse
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 34
Systems, Not Just Software
Bashar Nuseibeh & Steve Easterbrook [2000]:
RE has been called a branch of SoftwareEngineering.
In reality, software cannot function in isolationfrom the system in which it is embedded.
Prefer to characterize RE as a branch ofSystems Engineering.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 35
Ryan’s Definition of RE
RE is the development and use of cost-effective technology for the elicitation,specification and analysis of the stakeholderrequirements which are to be met by softwareintensive systems.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 36
Stakeholders
A stakeholder is a person who is directly orindirectly affected by the system underconstruction, .e.g.,
g customers and usersg marketing and sales personnelg developers and testersg maintainersg managers
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 37
But ‘X Engineering’ is Illegal
“Engineering” is a controlled term, not legal touse with “Requirements”.
The term “RE” is used as a reminder that thegathering of requirements occurs as part of anengineering process.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 38
RE is Hard
How hard?
Like fighting a platoon of angry, slightlyinebriated Klingons.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 39
Distance: Concept → Specs
Concept
FormalSpec.
InformalSpec.
Folded in middle to give feeling of trueconceptual distances involved
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 40
Modeling Difficulties
Brian Mathews has another view in terms ofmodeling
Model
Desired
Mir
ror
- A
nal
ysis
Wat
er -
An
alys
is
Reality
Model
Real World Real World
Air - Elicitation Fog - Elicitation
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 41
What vs. How
A requirements specification is supposed todescribe what the system should do and nothow.
It is not easy to obey this rule in practice.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 42
What vs. How, Cont’d
One person’s how is another person’s what;to an author, a WORD data structure is a howissue, but to a system programmer, a datastructure in UNIX is a what issue.
In a model of multiple levels of abstraction,each level is both the how of the level aboveand the what of the level below. [Ryan 1998]
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 43
Three Kinds of Requirements
Krogstie [1998] identifies 3 kinds of systemrequirements.
1. Normal—Users mention these with noproblems.They contribute proportionally to usersatisfaction of the system.
2. Exciting—Creative developers inventthese.They contribute dramatically to usersatisfaction of the system.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 44
Three Kinds, Cont’d
3. Tacit—Users understand these, but do notmention them; developers do not seethese.Unfound by developers, they contributedramatically to user dissatisfaction of thesystem.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 45
Three Kinds, Cont’d
Not FulfillExpectations
FulfillExpectations
Satisfaction
Dissatisfaction
Normal
Require
men
ts
Exciti
ng Req
uirem
ents
Tacit Require
ments
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 46
Errors and Requirements
According to Barry Boehm [1981] and others,around 75–85% of all errors found in SW canbe traced back to the requirements and designphases.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 47
Errors and Requirements, Cont’d
Ken Jackson in a 2003 Tutorial onRequirements Management and Modeling withUML2, cites data from a year 2000 survey of500 major projects’ maintenance costsconcluding that 70–85% of total project costsare rework due to requirements errors andnew requirements.
In the table, the *d lines include requirementsissues and add to 84%, but not all theirinstances are requirements related.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 48
Errors and Requirements, Cont’d
Cause of Rework %-age of TotalProject Costsiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
*Changes in user requirements 43%*Changes in data formats 17%*Emergency fixes 12%*Hardware changes 6%*Documentation 6%Efficiency improvements 6%Other 9%
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 49
Flip Side
Those data say that we are doing a prettygood job of implementing of what we think wewant.
But, we are doing a lousy job of knowing whatwe want.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 50
Source of Errors
Either
g the erroneous behavior is required becausethe situation causing the error was notunderstood or expressed correctly, or
g the erroneous behavior happens becausethe requirements simply do not mentionthe situation causing the error, andsomething not planned and not appropriatehappens.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 51
Worth Fixing an Error?
Sometimes it’s not worth fixing arequirements error in software that workspretty well. That is, it’s not worth modifyingthe software to meet a newly discoveredrequirement.
E.g., at U of Waterloo, a system called QUESThas automated course scheduling andregistration so that a student can register online via the WWW.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 52
Worth Fixing an Error, Cont’d?
For each course C for which a student S triesto register, QUEST checks that S hassuccessfully taken all the prerequisites for C.
However, there are degree programs, e.g.,ConGESE, that use regular courses, but in anon-normal sequence. In this program,because everyone is already a practicingsoftware engineer, no course has anyprerequisites.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 53
Worth Fixing an Error? Cont’d
Thus when a ConGESE student tries toregister for the RE course I teach at UW, he orshe is usually not allowed to register becausehe or she has not taken any of the prerequisitecourses.
This situation was never considered indeveloping QUEST.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 54
Worth Fixing an Error? Cont’d
Fortunately, QUEST has provided forsuperusers that can force QUEST to acceptregistrations that would otherwise not beallowed. So the students were able to beregistered.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 55
Worth Fixing an Error? Cont’d
Is it worth changing QUEST?
Decidely, “No!”.
The frequency of the ConGESE situation isonce every year, and the number of studentsinvolved is between 10 and 20 each time.
It’s easy enough for a superuser to handle thesituation manually.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 56
Worth Fixing an Error? Cont’d
Modifying the software risks introducing bugs.
This change would be rather complex becauseit would have to introduce a notion ofindependent streams with differentprerequisite structures and force prerequisitesto be associated not with just a course, but acourse and a program together. Implementingthis means changing the whole courseabstraction. Yecch!
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 57
Worth Fixing an Error? Cont’d
So this bug is declared as a feature, and thesuperuser intervention becomes the officialway to deal with ConGESE courseregistrations.
The same solution will be applied to any otherdegree program with similar requirements....
Until such time as there are so many otherprograms that superuser interventionbecomes burdensome.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 58
Even NASA Doesn’t Always Fix
Robyn Lutz and Ines Carmen Mikulski [2003]discuss how NASA sometimes discoversrequirements errors and new requirementsduring system operations.
If a mission is already in progress, sometimesthe response to this discovery is to changethe procedures for the human operators atmission control rather than to try to modifythe embedded system on board a space craft.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 59
Paradox
Fred Brooks [1995b] observed that a generalpurpose system is harder to design than aspecial purpose product.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 60
Study of Requirement Errors
by Martin & Tsai [1988]
Experiment to identify lifecycle stages inwhich requirement errors are found
Polished 10-page requirements for centralizedrailroad traffic controller, ...
written by the user, a professional railroadtraffic controller who had become aprogrammer—BOBW!
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 61
Experiment
Ten 4-person teams of software engineers,pretending to prepare for implementation
User believed that teams would find only 1 or2 errors
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 62
Study, Cont’d
92 errors, some very serious, were found!
Average team found only 35.5 errors, i.e., itmissed 56.5 to be found downstream!
Many errors found by only one team!
Errors of greatest severity found by fewestteams!
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 63
Michael Jackson Says
In a Requirements Engineering ’94 Keynote,Jackson [1994] says:
Two things are known about requirements:1. They will change!2. They will be misunderstood!
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 64
Tacit Assumption Tarpit
A “Foxtrot” cartoon in which Jason’shomework solution lists all the tacitassumptions, and I mean all, that allow him todeduce that the average speed of a 180 miletrain trip from 10am until 2pm is 45mph.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 65
Tacit Assumptions, Cont’d
Those tacit assumptions of the problem arereasonable, right?
Unfortunately, the source of most disasters,such as at nuclear power plants, is perfectlyreasonable, possibly explicit but usually tacit,assumptions that did not hold in some specialcircumstances that nobody thought about.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 66
Timely Tacit Assumptions
According to the UW schedule, a TA had alaboratory scheduled for “8:00” (with no “am”or “pm”). He and some students assumed thatit was at 8:00am. Most students assumed thatit was at 8:00pm. The university meant“8:00pm”.
Perhaps, those who assumed it was “8:00am”could have figured that since classes start at8:30am, “8:00” had to be “8:00pm”, but that’sstretching it.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 67
Timely Tacit Assumptions, Cont’d
The university schedule should have made itclear that it was at 8:00pm.
The reason it did not say “8:00pm” is thatthere is no “pm” designation because in mostcases, from from 12:00 until 5:00, it is obviousthat “pm” is meant. Who goes to class at4:00am?
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 68
More Timely Tacit Assumptions
Once in Tel Aviv, I read a Hebrew no-parkingsign saying “8:00–17:00” as saying that thereis no parking from 5:00pm until 8:00am thenext morning to reserve parking places for thepeople who live on the street, who would havespecial exemption certificates.
While numerals are read from left to right, theflow of the sentence is from right to left andthe “–” is not part of each numeral.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 69
Timely Tacit Assumptions, Cont’d
According to the city of Tel Aviv, the signmeans that there is no parking from 8:00amuntil 5:00pm to keep the street traversableduring the business day.
According to Hebrew reading rules, I amcorrect and the city is wrong.
I could not get the city to see their error andcancel the ticket!
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 70
Requirements Always Change
In a Requirements Engineering ’94 Keynote,Michael Jackson says:
Two things are known about requirements:
1. They will change!2. They will be misunderstood!
Why will they always change?
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 71
E-Type Software
a la Meir Lehman [Lehman 1980]
An E-type system solves a problem orimplements an application in some real-worlddomain.
Once installed, an E-type system becomesinextricably part of the application domain, sothat it ends up altering its own requirements.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 72
E-Type Software, Cont’d
Example:
g Consider a bank that exercises an option toautomate its process and then discoversthat it can handle more customers.
g It promotes and gets new customers, easilyhandled by the new system but beyond thecapacity of the manual way.
g It cannot back out of automation.g The requirements of the system have
changed!
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 73
E-Type Software, Cont’d
Daily use of a system causes an irresistibleambition to improve it as users begin tosuggest improvements.
Who is not familiar with that, from either end?
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 74
E-Type Software, Cont’d
In fact, data show that most maintenance isnot corrective, but for dealing with E-typepressures!
Perfective
Adaptive
Corrective
Oth
er
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 75
RE is Hard
Despite the clear benefits of gettingrequirements complete, right, and error-freeearly, they are the hardest part of the systemdevelopment lifecycle to do right because:
g we don’t always understand everythingabout the real world that we need to know,
g we may understand a lot, but we cannotexpress everything that we know,
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 76
RE is Hard, Cont’d
g we may think we understand a lot, but ourunderstanding may be wrong,
g requirements change as clients’ needschange,
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 77
RE is Hard, Cont’d
g requirements change as clients and usersthink of new things they want, and
g requirements of a system change as adirect result of deploying the system, aspointed out by Meir Lehman.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 78
Sources of RE Difficulties
g RE is where informal meets formal (saysMichael Jackson [1995]).
g Many requirements are created, not found.g Users, buyers, even developers may be
unknown.g Stakeholders have conflicting objectives.g Multiple views exist.g Inconsistency must be tolerated, for a
while.g Requirements evolve during and after
development.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 79
The TRUTH AboutMethodology Literature
Did you ever notice how error- andbacktracking-free are example developmentsfrom clean requirements in the methodologyliterature?
Have you ever noticed how your owndevelopments never go quite as smoothly andhow your requirements are never totally right?
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 80
Truth, Cont’dAs an author of some of this literature, I will letyou in on a little secret!
Shhh!
What you see in the literature is cleaned upfrom the rather messy real-life development.
The requirements specification was modifiedmore than the design and code.
Nu?
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 81
Montenegro’s View
Sergio Montenegro described the reality byshowing an older view of the requirementsengineering process:
and then a newer view, formed after hearingan earlier version of this talk:
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 82
Subprocesses of the Requirements Phase
Formalization
Functional
Requirements
Physical
Properties
Safety
Requirements
Requirements
Functional
Requirements
Physical
Properties
Safety
Requirements
Discretization
Functional
Requirements
Physical
Properties
Measurements
Functional
Requirements
Physical
Properties
Safety
Requirements
Textual/Informal
Continuous
Discrete
Measured
Mental ModelDescription
Safety
Requirements
Gauge
Requirements
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 83
Relation between Getting and Formalizing Requirements
Subprocesses of the Requirements Phase
Formalization
Functional
Requirements
Physical
Properties
Safety
Requirements
Requirements
Functional
Requirements
Physical
Properties
Safety
Requirements
Discretization
Functional
Requirements
Physical
Properties
Measurements
Functional
Requirements
Physical
Properties
Safety
Requirements
Textual/Informal
Continuous
Discrete
Measured
Safety
Requirements
Gauge
Requirements
Get Requirements from theMind of the Customer
Anthropology (Observe)Psychology (Talk)
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 84
Why Important to Do RE Early
The BIG Question:
Why is it so important to get the requirementsright early in the lifecycle? [Boehm 1981,Schach 1992]
We know that it is much cheaper to fix an errorat requirements time than any time later in thelifecycle.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 85
Cost to Fix Errors
Barry Boehm’s (next slide) and SteveSchach’s (slide after that) summaries of dataover many application areas show that fixingan error after delivery costs two orders ofmagnitude more than fixing it it at RE time.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 86
Phase in which error is detected
1
2
5
10
20
50
100
Rel
ativ
e co
st to
cor
rect
err
or
Preliminarydesign
Detaileddesign
Code anddebug
Integrate Validate Operation
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 87
200
150
100
50
0Reqs Specs Plan Design Code Integ Maint
1 2 3 4 10
30
Rel
ativ
e co
st to
fix
faul
t
Phase in which fault is detected and fixed
200
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 88
Conclusion...
Therefore, it pays to find errors during RE.
Also, it pays to spend a lot of time getting therequirements specification error-free, to avoidlater high-cost error repair, and to speed upimplementation—even 90% of the lifecycle!
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 89
Reliability, Safety, Security, & Survivability
We know that we cannot program reliability,safety, security, and survivability into the codeof a system only at implementation time. Theymust be required from the beginning so thatconsideration of their properties permeate theentire system development [Leveson 1995,Cheheyl et al 1981, Linger et al 1998].
The wrong requirements can preclude codingthem at implementation time.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 90
Prime Example: the Internet
Everybody is complaining about how insecurethe Internet is [Neumann 1986]
Many are trying to add security to the Internet,and ultimately fail.
Why?
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 91
Internet Requirements
The original requirements for the ARPAnet,which later became the Internet, was that it becompletely open.
Anyone sitting anywhere on the net was to beable to use any other site on the net as if he orshe were logged in at the other site.
In other words, the ARPAnet was required tobe open and essentially insecure [Cerf 2003,Leiner et al 2000].
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 92
Internet Requirements Were Met
And the implementers of the ARPAnet did adamn good job of implementing therequirements!
Adding security to the Internet ultimately failsbecause there is always a way around the addon security through the inherently openInternet.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 93
Secure Internet from Reqs Up
To get a secure Internet, we have to rebuildthe whole thing from requirements up, andthere is no guarantee that it will look anythinglike what we have now and that the sameapplications would run on it.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 94
User Interfaces (& Errors)
The same is true about good user interfaces.
They cannot be programmed in later.
They must be required in from the beginning[Shneiderman 1984, Kosters, Six & Voss1996].
Same is true also about system responses toerroneous input.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 95
RE & Project Costs
The next slides show the benefits of spendinga significant percentage of development costson studying the requirements.
They contain a graph by Kevin Forsberg andHarold Mooz [1997] relating percentage costoverrun to study phase cost as a percentageof development cost in 25 NASA projects.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 96
Project Costs, Cont’d
The study, performed by W. Gruhl at NASA HQincludes such projects as
g Hubble Space Telescopeg TDRSSg Gamma Ray Obs 1978g Gamma Ray Obs 1982g SeaSatg Pioneer Venusg Voyager
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 97
Project Costs, Cont’d180
160
140
120
100
80
60
40
20
0
0 5 10 15 20 25
Per
cen
tag
e C
ost
Ove
rru
n
Study Phase Cost as a Percentof Development Cost
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 98
Project Costs, Cont’d
There are three interpretations of the data:
The more you study the problem, ...
1. the lower the costs,2. the fewer the surprises that cause
debugging and rework, and,3. the more accurate the cost estimates are.
It’s probably a mixture of these.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 99
Some Advantages of Project Delay
Arnis Daugulis [1998] reports a significantincrease in the quality of the requirements fora power plant control system as a result ofdelays in start of production caused byshortage of funds.
They had the luxury of time to do tworevisions of the requirements.
He shudders to think of the failure that wouldhave resulted had they started to implementthe first requirements on time.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 99
A Case Study of Serious RE
A Master’s student of mine, Lihua Ou, did acase study of writing requirementsspecification in the form of a user’s manual[Berry et al (Ou) 2004].
It was very successful in that I got a piece ofsoftware that I wanted, it was implementedwell, it does what I want it to do, and there is awell-written manual that describes thesoftware’s behavior completely.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 100
A Case Study, Cont’d
Along the way, it ended up being also a casestudy in just having a serious requirementsprocess, in which implementation did notbegin, and was in fact delayed, until therequirements were completely worked out andspecified satisfactorily.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 101
The Software
The software was a WYSIWYG, directmanipulation picture drawing program, WD-PIC, based on the batch picture drawinglanguage PIC, a TROFF preprocessor.
Lihua Ou’s assignment was to produce a firstproduction-quality version of WD-PIC as hermaster’s thesis project.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 102
Ou’s Professional Background
Prior to coming to graduate school, Ou hadbuilt other systems in industrial jobs, mainlyin commerce.
She had followed the traditional waterfallmodel, with its traditional heavy weight SRS.
She had made effective use of libraries tosimplify development of applications.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 103
Ou’s Input
Ou was to look at all previous prototypes andUMs as specifications.
She was to filter these and scope them to firstrelease of a production quality version of WD-PIC running on Sun UNIX systems.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 104
Ou’s Assignment
Ou was to write a specification of WD-PIC inthe form of a UM.
This UM was
1. to describe all features as desired by thecustomer, and
2. to be accepted as complete by thecustomer,
before beginning design or implementation.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 105
Ou’s Assignment, Cont’d
Once implementation started, whenever newrequirements were discovered, the UM had tobe modified to capture new requirements.
In the end, the UM was to describe theprogram as delivered.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 106
Project PlaniiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiDurationin months Stepiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii1 Preparationiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii2 Requirements specificationiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii4 Implementationiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii2 Testingiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii1 Buffer (probably more implementation
and testing)iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii10 Total plannediiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiicc
cccccccccc
cccccccccccc
cccccccccccc
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 107
preparation
requirement
design
implementation
testing
10/1/01
11/1
1/1/02
2/1
5/1
6/31Note feedback
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 108
Actual ScheduleiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiDurationin months Stepiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii1 Preparationiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii4.9 Writing of user’s manual = reqs spec,
11 versionsiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii.7 Design including planning for maximum
reuse of PIC code and JAVA libraryiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii1.7 Implementation including module testing
and 3 manual revisionsiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii1.7 Integration testing including 1 manual
revision and implementation changesiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii10 Total actualiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiicc
ccccccccccccc
ccccccccccccccc
ccccccccccccccc
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 109
preparation
requirement
design
implementation
testing
10/2/01
11/1
3/28/02
4/20
6/11
7/31Note feedback
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 110
What Happened?
While detailed plan was not followed, totalproject time was as planned.
Also, Ou produced two implementations forthe price of one, for:
g (planned) Sun with UNIX andg (unplanned) PC with Windows 2000
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 111
Surprise
Ou was more surprised than Berry that shefinished on time.
Berry had a lot of faith in the power of goodRE to reduce implementation effort.
Adding to Ou’s surprise was that therequirements phase took nearly 5 monthsinstead of 2 months; the schedule had slipped3 months out of 10, what appeared to be waybeyond recovery.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 112
Then and ...
Ou’s long projected implementation andtesting times and the 1 month buffer indicatethat she expected implementation to beslowed by discovery of new requirements thatnecessitate major rewriting and restructuring.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 113
Then and Now
This time, only minor rewriting and norestructuring.
Thus instead of 2 months specifying and 7months implementing and testing,
she spent 5 months specifying and only 4months implementing and testing.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 114
Why?
By spending 3 additional months writing aspecification that satisfied a particularly hard-nosed customer who insisted that the manualconvince him that the product already existed,
Ou produced a specification that
g had very few errors andg that was very straightforwardly
implemented.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 115
The Errors
Almost all errors found by testing wererelatively minor, easy-to-fix implementationerrors.
The two requirement errors were relatively lowlevel and detailed.
They involved subfeatures in a way thatrequired only very local changes to both theUM and the code.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 116
What Helped?
All exceptional and variant cases had beenworked out and described in the UM.
Thus, very little of the traditional
g implementation-time fleshing out ofexceptional and variant cases and
g implementation-time subconscious RE.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 117
Test Cases
The manual’s scenarios, including exceptionsand variants turned out to be a complete set ofblack box test cases.
Tests were so effective that, to our surprise, ...
scenarios not described in the UM, but whichwere logical extensions and combinations ofthose of the UM worked the first time!
The features composed orthogonally without ahitch!
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 118
Satisfied Customer
Berry found Ou’s implementation to beproduction quality and is happily using it inhis own work.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 119
Another Case Study of Serious RE
This one involved what is called a lightweightformal method [Breen 2005].
At Philips Electronics, Michael Breenconsulted for the project to develop CDR870to become the first audio separate CDrecorder aimed at the consumer market.
The CDR870 was to be the first of a productline.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 120
Success or Failure
The key factor determining the conduct of theproject was that it had to be finished in 6months, in time for next Christmas.
Meeting this deadline and its implied scheduledefines success or failure for the project.
The critical component of the project was theapplication-level software to be developedfrom scratch.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 121
An Impossible Project?
The consensus among domain experts atPhilips, people who had worked on similarsystems in the past, was that it wasimpossible to finish in time. There were justtoo many unknowns.
Two people, including Breen, felt it would bepossible IF ...
(There’s ↑ the proverbial big “if”.)
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 122
High Quality RS Essential
The realized that success depended criticallyon having a high quality requirementsspecification (RS) with no omissions,inconsistencies, and other defects, fromwhich the code could be writtenstraightforwardly.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 123
High Quality RS Or Else
Any omission, inconsistency, or defect in theRS meant that the programmers would have todo RE on the fly, ...
leading inevitably to mistakes, backtracking,and other nasties, ...
leading in turn to delays, an unpredictableschedule, and flaky software, i.e., ...
to failure to deliver by Christmas.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 124
Requirements for RS
The RS would have to be of only the under-visible behavior, to have a pure WHAT RS withcomplete freedom to choose the HOW basedon the available technology ...
and the RS would have to be accompanied bya suite of automated regression tests ready touse at any stage to test the software’s and thesystem’s compliance with the RS.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 125
Started RS Provisionally
They started writing the RS on a provisionalbasis.
They would proceed to implementation only ifthey had completed the RS in time and the RSmet its quality requirements.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 126
FSM-Based RS
Breen got the project to use multi-variableFSMs specified in tabular form.
The available natural language descriptionswere translated into an initial tabular FSMspecification.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 127
Benefits of FSM-Based RS
This immediately exposed potentialincompleteness in the form of unfilled tablepositions.
This immediately inconsistencies in the formof multiple transitions from the same state.
Some potential incompletenesses proved tobe DON’T CARES.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 128
Benefits, Cont’d
Some potential inconsistencies proved to bethe need for additional states.
The tabular FSMs gave the engineers theinformation they needed to rapidly resolvethese problems.
The FSM model was built and checkedmanually.
Fortunately, the FSMs were not beyond theupper bound of what can be managedmanually.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 129
Result:
They finished the specification in time and itwas judged by all involved to be of good,actually superb, quality.
Some felt it was the best RS that they had everwritten. They had confidence that it wascomplete and consistent. They had confidencethat it could be implemented straightforwardlywith a minimum of delay and no backtracking.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 130
To Implementation
They proceeded to implementation.
The finished the implementation in time withvery few delays to flesh out requirements. Thetests ran smoothly and served to expose thefew implementation faults. No show stoppingfaults were found.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 131
Success!
They delivered a high quality product in timefor Christmas!
The tabular FSM specification approachcontinues to be used for subsequent membersof the product line.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 132
Myths and Realities
A bunch of myths about requirements and theanswering realities
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 133
Coding before RE
Several related myths:
“You people start the coding while I go findout what the customer wants.”
Requirements are easy to obtain.
The client/user knows what he/she wants.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 134
Coding before RE, Cont’d
According to Ruth Dameron, ...
The programmer who says the first line issuffering from the myth that the customerwould be able to know what he or shewants and to say it just because theprogrammer asked.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 135
Need Prototype
Most people (especially non-technicallyoriented) learn while doing; they’ve got tosee some kind of prototype (even if it’sonly yellow stickies on a board) to discoverwhat they want.
First also expresses the nonsensical notionthat somehow, coding can begin before it’sknown what to code.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 136
Prototyping
Actually, there is a circumstance in which it’sgood to start coding before requirements arecompletely known.
To develop a throw-away prototype fromwhich to learn requirements.
But, it should be a throw away!
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 137
IKIWISI
I’ll know it when I see it!
This is how most clients really identifyrequirements.
They cannot tell you what they want, but ifthey see what they want, they spot itimmediately!
Sometimes, anything you show them is it(AYSTII).
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 138
IKIWINT & IKIWIDSI
Flip sides of IKIWISI (identified by JanuszDobrowolski)
g IKIWINT—I’ll know it when it’s not there!
g IKIWIDSI—I’ll know it when I don’t see it!
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 139
We Don’t Have Time for RE
“I know that it is important to getrequirements, but we don’t have time for it; wehave to get to coding to meet our deadline!”
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 140
We Don’t Have Time, Cont’d
At least one Ph.B. has been heard to say,“Wally, we don’t have time to gather theproduct requirements ahead of time. I wantyou to start designing the product anyway.Otherwise it will look like we aren’taccomplishing anything.”
Wally stops working because he knows thatthe project is doomed anyway.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 141
We Don’t Have Time, Cont’d
I will prove that we, in fact, always do writerequirements during the normal commercialsoftware lifecycle.
Therefore, since we always do it, we musthave had enough time!
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 142
Never Needed RE Before
“We’ve never written a requirementsdocument and we’re still successful!”
So says the manager of a project thatdelivered tested software with a user’s manualor an on-line help.
So says the manager justifying a decision toplunge into development without firstdetermining and specifying requirements.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 143
Sorry to Disappoint You!
Kamsties, Hormann, and Schlich [1998]observe:
Any project that does testing has to determinethe requirements in order to determinecovering test cases and their expectedoutputs. The test plan ends up being arequirements specification.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 144
Sorry, Cont’d
Any project that produces user documentationhas to determine the requirements in orderthat the documentation describe all of thefeatures well. The documentation ends upbeing a requirements specification.
Even Microsoft does both.
So there is no escaping determination andspecification of requirements (unless youdon’t do testing and user documentation!).
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 145
Sorry, Cont’d
There is no avoiding the time required todetermine and specify the requirements.
However, if you produce requirements only asa side effect of testing and documentation,you lose the key benefit of early requirementsdetermination and specification, namelyfinding errors at the least cost.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 146
May Not Even Have a Problem!
The client often says that he or she requires aspecific solution of an unknown ornonexistent problem rather than any solutionto a specific problem [Gause and Weinberg1990].
“We gotta automate!”
The problem with such a client is that theremay not even be a problem that requires anysolution, or if there is, other solutions,including non-computer, may be better!
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 148
Another Myth
After the requirements are frozen, ...
Ha!Ha ha!Ha ha ha!Ha ha ha ha!
The only clients that are satisfied and havestopped asking for changes are themselvesfrozen!
We have already seen why requirements willnever be frozen!
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 149
Whence Do Requirements Come?
REQS
REQS
REQS
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 150
Whence, Cont’d
Joe Goguen [1994a] says, “It is not quiteaccurate to say that requirements are in theminds of clients; it would be more accurate tosay that they are in the social system of theclient organization. They have to be invented,not captured or elicited, and that invention hasto be a cooperative venture involving theclient, the users, and the developers. Thedifficulties are mainly social, political, andcultural, and not technical.”
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 151
Whence, Cont’d
Interviewing does not really help becausewhen asked what they do, most people willquote the official policy, and not what theyactually do. Most of what they really do,which is not specified by the policy, is whatthey do in situations not covered by thepolicy.
We’re not even talking about conscious,politically safe mouthing of the policy.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 152
Whence, Cont’d
Wally says to his Ph.B., “I can’t start theproject because the user won’t give me hisrequirements.”. The Ph.B. replies, “Startmaking something anyway. Otherwise we’lllook unhelpful.” Wally replies, “So, our plan isto cleverly hide our competence.” The Ph.B.observes, “You think too much.”
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 153
Whence, Cont’d
Many people simply do not remember theexceptions unless and until they actuallycome up. Their conscious model of whathappens is the policy.
Therefore, the requirements engineer has tobe there when the exceptional situations comeup in order to see what really happens.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 154
Whence, Cont’d
Moreover, many people just do not know whythey do something, saying only that it’s donethis way because the policy says so.
They very often do not even know why thepolicy is the way it is.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 155
Whence, Cont’d
Moreover, many people just do not know howthey do something, drawing a complete blankor saying only, “Watch me!”.
For example, how do you ride a bicycle? Nu?
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 156
Whence, Cont’d
Don Gause and Jerry Weinberg [1989] tell thestory of the woman who always cuts off 1⁄3 of araw roast before cooking both pieces together.
She was asked “Why?” ... “???”
Her mother was asked “Why?” ... “???”
Her grandmother was asked “Why?” ...
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 157
Whence, Cont’d
Because the pot of this woman’s grandmotherwas too small to accommodate the full lengthpiece. Nu?
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 158
Whence, Cont’d
In other words, the policy once made sense,but the person who formulated the policy, thereasons for it, and the understanding of thereasons are long since gone.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 159
Whence, Cont’d
For example, many companies that havecommitted all data to a highly reliable database continue to print out the summary inquintuplicate.
Why? At the time of automation, the five mostsenior members of the company, who longago retired, refused to learn to use thecomputer to access the data directly!
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 160
Creativity
Roberto Tom Price reminds us not to forgetthe requirement engineer’s
g imaginationg ideasg suggestions
i.e. creativity [Maiden, Gizikis, & Robertson2004]
like an architect for a new building, usinginput from the client
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 161
More About Creativity
Neil Maiden and Alexis Gizkis [2001] in askingfrom where do requirements come, identify 3kinds of creativity needed in RE:
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 162
Three Kinds of Creativity
1. exploratory creativity: explores a possiblesolution space and discovers new ideas
2. combinatorial creativity: combines two ormore ideas that already exist to create newideas, and
3. transformational creativity: changes thesolution space to make impossible thingspossible.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 163
Whence, Cont’d
Goguen further observes that most of theeffort for a typical large system goes intomaintenance.
In fact, Parnas [1994] has the data:
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 164
Whence, Cont’d
100
80
60
40
1960 1970 1980 1990 2000
Spen
t on
Mai
nten
ance
Perc
enta
ge o
f So
ftw
are
Res
eour
ces
Growing Percentage of Maintenance Costs
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 165
Formal Methods Needed?
Some formal methodologists say that this isthe fault of insufficient effort put into beingprecise in the early, specification stages ofsoftware development.
However, recall the conceptual distancesinvolved:
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 166
Concept
FormalSpec.
InformalSpec.
Folded in middle to give feeling of trueconceptual distances involved
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 167
FMs Needed, Cont’d
Goguen believes that “a deeper reason is thatmuch more is going on during so-calledmaintenance than is generally realized. Inparticular, reassessment and re-doing ofrequirements, specification, and code, as wellas documentation and validation, are verymuch part of maintenance....”
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 168
FMs Needed, Cont’d
Later, he adds, “it only becomes clear whatthe requirements really are when the system issuccessfully operating in its social andorganisational context.... it is impossible tocompletely formalise requirements ... becausethey cannot be fully separated from theirsocial context.”
This is precisely the phenomenon of E-typesystems.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 169
Formal Methods Myths
Goguen has identified other myths aboutrequirements, again based on the mistakenidea that the hard part about requirements aretheir specification.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 170
FM Myths, Cont’d
If only you had written a formal specificationof the system, you wouldn’t be having theseproblems.
Mathematical precision in the derivation ofsoftware eliminates imprecision.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 171
FM Myths, Cont’d
What is the reality?
Yes, formal specification are extremely usefulin identifying inconsistencies in requirementsspecifications, especially if one carries outsome minimal proofs of consistency andconstraint or invariant preservation, ...
just as writing a program for the specification!
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 172
FM Myths, Cont’d
Don’t get me wrong.
This formality is good, because it finds errorsearly, thus reducing the costs to fix them.
However, formal methods do not find all gapsin understanding!
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 173
FM Myths, Cont’d
As Eugene Strand and Warren Jones [1982]observe, “Omissions of function are oftendifficult for the user to recognize in formalspecifications”....
just as they are in programs!
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 174
FM Myths, Cont’d
von Neumann and Morgenstern (Theory ofGames [1944]) say,
“There’s no point to using exact methodswhere there’s no clarity in the concepts andissues to which they are to be applied.”
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 175
Preservation of Difficulty
Indeed, Oded Sudarsky has pointed out thephenomenon of preservation of difficulty.Specifically, difficulties caused by lack ofunderstanding of the real world situation arenot eliminated by use of formal methods;instead the misunderstanding gets formalizedinto the specifications, and may even beharder to recognize simply because formaldefinitions are harder to read by the clients.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 176
Bubbles in Wall Paper
Sudarsky adds that formal specificationmethods just shift the difficulty from theimplementation phase to the specificationphase. The “air-bubble-under-wallpaper”metaphor applies here; you press on thebubble in one place, and it pops upsomewhere else.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 177
One Saving Grace
Lest, you think I am totally against formalmethods, they do have one positive effect, andit’s a BIG one:
Use of them increases the correctness of thespecifications.
Therefore you find more bugs at specificationtime than without them, saving considerablemoney for each bug found earlier rather thanlater.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 178
Analogy with Math Theory
Building new software is like building a newmathematical theory from the ground up:
g Requirements gathering: deciding what isto be assumed, defined, and proved
g Development as a whole: assumingassumptions, defining the terms, andproving the theorems
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 179
Math Theory, Cont’d
g Design: determining the sequence ofassumptions, definitions, and theorems tobuild the theory
g Implementation: carrying out the designedtheory and proving the theorems
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 180
Math Theory, Cont’d
Mathematical papers and books show only theresults of the implementation,
This implementation is what is considered themathematics, and not the requirementsgathering and design that went into it.
But I know, from my own secret past life as amathematician, that the hard, time-consumingparts are the requirements gathering anddesign.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 181
Math vs. SW Development
g Software is usually developed under stricttime constraints, and mathematics isusually not.
g Mathematics development is subjected toerror-eliminating social processes, andsoftware development is subjected to a lotless.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 182
Math vs. SW, Cont’d
g Mathematics is written for a humanaudience that is very forgiving of minorerrors so long as it can see the main point;software is written for the computer that isvery literal and unforgiving of minor errors
- For people, UKWIM works, and theyaccept imprecision.
- For computers, UKWIM and DWIM donot work, and computers do not acceptimprecision.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 183
Another Implication of GrowingMaintenance Costs
For many programs, which are more and moreoften enhancements of legacy software, anyoriginal requirements specifications that mayhave existed are long gone.
The original programmers are long gone.
The old requirements have to be inferred fromthe software.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 184
Another Implication, Cont’d
What is inferred may not capture all features.
Also the obvious requirement of not impactingexisting functions in the enhancement is veryeasy to state, but, oh, so hard to satisfy.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 185
More on Whence
Recall that Joe Goguen [1994a] says, “It is notquite accurate to say that requirements are inthe minds of clients; it would be moreaccurate to say that they are in the socialsystem of the client organization. They have tobe invented, not captured or elicited, and thatinvention has to be a cooperative ventureinvolving the client, the users, and thedevelopers. The difficulties are mainly social,political, and cultural, and not technical.”[italics are mine]
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 186
Social, Political, & Cultural?
Several others have observed that emotions,values, beliefs, politics, and culture play asignificant role in whether or not users acceptand use deployed information-technologysystems (ITSs).
Management tries to introduce ITSs toautomate and transform business processes.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 187
Employee View
However, many times, employees see theseITSs not as work savers or work facilitators,but fear them as job eliminators, jobtrivializers, and job complicators.
Such employees have difficulty using theITSs, refuse to use them, or even sabotagethem!
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 188
Sabotage
Isabel Ramos (Santos) et al [1998, 2002, &2004] report several failed ITS deploymentsbecause of these fears and, in one case, usersabotage:
g a mistake-logging systemg a new centralized system for a university
libraryg an OTS ERP system replacing a home-
brewed system in a commercial companyg a CSCW system in a university classroom
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 189
Political Reasons for Failed Projects
Johann Rost [2004] writes about politicalreasons for failed software projects.
He describes how subversive behavior cansabotage software projects.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 190
LAS and CAPSA
The deployments of the London AmbulanceSystem [Finkelstein 1993, Finkelstein & Dowell1996] and the deployment of CAPSA, theCambridge University’s new on-lineaccounting system [Finkelstein & Shattock2001] failed miserably.
Ramos believes that a prime cause of thesefailed deployments was the failure to deal withthe stakeholders’ emotions, values, andbeliefs during their RE processes.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 191
Technology vs. Politics
M.B. Bergman, J.L. King and K. Lyytinen[2002] observe, “Indeed, policymakers willtend to see all problems as political, whileengineers will tend to see the same problemsas technical. Those on the policy side cannotsee the technical implications of unresolvedpolitical issues, and those on the technicalside are unaware that the political ecology iscreating serious problems that will show up inthe functional ecology.”
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 192
Technology vs. Politics, Cont’d
Bergman, King, and Lyytinen go on to say,“We believe that one source of opposition toexplicit engagement of the political side of REis the sense that politics is somehow inopposition to rationality. This is amisconception of the nature and role ofpolitics. Political action embodies a vital formof rationality that is required to reach sociallyimportant decisions in conditions ofincomplete information about the relationshipbetween actions and outcomes.”
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 193
User Acceptability
Boehm and Huang [2003] observe, project canbe tremendously successful with respect tocost-oriented earned value, but an absolutedisaster in terms of actual organizationalvalue earned. This frequently happens whenthe product has flaws with respect to useracceptability, operational cost-effectiveness,or timely market entry.”
Note that user acceptability is an emotionalissue.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 194
User Acceptability, Cont’d
Boehm and Huang add, “the initiative toimplement a new order-entry system to reducethe time required to process must convincethe sales people that using the new systemfeatures will be good for their careers. Forexample, if the order-entry system is soefficiency-optimized, it doesn’t track salescredits [which prove who sold what], the salespeople will fight using it.”
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 195
Emotional RE
Ramos [Ramos (Santos) et al 1998, 2002, &2004] suggests that the requirements engineerbe on the lookout for signs of all sorts ofsocial, emotional, political, and culturalproblems among the customers and usersduring RE.
When such a problem is found, it should beexplored with an eye to adjusting therequirements of the ITS so that the problem isameliorated or even goes away.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 196
Just Managerial Issues?
Some who see these ITS deploymentproblems regard the problems as managerialproblems and not as requirements problems.
In one sense, they are right, in that theseproblems require action by management,addressing social issues.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 197
What is a Requirements Problem?
However, any problem that can prevent thesuccessful deployment of a system, whether itbe
g incorrect function,g failure to notice tacit assumptions,g or anything else
should be identified as early as possible sothat dealing with it can permeate the entiresystem design and development process.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 198
Requirements Problems!
Perhaps a so-called managerial problem borneof emotion can be solved by a simple changein functionality or user interface, e.g., byeliminating a hated feature entirely.
Delaying consideration of any problem drivesup the cost of solving the problem once it isidentified as seen in graphs earlier.
When viewed this way, all such problemsbecome requirement problems.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 199
Managerial Solutions!
In the end, it may very well be that the adoptedsolution to an problem may be consideredmanagerial, e.g., educating users and theirmanagers, providing incentives for adopting,etc.
However, such solutions, especially that ofeducating users, may be applied also to whatmight appear to be a functional or user-interface issue (as did NASA [Lutz & Mikulski2003]).
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 200
RE and Other Engineering
Speaking of architects and other engineersthat get requirements from clients, ...
While software requirements gathering hasmuch in common with requirements gatheringfor buildings, bridges, cars, etc., there aresignificant differences in:
g the flexibility and malleability of themedium, and
g the degree to which basic assumptions areon the table, up for grabs.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 201
Other Engineering, Cont’d
Michael Jackson [1998] considers the moretraditional engineering disciplines.
Civil EngineeringMechanical EngineeringAeronautical EngineeringElectrical Engineering
Their engineers make machines by describingthem and then building them.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 202
Other Engineering, Cont’d
Software engineers make machines merely bydescribing them.
Software is an intangible, infinitely malleablemedium.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 203
Other Engineering, Cont’d
To build a new car from requirements the waysoftware is built from requirements would becalled totally rethinking the automobile. Infact, each new kind of car is really a minorperturbation of existing kinds of cars.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 204
Other Engineering, Cont’d
Perhaps, we should do much more minorperturbation of existing software, i.e., practicereuse, but in many cases we cannot, simplybecause we are developing software for anentirely new application.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 205
Bottom Line
The notions that
g one can derive requirementsor
g even interview a few people to getrequirements
are patent nonsense.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 206
Ample Evidence That
g The later an error is detected, the more itcosts to correct it.
g Many errors are made in requirementselicitation and definition.
g Many requirements errors can be detectedearly in the lifecycle.
g Typical errors include incorrect facts,omissions, inconsistencies, andambiguities.
g Requirements problems are industry’sbiggest concern.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 207
OK, OK, You’re Convinced!!!
So what do we DO about it?
What research is being done to solve theproblems?
First, recognize that the problem is HARD!
Second, recognize that requirementsengineering has its own lifecycle
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 208
Requirements EngineeringLifecycle
Specification
Validation
Analysis
Elicitation
Conception
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 209
RE Lifecycle, Cont’d
This, of course, is an idealization, just asmuch as the original waterfall.
Reality is that there is a spiral, with eachsweep going through this entire subwaterfall,and all the steps in the sweep happeningconcurrently.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 210
Another RE Lifecycle
Kevin Ryan offers the following RE process:
g Identify Requirementsg Document Requirementsg Validate Requirements—Have we elicited
and documented the right requirements?g Verify—Have we got the model right— and
Validate—Have got the right model—Models
g Rank Requirements by Priorityg Select and Plan Requirements
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 211
Scoping
Some facts:
g Many projects fail because what wasrequired was too big for the availableresources, and there is no way to subsetthe requirements, i.e., it’s all or nothing!
g 80% of execution is in 20% of the code, arule of thumb used by compiler writers.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 212
Scoping, Cont’d
g 1998 Standish Group data [Neumann 1999]show that among features in sampledmass-marketed applications,- 45% are never used,- 19% are rarely used,- 16% are sometimes used,- 13% are often used, and- only 7% are always used.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 213
Must Scope Requirements
The solution to these problems is to scope,but how?
Must rank requirements [Davis 2003]
1. absolutely essential2. essential3. important4. nice5. fluff
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 214
Subsetting Requirements
Select an affordable, coherent subset of therequirements consisting of the most importantrequirements.
OR
Build to cost, perhaps in a spiral.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 215
Use Cases and Scenarios
Consider an interactive computer-basedsystem (CBS), S. It is called interactivebecause its users interact with it.
A user tends to think of S in the ways that heor she will use it.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 216
Using a CBS -1
For example, if S is an electronic votingsystem, the average voter user tends to thinkof two particular ways to use S:
g registering to vote, andg voting, i.e., marking a ballot in an election.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 217
Using a CBS -2
There are other users of this S that think ofother particular ways to use the S.
For example, the voting manager user hasother particular ways to use S:
g preparing a ballot for a particular election,g opening the polls for a particular election
for voting by voters,g closing the polls for a particular election,g counting the votes for a particular election.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 218
Using a CBS -3
Of course, the voting manager is also a voterand can also register to vote and vote.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 219
Use Case
Each such particular way to use S is called ause case.
It is one case of the many ways to use S.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 220
Scenario
A use case should not be confused with aclosely related concept called a scenario. Ascenario of S is a particular sequence ofinteraction steps between a user of S and S.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 221
Use Cases and Scenarios
The relation between use cases and scenarioscan make both terms clearer.
A single use case contains many, manyscenarios.
A use case UC of S has a so-called typicalscenario. This scenario is that identified bythe stakeholders of S as being the normalcase of UC that proceeds with all decisionsbeing made in the so-called normal or typicalway.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 222
Variations
UC also consists of variations calledalternatives and exceptions.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 223
Alternatives -1
An alternative of UC is a sub-use-case, whichmay include many scenarios, that achievesthe main goal of UC through differentsequences of steps or fails to achieve thegoals of UC although it follows most of thesteps of UC.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 224
Alternatives -2
For example, for the voting use case, thetypical case is voting in one session.
One alternative is voting in multiple sessions.
Another alternative is starting to vote, but notfinishing.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 225
Exceptions
An exception of UC is a sub-use-case, whichmay include many scenarios, that deals withthe conditions along the typical scenario andother sub-use-cases that differ from the normand those already covered.
For example, for the voting, what to do with anon-registered voter trying to vote is anexception.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 226
Misuse Cases
Sindre and Opdahl [2000] and Alexander[2002] have proposed misuse cases to captureuse cases that a system must be protectedagainst, that you do not want to happen at all,e.g., a security breach.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 227
Sharing of Subsequences
Observe that all the scenarios of a use caseshare many subsequences of steps.
Some sets of these subsequences of stepsmay constitute sub-use-cases that are worthconsidering as use cases that can be used byother use cases.
For example, the voting and registering usecases may share the steps for validating that auser is a registered voter.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 228
Power of Scenarios
Aren’t scenarios nice? They can be usedg to help elicit requirementsg as a basis for user validation of
requirements understandingg as a basis of an active review of
specificationsg as a basis of a quick and dirty prototypeg as a basis of covering black-box test cases
for implementationg as a basis for writing a user’s manualWow!!
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 229
Agility vs. Full RE
In situations in which high-level requirementsare not fully understood, ...
in which prototyping should be done to helpidentify requirements and to validate themwith the customers and users, ...
and iterative, incremental, or Spiral models areappropriate, ...
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 230
Agility for Prototyping
then agile methods (AMs), such as eXtremeprogramming (XP) [Agile Alliance, Highsmith& Cockburn 2001, Eberlein & Leite 2002], helpfocus quickly to produce a series of well-inspected [Tomayko 2002] and well-testedincrements, and can be used to carry out theprototyping effort ...
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 231
But Must Refactor
so long as it is understood that the codeproduced is a prototype and that it must betossed in order that development of a high-quality production version be started. In XP,terminology, this is known as massiverefactoring.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 232
Power of XP
After all, in XP, each iteration starts with thewriting of stories (i.e., scenarios) describingfunctions to be implemented in this iterationand test cases for testing that the functionshave been implemented correctly.
This is far better than in most prototypingregimes, and the result should be higherquality software than under most prototypingregimes.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 233
However...
However, all the data I have seen say that fullRE is the most cost-effective way to producequality software, and that it will beat out anyAM any time in the cost and quality attributes.
When all the details are hammered out duringan RE process that lasts until it is done (andnot until a predetermined date), thedevelopment proceeds so much quicker andwith so few bugs!
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 234
Tradeoff
What is the tradeoff?
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 235
Full RE Pros & Cons
Full RE leads to better and better understoodcode
But risks failure to complete as nervousmanagers pull the plug or as funding runs out
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 236
AMs Pros & Cons
Incremental and AMs make sure that youalways have something that runs
But risks always having an incomplete,incorrect, and flaky program.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 237
Agility vs Full RE
Therefore, if the problem is just getting thehigh-level requirements right, then go theincremental or agile development route, ...
but if the problem is fleshing out therequirement details given a clear vision, thengo full RE route.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 238
RE is Still an Art
And most importantly, ...
There are no real solutions yet!
It is very much an art form.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 239
Research Topics
Earlier Work, prior to mid-80s
Later Work, mostly after mid-80s
Some temporal overlap, because as we willsee, the work is classified by nature, and thatnature has changed slowly.
I apologize in advance if I have left out thingsabout which I am not aware.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 240
Earlier Work-1
Languages and Tools:
PSL/PSA [Teichroew 1977]SADT [Ross and Ross & Schoman 1977]RSL [Alford 1977]RDL [Winchester 1982]PAISley [Zave 1982]RML [Borgida, Greenspan & Mylopoulos1985]IORL [Salton & McGill 1983]
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 241
Earlier Work-2
Alan Davis wrote the book! RequirementsAnalysis and Specification [1990]
Focus was on analysis and specification, noton elicitation
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 242
Later Work-1
More consideration of elicitation
Recognition of importance of sociology andpsychology
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 243
Later Work-2
g Elicitationg Analysisg Natural Language Processingg Tools and Environmentsg Changesg Empirical Studiesg RE as a Human Activity
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 244
Global View-1
Requirements Engineering is:
How to squeeze requirements out of theclient’s mind and environment withoutdamaging the client or the environment!
Elicitation is:
How to squeeze information out of the client’smind without damaging the client!
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 245
Global View-2
Analysis is:
How to squeeze as much additionalinformation as possible out of what has beenobtained by squeezing the client and theenvironment!
Natural Language Processing (NLP) isconcerned with:
How to automate as much of the analysissqueezing as possible
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 246
Global View-3
Tools and Environments deal with:
How to automate the storage of informationbefore and after analytic squeezing as well asall kinds of squeezing!
Changes cause that:
No matter how hard you squeeze, analyze, etc.there are new requirements, and the old oneschange.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 247
Global View-4
Empirical Studies are concerned with:
Understanding squeezing by observing it orparts of it in real-life circumstances!
RE as a Human Activity is concerned with:
Understanding how humans do the squeezingas a social activity.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 248
Use of Exemplars in RE Research
Many areas of SE use published exemplars,e.g., the KWIC Index System, for researchcase studies.
Since the problem is how to get theinformation for requirements, publishedexemplars are too polished and too late.
What is normally done to prepare exemplarsfor publication is the subject
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 249
Post Mortem Reports
Post mortem reports from failed projects, e.g.,the automation of the London AmbulanceService [Finkelstein & Dowell 96] dispatchingsystem, provide useful insight in how not todo requirements engineering.
Interestingly, the LAS learned its own lessonsand won the 1997 British Computer SocietyExcellence Award!
Another is the CAPSA Report [Finkelstein &Shattock 2001]
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 250
Elicitation Overview-1The gist of the specific work is:
g Identify the stakeholders; these are thepeople you have to ask!
g The customer is always right.g People matter.g Interviewing does not get all the
information that is needed.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 251
Elicitation Overview-2
g The requirements engineer should get intothe client’s work place, blend into thewoodwork or among the employees, andobserve, learn, and question, in order toovercome ignorance of the problemdomain.
g The requirements engineer should becomean employee of the client to learn the ropeswell enough to understand the underlyingrationale behind the way things are done.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 252
Elicitation Overview-3
g The requirements engineer should parlayhis or her ignorance into on-the-spotquestions that expose tacit assumptionsand special cases.
g Don’t tell them what you mean; show them!This works in both directions!
g Prototype to capture emergentrequirements and contextual factors.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 253
Elicitation Overview-4
g Getting all stakeholders together for week-long facilitated meetings at which therequirements are shlogged out togetherbuys commitment from all stakeholders.
g Scenarios and use-cases, which aredescriptions of the ways that the intendedsystem will be used to achieve specific orclasses of tasks, are a useful way to focususers’ attention on what they actually doand to document what they really do in thecourse of doing their work.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 254
Elicitation Specifics-1
g Ignorance hiding in elicitation and analysis[Berry 1980, 1983]
g Scenarios and Use Cases [Hooper & Hsia1982, Jacobson 1992]
g Concept of abstract user and prototypeelicitation management tool [Burstin 1984]
g Brainstorming [Gause & Weinberg 1989]g Contextual Inquiry, an anthropological
approach to understanding client[Holtzblatt & Jones 1990, Beyer & Holtzblatt1998]
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 255
Elicitation Specifics-2
g Study of discourses in elicitationtechniques, e.g., interviews [Goguen &Linde 1993]
g Storyboarding & paper mockups [Zahniser1993]
g Joint Application Development [Carmel,Whitaker & George 1993] [Wood & Silver1995]
g Importance of ignorance in elicitation[Berry 1995]
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 256
Elicitation Specifics-3
g Stakeholder Identification [Sharp,Finkelstein & Galal 1999]
g Scenarios and Prototyping to captureemergent contextual factors [Carroll,Rosson, Chin, & Koenemann 1998, Dzida &Freitag 1998]
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 257
Analysis Overview-1
g Basic idea of analysis is to- derive implications of,- resolve inconsistencies in, and- determine what is missing fromthe information that has been gathered sofar so that follow up questions may beasked.
g A key job of the analyst is to model thesystem under design and its environment.This is hard work, but from a good model,requirements are almost there for picking.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 258
Analysis Overview-2
g Modeling the enterprise in which therequirements are situated is essential.
g The requirements engineer must constantlyattempt to validate his or herunderstanding with the client or user.
g Prototypes are a nice way to make modelsand scenarios concrete to clients andusers.
g Clients’ and Users’ validation responses toprototypes are far more credible than tolong written specifications.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 259
Analysis Overview-3
g One has to be careful about the informationcontent of a prototype, what is there andnot, what is intended and not, in short, itsmeaning.
g It is essential to be able to trace the historyof a requirement from its conceptionthrough its specification and on to itsimplementation.
g Tracing allows determining the meaning ofa prototype.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 260
Analysis Overview-4
g Distilling scenarios into use cases is auseful way to put some order into themyriad scenarios described by diverseusers.
g Error checking, handling, and preventionwill not happen in a program unless theyare explicitly required of the program; thisis particularly so in safety-critical softwarefor which the dangers are not readilyapparent.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 261
Analysis Overview-5
g While being specified, requirements arelogically inconsistent.
g Goals and intents are important tounderstand and document.
g Ranking requirements by priority allowsscoping, which in turn allows building toresources.
g Requirements and design affect each other.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 262
Analysis Overview-6
g Dealing with non-functional requirements(NFR) is tough since often they are notquantifiable or expressible.
g Analysis = Modeling, Modeling, Modeling!f Enterprise Modelingf Data Modelingf Behavioral Modelingf Domain Modelingf NFR Modeling
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 263
Analysis Specifics-1
g Prototyping for requirements discoveryand validation [Wasserman et al 1984 &1986a & b, Bowers & Pycock 1993, Luqi1992]
g Software safety fault isolation techniques[Leveson 1986 & 1995]
g Viewpoint Resolution [Leite 1987,Easterbrook 1993]
g Brainstorming [Gause & Weinberg 1989]g Issue-based information system (IBIS)
[Burgess-Yakemovic & Conklin 1990]
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 264
Analysis Specifics-2
g Domain modeling [many, surveys: Kang etal 1990, Lubars et al 1993]
g Object-orientation as a natural view [many,including: Coad & Yourdon 1991, Zucconi1993]
g Non-Functional Requirements [Mylopoulos,Chung & Nixon 1992].
g Enterprise Modeling with Scenarios[Mylopoulos, Chung & Nixon 1992].
g Goal-directed RE [Dardenne, vanLamsweerde & Fickas 1993]
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 265
Analysis Specifics-3
g System Scoping & Bounding [Drake & Tsai1994]
g Requirements Traceability [Gotel &Finkelstein 1994]
g Living with Logical Inconsistency of Specs[Easterbrook & Nuseibeh 1995, 1996,Hunter & Nuseibeh 1997]
g Ranking Requirements by Priority[Karlsson & Ryan 1997, Karlsson, Olsson &Ryan 1997]
g Intent Specifications [Leveson 1997]
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 266
NLP Overview-1
The total amount of information to deal withfor any real problem is HUGE andrepetitititive.
We desire assistance in extracting usefulinformation from this mass of information.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 267
NLP Overview-2
We would like the extracted information to be
g summarizing,g meaningful, andg covering.
From 500 pages, we want 5 pages containingall and only the meaningful information in the500 pages.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 268
NLP Overview-3
We prefer less summarization and occasionalmeaningless stuff than to lose somemeaningful stuff, because in any case, ahuman will have to read the output and at thattime can filter out the meaningless stuff.
Stupidity is preferred to intelligence if thelatter can lose information as a result of it notever being perfect.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 269
NLP Overview-4
Expressing scenarios in natural languagekeeps them understandable by the clients andusers but runs the risk of ambiguity.
The user’s manual, written in naturallanguage, turns out to be a very goodrequirements specification [Berry, Daudjee, etal 2004].
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 270
NLP Specifics-1
g Restricted natural language processing ofrequirements ideas to get specifications[Saeki, Horai, et al 1987]
g Natural language abstraction identificationwith lexical affinities [Maarek 1989]
g Application domain lexicon building andtools [Leite & Franco 1993]
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 271
NLP Specifics-2
g AI-based natural language processing[Ryan 1993]
g Nonintelligent, fully covering naturallanguage abstraction identification usingsignal processing techniques [Goldin 1994]
g Scenarios in Natural Languages [Some,Dssouli, & Vaucher 1996]
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 272
Martin Feather’s View of RE Tools
The Requirements Iceberg and VariousMachine-Assisted Icepicks Chipping at It
Client’sView
Machine’s View
Leverage!
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 273
Tools & Environments Overview-1
Even with summarizing tools,the amount of information that therequirements engineer must deal with isHUGE,
the number of relations between theindividual items of information is HUGE2,and
the number of relations between theindividual relations is HUGE4...
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 274
Tools & Environments Overview-2
So we want an environment filled with usefultools that help manage all the informationneeded to produce a requirementsspecification from the first conceptions, andthen to be usable for the rest of the lifecycle.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 275
Tools & Environments Specifics-1
g Graphical Issue-Based Information System(gIBIS) [Burgess-Yakemovic & Conklin1990]
g Hypermedium as requirements engineeringenvironments [Potts & Takahashi 1993,Kaindl 1993]
g Full spectrum, including traceabilityanalysis, requirements engineering tool,READS [Smith 1993]
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 276
Tools & Environments Specifics-2
g PRIME, KAOS for formal requirementsmodeling and analysis [Dardenne et al1993]
g Multimedia hypermedium as requirementsengineering environments [Wood, Christel& Stevens 1994]
g DOORS (Quality Systems and Software),icCONCEPT-RTM (Integrated Chipware),Requisite Pro (Rational→IBM), & otherindustrial requirements managementplatforms
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 277
Some Views of Hypermedia Tools
˜˜˜˜˜˜˜˜˜˜˜˜
˜˜˜˜˜˜˜˜˜˜˜˜ ˜˜˜˜˜˜˜˜˜˜˜˜ ˜˜˜˜˜˜˜˜˜˜˜˜
˜˜˜˜˜˜˜˜˜˜˜˜
Network of Nodes
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 278
book passenger on flight book passenger on flight
flight passenger
Links
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 279
Database objects, Pseudo-code,Video, Image
t
a v
t
dbot
pcText, Diagrams, Audio,
Time-stamped Prior Copies of Hypermedium
Links of Arbitrary Functionality
Nodes of Arbitrary Type
Unit-to-Unit-LinksUnit-to-Node-Links
Node-to-Node LinksNode-to-Unit-Links
Workstation
Multi-media Hypermedium
Written Input
Requirements Engineer
Video Input
Client
System in Operation
Multimedia Hypermedium
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 280
Changes Overview-1
g Change is the only thing that is permanentabout software and requirements.
g Too many methods for RE (as for SE)assume incorrectly that the R (and the S)does not change, and these methodssimply wilt under the face of the continualrelentless changes that occur.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 281
Changes Overview-2
g Nowadays, a growing majority of thesoftware we write is reworked legacy code,code that is too valuable to scrap, toodifficult to modify or extend without error,too expensive to rebuild, but inadequate inits current form. RE for legacy softwaremust deal with ripple effects onrequirements that are largely unknown.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 282
Changes Overview-3
g Configuration management and tracing aremethods for dealing with changes insoftware, but they work only with the totalcooperation of the people involved, peoplewho generally disdain the regimentationrequired to use them. This drawbackapplies equally if not more so toconfiguration management and tracing ofrequirements.
g Prototyping is also a tool for controlledevolution of software and requirements.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 283
Change Specifics
g General Software Configuration andChange Management [Carter, Martin,Mayblin & Munday 1984, Tichy 1985]
g Prototyping [Davis 1992]g Traceability [Gotel & Finkelstein 1994]g Inconsistency Management [Easterbrook &
Nuseibeh 1995]g Change Impact Analysis [Bohner & Arnold
1996]g Combating Requirements Creep [Berry
1998]
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 284
Empirical Studies Overview-1
g We have come to recognize that it isessential to test in actual industrial usethose methods and tools that the researchproposes, that it is not enough to declarethat a method or tool should or mustobviously work, that it is not enough toapply the method or tool to toy examples.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 285
Empirical Studies Overview-2
g We have also come to recognize that it isessential to observe industrial SE and REin order to fully understand the problemsfaced by the practitioners, that it is notenough to theorize what must be theirproblem, or to decide for them what theirproblems are.
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 286
Empirical Studies Specifics
g User Participation in RE [El Aman, Quintin& Madhavji 1996]
g Inspections and RE [Kantorowitz,Guttmann & Arzi 1997]
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 287
RE as a Human Activity Overview-1
Nuseibeh and Easterbrook remind us that thecontext in which RE takes place is usually ahuman activity system.
Therefore RE draws on other disciplines forhelp in understanding the process.
g Cognitive Psychology: how peopledescribe needs
g Anthropology: observations of humanactivities
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 288
RE as a Human Activity Overview-2
g Sociology: political & cultural changesg Linguistics: RE requires clear
communication in human languagesg Legal documents and requirements
specifications have identical requirements:must anticipate all possible eventualitiesand contingencies and must beunambiguous
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 289
RE as a Human Activity Overview-3
g Philosophyf Epistemology: stakeholder beliefsf Phenomenology: real-world
observationsf Ontology: agreement on objective truths
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 290
RE as a Human Activity Specifics
g Linguistics [Knuth, Larrabee & Roberts1989, Dupre 1998]
g Cognitive Psychology [Posner 1993]g Anthropology [Goguen & Jirotka 1994b,
Goguen & Linde 1993]g Sociology [Holtzblatt & Beyer 1995, Beyer
& Holtzblatt 1998]g Ambiguity [Berry, Kamsties & Krieger 2000,
Berry & Kamsties 2004, Mich & Garigliano2002, Mich 2001]
g Ontologies [Breitman & Leite 2003]
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 291
Future
Lots more work is needed
Please join in!!
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 292
Recent Surveys
g “Requirements Engineering: A Roadmap”,Nuseibeh & Easterbrook [2000]
g “Requirements Engineering in the Year 00:A Research Perspective”, van Lamsweerde[2000]
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 293
Insightful Books
g Exploring Requirements: Quality BeforeDesign, Gause & Weinberg 1989
g Are Your Lights On? How to Figure OutWhat the Problem REALLY Is, Gause &Weinberg 1990
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 294
Conferences and Workshops
g International Workshop on SoftwareSystems Design 1–10
g International Symposium on RequirementsEngineering ’93, ’95, ’97, ’99, & ’01
g International Conference on RequirementsEngineering ’94, ’96, ’98 & ’00
g International Requirements EngineeringConference ’02, ’03, ’04, & ’05
g IFIP WG 2.9 Software RequirementsEngineering ’95, ’96, ’97, ’99, ’00, ’01, ’02,’03, & ’04
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 295
Journals
g Software Practice and Experienceg Journal of Systems and Softwareg IEEE Softwareg Journal of Automated Software
Engineeringg Requirements Engineering Journalg ACM Interactionsg Journal of Information and Software
Technology
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 296
Research Networks
g RENOIR, Requirements EngineeringNetwork Of International cooperatingResearch groups, a network of excellencesponsored by the European Union
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 297
Web Pages
g Requirements Engineering Newsletter(these are the files named renl*:ftp://ftp.cs.city.ac.uk/pub/requirements/
g Requirements Engineering Bibliography:http://www.inf.puc-rio.br/˜bdbib/
g RENOIR:http://www.cs.ucl.ac.uk/research/renoir/
2004 Daniel M. Berry Requirements Enginering Requirements Iceberg Pg. 298