Reikalavimų inžinerijos procesas Šie procesai naudojami sistemos

Скачать презентацию Reikalavimų inžinerijos procesas Šie procesai naudojami sistemos

f24b6044139feac23984909932e4be51.ppt

Количество слайдов: 115

Reikalavimų inžinerijos procesas • Šie procesai naudojami sistemos reikalavimų suradimui, analizavimui ir atestavimui. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 1

Tikslai l l Apibūdinti esmines reikalavimų inžinerijos pakopas. Supažindinti su reikalavimų išgavimo ir analizės metodais. Apibūdinti reikalavimų atestavimą. Aptarti reikalavimų vadybos įtaką kitiems reikalavimų inžinerijos procesams. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 2

Aptariamos temos l l l Galimybių tyrimas Reikalavimų išgavimas ir analizė Socialiniai ir organizaciniai faktoriai Reikalavimų atestavimas. Reikalavimų vadyba. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 3

Reikalavimų inžinerijos procesas l l Procesų, naudojamų RI, įvairovė kinta priklausomai nuo taikymo srities, su jais susijusių žmonių ir organizacijos, kuri kelia tuos reikalavimus. Žemiau išvardintos pakopos yra būdingos visiems procesams: • • ©Ian Sommerville 2000 Reikalavimų išgavimas Reikalavimų analizė Reikalavimų atestavimas Reikalavimų vadyba Software Engineering, 6 th edition. Chapter 6 Slide 4

Reikalavimų inžinerijos procesas ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 5

Reikalavimų inžinerijos procesas Galimybių tyrimas Reikalavimų išgavimas ir analizė Reikalavimų specifikavimas Galimybių ataskaita Sistemos modeliai Reikalavimų atestavimas Vartotojo ir sistemos reikalavimai Reikalavimų dokumentas ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 6

Reikalavimų inžinerija ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 7

Aptariamos temos l l l Galimybių tyrimas. Reikalavimų išgavimas ir analizė Socialiniai ir organizaciniai faktoriai Reikalavimų atestavimas. Reikalavimų vadyba. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 8

Galimybių tyrimas l l Galimybių tyrimai nustato, ar verta toliau kurti siūlomą sistemą. Trumpas koncentruotas tyrimas tikrina ar: • • • sistema atitinka organizacijos tikslus; sistema gali būti sukurta naudojant turimą technologiją ir vidinį biudžetą; sistema bus suderinama su jau naudojamomis sistemomis. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 9

Galimybių tyrimo realizavimas l l Pagrįstas informacijos įvertinimu (ko yra reikalaujama), informacijos kaupimu ir ataskaitų rašymu. Klausimai organizacijos darbuotojams: • • • ©Ian Sommerville 2000 Kas būtų, jei sistema nebūtų įdiegta? Kokie yra dabartinių procesų trūkumai? Kaip siūloma sistema padės? Kokios bus integravimo problemos? Ar reikės naujų technologijų? Kokių įgūdžių? Kokius darbo palengvinimus turėtų užtikrinti siūloma sistema? Software Engineering, 6 th edition. Chapter 6 Slide 10

Aptariamos temos l l l Galimybių tyrimas Reikalavimų išgavimas ir analizė Socialiniai ir organizaciniai faktoriai Reikalavimų atestavimas Reikalavimų vadyba ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 11

Išgavimas ir analizė l l l Kartais tai vadinama reikalavimų iškėlimu ar reikalavimų atradimu. Apima techninį personalą dirbantį su užsakovais, kad sužinotų apie taikymo sritį, paslaugas, kurias turėtų teikti sistema, ir sistemos darbo apribojimus. Gali apimti galutinius vartotojus, vadybininkus, palaikymo/aptarnavimo inžinierius, srities ekspertus, profsąjungas ir t. t. Jie vadinami užsakovais (suinteresuotais asmenimis). ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 12

