Requirements Engineering
 Establishing
what the
customer requires from a
software system
what is it
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Requirements engineering


The process of establishing the services that the
customer requires from a system and the
constraints under which it operates and is
developed
Requirements may be functional or nonfunctional
•
•
Functional requirements describe system services or functions
Non-functional requirements is a constraint on the system or on
the development process
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
What is a requirement?


It may range from a high-level abstract statement
of a service or of a system constraint to a detailed
mathematical functional specification
This is inevitable as requirements may serve a
dual function
•
•
•
May be the basis for a bid for a contract - therefore must be
open to interpretation
May be the basis for the contract itself - therefore must be
defined in detail
Both these statements may be called requirements
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Requirements definition/specification

Requirements definition
•

Requirements specification
•

A statement in natural language plus diagrams of the services
the system provides and its operational constraints. Written for
customers
A structured document setting out detailed descriptions of the
system services. Written as a contract between client and
contractor
Software specification
•
A detailed software description which can serve as a basis for a
design or implementation. Written for developers
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Definitions and specifications
Req u i rem en ts d efi n iti on
1 . Th e s oft w are m u st pro v id e a m eans o f repr esen ti ng an d
1 . access in g ex ternal fi les creat ed by other t oo ls .
Req u i rem en ts s p ecifi cati on
1 .1
1 .2
1 .2
1 .2
1 .3
1 .2
1 .4
1 .2
1 .5
1 .2
1 .2
The us er sh ou ld b e pro v id ed w it h facili ti es to defi ne th e ty pe of
ex ternal fi les.
Each ex ternal fi le t yp e m ay hav e an ass oci at ed t oo l w h ich m ay be
ap pl ied to th e fi le.
Each ex ternal fi le t yp e m ay be represen ted as a s peci fic i con o n
t he u ser’s di sp lay.
Facil it ies s ho ul d b e p rov id ed fo r th e ico n repr esen ti ng an
ex ternal fi le t yp e t o b e d efin ed by th e us er.
W h en a u ser sel ects an ico n repr esen ting an ex ternal fi le, th e
effect of th at s elect io n is to ap pl y t he to ol ass oci ated w it h t he ty pe o f
t he ex tern al fil e to t he fi le repres ent ed b y th e sel ected i con .
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Requirements readers
R equ irem ent s
d efi ni ti on
C l ient m an ag ers
S y st em end -us ers
C l ient en gi neers
C o nt racto r m an ag ers
S y st em archi tect s
R equ irem ent s
s pecifi cat io n
S y st em end -us ers
C l ient en gi neers
S y st em archi tect s
S o ftware d ev elo pers
S o ftware
s pecifi cat io n
C l ient en gi neers (perh ap s)
S y st em archi tect s
S o ftware d ev elo pers
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Wicked problems



Most large software systems address wicked
problems
Problems which are so complex that they can
never be fully understood and where
understanding evolves during the system
development
Therefore, requirements are normally both
incomplete and inconsistent
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Reasons for inconsistency




Large software systems must improve the current
situation. It is hard to anticipate the effects that
the new system will have on the organisation
Different users have different requirements and
priorities. There is a constantly shifting
compromise in the requirements
System end-users and organisations who pay for
the system have different requirements
Prototyping is often required to clarify
requirements
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
The requirements engineering process

Feasibility study
•

Find out if the current user needs be satisfied given the available
technology and budget?
Requirements analysis
•

Requirements definition
•

Find out what system stakeholders require from the system
Define the requirements in a form understandable to the
customer
Requirements specification
•
Define the requirements in detail
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
The RE process
Feasi bi li ty
s tu dy
Requ irem ent s
analy si s
Requ ir em ent s
d efi ni ti on
Feasi bi li ty
repo rt
R equ irem ent s
s pecifi cat io n
S y st em
m o dels
Defi ni ti on o f
requ irem ent s
Requ irem ent s
d ocum en t
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
S p eci ficat io n o f
requ irem ent s
Slid
The requirements document



The requirements document is the official
statement of what is required of the system
developers
Should include both a definition and a
specification of requirements
It is NOT a design document. As far as possible,
it should set of WHAT the system should do
rather than HOW it should do it
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Requirements document requirements






