Requirement Lecture 6d

8/18/2019 Requirement Lecture 6d

1/15

Requirements Management

SEG3101 (Fall 2009)


2/15

2

Why Do Requirements Change?

• Change in software development:

•

etter !nderstanding: new re"!irements #e$ome apparent• Ever%thing else is $hanging&

• !siness

• Conte't

• e$hnologies

• ar*ets

• &

• +ossi#le responses to $hange

• ,dd- modif%- or remove re"!irements


3/15

3

Some Problems Due to Changing Requirements

• .e"!irements $hanging towards the end of development

witho!t an% impa$t assessment

• ime spent $oding- writing test $ases or do$!mentation for

re"!irements that no longer e'ist


4/15

/

Requirements Management Activities

.e"!irements management in$l!des all a$tivities intended to

maintain the integrit% and a$$!ra$% of e'pe$ted re"!irements• anage $hanges to agreed re"!irements

• anage $hanges to #aseline (in$rements)

• eep proe$t plans s%n$hronied with re"!irements

• Control versions of individ!al re"!irements and versions ofre"!irements do$!ments

• anage relationships #etween re"!irements

• anaging the dependen$ies #etween the re"!irements

do$!ment and other do$!ments prod!$ed in the s%stemsengineering pro$ess

• ra$* re"!irements stat!s


5/15

From Management to Tools

• Changes lead to a need for management

•here is no management witho!t:

• ra$ea#ilit%

• aselines ena#ling $omparisons

• From a pra$ti$al point of view- there is no tra$ea#ilit% or

management witho!t appropriate tools


6/15

4

Factors might Change requirements (!

• .e"!irements errors- $onfli$ts- and in$onsisten$ies

•

a% #e dete$ted at an% phase (when re"!irements are anal%ed-spe$ified- validated- or implemented)

• Evolving $!stomer5!ser *nowledge of the s%stem

• 6hen the re"!irements are developed- $!stomers5!sers

sim!ltaneo!sl% develop a #etter !nderstanding of what the% reall%

need

• e$hni$al- s$hed!le- or $ost pro#lems

• 7iffi$!lt to plan and *now ever%thing in advan$e

• 6e ma% have to revisit the list of re"!irements and adapt it to the

$!rrent sit!ation


7/158

Requirements Change Factors ("!

Changing $!stomer priorities- new needs

•a% #e $a!sed #% a $hange in the s%stem environment(te$hnologi$al- #!siness- politi$al)- ie- the $onte't

• !siness and strategi$ goals ma% $hange

• a% #e $a!sed #% the arrival of a new $ompetitor

• aws and reg!lations ma% $hange

• Colla#orating s%stems ma% $hange

• a% also #e $a!sed #% te$hnolog% $hanges in the enterprise

(migration to a new operating s%stem- 7S&)

• a% #e $a!sed #% organiational $hanges (organiational

str!$t!re- #!siness pro$esses- emplo%ees&)


8/15;

Requirements #olatility

Requirements continuously change

•6hile the re"!irements are #eing eli$ited- anal%ed- spe$ified- andvalidated and after the s%stem has gone into servi$e

Some requirements are usually more sub$ect to change

than others

• Sta#le re"!irements are $on$erned with the essen$e of a s%stem and its

appli$ation domain

• 7erived from the $lient


9/159

%&'ectations o Requirements Management (!

• >dentifi$ation of individ!al re"!irements

• ra$ea#ilit% from highest level re"!irements to

implementation

• Esta#lished via lin*s thro!gh a re"!irements data#ase

•

in*s #etween re"!irements and design models- tests- $ode&• Coverage and $onsisten$% anal%sis

• 6hat are the tra$ea#ilit% poli$ies? 6hat t%pes of lin*s? From where?

o where?

• >mpa$t assessments of proposed $hanges

• ,nal%sis tools let %o! see whi$h other re"!irements (and other lin*ed

artifa$ts) will #e affe$ted #% a $hange


10/1510

%&'ectations o Requirements Management ("!

• Controlled a$$ess to $!rrent proe$t information

•

, shared data#ase ens!res that all !sers are wor*ing with $!rrent data($onsisten$%- parallel a$$ess)

• , $entral repositor% allows all !sers to see the information that the%

need to see (visi#ilit%)

• 7eplo%ment of re"!ired tool s!pport

• o help manage re"!irements $hange


11/1511

)*entiication o Requirements

• It is essential for requirements management that every

requirement has a unique identification• he most $ommon approa$h is re"!irements n!m#ering #ased on

$hapter5se$tion in the re"!irements do$!ment


12/15

12

Requirements +ave Attributes,

• ,part from an identifier- re"!irements sho!ld have attri#!tes

that esta#lish $onte't and #a$*gro!nd- and go #e%ond there"!irement des$ription

• For filtering- anal%sis- metri$s&

• Creation date- ast !pdate- ,!thor- Sta*eholders (@wners 5 So!r$e)

•

=ersion n!m#er • Stat!s- +riorit%- >mportan$e- Sta#ilit%

• .ationale- Comments

• ,$$eptan$e $riteria

• he more $omple' the proe$t- the ri$her the attri#!tes&

• an% attri#!tes are predefined in . tools- others are

defined #% re"!irements engineers as re"!ired #% the proe$t


13/15

13

Requirements Attributes

• Classes and attri#!tes of a re"!irements management

data#ase

• Sele$t onl% the ne$essar% attri#!tesA

REQUIREMENT

Identifier: TEXTStatement: TEXT | GRAPHICDate_entered: DATE

Date_changed:DATESources: SOURCE_LISTRationale: REQ_RATIONALEStatus: STATUSDependents: REQ_LISTIs_dependent_on: REQ_LISTModel_links: SYS_MODELSComments: TEXT

SOURCE_LIST

People: TEXTDocuments: TEXTReqs: REQ_LIST

REQ_RATIONALE

Rationale: TEXTDiagrams: GRAPHICPhotos: PICTURE

REQ_LIST

Req: REQUIREMENTDescription: TEXTNext: REQUIREMENT

| NULL

SYS_MODELS

Model: MODELDescription: TEXTNext: MODEL | NULL


14/15

1/

Requirements Status

• Belp manage the re"!irement life$%$le

•

heir n!m#er and nat!re depend on the pro$ess in pla$e• E'ample of a set of stat!ses:

• +roposed: #% some sta*eholder

• ,pproved: part of #aseline- $ommitted to implement

•

.ee$ted: after eval!ation• >mplemented: designed and implemented

• =erified: .elevant tests have passed

• 7eleted: .emoved from list

•

. in$l!des amongst its tas*s the tra$*ing of the stat!s of allre"!irements d!ring the proe$t


15/15

1

#ersion Control

• ,nother essential aspe$t of re"!irements management

•

Ever% version of a re"!irement needs to #e !ni"!el% identified• he last version of a re"!irement m!st #e availa#le to all team

mem#ers

• Changes need to #e do$!mented and $learl% $omm!ni$ated

• , version identifier m!st #e !pdated with ever% $hange to the

re"!irement

• .e"!irements do$!ments sho!ld in$l!de

• , revision histor%: $hanges- dates- #% whom- wh%

• Standard mar*ers for revisions (eg- stri*ethro!gh or !nderlined te't-

$oloring- line mar*ers&)

• =ersion $ontrol tool ma% #e !sed

• o store and manage the revision histor%

• o store !stifi$ations (to add- modif%- delete- ree$t a re"!irement)

Requirement Lecture 6d

Documents

Transcript of Requirement Lecture 6d