Reikalavimų analizės problemos l l l Suinteresuoti asmenys dažnai nežino, ko jie iš tiesų nori. Suinteresuoti asmenys išreiškia savo reikalavimus savais terminais. Skirtingi suinteresuoti asmenys gali kelti tarpusavyje nesuderinamų reikalavimų. Organizaciniai ir politiniai faktoriai gali įtakoti reikalavimus sistemai. Reikalavimai keičiasi analizės proceso metu. Gali atsirasti naujų suinteresuotų asmenų, ir tai pakeis verslo aplinką. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 13

Reikalavimų spiralė ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 14

Reikalavimų analizės procesas Reikalavimų apibrėžimas ir specifikacijos Reikalavimų atestavimas Prioritetų nustatymas Reikalavimų surinkimas Proceso įeiga Probleminės srities supratimas Konfliktų sprendimas Klasifikavimas ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 15

Proceso pakopos l l l Srities supratimas Reikalavimų surinkimas Klasifikavimas Konfliktų analizė/sprendimas Prioritetų nustatymas Reikalavimų atestavimas ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 16

Sistemos modeliai l l Skirtingi sistemos modeliai naudojami reikalavimų analizės metu. Reikalavimų analizė gali apimti tris struktūrines pakopas, kurios atsispindi skirtinguose modeliuose: • • • Padalinimas (dekompozicija). Identifikuoja struktūrinius ryšius tarp esybių. Apibendrinimas (abstrakcija). Identifikuoja bendrumus tarp esybių. Projekcija, perspektyva. Identifikuoja skirtingus požiūrius į problemą. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 17

Reikalavimų išgavimas pagal skirtingus požiūrius l l Suinteresuotų asmenų požiūriai į problemą yra skirtingi. Ši daugiaperspektyvinė analizė yra svarbi todėl, kad nėra vienintelio teisingo būdo sistemos reikalavimų analizei. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 18

Bankomato (ATM -automatic teller machine) sistema l l l Čia naudojamas pavyzdys yra bankomatas, kuris teikia tam tikras automatizuotas banko operacijas. Naudojama labai supaprastinta sistema, kuri siūlo tam tikras paslaugas banko - šios sistemos savininko - klientams ir siauresnę paslaugų sferą kitiems klientams. Paslaugos apima grynųjų pinigų išėmimą, žinutės siuntimą (tam, kad išsikviesti paslaugą), užsakymus ir lėšų pervedimą. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 19

Galimi požiūriai į bankomatą l l l l Banko klientų Kitų bankų atstovų Aparatūrinės ir programinės įrangos palaikymo inžinierių Marketingo departamento Banko valdytojų ir buhalterinio personalo Duomenų bazės administratorių ir apsaugos personalo Komunikacijos inžinierių Personalo departamento ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 20

Išoriniai požiūriai l l Natūralu galutinius vartotojus laikyti sistemos teikiamų paslaugų gavėjais. Požiūriai yra natūralus būdas reikalavimų išgavimo struktūrizavimui. Interviu yra pagrindinė priemonė požiūriųišryškinimui. Požiūriai ir paslaugos yra tinkami nefunkcinių reikalavimų struktūrizavimui. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 21

Požiūrių identifikavimas ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 22

Scenarijai l l l Scenarijai – tai aprašymai, kaip sistema naudojama praktiškai. Jie padeda formuojant reikalavimus, kadangi žmonės reikalavimus geriau susieja su scenarijais, negu su abstrakčiais teiginiais, nusakančiais, ko jie reikalauja iš sistemos. Scenarijai yra ypač naudingi detalizuojant reikalavimų aprašymo eskizą. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 23

Scenarijaus aprašymas l l l Sistemos būsena scenarijaus pradžioje Normali įvykių eiga scenarijuje Kas blogo gali atsitikti ir kaip tai sutvarkyti Kiti lygiagretūs veiksniai Sistemos būsena scenarijaus pabaigoje ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 24