Specify external system behaviour
Specify implementation constraints
Easy to change
Serve as reference tool for maintenance
Record forethought about the life cycle of the
system i.e. predict changes
Characterise responses to unexpected events
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Requirements document structure

Introduction
•

Glossary
•

Define technical terms used
System models
•

Describe need for the system and how it fits with business
objectives
Define models showing system components and relationships
Functional requirements definition
•
Describe the services to be provided
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Requirements document structure

Non-functional requirements definition
•

System evolution
•

Detailed specification of functional requirements
Appendices
•
•

Define fundamental assumptions on which the system is based
and anticipated changes
Requirements specification
•

Define constraints on the system and the development process
System hardware platform description
Database requirements (as an ER model perhaps)
Index
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Requirements validation


Concerned with demonstrating that the
requirements define the system that the customer
really wants
Requirements error costs are high so validation is
very important
•

Fixing a requirements error after delivery may cost up to 100
times the cost of fixing an implementation error
Prototyping is an important technique of
requirements validation
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Requirements checking




Validity. Does the system provide the functions
which best support the customer’s needs?
Consistency. Are there any requirements
conflicts?
Completeness. Are all functions required by the
customer included?
Realism. Can the requirements be implemented
given available budget and technology
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Requirements evolution


Requirements always evolve as a better
understanding of user needs is developed and as
the organisation’s objectives change
It is essential to plan for change in the
requirements as the system is being developed
and used
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Requirements evolution
Ini ti al
u nd ers tan di ng
o f p ro bl em
C h an ged
u nd ers tan di ng
o f p ro bl em
Ini ti al
requ irem ent s
C h an ged
requ ir em ent s
Ti m e
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Requirements classes


Enduring requirements. Stable requirements
derived from the core activity of the customer
organisation. E.g. a hospital will always have
doctors, nurses, etc. May be derived from domain
models
Volatile requirements. Requirements which
change during development or when the system is
in use. In a hospital, requirements derived from
health-care policy
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Controlled evolution
R equi rement s
change
R equi remen ts
do cu ment V1
S yst em
im pl em ent ati on V 1
Requi rement s
change
S yst em
im pl em ent ati on V 2
Requi remen ts and sys tem
in co nsi stent
©Ian Sommerville 1995
Requi remen ts
do cu ment V1
R equi remen ts
do cu ment V2
S yst em
im pl em ent ati on V 1
S yst em
im pl em ent ati on V 2
R equi remen ts and sys tem
cons ist ent
Software Engineering, 5th edition. Chapter 4
Slid
Model of requirements evolves (1)
time
final
high-level
view
initial
analysis
model
Detailing and implementing
design model. Changing and
adapting of high-level view.
• requirements themselves change
• our view / model of them changes
July 1998
Requirements Engineering
design objects
implementation
Model of requirements evolves (2)
controllable,
measurable
milestones
First, complete and precise requirements are
described, afterwards
the solutions designed.
P R O C
of modelling
It is possible to have
one objective problem definition, which
has several solutions.
C O N T
of the models
E
N
T
Any model, even if
describing reality,
is constructed and
designed.
E S S
The issues of
requirements become
evident as solutions
are explored.
July 1998
Requirements Engineering
gradually evolving
requirements and
final system model,
creative working
Model of requirements evolves (3)
Idealistic approach (e.g. Fusion):
• The analysis model is stable after the analysis phase. It can be
seamlessly extended into a design model.
• The initial analysis model is also the high-level view of the final
system.
One-model approach (e.g. BON):
• The goal is one single model, maybe on several abstraction levels;
no real separation between analysis and design.
• The model always undergoes changes and is never really stable.
• The initial analysis model is either discarded or changed into the
final high-level view.
Two-model approach (e.g. MSA):
• Two separate models are made: an (initial) analysis model and a
final high-level view of the system.
• These models are not identical; they may even use different
notations. Links provide necessary traces.
July 1998
Requirements Engineering
Key points



