Modeling

Business Modeling: Overview

Introduction to Business Modeling
Purpose
Relation to Other Disciplines
Concepts
Scope of Business Modeling
Activity-Based Costing
Business Architecture
Business Patterns
e-Business Development
Modeling Large Organiations
Purpose
!he purposes of "usiness modeling are#
!o understand the structure and the dynamics of the organiation in $hich a system
is to "e deployed %the target organiation&'
!o understand current pro"lems in the target organiation and identify improvement
potentials'
!o ensure that customers( end users( and developers have a common understanding
of the target organiation'
!o derive the system re)uirements needed to support the target organiation'
!o achieve these goals( the "usiness modeling discipline descri"es ho$ to develop a vision
of the ne$ target organiation( and "ased on this vision de*ne the processes( roles( and
responsi"ilities of that organiation in a "usiness use-case model and a "usiness o"+ect
model'
Complementary to these models( the follo$ing artifacts are developed#
Supplementary Business Speci*cation
,lossary
Relation to Other Disciplines
!he "usiness modeling discipline is related to other disciplines( as follo$s#
!he Requirements discipline uses "usiness models as an important input to
understanding re)uirements on the system'
!he Analysis & Design discipline uses "usiness entities as an input to identifying
entity classes in the design model'
!he Environment discipline develops and maintains supporting artifacts(
such as the Business-Modeling ,uidelines'
Business Modeling : Concepts
Scope of Business Modeling
Activity-Based Costing
Business Architecture
Business Patterns
e-Business Development
Modeling Large Organiations
Costing
Concepts: Activity-Based Costing
Topics
-ntroduction
Calculating the performance of a "usiness process
-dentifying areas of improvement
.ote# Portions of this content are dra$n from the user/s guide for the Rational Rose Activity-
Based Costing Lin0( a product developed and sold "y 1nsem"le Systems
%http#22$$$'ensem"le-systems'com2&'
Introduction Top Top
Activity-based costing (ABC) is a methodology that measures the cost and performance
of activities( resources( and cost o"+ects' Resources are assigned to activities( then activities
are assigned to cost o"+ects "ased on their use' Activity-"ased costing recognies the causal
relationships of cost drivers to activities 3PLR445'
Activity-"ased costing is a"out#
Measuring "usiness process performance( activity "y activity'
1stimating the cost of "usiness process outputs "ased on the cost of the resources
used in producing the product'
-dentifying opportunities to improve process e6ciency and e7ectiveness' Activity
costs are used as the )uantitative measurement' -f activities have unusually high
costs or it they don/t add value( they "ecome targets for re-engineering'
Activity-based management (ABM) is a "road discipline that focuses on achieving
customer value and company pro*t "y managing activities' ABM dra$s on activity-"ased
costing as a ma+or source of information'
Calculating the Peror!ance o a Business Process Top Top
!o calculate the performance of a "usiness process( you need to 0no$ $hat the $or08o$ is
and $hat type of resources are involved in performing the $or08o$' 9ou need to have the
follo$ing elements descri"ing the $or08o$ in place "efore you can start measuring#
A description of the "usiness use case representing the "usiness process:see
,uidelines# Business ;se Case( and the sections on $or08o$'
One or more activity diagrams descri"ing the $or08o$:see ,uidelines# Activity
Diagram in the Business ;se-Case Model'
!he realiation of that "usiness use case:see ,uidelines# Business ;se-Case
Realiation'
Basic Cost Drivers
<or each activity state in an activity diagram( the "asic cost drivers are#
Resources: determine $hat "usiness $or0ers and "usiness entities are participating(
and ho$ many instances of each' !he allocation of a resource to a $or08o$ implies a
certain cost'
Cost rate: each "usiness $or0er or "usiness entity instance may have a cost per
time in use'
Duration: an activity occurs for a certain time( therefore a resource can either "e
allocated for the duration of the activity( or for a *=ed amount of time'
ver!ead: any *=ed costs that the invocation of a $or08o$ or an activity $ould
incur'
Additionally( for a transition you may need to determine the "uard #robability( $hich is
the pro"a"ility for a transition to "e traversed' !his needs to "e determined for alternative
threads such as outgoing transitions from a decision( and for conditional threads such as a
conditional transition outgoing from a synchroniation "ar'
Calculating the Cost o Peror!ing a "or#low
A $or08o$ is descri"ed $ith a collection of activity states' <or each of those activity states(
you must de*ne $hat the cost drivers are( in order to calculate the total cost for performing
the activity'
1=ample#
!he total cost of performing this activity is /num"er of resources/ > /resource cost/ > /
duration/ ? /overhead cost/' @no$ing that the cost rate for using a customer representative
is ABB per hour( the total cost for this activity is then C>ABB>B'D ? CBBEABB'
!he total cost of performing the $or08o$ is the sum of the cost for each activity( although
there is often an overhead associated $ith initiating the $or08o$' <or the $hole $or08o$( it
may "e interesting to calculate the total duration or fre)uency'
1=ample#
!he $or08o$ depicted in this activity graph has an overhead cost that needs to "e added to
the cost of performing each activity'
Concurrent Threads
-f concurrent threads e=ist in an activity diagram( the duration of the longest thread is the
relevant duration for all threads' Concurrent threads are sho$n using synchroniation "ars'
1=ample#
!he total duration for these t$o concurrent threads is F minutes( $hich is the duration of the
longest thread in this case'
Alternative Threads
-f alternative threads e=ist in an activity diagram( the cost for the alternative threads are
calculated as the sum of the cost for each alternative( $eighted $ith the occurrence
pro"a"ility for each alternative' Alternative threads are sho$n using decision icons'
1=ample#
!he total calculated cost for a thread $ith alternatives is the $eighted cost of the alternative
threads'
Conditional Threads
-f a conditional thread e=ists( the cost for that thread is added to the cost for its parallel
threads( $eighted $ith the pro"a"ility of it occurring' A conditional thread is indicated $ith a
guard condition on a transition'
1=ample#
-f there is a conditional thread( its cost is *rst $eighted $ith the pro"a"ility of it occurring(
and then added to the cost of its parallel threads'
$ested Activity %raphs
-f an activity has a su"-graph( the cost of that activity is the cost of the activities in the su"-
graph'
Identiying Areas o I!prove!ent TopTop
Activity-"ased costing is often used to compare alternatives( such as proposed change
versus current practice( or to compare di7erent proposed changes' !here are three 0inds of
parameters to $or0 $ith to e=plore di7erences "et$een alternative 8o$s#
Changing values of cost attri"utes $ithout changing the structure or realiation of the
$or08o$G for e=ample( assuming shorter time durations'
Changing structure of the $or08o$G for e=ample( changing from se)uential to
concurrent e=ecution of activities'
Changing $hat resources are used in the realiation of the $or08o$G for e=ample(
merging resources to eliminate hand-o7s'
!o compare these alternatives( you may create Hsi"lingH activity diagrams to sho$ the
variations of the "usiness use case' Ihen changing $hat resources are used in the
realiation of the $or08o$( you must also esta"lish Hsi"lingH realiations of the $or08o$s to
correctly e=plore resource costs'
Concepts: Business Architecture
Ie de*ne "usiness architecture as an organied set of elements $ith clear relationships to
one another( $hich together form a $hole de*ned "y its functionality' !he elements
represent the organiational and "ehavioral structure of a "usiness 3system5( and sho$
a"stractions of the 0ey processes and structures of the "usiness' 3.DL4J5( 31R-BB5
!he intent of de*ning architecture is not to "e complete( "ut to cover the "readth of the
organiation' Similarly to ho$ $e de*ne soft$are architecture( see Concepts# Soft$are
Architecture( $e can tal0 a"out architectural vie$s of the "usiness' 1ach of these vie$s
contains an architecturally signi*cant su"set of $hat $ould "e a complete de*nition' A set of
vie$s could "e#
Business process vie$:includes and outlines the 0ey "usiness processes of the
"usiness( those that are the reason the "usiness e=ist'
Organiation structure vie$:outlines the 0ey roles and responsi"ilities in the
"usiness( as $ell as their grouping'
Culture vie$:e=presses a vision of the organiationKs culture( and de*nes the
mechanisms put in place to encourage that culture'
Luman resource aspects vie$:discusses the mechanisms put in place to maintain
and develop the s0ill set of your sta7'
Domain vie$ %optional&:for organiations that handle a comple= set of information( it
is often useful to de*ne 0ey mechanisms and patterns to "e applied to those
information structures' -n simple cases( this may already "e clear from the
organiation structure vie$'
Patterns
Concepts: Business Patterns
Ie de*ne a "usiness pattern as generalied solutions that can "e implemented and applied
in a pro"lem situation %a conte=t&( and there"y eliminate one or more of the inherent
pro"lems' Patterns can "e considered prototypes for production' 31R-BB5
Patterns are part of ho$ you de*ne your "usiness architecture#
!hey re8ect common solutions to common pro"lems'
Patterns help maintain an architectural style throughout the organiation'
!hey are a simple $ay of capturing e=periences'
Ie present a fe$ patterns that can "e useful as a "aseline#
Process evaluation pattern
Process feed"ac0 pattern
Activity interaction pattern
Business event-result history pattern
All of these patterns are "ased on the e=tensive pattern collection in 31R-BB5'
Process &valuation Pattern Top Top
Conte$t# !his pattern is a si"ling to the process feed"ac0 pattern' -t re8ects a need to plan
for more strategic and long-term investments $hen improving a process'
#roblem# !he process evaluation pattern can "e applied to all situations $here the "usiness
process results must "e evaluated to provide a competitive edge' Manufacturing( mar0eting(
and sales processes are e=amples of the di7erent "usiness processes that must "e
evaluated each time they are e=ecuted'
%olution# A solution to this pro"lem is to have an evaluation process in place that
continuously monitors and suggests improvements( "oth long-term and short term( to a
"usiness process'
Participants of the process evaluation pattern
&ist o' (artici(ants:
aBusiness Actor:A consumer of the "usiness'
Core Process:A "usiness process $hich has the primary purpose to ful*ll a need of the
consumer'
1valuate Core Process%es&:A "usiness process $hit the primary purpose of monitoring one
or more core processes to propose improvements to ma0e them more e6cient'
Dynamic vie$ of the process evaluation pattern' <or each core "usiness process( a
supporting "usiness process that evaluates and improves it should e=ist' !his evaluation
process needs to interact $ith the "usiness actor involved in the "asic process'
!his pattern has no static vie$'
Process 'eed(ac# Pattern TopTop
Conte$t# !he process feed"ac0 pattern can "e applied to all situations $here the "usiness
process results must "e evaluated to provide a competitive edge' Manufacturing( mar0eting(
and sales processes are e=amples of the di7erent "usiness processes that must "e
evaluated each time they are e=ecuted' <or e=ample( if the sales process is evaluated each
time itKs e=ecuted( the sales "udget can "e increased or decreased "ased on feed"ac0 from
the sales channels'
#roblem# A process starts $ith an input and ends $ith an output' !he process uses and
consumes resources to create and re*ne other resources that "ecome the output' A process
also has a certain goal to achieve( $hich can "e e=pressed in the num"er of resources that
are output from the process' -f resources are not used e7ectively( it may "ecome too
e=pensive to produce the outputs of the process( $hich $ould ena"le competitors to gain
mar0et shares'
%olution# A solution to this pro"lem is to measure the e7ectiveness of the process( and at
each initiation of a ne$ instance of the process( perform a fe$ steps to evaluate ho$ the
process can "e improved the ne=t time'
Participants of the process feed"ac0 pattern
&ist o' (artici(ants:
aBusiness Ior0er:A role including the set of responsi"ilities needed to re*ne the process
delivera"le'
aDelivera"le:!his is the delivera"le of the process( $hich changes state as the "usiness
$or0er manipulates it'
Metrics of aDelivera"le:!his is the metrics collected to sho$ the state changes of the
process delivera"le( and also ho$ the "usiness $or0er performs'
Static vie$ of the process feed"ac0 pattern
Dynamic vie$ of the process feed"ac0 pattern
Activity Interaction Pattern Top Top
Conte$t# !he activity interaction pattern can "e used $herever comple= interactions
"et$een activities $ithin a "usiness process are modeled'
#roblem# Activities may share resources $ith one another( typically "y $ay of data
transmission'
%olution# !he activity interaction pattern can "e used to model and organie comple=
interactions "et$een "usiness resources'
Participants of the activity interaction pattern
&ist o' (artici(ants:
aBusinessIor0er:One of the "usiness $or0ers participating in the realiation of the
process'
anotherBusinessIor0er:Another of the "usiness $or0ers participating in the realiation of
the process'
do!hing:Activity performed "y an instance of aBusinessIor0er'
doOther!hing:Activity performed "y an instance of anotherBusinessIor0er'
aDelivera"le:Ihat is produced or maintained "y the process'
Dynamic vie$ of the activity interaction pattern:Resource A and resource B use the same
shared o"+ect'
!his pattern has no static vie$'
Business &vent-Result )istory Pattern Top Top
Conte$t# !he "usiness event-result history pattern is suita"le for pro"lem domains $here
you need to maintain a history of "usiness events and their results' -t is most often used to
model *nancial systems and enterprise resource planning %1RP& systems'
#roblem# !he "usiness event-result history pattern is use to trac0 signi*cant "usiness
events and then to connect these events to their results' Capturing the di7erent "usiness
events( along $ith their results:such as decisions( contracts( statements( or products:
helps you ma0e "etter "usiness decisions' !he goal of this pattern is to ena"le you to 0eep a
record of all important "usiness events( $hich are typically descri"ed $ith attri"utes such as
description( purpose( and result'
%olution# ;sing the "usiness event-results history pattern ensures that models produced to
trac0 important "usiness events and their causes are e=tensi"le' 1=tensi"le means that ne$
0inds of events and causes can "e added at a later date to the same overall structure' ;sing
this pattern ma0es it possi"le to record "usiness events and( at a later point in time( to
analye these events and dra$ conclusions' !hese conclusions typically lead to activities or
decisions in the "usiness( such as to discontinue a relationship $ith a customer or vendor
"ecause of poor payment history' -f no record of "usiness events is maintained( no history is
availa"le to learn from and the same mista0es may "e repeated over and over again' One
potential pro"lem $ith this pattern is $hen too many lo$-level "usiness events are
recorded( the amount of detail ma0es the record hard to analye and evaluate' 1vents
should "e de*ned so theyKre easy to understand in a "usiness conte=tG for e=ample( order
placed( product delivered( invoice paid( and so on'
Participants of the "usiness event-result history pattern
&ist o' (artici(ants:
Business 1vent:!his "usiness entity descri"es signi*cant occurrences to the "usiness'
1=amples of attri"utes to a Business 1vent could "e date( priority( description( and type'
Common types are delivery( contract signing( and purchase'
Product:!his "usiness entity represents the delivera"les' Products can "e a"stract o"+ects(
such as a service( "usiness e7ort or mar0et share or physical o"+ects such as soft$are and
hard$are' Common attri"utes are identi*er and name' Common types of products are
computer program( support( consultation( and installation'
Party:!his "usiness entity may represent either individuals or companies' !he parties play
a role in the conte=t of a Contract' !ypical roles are seller and "uyer' Party typically has the
attri"utes name and address'
Contract:!his "usiness entity represents a deal or a decision' !he Contract de*nes the
circumstances of a delivery( $here the delivery is a Product' !he Contract is usually "et$een
a seller and a "uyer( "ut it can also "e "et$een other parties' Common attri"utes are
description( date and until-date' Contracts can "e associated $ith each otherG for e=ample(
one contract can "e complimentary to another contract' !his is also sho$n $ith the
recursive association' 1=amples of types of contracts are s0eleton contract or lease contract'
Statement:A Statement e=presses a Contract' A Statement can e=press many contracts
and a contract can "e stated many times' !ypical attri"utes are description and date'
Statements can also "e associated $ith each other' !his is sho$n $ith the recursive
association' 1=amples of types of statements are $ritten statements and ver"al statements'
!he static vie$ of the "usiness event-result history pattern
!his pattern has no dynamic vie$'
Re*uire!ents: Contenido
re)uirem2inMre)'htmre)uirem2inMre)'htm re)uirem2$fdMre)'htmre)uirem2$fdMre)'htm re)uire
m2$fovMre)'htmre)uirem2$fovMre)'htm re)uirem2r)Mresov'htmre)uirem2r)Mresov'htm re)uire
m2mdovMre)'htmre)uirem2mdovMre)'htm re)uirem2cosMre)'htmre)uirem2cosMre)'htm
Disciplines > Requirements > Introduction
Introduction to Re*uire!ents
Purpose
Relation to Other Disciplines
Concepts
Re)uirements
Re)uirements Management
!ypes of Re)uirements
!racea"ility
;ser-Centered Design
;se-Case Nie$
Purpose TopTop
!he purpose of the Re)uirements discipline is#
!o esta"lish and maintain agreement $ith the customers and other sta0eholders
on $hat the system should do'
!o provide system developers $ith a "etter understanding of the system
re)uirements'
!o de*ne the "oundaries of %delimit& the system'
!o provide a "asis for planning the technical contents of iterations'
!o provide a "asis for estimating cost and time to develop the system'
!o de*ne a user-interface for the system( focusing on the needs and goals of the
users'
!o achieve these goals( it is important( *rst of all( to understand the de*nition and scope
of the pro"lem $hich $e are trying to solve $ith this system' !he Business Rules(
Business ;se-Case Model and Business O"+ect Model developed during Business
Modeling $ill serve as valua"le input to this e7ort' Sta0eholders are identi*ed and
Sta0eholder Re)uests are elicited( gathered and analyed'
A Nision document( a use-case model( use cases and Supplementary Speci*cation are
developed to fully descri"e the system - )!at the system $ill do - in an e7ort that
vie$s all sta0eholders( including customers and potential users( as important sources of
information %in addition to system re)uirements&'
Sta0eholder Re)uests are "oth actively elicited and gathered from e=isting sources to
get a H$ish listH of $hat di7erent sta0eholders of the pro+ect %customers( users( product
champions& e=pect or desire the system to include( together $ith information on ho$
each re)uest has "een considered "y the pro+ect'
!he Nision document provides a complete vision for the soft$are system under
development and supports the contract "et$een the funding authority and the
development organiation' 1very pro+ect needs a source for capturing the e=pectations
among sta0eholders' !he vision document is $ritten from the customers/ perspective(
focusing on the essential features of the system and accepta"le levels of )uality' !he
Nision should include a description of $hat features $ill "e included as $ell as those
considered "ut not included' -t should also specify operational capacities %volumes(
response times( accuracies&( user pro*les %$ho $ill "e using the system&( and inter-
operational interfaces $ith entities outside the system "oundary( $here applica"le' !he
Nision document provides the contractual "asis for the re)uirements visi"le to the
sta0eholders'
!he use-case model should serve as a communication medium and can serve as a
contract "et$een the customer( the users( and the system developers on the
functionality of the system( $hich allo$s#
'
'
O
'
'
O
'
'
O
i
n
d
e
=
'
h
t
m
+
a
v
a
s
c
r
i
p
t
#
l
o
a
d
!
o
p
%
&
G
+
a
v
a
s
c
r
i
p
Customers and users to validate that the system $ill "ecome $hat they
e=pected'
System developers to "uild $hat is e=pected'
!he use-case model consists of use cases and actors' 1ach use case in the model is
descri"ed in detail( sho$ing step-"y-step ho$ the system interacts $ith the actors( and
$hat the system does in the use case' ;se cases function as a unifying thread
throughout the soft$are lifecycleG the same use-case model is used in system analysis(
design( implementation( and testing'
!he Supplementary Speci*cations are an important complement to the use-case model(
"ecause together they capture all soft$are re)uirements %functional and nonfunctional&
that need to "e descri"ed to serve as a complete soft$are re)uirements speci*cation'
A complete de*nition of the soft$are re)uirements descri"ed in the use cases and
Supplementary Speci*cations may "e pac0aged together to de*ne a Soft$are
Re)uirements Speci*cation %SRS& for a particular HfeatureH or other su"system grouping'
A Re)uirements Management Plan speci*es the information and control mechanisms
$hich $ill "e collected and used for measuring( reporting( and controlling changes to
the product re)uirements'
Complementary to the a"ove mentioned artifacts( the follo$ing artifacts are also
developed#
,lossary
;se-Case Story"oard
;ser--nterface Prototype
!he ,lossary is important "ecause it de*nes a common terminology $hich is used
consistently across the pro+ect or organiation'
!he ;se-Case Story"oard and ;ser--nterface Prototype are all results of user-interface
modeling and prototyping( $hich are done in parallel $ith other re)uirements activities'
!hese artifacts provide important feed"ac0 mechanisms in later iterations for
discovering un0no$n or unclear re)uirements'
Relation to Other Disciplines TopTop
!he Re)uirements discipline is related to other process disciplines'
!he Business Modeling discipline provides Business Rules( a Business ;se-
Case Model and a Business O"+ect Model( including a Domain Model and an
organiational conte=t for the system'
!he Analysis & Design discipline gets its primary input %the use-case model
and the ,lossary& from Re)uirements' <la$s in the use-case model can "e
discovered during analysis P designG change re)uests are then generated( and
applied to the use-case model'
!he *est discipline tests the system to verify the code against the ;se-Case
Model' ;se Cases and Supplementary Speci*cations provide input on
re)uirements used in planning and designing tests'
!he Con+guration & C!ange Management discipline provides the change
control mechanism for re)uirements' !he mechanism for proposing a change is
to su"mit a Change Re)uest( $hich is revie$ed "y the Change Control Board'
!he #ro,ect Management discipline plans the pro+ect and each iteration
%descri"ed in an -teration Plan&' !he use-case model and Re)uirements
Management Plan are important inputs to the iteration planning activities'
!he Environment discipline develops and maintains the supporting artifacts
that are used during re)uirements management and use-case modeling( such as
the ;se-Case-Modeling ,uidelines and ;ser--nterface ,uidelines'
t
#
l
o
a
d
!
o
p
%
&
G
Rational Unified Process
Re*uire!ents: Concepts
Re)uirements
Re)uirements Management
!ypes of Re)uirements
!racea"ility
;ser-Centered Design
;se-Case Nie$
Concepts: Re*uire!ents
More information on this topic can "e found at#
Concepts# Re)uirements Management
Concepts# !ypes of Re)uirements
Concepts# !racea"ility
Concepts# ;ser-Centered Design
Ihite Paper# Applying Re)uirements Management $ith ;se Cases
A requirement is de*ned as Ha condition or capa"ility to $hich a system must conformH'
!here are many di7erent 0inds of re)uirements' One $ay of categoriing them is descri"ed
as the -.R#%/ model 3,RA4A5( using the acronym <;RPS to descri"e the ma+or categories
of re)uirements $ith su"categories as sho$n "elo$'
- unctionality
. sa"ility
R elia"ility
# erformance
% upporta"ility
!he H?H in <;RPS? reminds you to include such re)uirements as#
design constraints
implementation re)uirements
interface re)uirements
physical re)uirements'
%See also 3-111 Std QCB'CA'C44B5'&
-unctional requirements specify actions that a system must "e a"le to perform( $ithout
ta0ing physical constraints into consideration' !hese are often "est descri"ed in a use-case
model and in use cases' <unctional re)uirements thus specify the input and output "ehavior
of a system'
Re)uirements that are not functional( such as the ones listed "elo$( are sometimes called
non-'unctional requirements' Many re)uirements are non-functional( and descri"e only
attri"utes of the system or attri"utes of the system environment' Although some of these
may "e captured in use cases( those that cannot may "e speci*ed in Supplementary
Speci*cations' .onfunctional re)uirements are those that address issues such as those
descri"ed "elo$'
A complete de*nition of the soft$are re)uirements( use cases( and Supplementary
Speci*cations may "e pac0aged together to de*ne a %o't)are Requirements
%(eci+cation (%R%) for a particular HfeatureH or other su"system grouping'
'unctionality TopTop
<unctional re)uirements may include#
feature sets
capabilities
security
+sa(ility TopTop
;sa"ility re)uirements may include such su"categories as#
human factors %see Concepts# ;ser-Centered Design&
aesthetics
consistency in the user interface %see ,uidelines# ;ser--nterface&
online and conte=t-sensitive help
$iards and agents
user documentation
training materials
Relia(ility TopTop
Relia"ility re)uirements to "e considered are#
fre)uency and severity of failure
recovera"ility
predicta"ility
accuracy
mean time "et$een failure %M!B<&
Peror!ance TopTop
A performance re)uirement imposes conditions on functional re)uirements' <or e=ample( for
a given action( it may specify performance parameters for#
speed
e6ciency
availa"ility
accuracy
throughput
response time
recovery time
resource usage
,upporta(ility TopTop
Supporta"ility re)uirements may include#
testa"ility
e=tensi"ility
adapta"ility
maintaina"ility
compati"ility
con*gura"ility
servicea"ility
installa"ility
localia"ility %internationaliation&
Design Re*uire!ent TopTop
A design re)uirement( often called a design constraint( speci*es or constrains the design
of a system'
I!ple!entation Re*uire!ent TopTop
An implementation re)uirement speci*es or constrains the coding or construction of a
system' 1=amples are#
re)uired standards
implementation languages
policies for data"ase integrity
resource limits
operation environments
Interace Re*uire!ent TopTop
An interface re)uirement speci*es#
an e=ternal item $ith $hich a system must interact
constraints on formats( timings( or other factors used "y such an interaction
Physical Re*uire!ent TopTop
A physical re)uirement speci*es a physical characteristic that a system must possessG for
e=ample(
material
shape
sie
$eight
!his type of re)uirement can "e used to represent hard$are re)uirements( such as the
physical net$or0 con*gurations re)uired'
Concepts: Re*uire!ents Manage!ent
Ihat is Re)uirements ManagementR
Pro"lem analysis
;nderstanding sta0eholder needs
De*ning the system
Managing the scope of the pro+ect
Re*ning the system de*nition
Managing changing re)uirements
More -nformation# Concepts# Re)uirements
Concepts# !ypes of Re)uirements
Concepts# !racea"ility
Ihite Paper# Applying Re)uirements Management $ith ;se Cases
"hat is Re*uire!ents Manage!ent- TopTop
Re)uirements management is a systematic approach to *nding( documenting( organiing
and trac0ing the changing re)uirements of a system'
Ie de*ne a re)uirement as#
A condition or capability to which the system must conform.
Our formal de*nition of re)uirements management is that it is a systematic approach to
eliciting( organiing( and documenting the re)uirements of the system( and
esta"lishing and maintaining agreement "et$een the customer and the pro+ect team
on the changing re)uirements of the system'
@eys to e7ective re)uirements management include maintaining a clear statement of the
re)uirements( along $ith applica"le attri"utes for each re)uirement type and tracea"ility to
other re)uirements and other pro+ect artifacts'
Collecting re)uirements may sound li0e a rather straightfor$ard tas0' -n real pro+ects(
ho$ever( you $ill run into di6culties "ecause#
Re)uirements are not al$ays o"vious( and can come from many sources'
Re)uirements are not al$ays easy to e=press clearly in $ords'
!here are many di7erent types of re)uirements at di7erent levels of detail'
!he num"er of re)uirements can "ecome unmanagea"le if not controlled'
Re)uirements are related to one another and also to other delivera"les of the
soft$are engineering process'
Re)uirements have uni)ue properties or property values' <or e=ample( they are
neither e)ually important nor e)ually easy to meet'
!here are many interested parties( $hich means re)uirements need to "e managed
"y cross-functional groups of people'
Re)uirements change'
So( $hat s0ills do you need to develop in your organiation to help you manage these
di6cultiesR Ie have learned that the follo$ing s0ills are important to master#
Pro"lem analysis
;nderstanding sta0eholder needs
De*ning the system
Managing scope of the pro+ect
Re*ning the system de*nition
Managing changing re)uirements
Pro(le! Analysis TopTop
Pro"lem analysis is done to understand pro"lems( initial sta0eholder needs( and propose
high-level solutions' -t is an act of reasoning and analysis to *nd Hthe pro"lem "ehind the
pro"lemH' During pro"lem analysis( agreement is gained on the real pro"lem%s&( and $ho the
sta0eholders are' Also( you de*ne $hat from a "usiness perspective are the "oundaries of
the solution( as $ell as "usiness constraints on the solution' 9ou should also have analyed
the "usiness case for the pro+ect so that there is a good understanding of $hat return is
e=pected on the investment made in the system "eing "uilt'
See also Ior08o$ Detail# Analye the Pro"lem'
+nderstanding ,ta#eholder $eeds TopTop
Re)uirements come from many sources( e=amples $ould "e customers( partners( end users(
and domain e=perts' 9ou need to 0no$ ho$ to "est determine $hat the sources should "e(
get access to those sources( and also ho$ to "est elicit information from them' !he
individuals $ho provide the primary sources for this information are referred to as
sta0eholders in the pro+ect' -f youKre developing an information system to "e used internally
$ithin your company( you may include people $ith end user e=perience and "usiness
domain e=pertise in your development team' Nery often you $ill start the discussions at a
"usiness model level rather than a system level' -f youKre developing a product to "e sold to
a mar0et place( you may ma0e e=tensive use of your mar0eting people to "etter understand
the needs of customers in that mar0et'
1licitation activities may occur using techni)ues such as intervie$s( "rainstorming(
conceptual prototyping( )uestionnaires( and competitive analysis' !he result of the
elicitation $ould "e a list of re)uests or needs that are descri"ed te=tually and graphically(
and that have "een given priority relative one another'
See also Ior08o$ Detail# ;nderstand Sta0eholder .eeds'
Deining the ,yste! TopTop
!o de*ne the system means to translate and organie the understanding of sta0eholder
needs into a meaningful description of the system to "e "uilt' 1arly in system de*nition(
decisions are made on $hat constitutes a re)uirement( documentation format( language
formality( degree of re)uirements speci*city %ho$ many and in $hat detail&( re)uest priority
and estimated e7ort %t$o very di7erent valuations usually assigned "y di7erent people in
separate e=ercises&( technical and management ris0s( and initial scope' Part of this activity
may include early prototypes and design models directly related to the most important
sta0eholder re)uests' !he outcome of system de*nition is a description of the system that is
"oth natural language and graphical'
See also Ior08o$ Detail# De*ne the System'
Managing the ,cope o the Pro.ect TopTop
!o e6ciently run a pro+ect( you need to carefully prioritie the re)uirements( "ased on input
from all sta0eholders( and manage its scope' !oo many pro+ects su7er from developers
$or0ing on so called H1aster eggsH %features the developer *nds interesting and
challenging&( rather than early focusing on tas0s that mitigate a ris0 in the pro+ect or
sta"ilie the architecture of the application' !o ma0e sure that you resolve or mitigate ris0s
in a pro+ect as early as possi"le( you should develop your system incrementally( carefully
choosing re)uirements to for each increment that mitigates 0no$n ris0s in the pro+ect' !o do
so( you need to negotiate the scope %of each iteration& $ith the sta0eholders of the pro+ect'
!his typically re)uires good s0ills in managing e=pectations of the output from the pro+ect in
its di7erent phases' 9ou also need to have control of the sources of re)uirements( of ho$ the
delivera"les of the pro+ect loo0( as $ell as the development process itself'
See also Ior08o$ Detail# Manage the Scope of the System'
Reining the ,yste! Deinition TopTop
!he detailed de*nition of the system needs to "e presented in such a $ay that your
sta0eholders can understand( agree to( and sign o7 on them' -t needs to cover not only
functionality( "ut also compliance $ith any legal or regulatory re)uirements( usa"ility(
relia"ility( performance( supporta"ility( and maintaina"ility' An error often committed is to
"elieve that $hat you feel is comple= to "uild needs to have a comple= de*nition' !his leads
to di6culties in e=plaining the purpose of the pro+ect and the system' People may "e
impressed( "ut they $ill not give good input since they donKt understand' 9ou should put lots
e7ort in understanding the audience for the documents you are producing to descri"e the
system' 9ou may often see a need to produce di7erent 0inds of description for di7erent
audiences'
Ie have seen that the use-case methodology( often in com"ination $ith simple visual
prototypes( is a very e6cient $ay of communicating the purpose of the system and de*ning
the details of the system' ;se cases help put re)uirements into a conte=t( they tell a story of
ho$ the system $ill "e used'
Another component of the detailed de*nition of the system is to state ho$ the system
should "e tested' !est plans and de*nitions of $hat tests to perform tells us $hat system
capa"ilities $ill "e veri*ed'
See also Ior08o$ Detail# Re*ne the System De*nition'
Managing Changing Re*uire!ents TopTop
.o matter ho$ careful you are a"out de*ning your re)uirements( there $ill al$ays "e things
that change' Ihat ma0es changing re)uirements comple= to manage is not only that a
changed re)uirement means that more or less time has to "e spent on implementing a
particular ne$ feature( "ut also that a change to one re)uirement may have an impact on
other re)uirements' 9ou need to ma0e sure that you give your re)uirements a structure that
is resilient to changes( and that you use tracea"ility lin0s to represent dependencies
"et$een re)uirements and other artifacts of the development lifecycle' Managing change
include activities li0e esta"lishing a "aseline( determining $hich dependencies are important
to trace( esta"lishing tracea"ility "et$een related items( and change control'
See also Ior08o$ Detail# Manage Changing Re)uirements'
Concepts: Traceability
Introduction
*raceability is t!e ability to trace a (ro,ect element to ot!er related (ro,ect
elements0 es(ecially t!ose related to requirements1 #ro,ect elements involved in
traceability are called traceability items1 *y(ical traceability items include
di2erent ty(es o' requirements0 analysis and design model elements0 testing
arti'acts (test cases0 test (rocedures0 etc1)0 and end-user su((ort documentation
and training material0 as s!o)n in t!e +gure belo)1
*!e traceability !ierarc!y1
Eac! traceability item !as its o)n unique set o' associated attributes0 )!ic! is
use'ul 'or trac3ing t!e status0 bene+t0 ris30 etc1 associated )it! eac! item1
Purpose of Traceability
*!e (ur(ose o' establis!ing traceability is to !el(:
.nderstand t!e source o' requirements
Manage t!e sco(e o' t!e (ro,ect
Manage c!anges to requirements
Assess t!e (ro,ect im(act o' a c!ange in a requirement
Assess t!e im(act o' a 'ailure o' a test on requirements (i1e1 i' test 'ails t!e
requirement may not be satis+ed)
4eri'y t!at all requirements o' t!e system are 'ul+lled by t!e
im(lementation1
4eri'y t!at t!e a((lication does only )!at it )as intended to do1
*raceability !el(s you understand and manage !o) in(ut to t!e requirements0
suc! as business rules and sta3e!older requests0 are translated into a set o' 3ey
sta3e!older5user needs and system 'eatures0 as s(eci+ed in t!e 4ision document1
*!e use-case model0 in turn0 outlines t!e !o) t!ese 'eatures are translated to t!e
'unctionality o' t!e system1 *!e details o' !o) t!e system interacts )it! t!e
outside )orld are ca(tured in use cases0 )it! ot!er im(ortant requirements (suc!
as non-'unctional requirements0 design constraints0 etc1) in t!e %u((lementary
%(eci+cations1 *raceability allo)s you to also 'ollo) !o) t!ese detailed
s(eci+cations are translated into a design0 !o) it is tested0 and !o) it is
documented 'or t!e user1 -or a large system0 use cases and %u((lementary
%(eci+cations may be (ac3aged toget!er to de+ne a %o't)are Requirements
%(eci+cation (%R%) 'or a (articular 6'eature6 or ot!er subsystem grou(ing1
A 3ey conce(t in !el(ing to manage c!anges in requirements is t!at o' a
6sus(ect6 traceability lin31 7!en a requirement (or ot!er traceability item)
c!anges at eit!er end o' a traceability lin30 all lin3s associated )it! t!at
requirement are mar3ed as 6sus(ect61 *!is 8ags t!e res(onsible role to revie)
t!e c!ange and determine i' t!e associated items )ill need to c!ange also1 *!is
conce(t also !el(s in analy9ing t!e im(act o' (otential c!anges1
*raceabilities may be set u( to !el( ans)er t!e 'ollo)ing sam(le set o' queries:
%!o) me user needs t!at are not lin3ed to (roduct 'eatures1
%!o) me t!e status o' tests on all use cases in iteration :n1
%!o) me all su((lementary requirements lin3ed to tests )!ose status is
untested1
%!o) me t!e results o' all tests t!at 'ailed0 in order o' criticality1
%!o) me t!e 'eatures sc!eduled 'or t!is release0 )!ic! user needs t!ey
satis'y0 and t!eir status1
E$am(le:
-or a Recycling Mac!ine system0 t!e 4ision document s(eci+es t!e 'ollo)ing
'eature:
-EA*;<:*!e recycling mac!ine )ill allo) t!e addition o' ne) bottle ty(es1
*!is 'eature is traced to a use case 6Add =e) Bottle *y(e6:
*!e use case Add =e) Bottle *y(e allo)s t!e (erator to teac! t!e
Recycling Mac!ine to recogni9e ne) 3inds o' bottles1
*!is traceability !el(s us veri'y t!at all 'eatures !ave been accounted 'or in use
cases and su((lementary s(eci+cations1
Typical Traceability
*!e most im(ortant traceability items are:
.ser5%ta3e!older =eeds ('rom 4ision0 may be 'urt!er traced to individual
%ta3e!older Requests)
#roduct -eature ('rom 4ision)1
%u((lementary Requirement ('rom %u((lementary %(eci+cations1)
.se Case
.se Case %ection (sections o' a detailed use case)1
Design Element ('rom t!e design model)1
*est Case (or ot!er element 'rom t!e test model)1
t!er elements0 suc! as Business Rules and >ssues may also be use'ul to trace1
A ty(ical traceability is s!o)n in t!e 'ollo)ing diagram:
*!is diagram only s!o)s traceability to requirements1 t!er traceability may e$ist
as )ell0 but is not s!o)n on t!is diagram: design elements trace do)n to
im(lementation com(onents0 t!ere are test cases 'or design and im(lementation0
etc
Concepts: Types o Re*uire!ents
More -nformation# Concepts# Re)uirements
Concepts# Re)uirements Management
Concepts# !racea"ility
Ihite Paper# Applying Re)uirements Management $ith ;se Cases
!raditionally( re)uirements are loo0ed upon as statements of te=t *tting into one of the
categories mentioned in Concepts# Re)uirements' 1ach re)uirement states Ha condition or
capa"ility to $hich the system must conformH'
!o perform e7ective re)uirements management( $e have learned that it helps to e=tend
$hat $e maintain as re)uirements "eyond only the detailed Hsoft$are re)uirementsH' Ie
introduce the notion of requirements ty(es to help separate the di7erent levels of
a"straction and purposes of our re)uirements'
Ie may $ant to 0eep trac0 of am"iguous H$ishesH( as $ell as formal re)uests( from our
sta0eholders to ma0e sure $e 0no$ ho$ they are ta0en care of' !he Nision document helps
us 0eep trac0 of 0ey Huser needsH and HfeaturesH of the system' !he use-case model is an
e7ective $ay of e=pressing detailed functional Hsoft$are re)uirementsH( therefore use cases
may need to "e trac0ed and maintained as re)uirements( as $ell as perhaps individual
statements $ithin the use case properties $hich state Hconditions or capa"ilities to $hich
the system must conformH' Supplementary Speci*cations may contain other Hsoft$are
re)uirementsH( such as design constraints or legal or regulatory re)uirements on our system'
<or a complete de*nition of the soft$are re)uirements( use cases and Supplementary
Speci*cations may "e pac0aged together to de*ne a %o't)are Requirements
%(eci+cation (%R%) for a particular HfeatureH or other su"system grouping'
!he larger and more intricate the system developed( the more e=pressions( or types of
re)uirements appear and the greater the volume of re)uirements' HBusiness rulesH and
HvisionH statements for a pro+ect trace to Huser needsH( HfeaturesH or other Hproduct
re)uirementsH' ;se cases or other forms of modeling and other Supplementary
Speci*cations drive design re)uirements( $hich may "e further decomposed to functional
and non-functional Hsoft$are re)uirementsH represented in analysis P design models and
diagrams'
Concepts: +se-Case /iew
!o provide a "asis for planning the technical contents of iterations( an architectural vie$
called the use-case vie) is used in the Re)uirements discipline' !here is only one use-case
vie$ of the system( $hich illustrates the use cases and scenarios that encompass
architecturally signi*cant "ehavior( classes( or technical ris0s' !he use-case vie$ is re*ned
and considered initially in each iteration'
!he use-case vie$ sho$s an architecturally signi*cant su"set of the use-case model( a
su"set of the use cases and actors'
!he analysis( design( and implementation activities su"se)uent to re)uirements are
centered on the notion of an arc!itecture' !he production and validation of that
architecture is the main focus of the early iterations( especially during the 1la"oration
phase' Architecture is represented "y a num"er of di7erent architectural vie$s( $hich in
their essence are e=tracts illustrating the Harchitecturally signi*cantH elements of the
models'
!here are four additional vie$s# the &ogical 4ie)( #rocess 4ie)( De(loyment 4ie)( and
>m(lementation 4ie)' !hese vie$s are handled in the Analysis P Design and
-mplementation disciplines'
!he architectural vie$s are documented in a %o't)are Arc!itecture Document' 9ou may
add di7erent vie$s( such as a security vie$( to convey other speci*c aspects of the soft$are
architecture'
So( in essence( architectural vie$s can "e seen as a"stractions or simpli*cations of the
models "uilt( in $hich you ma0e important characteristics more visi"le "y leaving the details
aside' !he architecture is an important means for increasing the )uality of any model "uilt
during system development'
Concepts: +ser-Centered Design
Topics
Ihat is user-centered designR
<ocus on users
-ntegrated $ith design
1arly user testing
-terative design
Ihy user-centered designR
Meeting user needs
;ser-interface design
Legislation and standards
;ser-centered design in the R;P
Conte=ts of use
Scenarios( use cases and essential use cases
1ssential use cases in the R;P
"hat is user-centered design-
!here is no clear consensus on $hat constitutes user-centered design' Lo$ever( Sohn ,ould
and his colleagues at -BM developed an approach in the C4FBKs called Design for Usability
3,O;FF5 $hich encompasses most commonly-accepted de*nitions' -t developed from
practical e=perience on a num"er of interactive systems( most nota"ly -BMKs C4FT Olympic
Messaging System 3,O;FJ5' !he approach has four main components as descri"ed "elo$'
'ocus on users
,ould suggests that developers should decide $ho the users $ill "e and to involve them at
the earliest possi"le opportunity' Le suggests a num"er of $ays of "ecoming familiar $ith
users( their tas0s and re)uirements#
U !al0 $ith users U Nisit customer locations
U O"serve users $or0ing U Nideotape users $or0ing
U Learn a"out $or0 organiation U !ry it yourself
U ,et users to thin0 aloud $hile $or0ing U Participative design
U -nclude e=pert users on the design team U Perform tas0 analysis
U Ma0e use of surveys and )uestionnaires U Develop testa"le goals
-n the Rational ;ni*ed ProcessV %R;P&( $or0shops are used at several 0ey stages( "ut these
must "e complemented "y the 0inds of activities ,ould descri"es if an accurate picture is to
"e formed' %Part of the argument "ehind this is that people fre)uently descri"e $hat they do
)uite di7erently from ho$ they do it' Commonly performed tas0s and seemingly
unimportant details such as placement of $or0 or the e=istence of HmysteriousH scraps of
paper are often forgotten - or omitted "ecause they are not Ho6ciallyH part of the current
process'&
Integrated with design
;sa"ility tas0s should "e performed in parallel early in development' !hese tas0s $ould
include s0etching the user interface and drafting the user guides or online help' ,ould also
ma0es the point that usa"ility should "e the responsi"ility of one group'
An important feature of integrated design is that the overall approach W the frame$or0 W for
detailed user-interface design is developed and tested at an early stage' !his is an important
di7erence "et$een user-centered design and other purely incremental techni)ues' -t
ensures that incremental design carried out in later phases *ts seamlessly into the
frame$or0 and that the user interface is consistent in appearance( terminology and concept'
Iithin the R;PX( this frame$or0 can "e esta"lished "y using a domain model to ensure that
all terminology and concepts that $ill appear in the user interface are 0no$n and
understood $ithin the "usiness in general and $ith users in particular' %!here $ill also "e
su"sets of the domain model that $ill "e relevant only to speci*c groups of users' Care
should "e ta0en to ensure that the domain model is organied so that these su"sets can "e
easily identi*ed'& As user-interface design progresses in the re)uirements discipline( many of
the domain classes $ill "e represented as "oundary classes in the interface' !he "oundary
classes( and the relationships "et$een them( should "e consistent $ith the domain model
and should "e represented consistently through all parts of the system under design' %!his
not only assists users( "ut also improves reuse of user-interface components'&
&arly user testing
1arly user testing means early prototyping( typically dra$ings and moc0ups descri"ed as
lo$-*delity prototypes' Li-*delity prototypes $ill follo$ later in the process'
Moc0ups can "e used in con+unction $ith use cases to $rite concrete scenarios of use for the
system under design' !hese can ta0e the form narrative( illustrated narrative %using the
moc0ups for illustration&( story"oards( $al0-throughs %$ith users& and the "asis of user focus
groups' Ihile these approaches are unfamiliar to many soft$are developers( they are clearly
more cost e7ective than the discovery of inappropriate design or misunderstood
re)uirements once implementation is under $ay'
Iterative design
O"+ect-oriented development has "ecome synonymous $ith an iterative process' -terative
design is $ell-suited to pro"lems that need a re*nement of understanding and have
changing re)uirements' .ot surprisingly( iterative design is a 0ey component of user-
centered design' !his is partly due to the changing needs of users over time( "ut also the
inherent comple=ity of producing design solutions that can deal $ith diverse needs'
.ote that in user-centered methods( iterative design ta0es place $ithin an integrated
frame$or0' Ie deli"erately avoid incremental development( outside of an agreed
frame$or0( that might lead to a Ypatch$or0Z solution'
"hy user-centered design-
Meeting user needs
-nteractive systems rely on their a"ility to accommodate the needs of users for their
success' !his means not only identifying diverse user communities "ut also recogniing the
range of s0ills( e=perience and preferences of individual users'
Ihile it is tempting for developers and managers to feel that they understand user needs(
this is seldom the case in practice' Attention is fre)uently focused on ho$ users ought to
perform tas0s rather than ho$ they prefer to perform them' -n many cases the issue of
preference is much more than simply feeling in control( although that is an important issue
in itself' Preference $ill also "e determined "y e=perience( a"ility and the conte=t of use'
!hese issues are considered su6ciently important to the design process to $arrant an
international standard( 3-SO C[TBJ5( entitled human-centred design processes for interactive
systems' !he standard and related issues are discussed in general terms in the remainder of
this paper'
+ser-interace design
;sers understand and interact $ith a system through its user interface' !he concepts(
images and terminology presented in the interface must "e appropriate to usersK needs' <or
e=ample( a system that allo$s customers to "uy their o$n tic0ets $ould "e very di7erent to
one used professionally "y tic0et sales sta7' !he main di7erences are not in the
re)uirements or even the detailed use cases( "ut the characteristics of the users and the
environments in $hich the systems might operate'
!he user interface must also cater for a potentially $ide range of e=perience along at least
t$o dimensions( computer and domain e=perience( as sho$n in <igure C "elo$' Computer
e=perience includes not only general familiarity $ith computers( "ut also e=perience of the
system under development' ;sers $ith little e=perience of either computers or the pro"lem
domain( in the near left corner of the *gure( $ill re)uire a su"stantially di7erent approach in
the user interface to e=pert users( sho$n here in the far right corner'
-igure ;: *!e e2ects o' com(uter and domain e$(erience on ease o' learning
versus ease o' use
Be$are that it is not a forgone conclusion that ine=perienced users $ill "ecome e=perts over
time' A num"er of factors may conspire to prevent this( for e=ample lo$ fre)uency of use(
lo$ motivation or high comple=ity' Conversely some systems may have predominately
e=pert users' <actors here might "e training( high fre)uency of use or high motivation %+o"
dependence&' Some of these issues and their e7ects on user-interface design are sho$n in
!a"le C'
&o) ?ig!
Com(uter e$(erience Simple )uestion and ans$er(
simple form-*ll( $e" %hyper
lin0ed& or menu interface
style
Comple= form-*ll( $e"
%hyper lin0ed& or menu
interface style %)uestion
and ans$er or simple form-
*ll $ould "e very frustrating
to e=perienced users&
Domain e$(erience Common terminology and
concepts
Domain-speci*c
terminology and concepts
*raining <ocus on ease of learning
%consistent( predicta"le(
memora"le&
<ocus on ease of use
%direct( customia"le( non-
intrusive&
-requency o' use 1asy to learn and remem"er(
simple interface style
1asy to use( multiple
shortcuts and techni)ues to
allo$ user control
Motivation Re$arding to use( po$erful
$ithout seeming comple='
Sophisticated $ith many
advanced and customia"le
features'
*able ;0 %ome 'actors a2ecting user-inter'ace design
-nteractive systems must either "e designed to cater for an appropriate range of user
e=perience and circumstances( or steps must "e ta0en to restrict the design universe' <or
instance( training can "e used to reduce the re)uirement for ease of learning in a comple=
system' Alternatively a system might "e reduced in its scope in order that it "etter meets
the core re)uirements of its users %a suggestion made "y Alan Cooper in his "oo0 The
Inmates Are Running the Asylum 3COO445&'
0egislation and standards
As part of user-centered design( $e need to consider the s0ills and physical attri"utes of
users' !hese issues are no$ "eing increasingly em"odied in legislation' !his is mostly
directed at accommodating users $ith disa"ilities' Lo$ever( ma0ing systems accessi"le to a
$ider range of users is generally seen as "ene*ting the user community as a $hole'
!he ta"le "elo$ sho$s the relevant legislation and resources for many parts of the $orld#
Descri(tion 7eb %ite
A;S!RAL-A
Disa"ility Discrimination Act http#22$$$'dea0in'edu'au2e=tern2rdlu2ddainde='html
Disa"ility Rights http#22$$$'hreoc'gov'au2disa"ilityMrights2inde='html
1;ROP1
!reaty of Amsterdam http#22$$$'edf'unicall'"e2teu2en2inde='asp
1uropean Disa"ility <orum http#22$$$'edf'unicall'"e
;.-!1D @-.,DOM
Disa"ility Discrimination Act http#22$$$'hmso'gov'u02acts2actsC44D2C44DBDB'htm
.e$ Deal for Disa"led People http#22$$$'disa"ility'gov'u0
Digital Access Campaign http#22$$$'rni"'org'u02digital2$elcome'htm
;.-!1D .A!-O.S
;nited .ations Standard Rules
on the 1)ualiation of
Opportunities for Persons $ith
Disa"ilities
http#22$$$'un'org2esa2socdev2dissreBB'htm
Social Development -nformation
on the -nternet
http#22unescap'org2sps2sdinfo2disa"lin0s'htm
;.-!1D S!A!1S
Americans $ith Disa"ilities Act
%ADA&# ;S Department of Sustice
http#22$$$'usdo+'gov2crt2ada2
Section DBF of the Ior0force
-nvestment Act# ;S Department
of Sustice
http#22$$$'usdo+'gov2crt2DBF2DBFhome'html
;S Access Board 1lectronic and
-nformation !echnology Advisory
Committee %1-!AAC&
http#22$$$'access-"oard'gov
Iorld Iide Ie" Consortium
Ie" Accessi"ility Campaign
http#22$$$'$['org2$ai2
O!L1R R1SO;RC1S
Disa"ility-Related -nternet
Resources
http#22$$$'$e"a"le'com2
*able @a0 Disability-related legislation by country0 region or body
Aside from legislation( user-centered design and user-interface design are increasingly
"ecoming the su"+ect of standardiation as sho$n "elo$'
Descri(tion 7eb %ite5%tandards
A.S- $$$'ansi'org
A.S-
A.S--L<1S
A.S--.SC
A.S- and the Luman <actors and 1rgonomics Society
have pu"lished a num"er of +oint standards' A.S-
also has A.S--.SC \[QD $hich relates to the control
and prevention of cumulative stress disorders %also
0no$n as repetitive strain in+ury or RS-&'
A.S- is drafting standards concerning human
computer interaction as part of the -nformation
-nfrastructure Standards Panel %--SP& at
http#22$e"'ansi'org2pu"lic2iisp2stdMneed2needcat'html
'
-SO $$$'iso'ch
-SO 4ATC A large series of standards mainly concerned $ith
ergonomics of $or0stations( "ut also includes
guidance on usa"ility %part CC&' Also the "asis for
A.S--L<1S ABB( under development'
-SO CBBJD# C44C 1rgonomic principles relating to mental $or0 load
-SO CJBTC-C# C44D Cursor control for te=t editing
-SO CCDFC Series in development dealing $ith icons and
pointers'
-SO C[TBJ# C444 Standard for human-centered design processes for
interactive systems'
*able @b0 A=%> and >% user inter'ace and user-centered design standards
+ser-centered design in the R+P
Developing systems appropriate to user needs means a signi*cant e7ort in re)uirements
analysis' -n user-centered design( this e7ort is focused on end users' !hese are a su"set of
the human Business Actors %for users outside of the "usiness& and Business Ior0ers found
$hen $or0ing in the Business Modeling discipline' !hey are later descri"ed in greater detail
in the Re)uirements discipline as Actors' %!he relationships "et$een Actors( Business Actors
and Business Ior0ers is discussed in ,uideline# ,oing from Business Models to Systems'&
Lo$ever( a su"stantial point of emphasis in ;ser-Centered design is that $e understand the
re)uirements of the real people $ho $ill *ll the roles descri"ed in the artifacts mentioned
a"ove' -n particular( $e must avoid designing hypothetical humans for $hom it is convenient
to design soft$are systems' !he artifacts descri"ing end users must "e $ritten only after
su"stantial( *rst-hand contact $ith users' -n user-centered design this *rst-hand contact is
part of a process sometimes called contextual inquiry' Lugh Beyer and @aren Lolt"latt %in
their "oo0 Contextual Design 3B194F5& descri"e the premise of conte=tual in)uiry as#
H'''go $here the customer $or0s( o"serve the customer as he or she $or0s( and tal0 to the
customer a"out the $or0'H
%Some concrete e=amples of this have already "een listed under <ocus on ;sers'& !his
approach is used not only to have a "etter understanding of system re)uirements( "ut also
of the users themselves( their tas0s and environments' 1ach have their o$n attri"utes and
ta0en together are referred to as the conte=t of use' !hey are detailed in the -SO standard
for user-centered design( descri"ed "elo$'
Conte1ts o use
-SOKs !uman-centered design processes for interactive systems 3-SOC[TBJ5 identi*es the
*rst step in design as understanding and specifying the conte=t of use' !he attri"utes
suggested are#
Context Attributes
!as0s ,oals of use of the system( fre)uency and
duration of performance( health and safety
considerations( allocation of activities(
operational steps "et$een human and
technological resources' !as0s should not
"e descri"ed solely in terms of the functions
or features provided "y a product or
system'
;sers %for each di7erent type or
role&
@no$ledge( s0ill( e=perience( education(
training( physical attri"utes( ha"its(
preferences( capa"ilities'
1nvironments Lard$are( soft$are( materialsG physical and
social environments( relevant standards(
technical environment( am"ient
environment( legislative environment( social
and cultural environment
*able A: Conte$t o' use 'rom >% standard 'or user-centered design
-t is useful to split the user conte=t into its t$o constituent parts %user type and role& and
then to consider the relationships "et$een all four conte=ts#
-igure @: Relations!i(s bet)een conte$ts
<igure A sho$s that every tas" is performed in a role ta0en "y a user $ithin an environment'
!hese conte=ts correspond to the R;P artifacts as sho$n in !a"le T'
>% ;AB<C Conte$tt!e R.# Arti'act
1nvironments Ligh-level#
Business Nision 3Section# Customer
1nvironment5(
Sta0eholder Re)uests(
Nision 3Section# ;ser 1nvironment5
;sers Ligh-level#
Business Nision 3Section# Customer
Pro*les5(
Sta0eholder Re)uests(
Nision 3Section# ;ser Pro*les5
Roles Ligh-level#
Business Actor %e=ternal users&(
Business Ior0er %internal users&
Detailed#
Actor
!as0s Ligh-level#
Sta0eholder Re)uests(
Nision 3Section# Product <eatures5
Detailed#
;se-Case Story"oard
;se Case
*able B0 >% user-centered design standard conte$ts and t!eir t!e R.# arti'acts
1ach of these conte=ts could have a signi*cant impact on the design of an appropriate user
interface' As a result $e are faced $ith a potentially large num"er of permutations' 1ven for
a small system( there may "e A environments %e'g' o6ce and customer site&( [ types of user
%sales novice( sales e=pert and management& and Q roles %telephone sales assistant(
e=ternal sales representative( etc'&' !hat means up to [Q potential variations per tas0(
although the set of realistic com"inations is usually much smaller'
Clearly tas0s must "e descri"ed individually( "ut a single description is unli0ely to "e
appropriate for all permutations' One approach is to factor the user and environment
conte=ts into the role description' !his is the solution adopted "y Constantine and Loc0$ood
3CO.445' -t involves providing a separate Huser roleH for each signi*cant permutation of role(
user and environment( then naming the resulting user role $ith a descriptive phrase( rather
that a simple noun' Compare( for e=ample( the role YCustomerZ $ith the user roles YCasual
CustomerZ( YIe" CustomerZ( YRegular CustomerZ and YAdvanced CustomerZ'
1ach user role description includes details of the role itself plus its users %referred to as role
incum"ents& and environment' !his approach can "e adopted $ith the R;P "y choosing
actors that correspond to user roles'
,cenarios2 use cases2 and essential use cases
!he terms scenarios( use cases and essential use cases have a confusing degree of overlap
and are used in di7erent design approaches to mean slightly di7erent things' <or e=ample(
$ithin the R;P HscenarioH means a use-case instanceG simply a speci*c HpathH through the
possi"le "asic and alternative 8o$s' Lo$ever( it is common to *nd user-centered and user-
interface design methods descri"ing scenarios as stories of use( containing su"stantially
more detail than +ust the 8o$ of events' Ihile this additional information may "e irrelevant
in later design phases( it does form part of the understanding of users( tas0s and
environments' Conse)uently( scenarios may "e used e=tensively %in story"oarding and role
playing& in the Business Modeling discipline( "ut the focus moves to$ards use cases in the
Re)uirements discipline'
<igure [ sho$s the nature of this overlap' !he scale at the top incorporates a num"er of
di7erent factors that tend to vary together' <or e=ample( as purpose moves more to$ards
re)uirements( structure usually "ecomes more formal' 1ssential use cases appear to the
right of generic use cases "ecause user roles ma0e them slightly more speci*c %see the
preceding section& and they have a more formal structure'
-igure A: verla( in conce(ts bet)een scenarios and use cases in user-centered
design
!he di7erences "et$een system use cases and essential use cases are "est illustrated "y
e=ample' !a"le D sho$s a use case from Constantine and Loc0$ood/s Soft$are for ;se
3CO.445#
.ser Action %ystem Res(onse
insert card
read magnetic strip
re)uest pint
enter P-.
verify P-.
display transaction option menu
press 0ey
display account menu
press 0ey
prompt for amount
enter amount
display amount
press 0ey
return card
ta0e card
dispense cash
ta0e cash
*able D: "eneric use case 'or getting cas! 'rom an A*M
!his e=ample details the se)uence of events "et$een the actor and the system( $ith the
vertical line "et$een the t$o columns representing the user interface' .otice that $hile
Constantine and Loc0$ood recommend this style for essential use cases( this particular use
case is not an essential one' !he reason is that it "ased on the syntactic detail of the
interaction' !hat is( ho# the interaction ta0es place' An essential use case focuses on #hat
the interaction is a"out %called the semantics&' !a"le Q is the essential version of the
interaction'
.ser >ntention %ystem Res(onsibility
identify self verify identity
o7er choices
choose dispense cash
ta0e cash
*able E: Essential use case 'or getting cas! 'rom an A*M
!his use case captures the essence of the getting cash interaction' !he ;ser Action and
System Response headings have "een replaced "y ;ser -ntention and System Responsi"ility
to re8ect the change in emphasis' ,ood interface design centers on user goals and
intentionsG these are often hidden in conventional use cases' 1ssential use cases are
particularly useful if#
there are fe$ design constraints %e'g' the implied design constraint of using "an0
cards is false&
the system might "e enhanced to use other means of identi*cation %such as some
0ind of secure internet access&
there is a desire to create ;se Cases $ithout design constraints( for potential reuse in
pro+ects that lac0 these constraints'
Lo$ever( essential use cases do have their dra$"ac0s' Perfectly straightfor$ard use cases
such as that in !a"le D can "e su"+ect to considera"le de"ate $hen it comes to distilling their
essence' <or e=ample( does inserting a card identify the customer or the accountR -n most
e=isting A!Ms( it is the later although Constantine and Loc0$ood have chosen to interpret
this as identifying the customer' !his may have "een a deli"erate decision in light of ne$er
technology such as retina scanning and *ngerprint identi*cation( or it may have "een an
oversight' !he conse)uences in this case is an additional choice that has to "e made "y
customers $ho hold more than one account'
Another di6culty that essential use cases present is that they are not as suita"le for revie$
$ith end users and other sta0eholders "ecause of their a"stract nature' Part of this pro"lem
stems from having to translate essential use cases "ac0 to a concrete form representing
user actions' !his can "e done once a design model is availa"le "y $riting scenarios that
descri"e the interaction in concrete terms %similar in concept to a ;se Case Realiation(
although concerned $ith user-system interaction rather than internal o"+ect colla"oration&'
-n summary( "uilding essential use cases may not a good idea if#
the user interface technologies are intentionally highly constrained %e'g' the system
must accept "an0 cards&
the time to re)uired for the users to understand the more a"stract use cases is
out$eighed "y the e=pected "ene*ts'
&ssential use cases in the R+P
!he R;P does not e=plicitly refer to essential use cases( "ut in the Activity# Model the ;ser
-nterface( essential use cases are used as a starting point( then developed and augmented
$ith usa"ility re)uirements to create use-case story"oards( as e=plained in ,uidelines# ;se-
Case Story"oard'
%tart by clari'ying t!e use case itsel' - not its user inter'ace1 Start "y 0eeping
the description independent of the user interface( especially if the use case is
une=plored' !hen( later on( as the use case is understood( the 8o$ of events -
story"oard can "e augmented $ith user interface and usa"ility aspects' $from
%uidelines& Use-Case 'toryboard(
!his means removing all design or current implementation detail so that only the semantics -
the meaning of the interaction - remain' !hen( as various design alternatives are e=plored(
syntactic detail - ho$ the interaction ta0es place - is added to the essential use case as a
type of realiation' %1ach alternative design is( in e7ect( a realiation of the same essential
use case'&
!hese use-case story"oards are used as input to the Activity# Prototype the ;ser -nterface to
develop the user-interface prototypes'
Re*uire!ents: "or#low
Problem
Topics
Purpose
Lo$ to Sta7
Ior0
,uidelines
Purpose Top Top
!he purpose of this $or08o$ detail is to#
,ain agreement on the pro"lem "eing solved(
-dentify sta0eholders(
De*ne the system "oundaries( and
-dentify constraints imposed on the system
!he *rst step in any pro"lem analysis is to ma0e sure that all parties involved agree on $hat
is the pro"lem that $e are trying to solve $ith our system' -n order to avoid
misunderstandings( it is important to agree on common terminology $hich $ill "e used
throughout the pro+ect' 1arly on( $e should "egin de*ning our pro+ect terms in a glossary
$hich $ill "e maintained throughout the pro+ect lifecycle'
-n order to fully understand the pro"lem%s& $e should "e addressing( it is very important to
0no$ $ho are our sta0eholders' .ote that some of these sta0eholders -- the users of the
system -- $ill "e represented "y actors in our use-case model'
!he Re)uirements Management Plan $ill provide guidance on the re)uirements artifacts that
should "e developed( the types of re)uirements that should "e managed for the pro+ect( the
re)uirements attri"utes that should "e collected and the re)uirements tracea"ility that $ill
"e used in managing the product re)uirements'
!he primary artifact in $hich $e document the pro"lem analysis information is the Nision
document( $hich identi*es the high-level user or customer vie$ of the system to "e "uilt' -n
the Nision( initial high-level re)uirements identify the 0ey features it is desired the
appropriate solution $ill provide' !hese are typically e=pressed as a set of high-level
features the system might possess in order to solve the most critical pro"lems'
@ey sta0eholders should "e involved in gathering the set of features to "e considered( $hich
might "e gathered in a Re)uirements Ior0shop' !he features should "e assigned attri"utes
such as rationale( relative value or priority( source of re)uest and so on( so that
dependencies can "egin to "e managed'
!o determine the initial scope for our pro+ect( the "oundaries of the system must "e agreed
upon' !he system analyst identi*es users and systems - represented "y actors - $hich $ill
interact $ith the system'
-f you have developed a domain model( a "usiness use-case model or a "usiness o"+ect
model( these $ill "e 0ey input( along $ith the "usiness rules( to helping to perform this
analysis' See also ,uidelines# ,oing from Business Models to Systems for more guidance'
!his $or08o$ detail should "e revisited several times during inception and early ela"oration'
!hen( throughout the lifecycle of the pro+ect( it should "e revisited as necessary $hile
managing the inevita"le changes that $ill occur in our pro+ect( in order to ensure that $e
continue to address the correct pro"lem%s&'
)ow to ,ta Top Top
!he pro+ect mem"ers involved in analying the pro"lem should "e e6cient facilitators and
have e=perience in techni)ues for *nding the pro"lem "ehind the pro"lem' Of course(
familiarity $ith the targeted technology is desira"le( "ut it is not essential' Active
involvement form various sta0eholders to the pro+ect is re)uired'
"or# %uidelines Top Top
!he follo$ing are sample techni)ues that can "e applied to *nd the pro"lem "ehind the
pro"lem#
Brainstorming
<ish"one diagrams
Pareto diagrams
See also#
Re)uirements# Overvie$
Ihite Paper# Applying Re)uirements Management $ith ;se Cases
,uidelines# ,oing from Business Models to Systems
"or#low Detail: +nderstand ,ta#eholder $eeds
Topics
Purpose
Lo$ to Sta7
Ior0
,uidelines
Purpose
!he purpose of this $or08o$ detail is to collect and elicit information from the sta0eholders
of the pro+ect in order to understand $hat their needs really are' !he collected sta0eholder
re)uests can "e regarded as a H$ish listH that $ill "e used as primary input to de*ning the
high-level features of our system( as descri"ed in the Nision( $hich drive the speci*cation of
the soft$are re)uirements( as descri"ed in the use-case model( use cases and
supplementary speci*cations'
!ypically( this activity is mainly performed during iterations in the inception and ela"oration
phases( ho$ever sta0eholder re)uests should "e gathered throughout the pro+ect "y using
Change Re)uests follo$ing the Change Re)uest Management Process'
!he 0ey activity is to elicit sta0eholder re)uests using such input as "usiness rules(
enhancement re)uests( intervie$s and re)uirements $or0shops' !he primary outputs are
collection%s& of prioritied features and their critical attri"utes( $hich $ill "e used in de*ning
the system and managing the scope of the system'
!his information results in a re*nement of the Nision document( as $ell as a "etter
understanding of the re)uirements attri"utes' Also( during this $or08o$ detail you may start
discussing the functional re)uirements of the system in terms of its use cases and actors'
!hose non-functional re)uirements( $hich do not *t easily into the use-case model( should
"e documented in the Supplementary Speci*cations'
Another important output is an updated ,lossary of terms to facilitate common voca"ulary
among team mem"ers'
)ow to ,ta Top Top
!he pro+ect mem"ers involved in understanding sta0eholder needs should "e e6cient
facilitators and have e=perience in eliciting information' Of course( familiarity $ith the
targeted technology is desira"le( "ut it is not essential'
"or# %uidelines Top Top
!he follo$ing are sample techni)ues that can "e applied to ma0e sure you collect the
correct and relevant information from the sta0eholders#
-ntervie$s
Re)uirements Ior0shop
Brain-storming and idea reduction
;se-Case Ior0shop
Story"oarding
Role playing
Revie$ of e=isting re)uirements
See also#
Re)uirements# Overvie$
Ihite Paper# Applying Re)uirements Management $ith ;se Cases
Concepts# ;ser-Centered Design
"or#low Detail: Deine the ,yste!
Topics
Purpose
Lo$ to Sta7
Ior0
,uidelines
Purpose
!he purpose of this $or08o$ detail is to#
Align the pro+ect team in their understanding of the system'
Perform a high-level analysis on the results of collecting sta0eholder re)uests'
Re*ne the Nision to include the features to include in the system( along $ith
appropriate attri"utes'
Re*ne the use-case model( to include outlined use cases'
More formally document the results in models and documents'
Pro"lem Analysis and activities for ;nderstanding Sta0eholder .eeds create early iterations
of 0ey system de*nitions( including the features de*ned in the Nision document( a *rst
outline to the use-case model and the Re)uirements Attri"utes' -n De*ning the System you
$ill focus on identifying actors and use cases more completely( and e=pand the glo"al non-
functional re)uirements as de*ned in the Supplementary Speci*cations'
-f you have developed a "usiness use-case model and "usiness o"+ect model( see also
,uidelines# ,oing from Business Models to Systems for more guidance'
!ypically( this is primarily performed in iterations during the inception and ela"oration
phases( ho$ever it may "e revisited as needed $hen managing scope and responding to
changing re)uirements( as $ell as other changing conditions'
)ow to ,ta Top Top
All mem"ers of the pro+ect team should participate'
"or# %uidelines Top Top
!he follo$ing are sample techni)ues that can "e applied#
Re)uirements Ior0shop
;se-Case Ior0shop
Story"oarding
"or#low Detail: Manage the ,cope o the ,yste!
Topics
Purpose
Lo$ to Sta7
Ior0
,uidelines
Purpose
!he purpose of this $or08o$ detail is to#
Prioritie and re*ne input to the selection of features and re)uirements that are to "e
included in the current iteration'
De*ne the set of use cases %or scenarios& that represent some signi*cant( central
functionality'
De*ne $hich re)uirement attri"utes and tracea"ilities to maintain'
!he scope of a pro+ect is de*ned "y the set of re)uirements allocated to it' Managing pro+ect
scope to *t the availa"le resources %time( people( and money& is 0ey to managing successful
pro+ects' Managing scope is a continuous activity that re)uires iterative or incremental
development( $hich "rea0s pro+ect scope into smaller more managea"le pieces'
;sing re)uirement attri"utes( such as priority( e7ort( and ris0( as the "asis for negotiating
the inclusion of a re)uirement is a particularly useful techni)ue for managing scope'
<ocusing on the attri"utes rather than the re)uirements themselves helps desensitie
negotiations that are other$ise contentious'
-t is also helpful for team leaders to "e trained in negotiation s0ills and for the pro+ect to
have a champion in the organiation( as $ell as on the customer side' Product2pro+ect
champions should have the organiational po$er to refuse scope changes "eyond the
availa"le resources or to e=pand resources to accommodate additional scope'
Pro+ect scope should "e managed continuously throughout the pro+ect' A "etter
understanding of system functionality is o"tained from identifying most actors and use
cases' .on-functional re)uirements( $hich do not *t in the use-case model( should "e
documented in the Supplementary Speci*cations' !he system analyst should determine
values of priority( e7ort( cost( ris0 values etc'( from the appropriate sta0eholders( to collect
in the repository of re)uirements attri"utes' !hese $ill "e used "y the Pro+ect Manager in
planning the iterations and ena"les the soft$are architect to identify the architecturally
signi*cant use cases( de*ning the use-case vie$ of the architecture in the Soft$are
Architecture Document'
)ow to ,ta Top Top
!he people involved in this $or08o$ detail should all "e mem"ers of the architecture team'
"or# %uidelines Top Top
!he architecture team $ill lead a session to discuss ho$ to "est prioritie the re)uirements'
Topics
Purpose
Lo$ to Sta7
Ior0
,uidelines
Re*uire!ents: Activity Overview
Re*uire!ents: Artiact Overview
!he roles and the artifacts developed in the Re)uirements discipline'
Re*uire!ents: %uidelines Overview
;se Case
Activity Diagram in the ;se-Case Model
Actor
;se-Case Model
Actor-,eneraliation
Communicate-Association
1=tend-Relationship
-nclude-Relationship
;se-Case-,eneraliation
;se-Case Diagram
Re)uirements Management Plan
;se-Case Pac0age
Soft$are Architecture Document
Soft$are Re)uirements Speci*cation
Boundary Class
;se-Case Story"oard
;ser -nterface %,eneral&