Įvykių scenarijus l l Įvykių scenarijus gali būti naudojamas aprašyti, kaip sistema reaguoja į tam tikrus reiškinius pavyzdžiui, įvykis “pradėti sandėrį”. Metodai turi sutartinį schematinį vaizdavimą įvykių scenarijui: • • Tiekiami ir pristatomi duomenys Kontrolės ir valdymo informacija Išimčių apdorojimas Kitas laukiamas įvykis ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 25

Event scenario - start transaction ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 26

Duomenų ir valdymo analizės žymėjimas l l l Elipsės. Duomenys tiekiami iš požiūrio taško arba pristatomi jam. Valdymo informacija įeina ir išeina kiekvieno stačiakampio viršuje. Duomenys išeina iš stačiakampio dešinės. Išimtys yra parodomos stačiakampio apačioje. Sekančio įvykio pavadinimas yra stačiakampyje su storesniais kraštais. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 27

Išimčių aprašymas l l Dauguma metodų neteikia galimybės išimčių aprašymui. Šiame pavyzdyje išimtys yra: • • • Laiko limito pabaiga. Laiko limitas. Klientas neįveda PIN per skirtą laiko limitą. Bloga kortelė. Kortelė neatpažįstama ir grąžinama. Vogta kortelė. Kortelė buvo užregistruota kaip vogta ir bankomatas ją sulaiko. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 28

Panaudojimo atvejai l l l “Panaudojimo atvejai” yra scenarijais pagrįstas UML (Unified Modelling Language) metodas, kuris identifikuoja veikėjus sąveikos metu ir aprašo pačią saveiką. Panaudojimo atvejų rinkinys turi aprašyti visas galimas sąveikas su sistema. Sekų diagramos gali būti naudojamos panaudojimo atvejų detalizavimui, parodant sistemoje vykstančių įvykių seką. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 29

Lending use-case ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 30

Library use-cases ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 31

Catalogue management ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 32

Socialiniai ir organizaciniai faktoriai l l l Programinės įrangos sistemos yra naudojamos socialinėje ir organizacinėje aplinkoje. Tai gali įtakoti ar net užgožti sistemos reikalavimus. Socialiniai ir organizaciniai faktoriai nėra vienintelis požiūris. Jie įtakoja visus požiūrius. Geri analitikai turi atsižvelgti į šiuos faktorius, bet dabartiniu metu nėra sistemingo būdo sujungti jų analizes. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 34

Pavyzdys l Nagrinėkim sistemą, kuri leistų aukštesnio lygio vadovui pasiekti informaciją, “neliečiant” vidutinio lygio vadovų. • • • Vadovo statusas. Viršesni vadovai gali jaustis per daug svarbūs, kad naudotų klaviatūrą. Tai gali apriboti sistemos naudojamą sąsajos tipą. Vadovo pareigos. Vadovai gali neturėti laisvo laiko, kurį galėtų skirti mokymuisi dirbti su sistema. Prieštaravimai organizacijoje. Vidutinio atsakomybės lygio vadovai, kurių gali nebereikėti, gali tyčia pateikti blogą ar nesuderinamą informaciją, kuri “nulaužtų” sistemą. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 35

Stebėjimas l l Socialinių mokslų srities mokslininkai praleidžia daug laiko stebėdami ir analizuodami, kaip žmonės iš tiesų dirba. Žmonės neturi aiškinti ar tiksliai apibūdinti savo darbo. Svarbūs socialiniai ir organizaciniai faktoriai gali būti stebimi. Tyrimai parodė, kad darbas yra paprastai turtingesnis ir sudėtingesnis, nei teigiama paprastų sistemų modeliuose. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 36