It is very difficult to formulate a complete and
consistent requirements specification
A requirements definition, a requirements
specification and a software specification are
ways of specifying software for different types of
reader
The requirements document is a description for
customers and developers
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Key points




Requirements errors are usually very expensive to
correct after system delivery
Reviews involving client and contractor staff are
used to validate the system requirements
Stable requirements are related to core activities
of the customer for the software
Volatile requirements are dependent on the
context of use of the system
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
End: Requirements Engineering
 Establishing
what the
customer requires from a
software system
what is it
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Requirements Analysis
the customer’s
requirements for a software
system
 Understanding
how to do it
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Requirements analysis



Sometimes called requirements elicitation or
requirements discovery
Involves technical staff working with customers
to find out about the application domain, the
services that the system should provide and the
system’s operational constraints
May involve end-users, managers, engineers
involved in maintenance, domain experts, trade
unions, etc. These are called stakeholders
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Problems of requirements analysis





Stakeholders don’t know what they really want
Stakeholders express requirements in their own
terms
Different stakeholders may have conflicting
requirements
Organisational and political factors may
influence the system requirements
The requirements change during the analysis
process. New stakeholders may emerge
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
The requirements analysis process
Requ ir em ent s
d efi ni ti on an d
s pecifi cat io n
R equ irement s
v ali dat io n
P ro ces s
ent ry
Do m ain
u nd ers tan di ng
P ri ori ti zat io n
R equ irem ent s
col lect io n
C o nfl ict
reso lu ti on
C l as s ifi cat io n
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
System models


Different models may be produced during the
requirements analysis activity
Requirements analysis may involve three
structuring activities which result in these
different models
•
•
•

Partitioning. Identifies the structural (part-of) relationships
between entities
Abstraction. Identifies generalities among entities
Projection. Identifies different ways of looking at a problem
Using modeling techniques, e.g. UML
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Viewpoint-oriented analysis

Stakeholders represent different ways of
looking at a problem or problem viewpoints
•
•

different types of stakeholders
different views among stakeholders of same type
This multi-perspective analysis is important as
there is no single correct way to analyse system
requirements
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Autoteller system



The example used here is an auto-teller system
which provides some automated banking services
I use a very simplified system which offers some
services to customers of the bank who own the
system and a narrower range of services to other
customers
Services include cash withdrawal, message
passing (send a message to request a service),
ordering a statement and transferring funds
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Autoteller viewpoints








Bank customers
Representatives of other banks
Hardware and software maintenance engineers
Marketing department
Bank managers and counter staff
Database administrators and security staff
Communications engineers
Personnel department
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Multiple problem viewpoints
P ro bl em
to b e
anal y sed
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Types of viewpoint

Data sources or sinks
•

Representation frameworks
•

Viewpoints are responsible for producing or consuming data.
Analysis involves checking that data is produced and consumed
and that assumptions about the source and sink of data are valid
Viewpoints represent particular types of system models. These
may be compared to discover requirements that would be
missed using a single representation. Particularly suitable for
real-time systems
Receivers of services
•
Viewpoints are external to the system and receive services
from it. Most suited to interactive systems
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
External viewpoints




