Techniques for Requirements Gathering and Definition. Kristian Persson Principal Product Specialist

Transcription

1 Techniques for Requirements Gthering nd Definition Kristin Persson Principl Product Specilist

2 Requirements Lifecycle Mngement Elicit nd define business/user requirements Vlidte requirements Anlyze requirements to define the solution Drive implementtion from the requirements Drive testing from the requirements Mnge trcebility nd chnge 2

3 Requirements Definition Requirements Definition Requirements Lifecycle Mngement Chnge Mngement Trcebility Impct Anlysis Reporting & Metrics Monitoring Business Anlysis Systems Anlysis & Implementtion Definition Vlidtion Anlysis Implementtion Test Definition Elicittion Specifiction Visuliztion Storybording 3

4 Distinguish between Problem nd Solution Risk of defining the wrong problem Problem definition Stkeholder Requirements Abstrct solution System Requirements Should be possible to chnge the design without chnging system requirements 4 Risk of unnecessrily constrining the solution Risk of not meeting the requirements Specific solution Design

5 Good Prctice: Distinguish between Problem nd Solution Problem nd Solution Wht cuses pples to fll off trees? Wht is the purpose of pples flling off trees? Wht re the user requirements for set of trffic lights to control trffic t rod junction? 5

6 Differentiting Problem nd Solution Problem Solution Customer requirements A description of the problem nd its context Results tht stkeholders wnt from the system Do not define the solution, other thn for environment Qulity of results Owned by stkeholders or their representtives (e.g. business) System requirements An bstrct representtion of the solution Wht the system does Do not define the design How well it does it Owned by IT or systems engineers The user shll be ble to... The system shll do. 6

7 Results of mixing Problem nd Solution Don t understnd the problem Cn t decide on functions Developers dominte Cn t do cceptnce User nd system constrints muddled Uncler ownership Disster! 7

8 Gthering requirements Problem domin Concentrte on wht the stkeholders wnt to be ble to do: i.e. Cpbilities Do not design the system System Level Concentrte on wht the system must do (function) Do not define the design (i.e. void sying how) Subsystem nd lower level components Concentrte on wht the subsystem or component must do (function) Mke design constrints explicit (e.g. interfce obligtions) Do not over constrin leds to inflexibility, builds in obsolescence, reduces/removes freedom to innovte Do not define the design (i.e. void sying how) 8

9 Good Prctice: Avoid premture detils Use the four key questions 1. Wht is the purpose? Focus on problem rther thn solution Recognize where requirement is stted s solution Express requirement in solution-free mnner 2. Wht is the underlying gol? Helps to express the requirement properly Helps to quntify the requirement Is it to mximise, minimise or optimise? 3. Is there n implied solution? Understnd why prticulr solution my be required Collect the constrints tht led to the suggested solution 4. How will you know if the need hs been met? Mke requirements quntifible nd testble (see lter) 9

10 Use concise, cler, consistent lnguge Ech requirement sttement should be: 1. Individul: ech sttement is single trceble element 2. Unique: ech sttement is uniquely identified 3. Cler: ech sttement is clerly understndble 4. Precise: ech sttement is precise nd concise 5. Abstrct: does not impose solution on the next lyer 6. Quntified: ech sttement hs cceptnce criteri 7. Testble: ech sttement cn be vlidted/verified 10

11 Good Prctice: Use concise, cler, consistent lnguge Six Things to Avoid 1. Rmbling: conciseness is virtue 2. Let-out cluses: such s if tht should be necessry ; they render the requirements useless 3. Multiple requirements: often indicted by nd, or, but, however 4. Vgue terms: usully, generlly, often, normlly, typiclly, user friendly, verstile, flexible 5. Wishful thinking: 100% relible, plese ll users, run on ll pltforms, hndle ll unexpected filures, upgrdeble to ll future situtions 6. Specultion: stick to wht you know 11

12 Good Prctice: Focus on documents s well s sttements Focus on documents s well s sttements Need to blnce two spects: Focus on the individul sttement of requirement (principle 4) : Lnguge Clrity, preciseness Identity, trcebility Sttements provide precision Focus on the requirements document: Understnding context Assessing completeness Identifying repetition/conflict Nvigting/serching requirements Documents provide context 12

13 Good Prctice: Focus on documents s well s sttements Structuring Documents - Gols Orgnizing requirements into the right structure cn help: Understnd lrge mounts of informtion Nvigte sets of requirements relting to prticulr topics Detect omissions nd duplictions Minimize the number of requirements Eliminte conflicts between requirements Evlute requirements sets Reuse requirements cross projects 13