Aktyvus stebėjimas l l Naudojamas projekte, nagrinėjančiame lėktuvų eismo kontroliavimo procesą. Derina stebėjimą su maketavimu. Prototipų kūrimo rezultatas – atsakyti į klausimus, kuriems reikalingas aktyvus stebėjimas. Stebėjimo problema yra ta, kad ji nagrinėja egzistuojančią praktiką, kuri gali būti labiau istorinė ir dabar jau praradusi savo reikšmę. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 37

Stebėjimas ir prototipai Stebėjimų analizė Apklausa per susitikimus Aktyvus stebėjimas Prototipų vystymas Bendras sistemos vystymas ©Ian Sommerville 2000 Sistemos prototipavimas Software Engineering, 6 th edition. Chapter 6 Slide 38

Reikalavimai stebėjimui l l Reikalavimai, kurie kildinami iš to, kaip žmonės dirba iš tikrųjų, o ne kaip jiems siūloma dirbti. Reikalavimai, išvesti iš bendradarbiavimo ir kitų žmonių darbų supratimo. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 39

Reikalavimų atestavimas l l Čia įrodinėjama, kad reikalavimai apibūdina tikrai tokią sistemą, kokios nori vartotojas. Reikalavimų klaidos kainuoja brangiai, taigi atestavimas yra ypač svarbus. • Reikalavimų klaidų taisymas po pristatymo gali kainuoti 100 kartų brangiau nei veikimo klaidų taisymas. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 41

Reikalavimų atestavimas l l l Teisingumas. Ar sistema atlieka funkcijas, geriausiai atitinkančias vartotojo reikalavimus? Nuoseklumas. Ar nėra reikalavimų konfliktų? Pilnumas. Ar įtrauktos visos funkcijos, kurių reikalauja vartotojas? Realistiškumas. Ar reikalavimai gali būti įgyvendinti su turimu biudžetu ir technologija? Patikrinamumas. Ar gali reikalavimai būti patikrinami ? ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 42

Reikalavimų atestavimo metodika l Reikalavimų apžvalga • l Prototipų kūrimas • l Vykdomojo sistemos modelio naudojimas reikalavimų patikrinimui. . Apžvelgiamas 8 dalyje. Testavimo atvejų generavimas • l Sisteminga neautomatizuota reikalavimų analizė. Testų reikalavimams kūrimas testavimo galimybei tikrinti. Automatizuota nuoseklumo analizė • Struktūrizuotų reikalavimų aprašymo nuoseklumo tikrinimas. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 43

Reikalavimų peržiūra l l l Reguliarios peržiūros turi trukti tol, kol formuluojamas reikalavimų apibrėžimas. Ir kliento, ir rangovo personalas turi būti įtraukti į peržiūras Apžvalgos turi būti formalios (su pilnai baigtais dokumentais) arba neformalios. Glaudus bendravimas tarp kūrėjų, klientų ir vartotojų gali išspręsti problemas ankstyvoje stadijoje. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 44

Peržiūros tikrinimai l l Patikrinamumas. Ar reikalavimą tikrai galima patikrinti (testuoti)? Išsamumas. Ar reikalavimai teisingai suprasti? Sekamumas. Ar reikalavimų kilmė yra aiškiai suformuluota? Prisitaikomumas. Ar gali reikalavimas pasikeisti be didelio poveikio kitiems reikalavimams? ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 45

Automated consistency checking ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 46

Automatinis suderinamumo tikrinimas Reikalavimai formaliomis kalbomis Reikalavimų problemų ataskaita Reikalavimų procesorius Reikalavimų analizatorius Reikalavimų duomenų bazė ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 47

Aptariamos temos l l Galimybių tyrimas. Reikalavimų išgavimas ir analizė. Reikalavimų atestavimas. Reikalavimų vadyba. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 48