Natural to think of end-users as receivers of
system services
Viewpoints are a natural way to structure
requirements elicitation
It is relatively easy to decide if a viewpoint is
valid
Viewpoints and services may be sued to structure
non-functional requirements
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
The VORD method
Vi ewp oi n t
i dent ifi cat io n
©Ian Sommerville 1995
Vi ewp oi n t
st ruct uri ng
V i ewp oi n t
d ocum en ta t io n
Software Engineering, 5th edition. Chapter 4
Vi ewp oi n t
s ys tem m a p pi ng
Slid
VORD standard forms
Vi ewpoi nt templ ate
Ref erence:
Attri butes:
Events :
Servi ces
Sub -VPs :
Servi ce templ ate
The v iewp oin t name.
Att ri but es
provi din g
vi ewpoi nt i nformati on.
A referen ce to a s et o f
ev ent
scenari os des cribi ng
how
t he
sy stem react s to
vi ewpoi nt event s.
A referen ce
t o a s et o f
servi ce d escri pti ons .
The n ames o f
su b vi ewpoi nt s.
Ref erence:
Ration ale:
Speci fi cation :
Vi ewpoi nts:
Non-fun cti ona l
requi remen ts :
Provi der:
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
The s ervice name.
Reason why th e servi ce i s
provi ded.
Referen ce to a
l ist of s erv ice
sp eci fi cati ons . These
may
be express ed in di fferen t
not at io ns.
Li st of viewpoin t names
receivi ng th e servi ce.
Referen ce to
a set of non
funct io nal
requi rement s
whi ch con strai n the service.
Referen ce to a
l ist of s yst em
obj ects whi ch provid e the
servi ce.
Slid
Viewpoint identification
Qu ery
b al ance
Get
t rans acti on s
C u st om er
d at ab as e
C ard
retu rni ng
M anag er
M achi ne
s up pl ies
M ess ag e
l og
Acco un t
i nfo rm at io n
Us er
i nt erface
Acco un t
h ol der
Rem ot e
d iag no st ics
©Ian Sommerville 1995
S y st em cos t
S to len
card
Reli ab il it y
C as h
wi t hd rawal
F o reig n
cus to m er
Ord er
s tat em en t
Up dat e
accou nt
Trans acti on
l og
Rem ot e
s oft ware
u pg rade
S o ftw are
s ize
P ri nt e
r
Hardw are
m ain ten ance
F u nd s
t rans fer
Software Engineering, 5th edition. Chapter 4
B ank
t el ler
Ord er
cheq ues
Inv ali d
u ser
S ecuri ty
M ess ag e
p as si n g
C ard
reten ti on
C ard
v ali dat io n
Slid
Viewpoint service information
AC C O UN T
HO LD ER
S ervi ce l is t
W i th draw cash
Qu ery bal ance
Or d er cheq ues
S en d m es sag e
Trans acti on l is t
Or d er st at em en t
Trans fer fu nd s
©Ian Sommerville 1995
F O REIG N
C U S TO M ER
S ervi ce l is t
W i th draw cash
Qu ery balance
Software Engineering, 5th edition. Chapter 4
B AN K
TE LL ER
S ervi ce l is t
R u n d iag no st ics
Ad d cash
Ad d pap er
S en d m es sag e
Slid
Viewpoint hierarchy
Al l VP s
S ervi ces
Qu ery bal ance
W i th draw cash
S ervi ces
C u st om er
Acco un t
h ol der
Fo reig n
cus to m er
B ank s taff
Tell er
M anag er
En gi neer
Ord er cheq ues
S en d m es sag e
Trans acti on l is t
Ord er st at em en t
Trans fer fu nd s
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Customer/cash withdrawal templates
Referen ce: C u st om er
Referen ce:
C as h w it hd rawal
Attri b u tes: Acco un t nu m ber
P IN
S t art t ran sacti on
E ven ts:
S el ect s ervi ce
C ancel
t ran sacti on
En d tran sacti on
Ra tio n a le:
To im p rove cu st om er s ervi ce
and redu ce p ap erw o rk
S ervi ces:
C as h w it hd rawal
B alan ce en qu iry
S p eci fi cati on : Us ers cho os e th is s ervi ce by
p res si ng t he cas h wi th draw al
b ut to n. They t hen ent er t he
am ou nt req ui red. Th is is
con firm ed an d, if fu nd s all ow ,
t he b alan ce is d eli vered .
VP s:
S u b -V Ps :
Acco un t ho ld er
F orei gn
cus to m er
Del iv er cas h w it hi n 1 m i nu te
No n -fu n ct.
req u i remen ts : o f am ou nt bei ng co nfi rm ed
Prov id er:
©Ian Sommerville 1995
C u st om er
Fi ll ed in la ter
Software Engineering, 5th edition. Chapter 4
Slid
Method advantages/disadvantages





Methods impose structure on the requirements
analysis process
May be supported by CASE tools
Can be applied systematically and can lead
naturally to design
However, forces system modelling using a
computational framework
Methods fail to adequately provide for the
description of human activities
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
System contexts