14 Good Prctice: Focus on documents s well s sttements Seven Criteri for Requirements Documents Ech requirements set should be: 1. Complete / Sufficient: ll requirements re present 2. Consistent: no two requirements re in conflict 3. Non-redundnt: ech requirement is expressed once 4. Modulr: requirements sttements tht belong together re close to one nother 5. Structured: there is cler structure to the requirements document Define n outline structure t the outset, nd improve it s you go 6. Stisfied: the pproprite degree of design trcebility hs been chieved 7. Evluted: the pproprite degree of test trcebility hs been chieved 14

15 Understnd the role of modelling Requirements lyer Modeling lyer Requirements lyer Modeling lyer Requirements lyer Modeling lyer Requirements lyer The requirements re the bred nd butter of development. Wht is sndwich without the bred? Requirements lone re little dry. Modeling is wht mkes the whole rther more interesting. The filling holds the bred together. It is the bred nd the filling together tht mke sndwich. 15

16 Complementry techniques Requirements mngement: cpture of nd trcebility between individul textul requirements Modelling: multiple views of structured informtion consistency cn be checked cross the system using the model dt dictionry llows nimtion to be used s vlidtion technique The model is not the requirement non-functionl requirements re typiclly not cptured in model grphicl model is generlly insufficient s contrctul bsis 16

17 The Role of Models Modeling is used to understnd nd nlyze problem Models provide vitl mens of communiction with stkeholders tem members Modeling provides bsis for resoning bout: problem, potentil solutions, etc Modeling complements requirements engineering 17

18 Models Bridge Lyers of Requirements Requirements lyer Sttement of need Modeling lyer e.g Gol / Usge modeling Requirements lyer Stkeholder Requirements Modeling lyer Requirements lyer Modeling lyer Requirements lyer System Requirements Design Specifiction e.g. Functionl Functionl modeling modeling Functionl Functionl e.g. Architecture modeling modeling modeling 18

19 Requirements Definition Rtionl Requirements Composer* Requirements Definition for DOORS nd RequisitePro Rich Authoring Environment Web Review nd Approvl Rich Text Requirements Use Cses Glossries UI Sketching nd Storybording Collbortion Server Wiki style interfce Ctegorize / Tg Comment Review / Approve Shre work instntly Users / tems / uthoriztions Linking between ll rtifcts Versioning Process Sketching 19 RequisitePro DOORS *Not yet vilble; detils subject to chnge

20 Requirements Vlidtion Requirements Vlidtion Requirements Lifecycle Mngement Chnge Mngement Trcebility Impct Anlysis Reporting & Metrics Monitoring Business Anlysis Systems Anlysis & Implementtion Definition Vlidtion Anlysis Implementtion Test Vlidtion Prototyping Simultion Prioritiztion Review Define Test & Acceptnce Criteri 20

21 Model simultion for requirements vlidtion Use requirement scenrios to vlidte the design Simulte to verify tht model is correct Avoid errors Reduce costly rework Increse qulity Virtul prototype / Pnel grphics support Idel communictions id for design reviews nd to shre informtion. Expected Requirement Scenrio Simultion Results Telelogic Rhpsody Requirements Vlidtion 21

22 Requirements Vlidtion Prioritiztion Telelogic Focl Point 22

23 Quntifying requirements for testing Of every requirement sttement, sk: How will you know if the need hs been met? Improves the wy the requirement is expressed Is it quntified? Wht re the success criteri? Add requirements to mke system testble Pln the tests now, not lter: Wht kind of tests will be used? When will the tests be performed? Prepring the tests my tke months or yers: Collect requirements for test fcilities Trce tests to requirements Include tests in impct nlysis 23

24 Good Prctice: Quntify requirements for testing Quntifying Requirements Quntities relte to vilbility, coverge, timeliness, rediness... My be relted to cpbilities, functions or constrints sometimes mximum or minimum level set s constrint Defines the trde-off spce by indicting the scope for negotition between conflicting gols Gives requirements test criteri 24

25 Good Prctice: Quntify requirements for testing Quntifiction Exmple Requirement The system shll hndle simultneous users 100 Performnce Vlue to user Fil Pss Performnce Simplistic pproch 200 Best Vlue to user Pss 100 Pln Fil Vlue curve 50 Minimum cceptble Performnce 25

26 100 Chrcterising Quntifiction 100 vlue users performnce mximise 100 vlue vlue vlue users performnce exceed kg performnce minimise Krpm performnce optimise

27 Requirements Lifecycle Mngement Chnge Mngement Trcebility Impct Anlysis Reporting & Metrics Monitoring DOORS - Chnge Business Anlysis Definition Vlidtion DOORS, DOORS/TrceLine Anlysis Implementtion DOORS, Dshbord Systems Anlysis & Implementtion Test Requirements Composer DOORS/Anlyst DOORS T3 DOORS 27

28 Requirements Lifecycle Mngement Elicit nd define business/user requirements Vlidte requirements Anlyze requirements to define the solution Drive implementtion from the requirements Drive testing from the requirements Mnge trcebility nd chnge 28