Reikalavimų vadyba l l Reikalavimų vadyba - tai procesas, koordinuojantis reikalavimų pasikeitimus reikalavimų inžinerijos ir sistemos kūrimo procese. Reikalavimai neišvengiamai yra neišbaigti ir nepastovūs. • • Nauji reikalavimai atsiranda keičiantis verslo reikmėms ir kuriant geresnį sistemos supratimą. Skirtingi požiūriai iškelia skirtingus reikalavimus, kurie dažnai būna prieštaringi. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 50

Reikalavimų pakeitimai l l l Reikalavimų, kylančių iš skirtingų požiūrių, prioritetai keičiasi kūrimo procese. Sistemos užsakovai gali apibrėžti reikalavimus, kylančius iš verslo perspektyvų, kurie gali kirstis su galutinio vartotojo reikalavimais. Verslo ir techninė aplinka keičiasi sistemos kūrimo metu. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 51

Requirements evolution ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 52

Reikalavimų vystymasis Pradinis problemos supratimas Pasikeitęs problemos supratimas Pradiniai reikalavimai Pasikeitę reikalavimai Laikas ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 53

Pastovūs ir kintantys reikalavimai l l Pastovūs reikalavimai. Formuluojami nagrinėjant pagrindinę užsakovo organizacijos veiklą. Pvz. : ligoninė visada turi turėti daktarus, seseles ir pan. Gali būti gaunami iš veiklos srities modelio. Kintantys reikalavimai. Reikalavimai, kintantys sistemos kūrimo ar eksplotavimo metu. Ligoninėje reikalavimus formuoja sveikatos apsaugos politika. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 54

Pastovių ir kintamų reikalavimų klasifikavimas l Mutuojantys reikalavimai • l Paaiškėjantys reikalavimai • l Reikalavimai, išaiškėjantys kuriant sistemą. Iškylantys reikalavimai • l Reikalavimai, kintantys dėl sistemos aplinkos. Reikalavimai, kylantys diegiant kompiuterinę sistemą. Suderinamumo reikalavimai • Reikalavimai, priklausantys nuo kitų sistemų ar organizacijos procesų. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 55

Reikalavimų vadybos planavimas l Reikalavimų inžinerijos procese reikia planuoti: • Reikalavimų identifikavimas » Kaip reikalavimai individualiai identifikuojami • Pakeitimų vadybos procesas » Procesas, vykstantis analizuojant reikalavimų pasikeitimus • Sekamumo politika » Visuma informacijos apie reikalavimų tarpusavio santykius, kurie yra išlaikomi • CASE priemonių palaikymas » Priemonių palaikymas reikalingas tam, kad padėtų valdyti reikalavimų pasikeitimus ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 56

Reikalavimų sekamumas l l Sekamumo paskirtis – tai ryšiai tarp reikalavimų, jų šaltinių ir sistemos kūrimo. Šaltinių sekamumas • l Reikalavimų sekamumas • l Nuoroda iš reikalavimo į užsakovus, pateikusius šį reikalavimą. Nuorodos tarp priklausomų reikalavimų Kūrimo sekamumas • Nuorodos iš reikalavimų į kūrimą ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 57

CASE priemonių palaikymas l Reikalavimų saugykla • l Pasikeitimų vadyba • l Reikalavimai turi būti sudėti saugioje, valdomoje duomenų saugykloje. Pasikeitimų valdymo procesas yra darbų sekos procesas, kurio etapai gali būti apibrėžti. Informacijos srautas tarp šių etapų yra iš dalies automatizuotas. Sekamumo vadyba • Automatinis nuorodų tarp reikalavimų grąžinimas ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 58

Reikalavimų pasikeitimų vadyba l l Turi būti taikoma visiems siūlomiems reikalavimų pakeitimams. Pagrindiniai etapai: • • • Problemos analizė - apsvarstyti reikalavimuose iškilusią problemą ir pasiūlyti pakeitimus. Pakeitimų analizė ir kaina - įvertinti pakeitimų įtaką kitiems reikalavimams. Pakeitimų įgyvendinimas - modifikuoti reikalavimų ir kitus dokumentus taip, kad atsispindėtų pakeitimai. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 59