The boundaries of the system must be
established to determine what must be
implemented
These are documented using a description of the
system context. This should include a
description of the other systems which are in
the environment
Social and organisational factors may influence
the positioning of the system boundary
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Auto-teller system context
S ecuri ty
s ys tem
B ranch
accou nt ing
s ys tem
Acco un t
d at ab as e
Au to -t ell er
s ys tem
B ranch
cou nt er
s ys tem
Us ag e
d at abas e
M ain ten ance
s ys tem
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Social and organisational factors



Software systems are used in a social and
organisational context. This can influence or
even dominate the system requirements
Social and organisational factors are not a single
viewpoint but are influences on all viewpoints
Good analysts must be sensitive to these factors
but currently no systematic way to tackle their
analysis
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Ethnographic analysis




A social scientists spends a considerable time
observing and analysing how people actually
work
People do not have to explain or articulate their
work
Social and organisational factors of importance
may be observed
Ethnographic studies have shown that work is
usually richer and more complex than suggested
by simple system models
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Key points



Requirements analysis requires domain
understanding, requirements collection,
classification, structuring, prioritisation and
validation
Complex systems should be analysed from
different viewpoints
Viewpoints may be based on sources and sinks of
data, system models or external interaction
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Key points




Structured methods may be used for requirements
analysis. They should include a process model,
system modelling notations, rules and guidelines
for system modelling and standard reports
The VORD viewpoint-oriented method relies on
viewpoints which are external to the system
The boundaries between a system and its
environment must be defined
Social and organisational factors have a strong
influence on system requirements
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
End: Requirements Analysis
the customer’s
requirements for a software
system
 Understanding
how to do it
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Analysis models in RE-documents
Analysis model
current system or future system?
stable model after initial
requirements definition phase
goals
real world model or
model of a software system?
notation
technology dependency:
concerning automation boundaries?
concerning interaction mechanisms?
concerning low-level details?
concerning system architecture?
seamlessly extendable
into design model
application-oriented or reuse-oriented?
etc.
etc.
completeness or essential information?
targeted audience:
for users or computers?
for a contract or for developers of the same team?
unambiguity or understandability?
July 1998
Requirements Engineering
objective real world model
Software Prototyping for RE
 Animating
and demonstrating
system requirements
There are also other domains for
prototyping!
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Uses of system prototypes



The principal use is to help customers and
developers understand the requirements for the
system
The prototype may be used for user training
before a final system is delivered
The prototype may be used for back-to-back
testing
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Prototyping benefits





Misunderstandings between software users and
developers are exposed
Missing services may be detected
Confusing services may be identified
A working system is available early in the
process
The prototype may serve as a basis for deriving a
system specification
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Prototyping process
Es t abl is h
p ro to ty pe
o bj ect iv es
Defi ne
p ro to ty pe
fun cti on ali ty
Develo p
p ro to ty pe
Ev alu at e
p ro to ty pe
P ro to ty pi ng
p lan
Ou t li ne
d efi ni ti on
Ex ecut ab le
p ro to ty pe
Ev alu ati on
repo rt
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Prototyping objectives


The objective of evolutionary prototyping is to
deliver a working system to end-users. The
development starts with those requirements
which are best understood.
The objective of throw-away prototyping is to
validate or derive the system requirements. The
prototyping process starts with those
requirements which are poorly understood
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Approaches to prototyping
Ev o lu ti on ary
p ro to ty pi ng
Del i vered
s ys tem
Ou t li ne
R equ irem ent s
Th row-away
P ro to ty pi ng
©Ian Sommerville 1995
Execut able P rot ot yp e +
S y st em S peci ficat io n
Software Engineering, 5th edition. Chapter 4
Slid
Evolutionary prototyping



Must be used for systems where the specification
cannot be developed in advance e.g. AI systems
and user interface systems
Based on techniques which allow rapid system
iterations
Verification is impossible as there is no
specification. Validation means demonstrating
the adequacy of the system
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Evolutionary prototyping
Develo p ab st ract
s pecifi cat io n
B u il d p ro to ty pe
s ys tem
Us e prot ot yp e
s ys tem
N
Del iv er
s ys tem
©Ian Sommerville 1995
YE S
S y st em
adeq uat e?
Software Engineering, 5th edition. Chapter 4
Slid
Evolutionary Prototyping
Problems?
Dangers?
July 1998
Requirements Engineering
Evol. prototyping problems




