Requirements: Contenido

requrem/n_req.htmrequrem/n_req.htm requrem/wfd_req.htmrequrem/wfd_req.htm requre

m/wfov_req.htmrequrem/wfov_req.htm requrem/rq_resov.htmrequrem/rq_resov.htm requre
m/mdov_req.htmrequrem/mdov_req.htm requrem/cos_req.htmrequrem/cos_req.htm
Disciplines > Requirements > Introduction
Introduction to Requirements
Purpose
Reaton to Other Dscpnes
Concepts
Requrements
Requrements Management
Types of Requrements
Traceabty
User-Centered Desgn
Use-Case Vew
Purpose TopTop
The purpose of the Requrements dscpne s:
To estabsh and mantan agreement wth the customers and other stakehoders
on what the system shoud do.
To provde system deveopers wth a better understandng of the system
requrements.
To dene the boundares of (demt) the system.
To provde a bass for pannng the technca contents of teratons.
To provde a bass for estmatng cost and tme to deveop the system.
To dene a user-nterface for the system, focusng on the needs and goas of the
users.
To acheve these goas, t s mportant, rst of a, to understand the denton and scope
of the probem whch we are tryng to sove wth ths system. The Busness Rues,
Busness Use-Case Mode and Busness Ob|ect Mode deveoped durng Busness
Modeng w serve as vauabe nput to ths ehort. Stakehoders are dented and
Stakehoder Requests are ected, gathered and anayzed.
A Vson document, a use-case mode, use cases and Suppementary Speccaton are
deveoped to fuy descrbe the system - what the system w do - n an ehort that
vews a stakehoders, ncudng customers and potenta users, as mportant sources of
nformaton (n addton to system requrements).
Stakehoder Requests are both actvey ected and gathered from exstng sources to
get a "wsh st" of what dherent stakehoders of the pro|ect (customers, users, product
champons) expect or desre the system to ncude, together wth nformaton on how
each request has been consdered by the pro|ect.
The Vson document provdes a compete vson for the software system under
deveopment and supports the contract between the fundng authorty and the
deveopment organzaton. Every pro|ect needs a source for capturng the expectatons
among stakehoders. The vson document s wrtten from the customers' perspectve,
focusng on the essenta features of the system and acceptabe eves of quaty. The
Vson shoud ncude a descrpton of what features w be ncuded as we as those
consdered but not ncuded. It shoud aso specfy operatona capactes (voumes,
response tmes, accuraces), user proes (who w be usng the system), and nter-
operatona nterfaces wth enttes outsde the system boundary, where appcabe. The
Vson document provdes the contractua bass for the requrements vsbe to the
stakehoders.
The use-case mode shoud serve as a communcaton medum and can serve as a
contract between the customer, the users, and the system deveopers on the
functonaty of the system, whch aows:
.
.
\
.
.
\
.
.
\

n
d
e
x
.
h
t
m
|
a
v
a
s
c
r

p
t
:

o
a
d
T
o
p
(
)
;
|
a
v
a
s
c
r

p
Customers and users to vadate that the system w become what they
expected.
System deveopers to bud what s expected.
The use-case mode conssts of use cases and actors. Each use case n the mode s
descrbed n deta, showng step-by-step how the system nteracts wth the actors, and
what the system does n the use case. Use cases functon as a unfyng thread
throughout the software fecyce; the same use-case mode s used n system anayss,
desgn, mpementaton, and testng.
The Suppementary Speccatons are an mportant compement to the use-case mode,
because together they capture a software requrements (functona and nonfunctona)
that need to be descrbed to serve as a compete software requrements speccaton.
A compete denton of the software requrements descrbed n the use cases and
Suppementary Speccatons may be packaged together to dene a Software
Requrements Speccaton (SRS) for a partcuar "feature" or other subsystem groupng.
A Requrements Management Pan speces the nformaton and contro mechansms
whch w be coected and used for measurng, reportng, and controng changes to
the product requrements.
Compementary to the above mentoned artfacts, the foowng artfacts are aso
deveoped:
Gossary
Use-Case Storyboard
User-Interface Prototype
The Gossary s mportant because t denes a common termnoogy whch s used
consstenty across the pro|ect or organzaton.
The Use-Case Storyboard and User-Interface Prototype are a resuts of user-nterface
modeng and prototypng, whch are done n parae wth other requrements actvtes.
These artfacts provde mportant feedback mechansms n ater teratons for
dscoverng unknown or uncear requrements.
Relation to Other Disciplines TopTop
The Requrements dscpne s reated to other process dscpnes.
The Business Modeling dscpne provdes Busness Rues, a Busness Use-
Case Mode and a Busness Ob|ect Mode, ncudng a Doman Mode and an
organzatona context for the system.
The Analysis & Design dscpne gets ts prmary nput (the use-case mode
and the Gossary) from Requrements. Faws n the use-case mode can be
dscovered durng anayss & desgn; change requests are then generated, and
apped to the use-case mode.
The Test dscpne tests the system to verfy the code aganst the Use-Case
Mode. Use Cases and Suppementary Speccatons provde nput on
requrements used n pannng and desgnng tests.
The Confguration & Change Management dscpne provdes the change
contro mechansm for requrements. The mechansm for proposng a change s
to submt a Change Request, whch s revewed by the Change Contro Board.
The Project Management dscpne pans the pro|ect and each teraton
(descrbed n an Iteraton Pan). The use-case mode and Requrements
Management Pan are mportant nputs to the teraton pannng actvtes.
The Environment dscpne deveops and mantans the supportng artfacts
that are used durng requrements management and use-case modeng, such as
the Use-Case-Modeng Gudenes and User-Interface Gudenes.
t
:

o
a
d
T
o
p
(
)
;
Rational Unified Process
Requirements: Concepts
Requrements
Requrements Management
Types of Requrements
Traceabty
User-Centered Desgn
Use-Case Vew
Concepts: Requirements
More nformaton on ths topc can be found at:
Concepts: Requrements Management
Concepts: Types of Requrements
Concepts: Traceabty
Concepts: User-Centered Desgn
Whte Paper: Appyng Requrements Management wth Use Cases
A requirement s dened as "a condton or capabty to whch a system must conform".
There are many dherent knds of requrements. One way of categorzng them s descrbed
as the !"P#$ mode |GRA92|, usng the acronym FURPS to descrbe the ma|or categores
of requrements wth subcategores as shown beow.
unctonaty
! sabty
" eabty
P erformance
# upportabty
The "+" n FURPS+ remnds you to ncude such requrements as:
desgn constrants
mpementaton requrements
nterface requrements
physca requrements.
(See aso |IEEE Std 610.12.1990|.)
unctional requirements specfy actons that a system must be abe to perform, wthout
takng physca constrants nto consderaton. These are often best descrbed n a use-case
mode and n use cases. Functona requrements thus specfy the nput and output behavor
of a system.
Requrements that are not functona, such as the ones sted beow, are sometmes caed
non%&unctional requirements. Many requrements are non-functona, and descrbe ony
attrbutes of the system or attrbutes of the system envronment. Athough some of these
may be captured n use cases, those that cannot may be speced n Suppementary
Speccatons. Nonfunctona requrements are those that address ssues such as those
descrbed beow.
A compete denton of the software requrements, use cases, and Suppementary
Speccatons may be packaged together to dene a #o&tware "equirements
#'ecifcation (#"#) for a partcuar "feature" or other subsystem groupng.
Functionality TopTop
Functona requrements may ncude:
feature sets
capabilities
security
Usability TopTop
Usabty requrements may ncude such subcategores as:
human factors (see Concepts: User-Centered Desgn)
aesthetcs
consstency n the user nterface (see Gudenes: User-Interface)
onne and context-senstve hep
wzards and agents
user documentaton
tranng materas
Reliability TopTop
Reabty requrements to be consdered are:
frequency and severty of faure
recoverabty
predctabty
accuracy
mean tme between faure (MTBF)
Performance TopTop
A performance requrement mposes condtons on functona requrements. For exampe, for
a gven acton, t may specfy performance parameters for:
speed
emcency
avaabty
accuracy
throughput
response tme
recovery tme
resource usage
Supportability TopTop
Supportabty requrements may ncude:
testabty
extensbty
adaptabty
mantanabty
compatbty
congurabty
servceabty
nstaabty
ocazabty (nternatonazaton)
Desin Requirement TopTop
A desgn requrement, often caed a design constraint, speces or constrans the desgn
of a system.
Implementation Requirement TopTop
An mpementaton requrement speces or constrans the codng or constructon of a
system. Exampes are:
requred standards
mpementaton anguages
poces for database ntegrty
resource mts
operaton envronments
Interface Requirement TopTop
An nterface requrement speces:
an externa tem wth whch a system must nteract
constrants on formats, tmngs, or other factors used by such an nteracton
Physical Requirement TopTop
A physca requrement speces a physca characterstc that a system must possess; for
exampe,
matera
shape
sze
weght
Ths type of requrement can be used to represent hardware requrements, such as the
physca network conguratons requred.
Concepts: Requirements !anaement
What s Requrements Management?
Probem anayss
Understandng stakehoder needs
Denng the system
Managng the scope of the pro|ect
Renng the system denton
Managng changng requrements
More Informaton: Concepts: Requrements
Concepts: Types of Requrements
Concepts: Traceabty
Whte Paper: Appyng Requrements Management wth Use Cases
"hat is Requirements !anaement# TopTop
Requrements management s a systematc approach to ndng, documentng, organzng
and trackng the changng requrements of a system.
We dene a requrement as:
A condition or capability to which the system must conform.
Our forma denton of requrements management s that t s a systematc approach to
ectng, organzng, and documentng the requrements of the system, and
estabshng and mantanng agreement between the customer and the pro|ect team
on the changng requrements of the system.
Keys to ehectve requrements management ncude mantanng a cear statement of the
requrements, aong wth appcabe attrbutes for each requrement type and traceabty to
other requrements and other pro|ect artfacts.
Coectng requrements may sound ke a rather straghtforward task. In rea pro|ects,
however, you w run nto dmcutes because:
Requrements are not aways obvous, and can come from many sources.
Requrements are not aways easy to express ceary n words.
There are many dherent types of requrements at dherent eves of deta.
The number of requrements can become unmanageabe f not controed.
Requrements are reated to one another and aso to other deverabes of the
software engneerng process.
Requrements have unque propertes or property vaues. For exampe, they are
nether equay mportant nor equay easy to meet.
There are many nterested partes, whch means requrements need to be managed
by cross-functona groups of peope.
Requrements change.
So, what sks do you need to deveop n your organzaton to hep you manage these
dmcutes? We have earned that the foowng sks are mportant to master:
Probem anayss
Understandng stakehoder needs
Denng the system
Managng scope of the pro|ect
Renng the system denton
Managng changng requrements
Problem $nalysis TopTop
Probem anayss s done to understand probems, nta stakehoder needs, and propose
hgh-eve soutons. It s an act of reasonng and anayss to nd "the probem behnd the
probem". Durng probem anayss, agreement s ganed on the rea probem(s), and who the
stakehoders are. Aso, you dene what from a busness perspectve are the boundares of
the souton, as we as busness constrants on the souton. You shoud aso have anayzed
the busness case for the pro|ect so that there s a good understandng of what return s
expected on the nvestment made n the system beng but.
See aso Workow Deta: Anayze the Probem.
Understandin Sta%eholder &eeds TopTop
Requrements come from many sources, exampes woud be customers, partners, end users,
and doman experts. You need to know how to best determne what the sources shoud be,
get access to those sources, and aso how to best ect nformaton from them. The
ndvduas who provde the prmary sources for ths nformaton are referred to as
stakehoders n the pro|ect. If youre deveopng an nformaton system to be used nternay
wthn your company, you may ncude peope wth end user experence and busness
doman expertse n your deveopment team. Very often you w start the dscussons at a
busness mode eve rather than a system eve. If youre deveopng a product to be sod to
a market pace, you may make extensve use of your marketng peope to better understand
the needs of customers n that market.
Ectaton actvtes may occur usng technques such as ntervews, branstormng,
conceptua prototypng, questonnares, and compettve anayss. The resut of the
ectaton woud be a st of requests or needs that are descrbed textuay and graphcay,
and that have been gven prorty reatve one another.
See aso Workow Deta: Understand Stakehoder Needs.
Definin the System TopTop
To dene the system means to transate and organze the understandng of stakehoder
needs nto a meanngfu descrpton of the system to be but. Eary n system denton,
decsons are made on what consttutes a requrement, documentaton format, anguage
formaty, degree of requrements speccty (how many and n what deta), request prorty
and estmated ehort (two very dherent vauatons usuay assgned by dherent peope n
separate exercses), technca and management rsks, and nta scope. Part of ths actvty
may ncude eary prototypes and desgn modes drecty reated to the most mportant
stakehoder requests. The outcome of system denton s a descrpton of the system that s
both natura anguage and graphca.
See aso Workow Deta: Dene the System.
!anain the Scope of the Pro'ect TopTop
To emcenty run a pro|ect, you need to carefuy prortze the requrements, based on nput
from a stakehoders, and manage ts scope. Too many pro|ects suher from deveopers
workng on so caed "Easter eggs" (features the deveoper nds nterestng and
chaengng), rather than eary focusng on tasks that mtgate a rsk n the pro|ect or
stabze the archtecture of the appcaton. To make sure that you resove or mtgate rsks
n a pro|ect as eary as possbe, you shoud deveop your system ncrementay, carefuy
choosng requrements to for each ncrement that mtgates known rsks n the pro|ect. To do
so, you need to negotate the scope (of each teraton) wth the stakehoders of the pro|ect.
Ths typcay requres good sks n managng expectatons of the output from the pro|ect n
ts dherent phases. You aso need to have contro of the sources of requrements, of how the
deverabes of the pro|ect ook, as we as the deveopment process tsef.
See aso Workow Deta: Manage the Scope of the System.
Refinin the System Definition TopTop
The detaed denton of the system needs to be presented n such a way that your
stakehoders can understand, agree to, and sgn oh on them. It needs to cover not ony
functonaty, but aso compance wth any ega or reguatory requrements, usabty,
reabty, performance, supportabty, and mantanabty. An error often commtted s to
beeve that what you fee s compex to bud needs to have a compex denton. Ths eads
to dmcutes n expanng the purpose of the pro|ect and the system. Peope may be
mpressed, but they w not gve good nput snce they dont understand. You shoud put ots
ehort n understandng the audence for the documents you are producng to descrbe the
system. You may often see a need to produce dherent knds of descrpton for dherent
audences.
We have seen that the use-case methodoogy, often n combnaton wth smpe vsua
prototypes, s a very emcent way of communcatng the purpose of the system and denng
the detas of the system. Use cases hep put requrements nto a context, they te a story of
how the system w be used.
Another component of the detaed denton of the system s to state how the system
shoud be tested. Test pans and dentons of what tests to perform tes us what system
capabtes w be vered.
See aso Workow Deta: Rene the System Denton.
!anain Chanin Requirements TopTop
No matter how carefu you are about denng your requrements, there w aways be thngs
that change. What makes changng requrements compex to manage s not ony that a
changed requrement means that more or ess tme has to be spent on mpementng a
partcuar new feature, but aso that a change to one requrement may have an mpact on
other requrements. You need to make sure that you gve your requrements a structure that
s resent to changes, and that you use traceabty nks to represent dependences
between requrements and other artfacts of the deveopment fecyce. Managng change
ncude actvtes ke estabshng a basene, determnng whch dependences are mportant
to trace, estabshng traceabty between reated tems, and change contro.
See aso Workow Deta: Manage Changng Requrements.
Concepts: Traceability
Introduction
Tracea*ility is the a*ility to trace a 'roject element to other related 'roject
elements+ es'ecially those related to requirements, Project elements involved in
tracea*ility are called tracea*ility items, Ty'ical tracea*ility items include
di-erent ty'es o& requirements+ analysis and design model elements+ testing
arti&acts (test cases+ test 'rocedures+ etc,)+ and end%user su''ort documentation
and training material+ as shown in the fgure *elow,
The tracea*ility hierarchy,
Each tracea*ility item has its own unique set o& associated attri*utes+ which is
use&ul &or trac.ing the status+ *eneft+ ris.+ etc, associated with each item,
Purpose of Traceability
The 'ur'ose o& esta*lishing tracea*ility is to hel'/
!nderstand the source o& requirements
Manage the sco'e o& the 'roject
Manage changes to requirements
Assess the 'roject im'act o& a change in a requirement
Assess the im'act o& a &ailure o& a test on requirements (i,e, i& test &ails the
requirement may not *e satisfed)
0eri&y that all requirements o& the system are &ulflled *y the
im'lementation,
0eri&y that the a''lication does only what it was intended to do,
Tracea*ility hel's you understand and manage how in'ut to the requirements+
such as *usiness rules and sta.eholder requests+ are translated into a set o& .ey
sta.eholder1user needs and system &eatures+ as s'ecifed in the 0ision document,
The use%case model+ in turn+ outlines the how these &eatures are translated to the
&unctionality o& the system, The details o& how the system interacts with the
outside world are ca'tured in use cases+ with other im'ortant requirements (such
as non%&unctional requirements+ design constraints+ etc,) in the #u''lementary
#'ecifcations, Tracea*ility allows you to also &ollow how these detailed
s'ecifcations are translated into a design+ how it is tested+ and how it is
documented &or the user, or a large system+ use cases and #u''lementary
#'ecifcations may *e 'ac.aged together to defne a #o&tware "equirements
#'ecifcation (#"#) &or a 'articular 2&eature2 or other su*system grou'ing,
A .ey conce't in hel'ing to manage changes in requirements is that o& a
2sus'ect2 tracea*ility lin., 3hen a requirement (or other tracea*ility item)
changes at either end o& a tracea*ility lin.+ all lin.s associated with that
requirement are mar.ed as 2sus'ect2, This 4ags the res'onsi*le role to review
the change and determine i& the associated items will need to change also, This
conce't also hel's in analy5ing the im'act o& 'otential changes,
Tracea*ilities may *e set u' to hel' answer the &ollowing sam'le set o& queries/
#how me user needs that are not lin.ed to 'roduct &eatures,
#how me the status o& tests on all use cases in iteration 6n,
#how me all su''lementary requirements lin.ed to tests whose status is
untested,
#how me the results o& all tests that &ailed+ in order o& criticality,
#how me the &eatures scheduled &or this release+ which user needs they
satis&y+ and their status,
E7am'le/
or a "ecycling Machine system+ the 0ision document s'ecifes the &ollowing
&eature/
EAT89/The recycling machine will allow the addition o& new *ottle ty'es,
This &eature is traced to a use case 2Add :ew Bottle Ty'e2/
The use case Add :ew Bottle Ty'e allows the ;'erator to teach the
"ecycling Machine to recogni5e new .inds o& *ottles,
This tracea*ility hel's us veri&y that all &eatures have *een accounted &or in use
cases and su''lementary s'ecifcations,
Typical Traceability
The most im'ortant tracea*ility items are/
!ser1#ta.eholder :eeds (&rom 0ision+ may *e &urther traced to individual
#ta.eholder "equests)
Product eature (&rom 0ision),
#u''lementary "equirement (&rom #u''lementary #'ecifcations,)
!se Case
!se Case #ection (sections o& a detailed use case),
Design Element (&rom the design model),
Test Case (or other element &rom the test model),
;ther elements+ such as Business "ules and <ssues may also *e use&ul to trace,
A ty'ical tracea*ility is shown in the &ollowing diagram/
This diagram only shows tracea*ility to requirements, ;ther tracea*ility may e7ist
as well+ *ut is not shown on this diagram/ design elements trace down to
im'lementation com'onents+ there are test cases &or design and im'lementation+
etc
Concepts: Types of Requirements
More Informaton: Concepts: Requrements
Concepts: Requrements Management
Concepts: Traceabty
Whte Paper: Appyng Requrements Management wth Use Cases
Tradtonay, requrements are ooked upon as statements of text ttng nto one of the
categores mentoned n Concepts: Requrements. Each requrement states "a condton or
capabty to whch the system must conform".
To perform ehectve requrements management, we have earned that t heps to extend
what we mantan as requrements beyond ony the detaed "software requrements". We
ntroduce the noton of requirements ty'es to hep separate the dherent eves of
abstracton and purposes of our requrements.
We may want to keep track of ambguous "wshes", as we as forma requests, from our
stakehoders to make sure we know how they are taken care of. The Vson document heps
us keep track of key "user needs" and "features" of the system. The use-case mode s an
ehectve way of expressng detaed functona "software requrements", therefore use cases
may need to be tracked and mantaned as requrements, as we as perhaps ndvdua
statements wthn the use case propertes whch state "condtons or capabtes to whch
the system must conform". Suppementary Speccatons may contan other "software
requrements", such as desgn constrants or ega or reguatory requrements on our system.
For a compete denton of the software requrements, use cases and Suppementary
Speccatons may be packaged together to dene a #o&tware "equirements
#'ecifcation (#"#) for a partcuar "feature" or other subsystem groupng.
The arger and more ntrcate the system deveoped, the more expressons, or types of
requrements appear and the greater the voume of requrements. "Busness rues" and
"vson" statements for a pro|ect trace to "user needs", "features" or other "product
requrements". Use cases or other forms of modeng and other Suppementary
Speccatons drve desgn requrements, whch may be further decomposed to functona
and non-functona "software requrements" represented n anayss & desgn modes and
dagrams.
Concepts: Use(Case )ie*
To provde a bass for pannng the technca contents of teratons, an archtectura vew
caed the use%case view s used n the Requrements dscpne. There s ony one use-case
vew of the system, whch ustrates the use cases and scenaros that encompass
archtecturay sgncant behavor, casses, or technca rsks. The use-case vew s rened
and consdered ntay n each teraton.
The use-case vew shows an archtecturay sgncant subset of the use-case mode, a
subset of the use cases and actors.
The anayss, desgn, and mpementaton actvtes subsequent to requrements are
centered on the noton of an architecture. The producton and vadaton of that
archtecture s the man focus of the eary teratons, especay durng the Eaboraton
phase. Archtecture s represented by a number of dherent archtectura vews, whch n
ther essence are extracts ustratng the "archtecturay sgncant" eements of the
modes.
There are four addtona vews: the =ogical 0iew, Process 0iew, De'loyment 0iew, and
<m'lementation 0iew. These vews are handed n the Anayss & Desgn and
Impementaton dscpnes.
The archtectura vews are documented n a #o&tware Architecture Document. You may
add dherent vews, such as a securty vew, to convey other specc aspects of the software
archtecture.
So, n essence, archtectura vews can be seen as abstractons or smpcatons of the
modes but, n whch you make mportant characterstcs more vsbe by eavng the detas
asde. The archtecture s an mportant means for ncreasng the quaty of any mode but
durng system deveopment.
Concepts: User(Centered Desin
Topics
What s user-centered desgn?
Focus on users
Integrated wth desgn
Eary user testng
Iteratve desgn
Why user-centered desgn?
Meetng user needs
User-nterface desgn
Legsaton and standards
User-centered desgn n the RUP
Contexts of use
Scenaros, use cases and essenta use cases
Essenta use cases n the RUP
"hat is user(centered desin#
There s no cear consensus on what consttutes user-centered desgn. However, |ohn Goud
and hs coeagues at IBM deveoped an approach n the 1980s caed Design for Usability
|GOU88| whch encompasses most commony-accepted dentons. It deveoped from
practca experence on a number of nteractve systems, most notaby IBMs 1984 Oympc
Messagng System |GOU87|. The approach has four man components as descrbed beow.
Focus on users
Goud suggests that deveopers shoud decde who the users w be and to nvove them at
the earest possbe opportunty. He suggests a number of ways of becomng famar wth
users, ther tasks and requrements:
Tak wth users Vst customer ocatons
Observe users workng Vdeotape users workng
Learn about work organzaton Try t yoursef
Get users to thnk aoud whe workng Partcpatve desgn
Incude expert users on the desgn team Perform task anayss
Make use of surveys and questonnares Deveop testabe goas
In the Ratona Uned Process (RUP), workshops are used at severa key stages, but these
must be compemented by the knds of actvtes Goud descrbes f an accurate pcture s to
be formed. (Part of the argument behnd ths s that peope frequenty descrbe what they do
qute dherenty from how they do t. Commony performed tasks and seemngy
unmportant detas such as pacement of work or the exstence of "mysterous" scraps of
paper are often forgotten - or omtted because they are not "omcay" part of the current
process.)
Interated *ith desin
Usabty tasks shoud be performed n parae eary n deveopment. These tasks woud
ncude sketchng the user nterface and draftng the user gudes or onne hep. Goud aso
makes the pont that usabty shoud be the responsbty of one group.
An mportant feature of ntegrated desgn s that the overa approach - the framework - for
detaed user-nterface desgn s deveoped and tested at an eary stage. Ths s an mportant
dherence between user-centered desgn and other purey ncrementa technques. It
ensures that ncrementa desgn carred out n ater phases ts seamessy nto the
framework and that the user nterface s consstent n appearance, termnoogy and concept.
Wthn the RUP, ths framework can be estabshed by usng a doman mode to ensure that
a termnoogy and concepts that w appear n the user nterface are known and
understood wthn the busness n genera and wth users n partcuar. (There w aso be
subsets of the doman mode that w be reevant ony to specc groups of users. Care
shoud be taken to ensure that the doman mode s organzed so that these subsets can be
easy dented.) As user-nterface desgn progresses n the requrements dscpne, many of
the doman casses w be represented as boundary casses n the nterface. The boundary
casses, and the reatonshps between them, shoud be consstent wth the doman mode
and shoud be represented consstenty through a parts of the system under desgn. (Ths
not ony asssts users, but aso mproves reuse of user-nterface components.)
+arly user testin
Eary user testng means eary prototypng, typcay drawngs and mockups descrbed as
ow-dety prototypes. H-dety prototypes w foow ater n the process.
Mockups can be used n con|uncton wth use cases to wrte concrete scenaros of use for the
system under desgn. These can take the form narratve, ustrated narratve (usng the
mockups for ustraton), storyboards, wak-throughs (wth users) and the bass of user focus
groups. Whe these approaches are unfamar to many software deveopers, they are ceary
more cost ehectve than the dscovery of napproprate desgn or msunderstood
requrements once mpementaton s under way.
Iterati,e desin
Ob|ect-orented deveopment has become synonymous wth an teratve process. Iteratve
desgn s we-suted to probems that need a renement of understandng and have
changng requrements. Not surprsngy, teratve desgn s a key component of user-
centered desgn. Ths s party due to the changng needs of users over tme, but aso the
nherent compexty of producng desgn soutons that can dea wth dverse needs.
Note that n user-centered methods, teratve desgn takes pace wthn an ntegrated
framework. We deberatey avod ncrementa deveopment, outsde of an agreed
framework, that mght ead to a "patchwork" souton.
"hy user(centered desin#
!eetin user needs
Interactve systems rey on ther abty to accommodate the needs of users for ther
success. Ths means not ony dentfyng dverse user communtes but aso recognzng the
range of sks, experence and preferences of ndvdua users.
Whe t s temptng for deveopers and managers to fee that they understand user needs,
ths s sedom the case n practce. Attenton s frequenty focused on how users ought to
perform tasks rather than how they prefer to perform them. In many cases the ssue of
preference s much more than smpy feeng n contro, athough that s an mportant ssue
n tsef. Preference w aso be determned by experence, abty and the context of use.
These ssues are consdered sumcenty mportant to the desgn process to warrant an
nternatona standard, |ISO 13407|, entted human-centred design processes for interactive
systems. The standard and reated ssues are dscussed n genera terms n the remander of
ths paper.
User(interface desin
Users understand and nteract wth a system through ts user nterface. The concepts,
mages and termnoogy presented n the nterface must be approprate to users needs. For
exampe, a system that aows customers to buy ther own tckets woud be very dherent to
one used professonay by tcket saes stah. The man dherences are not n the
requrements or even the detaed use cases, but the characterstcs of the users and the
envronments n whch the systems mght operate.
The user nterface must aso cater for a potentay wde range of experence aong at east
two dmensons, computer and doman experence, as shown n Fgure 1 beow. Computer
experence ncudes not ony genera famarty wth computers, but aso experence of the
system under deveopment. Users wth tte experence of ether computers or the probem
doman, n the near eft corner of the gure, w requre a substantay dherent approach n
the user nterface to expert users, shown here n the far rght corner.
igure 8/ The e-ects o& com'uter and domain e7'erience on ease o& learning
versus ease o& use
Beware that t s not a forgone concuson that nexperenced users w become experts over
tme. A number of factors may conspre to prevent ths, for exampe ow frequency of use,
ow motvaton or hgh compexty. Conversey some systems may have predomnatey
expert users. Factors here mght be tranng, hgh frequency of use or hgh motvaton (|ob
dependence). Some of these ssues and ther ehects on user-nterface desgn are shown n
Tabe 1.
=ow >igh
Com'uter e7'erience Smpe queston and answer,
smpe form-, web (hyper
nked) or menu nterface
stye
Compex form-, web
(hyper nked) or menu
nterface stye (queston
and answer or smpe form-
woud be very frustratng
to experenced users)
Domain e7'erience Common termnoogy and
concepts
Doman-specc
termnoogy and concepts
Training Focus on ease of earnng
(consstent, predctabe,
memorabe)
Focus on ease of use
(drect, customzabe, non-
ntrusve)
requency o& use Easy to earn and remember,
smpe nterface stye
Easy to use, mutpe
shortcuts and technques to
aow user contro
Motivation Rewardng to use, powerfu
wthout seemng compex.
Sophstcated wth many
advanced and customzabe
features.
Ta*le 8+ #ome &actors a-ecting user%inter&ace design
Interactve systems must ether be desgned to cater for an approprate range of user
experence and crcumstances, or steps must be taken to restrct the desgn unverse. For
nstance, tranng can be used to reduce the requrement for ease of earnng n a compex
system. Aternatvey a system mght be reduced n ts scope n order that t better meets
the core requrements of ts users (a suggeston made by Aan Cooper n hs book The
Inmates Are Running the Asylum |COO99|).
-eislation and standards
As part of user-centered desgn, we need to consder the sks and physca attrbutes of
users. These ssues are now beng ncreasngy emboded n egsaton. Ths s mosty
drected at accommodatng users wth dsabtes. However, makng systems accessbe to a
wder range of users s generay seen as benetng the user communty as a whoe.
The tabe beow shows the reevant egsaton and resources for many parts of the word:
Descri'tion 3e* #ite
AUSTRALIA
Dsabty Dscrmnaton Act http://www.deakn.edu.au/extern/rdu/ddandex.htm
Dsabty Rghts http://www.hreoc.gov.au/dsabty_rghts/ndex.htm
EUROPE
Treaty of Amsterdam http://www.edf.unca.be/teu/en/ndex.asp
European Dsabty Forum http://www.edf.unca.be
UNITED KINGDOM
Dsabty Dscrmnaton Act http://www.hmso.gov.uk/acts/acts1995/1995050.htm
New Dea for Dsabed Peope http://www.dsabty.gov.uk
Dgta Access Campagn http://www.rnb.org.uk/dgta/wecome.htm
UNITED NATIONS
Unted Natons Standard Rues
on the Equazaton of
Opportuntes for Persons wth
Dsabtes
http://www.un.org/esa/socdev/dssre00.htm
Soca Deveopment Informaton
on the Internet
http://unescap.org/sps/sdnfo/dsabnks.htm
UNITED STATES
Amercans wth Dsabtes Act
(ADA): US Department of |ustce
http://www.usdo|.gov/crt/ada/
Secton 508 of the Workforce
Investment Act: US Department
of |ustce
http://www.usdo|.gov/crt/508/508home.htm
US Access Board Eectronc and
Informaton Technoogy Advsory
Commttee (EITAAC)
http://www.access-board.gov
Word Wde Web Consortum
Web Accessbty Campagn
http://www.w3.org/wa/
OTHER RESOURCES
Dsabty-Reated Internet
Resources
http://www.webabe.com/
Ta*le ?a+ Disa*ility%related legislation *y country+ region or *ody
Asde from egsaton, user-centered desgn and user-nterface desgn are ncreasngy
becomng the sub|ect of standardzaton as shown beow.
Descri'tion 3e* #ite1#tandards
ANSI www.ans.org
ANSI
ANSI-HFES
ANSI-NSC
ANSI and the Human Factors and Ergonomcs Socety
have pubshed a number of |ont standards. ANSI
aso has ANSI-NSC Z365 whch reates to the contro
and preventon of cumuatve stress dsorders (aso
known as repettve stran n|ury or RSI).
ANSI s draftng standards concernng human
computer nteracton as part of the Informaton
Infrastructure Standards Pane (IISP) at
http://web.ans.org/pubc/sp/std_need/needcat.htm
.
ISO www.so.ch
ISO 9241 A arge seres of standards many concerned wth
ergonomcs of workstatons, but aso ncudes
gudance on usabty (part 11). Aso the bass for
ANSI-HFES 200, under deveopment.
ISO 10075: 1991 Ergonomc prncpes reatng to menta work oad
ISO 17041-1: 1995 Cursor contro for text edtng
ISO 11581 Seres n deveopment deang wth cons and
ponters.
ISO 13407: 1999 Standard for human-centered desgn processes for
nteractve systems.
Ta*le ?*+ A:#< and <#; user inter&ace and user%centered design standards
User(centered desin in the RUP
Deveopng systems approprate to user needs means a sgncant ehort n requrements
anayss. In user-centered desgn, ths ehort s focused on end users. These are a subset of
the human Busness Actors (for users outsde of the busness) and Busness Workers found
when workng n the Busness Modeng dscpne. They are ater descrbed n greater deta
n the Requrements dscpne as Actors. (The reatonshps between Actors, Busness Actors
and Busness Workers s dscussed n Gudene: Gong from Busness Modes to Systems.)
However, a substanta pont of emphass n User-Centered desgn s that we understand the
requrements of the rea peope who w the roes descrbed n the artfacts mentoned
above. In partcuar, we must avod desgnng hypothetca humans for whom t s convenent
to desgn software systems. The artfacts descrbng end users must be wrtten ony after
substanta, rst-hand contact wth users. In user-centered desgn ths rst-hand contact s
part of a process sometmes caed contextual inquiry. Hugh Beyer and Karen Hotzbatt (n
ther book Contextual Design |BEY98|) descrbe the premse of contextua nqury as:
"...go where the customer works, observe the customer as he or she works, and tak to the
customer about the work."
(Some concrete exampes of ths have aready been sted under Focus on Users.) Ths
approach s used not ony to have a better understandng of system requrements, but aso
of the users themseves, ther tasks and envronments. Each have ther own attrbutes and
taken together are referred to as the context of use. They are detaed n the ISO standard
for user-centered desgn, descrbed beow.
Conte.ts of use
ISOs !uman-centered design processes for interactive systems |ISO13407| dentes the
rst step n desgn as understandng and specfyng the context of use. The attrbutes
suggested are:
Context Attributes
Tasks Goas of use of the system, frequency and
duraton of performance, heath and safety
consderatons, aocaton of actvtes,
operatona steps between human and
technoogca resources. Tasks shoud not
be descrbed soey n terms of the functons
or features provded by a product or
system.
Users (for each dherent type or
roe)
Knowedge, sk, experence, educaton,
tranng, physca attrbutes, habts,
preferences, capabtes.
Envronments Hardware, software, materas; physca and
soca envronments, reevant standards,
technca envronment, ambent
envronment, egsatve envronment, soca
and cutura envronment
Ta*le @/ Conte7t o& use &rom <#; standard &or user%centered design
It s usefu to spt the user context nto ts two consttuent parts (user type and roe) and
then to consder the reatonshps between a four contexts:
igure ?/ "elationshi's *etween conte7ts
Fgure 2 shows that every tas" s performed n a role taken by a user wthn an environment.
These contexts correspond to the RUP artfacts as shown n Tabe 4.
<#; 8@A9B Conte7tthe "!P Arti&act
Envronments Hgh-eve:
Busness Vson |Secton: Customer
Envronment|,
Stakehoder Requests,
Vson |Secton: User Envronment|
Users Hgh-eve:
Busness Vson |Secton: Customer
Proes|,
Stakehoder Requests,
Vson |Secton: User Proes|
Roes Hgh-eve:
Busness Actor (externa users),
Busness Worker (nterna users)
Detaed:
Actor
Tasks Hgh-eve:
Stakehoder Requests,
Vson |Secton: Product Features|
Detaed:
Use-Case Storyboard
Use Case
Ta*le A+ <#; user%centered design standard conte7ts and their the "!P arti&acts
Each of these contexts coud have a sgncant mpact on the desgn of an approprate user
nterface. As a resut we are faced wth a potentay arge number of permutatons. Even for
a sma system, there may be 2 envronments (e.g. omce and customer ste), 3 types of user
(saes novce, saes expert and management) and 6 roes (teephone saes assstant,
externa saes representatve, etc.). That means up to 36 potenta varatons per task,
athough the set of reastc combnatons s usuay much smaer.
Ceary tasks must be descrbed ndvduay, but a snge descrpton s unkey to be
approprate for a permutatons. One approach s to factor the user and envronment
contexts nto the roe descrpton. Ths s the souton adopted by Constantne and Lockwood
|CON99|. It nvoves provdng a separate "user roe" for each sgncant permutaton of roe,
user and envronment, then namng the resutng user roe wth a descrptve phrase, rather
that a smpe noun. Compare, for exampe, the roe "Customer" wth the user roes "Casua
Customer", "Web Customer", "Reguar Customer" and "Advanced Customer".
Each user roe descrpton ncudes detas of the roe tsef pus ts users (referred to as roe
ncumbents) and envronment. Ths approach can be adopted wth the RUP by choosng
actors that correspond to user roes.
Scenarios/ use cases/ and essential use cases
The terms scenaros, use cases and essenta use cases have a confusng degree of overap
and are used n dherent desgn approaches to mean sghty dherent thngs. For exampe,
wthn the RUP "scenaro" means a use-case nstance; smpy a specc "path" through the
possbe basc and aternatve ows. However, t s common to nd user-centered and user-
nterface desgn methods descrbng scenaros as stores of use, contanng substantay
more deta than |ust the ow of events. Whe ths addtona nformaton may be rreevant
n ater desgn phases, t does form part of the understandng of users, tasks and
envronments. Consequenty, scenaros may be used extensvey (n storyboardng and roe
payng) n the Busness Modeng dscpne, but the focus moves towards use cases n the
Requrements dscpne.
Fgure 3 shows the nature of ths overap. The scae at the top ncorporates a number of
dherent factors that tend to vary together. For exampe, as purpose moves more towards
requrements, structure usuay becomes more forma. Essenta use cases appear to the
rght of generc use cases because user roes make them sghty more specc (see the
precedng secton) and they have a more forma structure.
igure @/ ;verla' in conce'ts *etween scenarios and use cases in user%centered
design
The dherences between system use cases and essenta use cases are best ustrated by
exampe. Tabe 5 shows a use case from Constantne and Lockwood's Software for Use
|CON99|:
!ser Action #ystem "es'onse
nsert card
read magnetc strp
request pnt
enter PIN
verfy PIN
dspay transacton opton menu
press key
dspay account menu
press key
prompt for amount
enter amount
dspay amount
press key
return card
take card
dspense cash
take cash
Ta*le C/ Deneric use case &or getting cash &rom an ATM
Ths exampe detas the sequence of events between the actor and the system, wth the
vertca ne between the two coumns representng the user nterface. Notce that whe
Constantne and Lockwood recommend ths stye for essenta use cases, ths partcuar use
case s not an essenta one. The reason s that t based on the syntactc deta of the
nteracton. That s, ho# the nteracton takes pace. An essenta use case focuses on #hat
the nteracton s about (caed the semantcs). Tabe 6 s the essenta verson of the
nteracton.
!ser <ntention #ystem "es'onsi*ility
dentfy sef verfy dentty
oher choces
choose dspense cash
take cash
Ta*le E/ Essential use case &or getting cash &rom an ATM
Ths use case captures the essence of the gettng cash nteracton. The User Acton and
System Response headngs have been repaced by User Intenton and System Responsbty
to reect the change n emphass. Good nterface desgn centers on user goas and
ntentons; these are often hdden n conventona use cases. Essenta use cases are
partcuary usefu f:
there are few desgn constrants (e.g. the mped desgn constrant of usng bank
cards s fase)
the system mght be enhanced to use other means of dentcaton (such as some
knd of secure nternet access)
there s a desre to create Use Cases wthout desgn constrants, for potenta reuse n
pro|ects that ack these constrants.
However, essenta use cases do have ther drawbacks. Perfecty straghtforward use cases
such as that n Tabe 5 can be sub|ect to consderabe debate when t comes to dstng ther
essence. For exampe, does nsertng a card dentfy the customer or the account? In most
exstng ATMs, t s the ater athough Constantne and Lockwood have chosen to nterpret
ths as dentfyng the customer. Ths may have been a deberate decson n ght of newer
technoogy such as retna scannng and ngerprnt dentcaton, or t may have been an
oversght. The consequences n ths case s an addtona choce that has to be made by
customers who hod more than one account.
Another dmcuty that essenta use cases present s that they are not as sutabe for revew
wth end users and other stakehoders because of ther abstract nature. Part of ths probem
stems from havng to transate essenta use cases back to a concrete form representng
user actons. Ths can be done once a desgn mode s avaabe by wrtng scenaros that
descrbe the nteracton n concrete terms (smar n concept to a Use Case Reazaton,
athough concerned wth user-system nteracton rather than nterna ob|ect coaboraton).
In summary, budng essenta use cases may not a good dea f:
the user nterface technooges are ntentonay hghy constraned (e.g. the system
must accept bank cards)
the tme to requred for the users to understand the more abstract use cases s
outweghed by the expected benets.
+ssential use cases in the RUP
The RUP does not expcty refer to essenta use cases, but n the Actvty: Mode the User
Interface, essential use cases are used as a startng pont, then deveoped and augmented
wth usabty requrements to create use-case storyboards, as expaned n Gudenes: Use-
Case Storyboard.
#tart *y clari&ying the use case itsel& % not its user inter&ace, Start by keepng
the descrpton ndependent of the user nterface, especay f the use case s
unexpored. Then, ater on, as the use case s understood, the ow of events -
storyboard can be augmented wth user nterface and usabty aspects. $from
%uidelines& Use-Case 'toryboard(
Ths means removng a desgn or current mpementaton deta so that ony the semantcs -
the meanng of the nteracton - reman. Then, as varous desgn aternatves are expored,
syntactc deta - how the nteracton takes pace - s added to the essenta use case as a
type of reazaton. (Each aternatve desgn s, n ehect, a reazaton of the same essenta
use case.)
These use-case storyboards are used as nput to the Actvty: Prototype the User Interface to
deveop the user-nterface prototypes.
Requirements: "or%flo*
Problem
Topics
Purpose
How to Stah
Work
Gudenes
Purpose Top Top
The purpose of ths workow deta s to:
Gan agreement on the probem beng soved,
Identfy stakehoders,
Dene the system boundares, and
Identfy constrants mposed on the system
The rst step n any probem anayss s to make sure that a partes nvoved agree on what
s the probem that we are tryng to sove wth our system. In order to avod
msunderstandngs, t s mportant to agree on common termnoogy whch w be used
throughout the pro|ect. Eary on, we shoud begn denng our pro|ect terms n a gossary
whch w be mantaned throughout the pro|ect fecyce.
In order to fuy understand the probem(s) we shoud be addressng, t s very mportant to
know who are our stakehoders. Note that some of these stakehoders -- the users of the
system -- w be represented by actors n our use-case mode.
The Requrements Management Pan w provde gudance on the requrements artfacts that
shoud be deveoped, the types of requrements that shoud be managed for the pro|ect, the
requrements attrbutes that shoud be coected and the requrements traceabty that w
be used n managng the product requrements.
The prmary artfact n whch we document the probem anayss nformaton s the Vson
document, whch dentes the hgh-eve user or customer vew of the system to be but. In
the Vson, nta hgh-eve requrements dentfy the key features t s desred the
approprate souton w provde. These are typcay expressed as a set of hgh-eve
features the system mght possess n order to sove the most crtca probems.
Key stakehoders shoud be nvoved n gatherng the set of features to be consdered, whch
mght be gathered n a Requrements Workshop. The features shoud be assgned attrbutes
such as ratonae, reatve vaue or prorty, source of request and so on, so that
dependences can begn to be managed.
To determne the nta scope for our pro|ect, the boundares of the system must be agreed
upon. The system anayst dentes users and systems - represented by actors - whch w
nteract wth the system.
If you have deveoped a doman mode, a busness use-case mode or a busness ob|ect
mode, these w be key nput, aong wth the busness rues, to hepng to perform ths
anayss. See aso Gudenes: Gong from Busness Modes to Systems for more gudance.
Ths workow deta shoud be revsted severa tmes durng ncepton and eary eaboraton.
Then, throughout the fecyce of the pro|ect, t shoud be revsted as necessary whe
managng the nevtabe changes that w occur n our pro|ect, n order to ensure that we
contnue to address the correct probem(s).
0o* to Staff Top Top
The pro|ect members nvoved n anayzng the probem shoud be emcent factators and
have experence n technques for ndng the probem behnd the probem. Of course,
famarty wth the targeted technoogy s desrabe, but t s not essenta. Actve
nvovement form varous stakehoders to the pro|ect s requred.
"or% 1uidelines Top Top
The foowng are sampe technques that can be apped to nd the probem behnd the
probem:
Branstormng
Fshbone dagrams
Pareto dagrams
See aso:
Requrements: Overvew
Whte Paper: Appyng Requrements Management wth Use Cases
Gudenes: Gong from Busness Modes to Systems
"or%flo* Detail: Understand Sta%eholder &eeds
Topics
Purpose
How to Stah
Work
Gudenes
Purpose
The purpose of ths workow deta s to coect and ect nformaton from the stakehoders
of the pro|ect n order to understand what ther needs reay are. The coected stakehoder
requests can be regarded as a "wsh st" that w be used as prmary nput to denng the
hgh-eve features of our system, as descrbed n the Vson, whch drve the speccaton of
the software requrements, as descrbed n the use-case mode, use cases and
suppementary speccatons.
Typcay, ths actvty s many performed durng teratons n the ncepton and eaboraton
phases, however stakehoder requests shoud be gathered throughout the pro|ect by usng
Change Requests foowng the Change Request Management Process.
The key actvty s to ect stakehoder requests usng such nput as busness rues,
enhancement requests, ntervews and requrements workshops. The prmary outputs are
coecton(s) of prortzed features and ther crtca attrbutes, whch w be used n denng
the system and managng the scope of the system.
Ths nformaton resuts n a renement of the Vson document, as we as a better
understandng of the requrements attrbutes. Aso, durng ths workow deta you may start
dscussng the functona requrements of the system n terms of ts use cases and actors.
Those non-functona requrements, whch do not t easy nto the use-case mode, shoud
be documented n the Suppementary Speccatons.
Another mportant output s an updated Gossary of terms to factate common vocabuary
among team members.
0o* to Staff Top Top
The pro|ect members nvoved n understandng stakehoder needs shoud be emcent
factators and have experence n ectng nformaton. Of course, famarty wth the
targeted technoogy s desrabe, but t s not essenta.
"or% 1uidelines Top Top
The foowng are sampe technques that can be apped to make sure you coect the
correct and reevant nformaton from the stakehoders:
Intervews
Requrements Workshop
Bran-stormng and dea reducton
Use-Case Workshop
Storyboardng
Roe payng
Revew of exstng requrements
See aso:
Requrements: Overvew
Whte Paper: Appyng Requrements Management wth Use Cases
Concepts: User-Centered Desgn
"or%flo* Detail: Define the System
Topics
Purpose
How to Stah
Work
Gudenes
Purpose
The purpose of ths workow deta s to:
Agn the pro|ect team n ther understandng of the system.
Perform a hgh-eve anayss on the resuts of coectng stakehoder requests.
Rene the Vson to ncude the features to ncude n the system, aong wth
approprate attrbutes.
Rene the use-case mode, to ncude outned use cases.
More formay document the resuts n modes and documents.
Probem Anayss and actvtes for Understandng Stakehoder Needs create eary teratons
of key system dentons, ncudng the features dened n the Vson document, a rst
outne to the use-case mode and the Requrements Attrbutes. In Denng the System you
w focus on dentfyng actors and use cases more competey, and expand the goba non-
functona requrements as dened n the Suppementary Speccatons.
If you have deveoped a busness use-case mode and busness ob|ect mode, see aso
Gudenes: Gong from Busness Modes to Systems for more gudance.
Typcay, ths s prmary performed n teratons durng the ncepton and eaboraton
phases, however t may be revsted as needed when managng scope and respondng to
changng requrements, as we as other changng condtons.
0o* to Staff Top Top
A members of the pro|ect team shoud partcpate.
"or% 1uidelines Top Top
The foowng are sampe technques that can be apped:
Requrements Workshop
Use-Case Workshop
Storyboardng
"or%flo* Detail: !anae the Scope of the System
Topics
Purpose
How to Stah
Work
Gudenes
Purpose
The purpose of ths workow deta s to:
Prortze and rene nput to the seecton of features and requrements that are to be
ncuded n the current teraton.
Dene the set of use cases (or scenaros) that represent some sgncant, centra
functonaty.
Dene whch requrement attrbutes and traceabtes to mantan.
The scope of a pro|ect s dened by the set of requrements aocated to t. Managng pro|ect
scope to t the avaabe resources (tme, peope, and money) s key to managng successfu
pro|ects. Managng scope s a contnuous actvty that requres teratve or ncrementa
deveopment, whch breaks pro|ect scope nto smaer more manageabe peces.
Usng requrement attrbutes, such as prorty, ehort, and rsk, as the bass for negotatng
the ncuson of a requrement s a partcuary usefu technque for managng scope.
Focusng on the attrbutes rather than the requrements themseves heps desenstze
negotatons that are otherwse contentous.
It s aso hepfu for team eaders to be traned n negotaton sks and for the pro|ect to
have a champon n the organzaton, as we as on the customer sde. Product/pro|ect
champons shoud have the organzatona power to refuse scope changes beyond the
avaabe resources or to expand resources to accommodate addtona scope.
Pro|ect scope shoud be managed contnuousy throughout the pro|ect. A better
understandng of system functonaty s obtaned from dentfyng most actors and use
cases. Non-functona requrements, whch do not t n the use-case mode, shoud be
documented n the Suppementary Speccatons. The system anayst shoud determne
vaues of prorty, ehort, cost, rsk vaues etc., from the approprate stakehoders, to coect
n the repostory of requrements attrbutes. These w be used by the Pro|ect Manager n
pannng the teratons and enabes the software archtect to dentfy the archtecturay
sgncant use cases, denng the use-case vew of the archtecture n the Software
Archtecture Document.
0o* to Staff Top Top
The peope nvoved n ths workow deta shoud a be members of the archtecture team.
"or% 1uidelines Top Top
The archtecture team w ead a sesson to dscuss how to best prortze the requrements.
Topics
Purpose
How to Stah
Work
Gudenes
Requirements: $cti,ity O,er,ie*
Requirements: $rtifact O,er,ie*
The roes and the artfacts deveoped n the Requrements dscpne.
Requirements: 1uidelines O,er,ie*
Use Case
Actvty Dagram n the Use-Case Mode
Actor
Use-Case Mode
Actor-Generazaton
Communcate-Assocaton
Extend-Reatonshp
Incude-Reatonshp
Use-Case-Generazaton
Use-Case Dagram
Requrements Management Pan
Use-Case Package
Software Archtecture Document
Software Requrements Speccaton
Boundary Cass
Use-Case Storyboard
User Interface (Genera)