Requirements change management ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 60

Reikalavimų pakeitimų vadyba Nustatyta problema Problemos analizė ir pakeitimų specifikavimas ©Ian Sommerville 2000 Pakeitimų analizė ir įkainavimas Software Engineering, 6 th edition. Chapter 6 Pakeitimų įgyvendinimas Ištaisyti reikalavimai Slide 61

Esminiai akcentai l l l Reikalavimų inžinerijos procesas apima galimybių tyrimą, reikalavimų iškėlimą ir analizę, reikalavimų specifikavimą ir reikalavimų vadybą. Reikalavimų analizę sudaro šios periodiškai pasikartojančios pakopos: srities supratimas, reikalavimų surinkimas, klasifikavimas, struktūrizavimas, prioritetizavimas ir atestavimas. Yra daug sistemos užsakovų (suinteresuotų asmenų), keliančių skirtingus reikalavimus. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 62

Esminiai akcentai l l Socialiniai ir organizaciniai faktoriai įtakoja reikalavimus sistemai. Reikalavimų atestavimas yra susijęs su teisingumo, nuoseklumo, pilnumo, realumo ir tikrinamumo patikrinimais. Verslo pasikeitimai neišvengiamai verčia keisti reikalavimus. Reikalavimų vadyba apima planavimą ir pasikeitimų valdymą. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 63

Requirements Engineering Processes ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 64

Objectives l l To describe the principal requirements engineering activities and their relationships To introduce techniques for requirements elicitation and analysis To describe requirements validation and the role of requirements reviews To discuss the role of requirements management in support of other requirements engineering processes ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 65

Topics covered l l Feasibility studies Requirements elicitation and analysis Requirements validation Requirements management ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 66

Requirements engineering processes l l The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements. However, there a number of generic activities common to all processes • • ©Ian Sommerville 2000 Requirements elicitation; Requirements analysis; Requirements validation; Requirements management. Software Engineering, 6 th edition. Chapter 6 Slide 67

The requirements engineering process ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 68

Requirements engineering ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 69

Feasibility studies l l A feasibility study decides whether or not the proposed system is worthwhile. A short focused study that checks • • • ©Ian Sommerville 2000 If the system contributes to organisational objectives; If the system can be engineered using current technology and within budget; If the system can be integrated with other systems that are used. Software Engineering, 6 th edition. Chapter 6 Slide 70

Feasibility study implementation l l Based on information assessment (what is required), information collection and report writing. Questions for people in the organisation • • • ©Ian Sommerville 2000 What if the system wasn’t implemented? What are current process problems? How will the proposed system help? What will be the integration problems? Is new technology needed? What skills? What facilities must be supported by the proposed system? Software Engineering, 6 th edition. Chapter 6 Slide 71

Elicitation and analysis l l l Sometimes called requirements elicitation or requirements discovery. Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints. May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 72

Problems of requirements analysis l l l Stakeholders don’t know what they really want. Stakeholders express requirements in their own terms. Different stakeholders may have conflicting requirements. Organisational and political factors may influence the system requirements. The requirements change during the analysis process. New stakeholders may emerge and the business environment change. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 73

The requirements spiral ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 74

Process activities l Requirements discovery • l Requirements classification and organisation • l Groups related requirements and organises them into coherent clusters. Prioritisation and negotiation • l Interacting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage. Prioritising requirements and resolving requirements conflicts. Requirements documentation • ©Ian Sommerville 2000 Requirements are documented and input into the next round of the spiral. Software Engineering, 6 th edition. Chapter 6 Slide 75

Requirements discovery l l The process of gathering information about the proposed and existing systems and distilling the user and system requirements from this information. Sources of information include documentation, system stakeholders and the specifications of similar systems. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 76