Existing management processes assume a
waterfall model of development
Continual change tends to corrupt system
structure so long-term maintenance is expensive
Specialist skills are required which may not be
available in all development teams
Organisations must accept that the lifetime of
systems developed this way will inevitably be
short
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Throw-away prototyping



Used to reduce requirements risk
The prototype is developed from an initial
specification, delivered for experiment then
discarded
The throw-away prototype should NOT be
considered as a final system
•
•
•
Some system characteristics may have been left out - shortcuts
There is no specification for long-term maintenance
The system will be poorly structured and difficult to maintain
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Throw-away prototyping
Ou t li ne
requ irem en ts
S p eci fy
s ys tem
Ev alu at e
p ro to ty pe
Dev elo p
p ro to ty pe
Reus abl e
com p on ent s
Develo p
s oft ware
©Ian Sommerville 1995
Vali dat e
s ys tem
Software Engineering, 5th edition. Chapter 4
Del i vered
s oft ware
s ys tem
Slid
Throw-away Prototyping
Problems?
Dangers?
July 1998
Requirements Engineering
Prototypes as specifications




Some parts of the requirements (e.g. safetycritical functions) may be impossible to
prototype and so don’t appear in the
specification
An implementation has no legal standing as a
contract
Non-functional requirements cannot be
adequately tested in a system prototype
System model is hidden - and gets lost
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Incremental development



System is developed and delivered in increments
after establishing an overall architecture
Users may experiment with delivered increments
while others are being developed. therefore, these
serve as a form of prototype system
Intended to combine some of the advantages of
prototyping but with a more manageable process
and better system structure
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Incremental development process
Defi ne sys tem
d el i verabl es
S p eci fy sy st em
i ncrem ent
Des ig n sy st em
archi tect ur e
B u il d s ys tem
i ncrem ent
Vali dat e
i ncrem ent
Vali dat e
s ys tem
Int egrat e
i ncrem ent
NO
Del iv er fi nal
s ys tem
S y st em
com p let e?
YE S
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Incremental Prototyping
Problems?
Dangers?
July 1998
Requirements Engineering
Prototyping techniques




Executable specification languages
Very high-level languages
Application generators and 4GLs
Composition of reusable components
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
User interface prototyping




It is impossible to pre-specify the look and feel
of a user interface in an effective way.
prototyping is essential
UI development consumes an increasing part of
overall system development costs
Prototyping may use very high level languages
such as Smalltalk or Java, or UIMS's
User interface generators may be used to ‘draw’
the interface and simulate its functionality
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
User interface management system
Us er
com m an ds
Us er in terface
d is pl ay
Us er in terface
Ap pl icat io n
com m an ds
Us er i nt erface
m anag em en t
s ys tem
A p pl icat io n
Us er
Di s pl ay
s pecifi catio n
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Ap pl icat io n
com m an d
s pecifi cat io n
Slid
Key points




A prototype can be used to give end-users a
concrete impression of the system’s capabilities
Prototyping may be evolutionary prototyping or
throw-away prototyping; special case of
incremental development
Rapid development is essential for prototype
systems
Prototype structures become corrupted by
constant change. Hence, long-term evolution is
difficult
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Key points



In a throw-away prototype start with the least
well-understood parts; in an evolutionary
prototype, start with the best understood parts
Prototyping methods include the use of
executable specification languages, very highlevel languages, fourth-generation languages and
prototype construction from reusable components
Prototyping is essential for parts of the system
such as the user interface which cannot be
effectively pre-specified
©Ian Sommerville 1995
Software Engineering, 5th edition. Chapter 4
Slid
Template
First header
• 1st paragraph, text
– SEI Process Maturity Model
» IEEE standards, e.g. requirements
document,
• ISO standards, e.g. ISO 9000 - 9001
July 1998
Requirements Engineering
Descargar

Requirements Engineering - The Stanford University …