2. Requirements Gathering.pptx

8/16/2019 2. Requirements Gathering.pptx

1/57

Requirements

GatheringDr Kristin Stock


2/57

OutlineWhy do we need to gather requirements?

Types of requirements.

Determining requirements.Requirements analysis strategies.

Data gathering techniques.

ase study! SD"S


3/57

#ntroduction The systems de$elopment process transforms the

e%isting &as is' system into the proposed &to (e'

system

Requirements determination The single most critical step of the entire SD)

hanges can (e made easily in this stage

"ost &*+,-' system failures are due to pro(lems with

requirements The iterati$e process of OOSD is e/ecti$e (ecause! Small (atches of requirements can (e identi0ed and

implemented incrementally

The system will e$ol$e o$er time


4/57

equ rementsDetermination

1urpose! to con$ert high le$el (usinessrequirements &from the system request' intodetailed requirements that can (e used as inputsfor creating models

What is a requirement?

statement of what the system must do or acharacteristic it must ha$e

Will later e$ol$e into a technical description of howthe system will (e implemented

Types!

2unctional! relates to a process or data

3on4functional! relates to performance or usa(ility


5/57

2unctional RequirementsWhat should the system do?

5%amples!llow users to search for something &(y certain criteria'

(uy items

trace the location of an o(6ect through aprocess chain

communicate (y real time $oice

7.


6/57

3on4functionalrequirements

What characteristics should the system ha$e?Operational requirements! what situation must the system

operate in.

)ook and feel requirements &fun8 moti$ating8 etc.'.9sa(ility &and humanity' requirements.

5n$ironmental requirements! location8 physical requirements.

9ser requirements! what kind of users will use it8 what are

their needs?

1erformance requirements! speed8 capacity8 relia(ility.

Security requirements.

"aintaina(ility and support requirements.

ultural8 political8 legal requirements.

&Data requirements'


7/57

2unctional $s. 3on4

functional

2unctional : how much of the pro(lem does

the system sol$e?3on4functional : e;ciency8 maintaina(ility8

usa(ility8 relia(ility8 testa(ility8 etc.


8/57

<

=

>

@

+

A

B


9/57

"ini quiC7http!q.%orro.compndk

9se your student id

cti$ity! chairs

http://q.xorro.com/pndkhttp://q.xorro.com/pndkhttp://q.xorro.com/pndk


10/57


11/57

Requirements De0nition2unctional E non4functional requirements listed in

outline format

"ay (e prioritiCed1ro$ides information needed in su(sequent workFows

De0nes the scope of the system G useful to a$oidscope creep


12/57

Sample of Requirements De0nition


13/57

Requirements

"anagement

n important part of a$oiding scope creep.

Hersioning8 change control.

Tracea(ility.

See h A8 IIOK Juide.


14/57

2it riterionOperationalisesL the requirement.

"akes sure that we can measurewhether or not it has succeeded.

See h Ro(ertson.


15/57


9se your student id

cti$ity! requirement types



16/57

So now we know whatrequirements are –

but how do weactually defne them?


17/57

Determining

RequirementsWho should do it?

#T people?9sers?


18/57

Together7

Iut how?


19/57

reating aRequirements De0nitionDetermine the types of functional and non4

functional requirements applica(le to the pro6ect

9se requirements4gathering techniques to collectdetails

nalysts work with users to $erify8 change andprioritiCe each requirement

ontinue this process through analysis workFow8(ut (e careful of scope creep

Requirements that meet a need (ut are not withinthe current scope can (e added to a list of futureenhancements


20/57

1ro(lems in

Requirements Determination

nalyst may not ha$e access to the correct

usersRequirements speci0cations may (e

inadequate

Some requirements may not (e known in the(eginning

Herifying and $alidating requirements can (edi;cult


21/57

We will look at7Requirements gathering techniques!

Mow do we actually get data?Requirements analysis strategies!What kinds of data do we get8 and how do we

analyse it to identify requirements?

1art of it is a process of helping people tomo$e through the design process G gettingthem on (oard


22/57

Requirements nalysis Strategies

1ro(lem analysis

Root cause analysisDuration analysis

cti$ity4(ased costing

#nformal (enchmarking

Outcome analysis Technology analysis

cti$ity elimination


23/57

1ro(lem nalysissk users to identify pro(lems with the current

system

sk users how they would sol$e these pro(lems

Jood for impro$ing e;ciency or ease4of4use


24/57

Root ause nalysis2ocus is on the cause of a

pro(lem8 not its solution

reate a prioritiCed list ofpro(lems

Try to determine all thepossi(le root causes for each

pro(lemOnce the causes are known8

solutions can (e de$eloped


25/57

Duration nalysisDetermine the time required to

complete each step in a (usinessprocess

ompare this to the total timerequired for the entire process

)arge di/erences suggest pro(lemsthat might (e sol$ed (y!#ntegrating some steps together

1erforming some stepssimultaneously &in parallel'


26/57

cti$ity4(ased costingSame as duration analysis (ut

applied to costs.nalysts identify costs for each

step in the process.

Direct cost of la(our and

materials for each input8 plusindirect costs.


27/57

#nformal IenchmarkingnalyCes similar processes in other successful organiCations.

5specially common for customer4facing (usiness processes.

Irings new ideas into the organisation.

an also use this to get ideas for a new system.


28/57

Outcome nalysisWhat does the customer want in the end?

3ot always the most o($ious thing.What is the ultimate goal?

lso helpful for de$eloping a new system.


29/57

Technology nalysis"ake a list of important and interesting new

technologies.

5%amine each in terms of what it might o/er to theorganisation.

"ust only (e 6usti0ed (y (ene0t to the organisation.


30/57

cti$ity 5limination

5liminate each acti$ity in a (usiness process.

1eople are often reluctant8 (ut must choose somethingN


31/57

Requirements nalysis Strategies

Method Finds and analyses

1ro(lem analysis 1ro(lems with the current processRoot cause analysis The root cause of pro(lems with the current

process

Duration analysis The duration of acti$ities in the current process

cti$ity4(ased

costing

The cost of acti$ities in the current process

#nformal(enchmarking

Mow other organisations perform the process

Outcome analysis The ultimate outcomes required (y the users

Technology analysis $aila(le technology

cti$ity elimination SuperFuous acti$ities in the current process.


32/57


9se your student id

cti$ity! requirement analysis strategies



33/57

So now we have someidea o what data tocollect – but how dowe collect it?


34/57

Requirements Jathering Techniques1rocess is used to!9nco$er all requirements &those unco$ered late in the

process are more di;cult to incorporate'

Iuild support and trust among users

Which technique&s' to use?

#nter$iews

oint pplication De$elopment &D'

PuestionnairesDocument analysis

O(ser$ation

2ocus Jroups

Requirements Workshops


35/57

Document nalysis1ro$ides information a(out the Qas4is system

Re$iew technical documents when a$aila(le

Re$iew typical user documents!

2orms

Reports

1olicy manuals)ook for user additions to forms

)ook for unused form elements


36/57

#nter$iews"ost popular techniqueif you need to know

something8 6ust ask

1rocess!Select people to inter$iew E create a schedule

Design inter$iew questions &Open4ended8 closed4ended8 E pro(ing types of questions'

1repare for the inter$iew &9nstructured $s.structured inter$iew organiCed in a logical order'

onduct the inter$iew &Top4down $s. (ottom4up'

2ollow4up after the inter$iew


37/57

Who and Mow?9sually one on one is (est to get indi$idual

opinions.

#dentify key people G often (ecomes

apparent.

Iest to do some re$iew of documents andother materials (efore hand.

"ay go (ack to the same indi$idual again

later8 to ask other or more speci0c questions.Should not ask for information you can get

from another source.

an (e politically sensiti$e.


38/57

Puestion Types


39/57

Design of inter$iewsDi/erent le$els of detail at

di/erent points in theprocess.

sk questions in a logicalsequence.

Start with non4contro$ersial8

non4threatening questions.Ji$e the inter$iewee

information a(out what will

(e co$ered.


40/57

#nter$iewing Strategies

Mowcan order

processing (e

impro$ed?

Mow can we reduce thenum(er of times that customers

return ordered items?

Mow can we reduce the num(er of errors in order processing &e.g.8 shipping

the wrong products'?

o!"down

#ottom"u!

$igh"level%Hery general

Medium"level%"oderately speci0c

&ow"level%Hery speci0c


41/57

onducting the #nter$iew Try to (uild rapport.

1eople will often gi$e their opinion8 (ut you

need to stay o(6ecti$e8 collect facts as well.5%amples!QThis system is ru((ish

Q# canLt do any of the things # want to

Q#t always crashes

Q# told the programmer to (uild the system likethis7

sk them to show you the pro(lems.


42/57

1ost4#nter$iew1repare notes and send to the inter$iewee for $eri0cation


43/57

oint pplication De$elopment &D'

oint user4analyst meeting hosted (y a facilitator, users

< to > scri(es as needed to record the session

9sually in a specially prepared room

"eetings can (e held electronically and anonymously

Reduces pro(lems in group settings

an (e held remotelySessions require careful planning to (e successful9sers may need to (ring documents or user manuals

Jround rules should (e esta(lished


44/57

oint pplication De$elopment &D'&>'

s with inter$iews8 questions should (e

planned8 participants prepared.Hary in length.

9sers (ring along documents.

1otential challenges!an (e hard to get the right people there

Jroup dynamics are a (ig issue.

Require a skilled and trained facilitator.


45/57

2ocus Jroups

ddress a speci0c product8 ser$ice or

opportunity.4 participants.

"oderator and recorder.

an (e good work working on an e%istingmodel.


46/57

Puestionnaires set of written questions used to o(tain

information from indi$iduals

3ot Fe%i(le8 so ha$e to (e designed $arycarefully. Iest for $ery speci0c questions.

ommon uses!)arge num(ers of people

3eed (oth information and opinions

When designing for use outside the organiCation&customers8 $endors8 etc.'


47/57

Requirements Workshops"ore general than D &which in$ol$es

speci0c techniques'.5.g. thematic e%perts to elicit requirements

for a data model.

ll group acti$ities pro(a(ly (est in non4

contentious pro6ects.


48/57

Puestionnaire StepsSelect the participants #dentify the population9se representati$e samples for large populations

Designing the questionnaireareful question selectionRemo$e am(iguities

dministering the questionnaireWorking to get good response rateO/er an incenti$e &e.g.8 a free pen'

Puestionnaire follow4upSend results to participantsSend a thank4you

J d P i i


49/57

Jood Puestionnaire

DesignIegin with non4threatening and interesting

questions

Jroup items into logically coherent sections

3o important items at the $ery end

Do not crowd a page with too many items

$oid a((re$iations$oid (iased or suggesti$e items or terms

3um(er questions to a$oid confusion

1retest to identify confusing questions

1ro$ide anonymity to respondents


50/57

O(ser$ation9sersmanagers often donLt remem(er e$erything

they do

hecks $alidity of information gathered in other ways

Ieha$iors may change when people are watched

Workers tend to (e $ery careful when watched

Keep a low pro0le

Try not to interrupt or inFuence workers

Ie careful not to ignore periodic acti$ities

Weekly 7 "onthly 7 nnually


51/57

Requirements4Jathering

Techniques ompared com(ination of techniques may (e used

Document analysis E o(ser$ation require

little training D sessions can (e $erychallenging


52/57

oncept "aps

Represent meaningful relationships (etweenconcepts

2ocus indi$iduals on a small num(er of key ideas

an (e used to model!Requirements8oncepts

1rocesses8 etc. Then Feshed out in more detail in later parts of the process.

house street city

is in is in


53/57

Story ards E Task )ists

ssociated with agile de$elopment methods

Hery low tech8 high touch8 easily updata(le8 and $eryporta(le

apture requirement using story cards &inde% cards'2ile card with single requirement

5ach requirement &card' is discussed

Mow much e/ort is required to implement it

task list is created for each requirement &story')arge requirements can (e split into smaller sections

The story can (e prioritiCed (y risk le$el and importance

S t 1 l T l t


54/57

System 1roposal Template


55/57

ase Study! ustralian apital

Territory SD"S

Joal! to automate8 record8 ena(le landadministration

Two e%isting systems!D system

Oracle (ased te%tual system

Requirement! a single integrated system tosupport all (usiness functions


56/57

ase Study! ustralian apital

Territory SD"SSome requirements de0ned in the pro6ect

(rief.

Documents of $arious kinds!data models

registers and spreadsheets of work progress

legislation

we( pages.

Some sta/ felt threatened.


57/57

Summary1resented in this lecture!Discussion of functional and non4functional

requirements determination

Requirements analysis strategies pro(lem analysis8 root cause analysis8 duration analysis8

acti$ity4(ased costing analysis8 informal (enchmarkinganalysis8 outcome analysis8 technology analysis andacti$ity elimination

Requirements gathering techniques #nter$iews8 6oint application de$elopment8 questionnaires8

document analysis and o(ser$ation

lternati$e requirements documentation techniques concept maps8 story cards and task lists

The system proposal

Date post:	05-Jul-2018
Category:	Documents
Upload:	johnluce
View:	216 times
Download:	0 times