ATM stakeholders l l l l l Bank customers Representatives of other banks Bank managers Counter staff Database administrators Security managers Marketing department Hardware and software maintenance engineers Banking regulators ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 77

Viewpoints l l Viewpoints are a way of structuring the requirements to represent the perspectives of different stakeholders. Stakeholders may be classified under different viewpoints. This multi-perspective analysis is important as there is no single correct way to analyse system requirements. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 78

Types of viewpoint l Interactor viewpoints • l Indirect viewpoints • l People or other systems that interact directly with the system. In an ATM, the customer’s and the account database are interactor VPs. Stakeholders who do not use the system themselves but who influence the requirements. In an ATM, management and security staff are indirect viewpoints. Domain viewpoints • ©Ian Sommerville 2000 Domain characteristics and constraints that influence the requirements. In an ATM, an example would be standards for inter-bank communications. Software Engineering, 6 th edition. Chapter 6 Slide 79

Viewpoint identification l Identify viewpoints using • • • ©Ian Sommerville 2000 Providers and receivers of system services; Systems that interact directly with the system being specified; Regulations and standards; Sources of business and non-functional requirements. Engineers who have to develop and maintain the system; Marketing and other business viewpoints. Software Engineering, 6 th edition. Chapter 6 Slide 80

Interviewing l l In formal or informal interviewing, the RE team puts questions to stakeholders about the system that they use and the system to be developed. There are two types of interview • • ©Ian Sommerville 2000 Closed interviews where a pre-defined set of questions are answered. Open interviews where there is no pre-defined agenda and a range of issues are explored with stakeholders. Software Engineering, 6 th edition. Chapter 6 Slide 82

Interviews in practice l l l Normally a mix of closed and open-ended interviewing. Interviews are good for getting an overall understanding of what stakeholders do and how they might interact with the system. Interviews are not good for understanding domain requirements • • ©Ian Sommerville 2000 Requirements engineers cannot understand specific domain terminology; Some domain knowledge is so familiar that people find it hard to articulate or think that it isn’t worth articulating. Software Engineering, 6 th edition. Chapter 6 Slide 83

Effective interviewers l l Interviewers should be open-minded, willing to listen to stakeholders and should not have preconceived ideas about the requirements. They should prompt the interviewee with a question or a proposal and should not simply expect them to respond to a question such as ‘what do you want’. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 84

Scenarios l l Scenarios are real-life examples of how a system can be used. They should include • • • ©Ian Sommerville 2000 A description of the starting situation; A description of the normal flow of events; A description of what can go wrong; Information about other concurrent activities; A description of the state when the scenario finishes. Software Engineering, 6 th edition. Chapter 6 Slide 85

Use cases l l l Use-cases are a scenario based technique in the UML which identify the actors in an interaction and which describe the interaction itself. A set of use cases should describe all possible interactions with the system. Sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 88

Social and organisational factors l l l Software systems are used in a social and organisational context. This can influence or even dominate the system requirements. Social and organisational factors are not a single viewpoint but are influences on all viewpoints. Good analysts must be sensitive to these factors but currently no systematic way to tackle their analysis. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 93

Ethnography l l A social scientists spends a considerable time observing and analysing how people actually work. People do not have to explain or articulate their work. Social and organisational factors of importance may be observed. Ethnographic studies have shown that work is usually richer and more complex than suggested by simple system models. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 94

Focused ethnography l l Developed in a project studying the air traffic control process Combines ethnography with prototyping Prototype development results in unanswered questions which focus the ethnographic analysis. The problem with ethnography is that it studies existing practices which may have some historical basis which is no longer relevant. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 95

Scope of ethnography l l Requirements that are derived from the way that people actually work rather than the way I which process definitions suggest that they ought to work. Requirements that are derived from cooperation and awareness of other people’s activities. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 97

Requirements validation l l Concerned with demonstrating that the requirements define the system that the customer really wants. Requirements error costs are high so validation is very important • ©Ian Sommerville 2000 Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error. Software Engineering, 6 th edition. Chapter 6 Slide 98

Requirements checking l l l Validity. Does the system provide the functions which best support the customer’s needs? Consistency. Are there any requirements conflicts? Completeness. Are all functions required by the customer included? Realism. Can the requirements be implemented given available budget and technology Verifiability. Can the requirements be checked? ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 99

Requirements validation techniques l Requirements reviews • l Prototyping • l Systematic manual analysis of the requirements. Using an executable model of the system to check requirements. Covered in Chapter 17. Test-case generation • ©Ian Sommerville 2000 Developing tests for requirements to check testability. Software Engineering, 6 th edition. Chapter 6 Slide 100

Requirements reviews l l l Regular reviews should be held while the requirements definition is being formulated. Both client and contractor staff should be involved in reviews. Reviews may be formal (with completed documents) or informal. Good communications between developers, customers and users can resolve problems at an early stage. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 101

Review checks l l Verifiability. Is the requirement realistically testable? Comprehensibility. Is the requirement properly understood? Traceability. Is the origin of the requirement clearly stated? Adaptability. Can the requirement be changed without a large impact on other requirements? ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 102

Requirements management l l Requirements management is the process of managing changing requirements during the requirements engineering process and system development. Requirements are inevitably incomplete and inconsistent • • ©Ian Sommerville 2000 New requirements emerge during the process as business needs change and a better understanding of the system is developed; Different viewpoints have different requirements and these are often contradictory. Software Engineering, 6 th edition. Chapter 6 Slide 103

Requirements change l l l The priority of requirements from different viewpoints changes during the development process. System customers may specify requirements from a business perspective that conflict with end-user requirements. The business and technical environment of the system changes during its development. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 104

Enduring and volatile requirements l l Enduring requirements. Stable requirements derived from the core activity of the customer organisation. E. g. a hospital will always have doctors, nurses, etc. May be derived from domain models Volatile requirements. Requirements which change during development or when the system is in use. In a hospital, requirements derived from health-care policy ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 106

Requirements management planning l During the requirements engineering process, you have to plan: • Requirements identification » How requirements are individually identified; • A change management process » The process followed when analysing a requirements change; • Traceability policies » The amount of information about requirements relationships that is maintained; • CASE tool support » The tool support required to help manage requirements change; ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 108

Traceability l l Traceability is concerned with the relationships between requirements, their sources and the system design Source traceability • l Requirements traceability • l Links from requirements to stakeholders who proposed these requirements; Links between dependent requirements; Design traceability • ©Ian Sommerville 2000 Links from the requirements to the design; Software Engineering, 6 th edition. Chapter 6 Slide 109

CASE tool support l Requirements storage • l Change management • l Requirements should be managed in a secure, managed data store. The process of change management is a workflow process whose stages can be defined and information flow between these stages partially automated. Traceability management • ©Ian Sommerville 2000 Automated retrieval of the links between requirements. Software Engineering, 6 th edition. Chapter 6 Slide 111

Requirements change management l l Should apply to all proposed changes to the requirements. Principal stages • • • ©Ian Sommerville 2000 Problem analysis. Discuss requirements problem and propose change; Change analysis and costing. Assess effects of change on other requirements; Change implementation. Modify requirements document and other documents to reflect change. Software Engineering, 6 th edition. Chapter 6 Slide 112

Key points l l l The requirements engineering process includes a feasibility study, requirements elicitation and analysis, requirements specification and requirements management. Requirements elicitation and analysis is iterative involving domain understanding, requirements collection, classification, structuring, prioritisation and validation. Systems have multiple stakeholders with different requirements. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 114

Key points l l Social and organisation factors influence system requirements. Requirements validation is concerned with checks for validity, consistency, completeness, realism and verifiability. Business changes inevitably lead to changing requirements. Requirements management includes planning and change management. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 6 Slide 115