Programų sistemų inžinerija

7 paskaita

Reikalavimų inžinerijos procesai

Skaidrės paruoštos remianti I. Sommerville medžiaga

Reikalavimų inžinerijos veiklos

Galimybių studija

Reikalavimų išsiaiškinimas ir analizė

Reikalavimų specifikavimas (užrašymas standartine

forma)

Reikalavimų atestavimas/validavimas/vertinimas

(tikrinimas ar reikalavimai atitinka užsakovo lūkesčius

ir poreikius)

Reikalavimų vadyba

Tikslai

Apibrėžti pagrindines reikalavimų inžinerijos veiklas.

Supažindinti su reikalavimų išsiaiškinimo ir analizės

metodais.

Apibūdinti reikalavimų atestavimo procesą.

Aptarti reikalavimų vadybos įtaką kitiems

reikalavimų inžinerijos procesams.

Reikalavimų inžinerijos veiklos

Galimybių

studija

Reikalavimų

išsiaiškinimas ir

analizė

Reikalavimų

atestavimas

Reikalavimų

specifikavimas Galimybių

ataskaita

Sistemos

modeliai

Vartotojo

ir sistemos

reikalavimai

Reikalavimų

dokumentas

Reikalavimų inžinerija Requirements

specification

Requirements

validation

Requirementselicitation

Sy stem requirements

specification andmodeling

Sy stem

requirementselicitation

User requirementsspecification

Userrequirements

elicitation

Business requirementsspecification

Prototy ping

Feasibility

study

Reviews

Syst em requirements

document

Reikalavimų inžinerijos veiklos

Galimybių studija (į ką koncentruojasi galimybių tyrimas, tyrimo realizavimas, klausimai organizacijos darbuotojams)

Reikalavimų išsiaiškinimas ir analizė

Reikalavimų specifikavimas

Reikalavimų atestavimas (vertinimas).

Reikalavimų vadyba.

Galimybių studija

Galimybių studijos tikslas - nustatyti, ar verta iš

principo kurti programų sistemą.

Trumpas koncentruotas galimybių tyrimas tikrina ar:

• Būsima PI sistema atitiks organizacijos tikslus;

• PI sistema gali būti sukurta naudojant turimą technologiją

ir vidinį užsakovo biudžetą;

• PI sistema bus suderinama su jau užsakovo

naudojamomis programų sistemomis.

Galimybių studijos realizavimas

Pagrįstas informacijos įvertinimu (ko yra

reikalaujama), informacijos kaupimu ir ataskaitų

rašymu.

Klausimai organizacijos darbuotojams: • 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?

Reikalavimų inžinerijos veiklos

Galimybių studija

Reikalavimų išsiaiškinimas ir analizė (reikalavimų analizės problemos, reikalavimų analizės spiralė, reikalavimų

analizės procesas, pakopos, reikalavimų analizės modeliai,

banko automato pavyzdys, scenarijai, jų aprašymai,

žymėjimai, išimtys, panaudos atvejai, socialiniai ir

organizaciniai faktoriai, stebėjimas)

Reikalavimų specifikavimas

Reikalavimų atestavimas

Reikalavimų vadyba

Reikalavimų išsiaiškinimas ir analizė

Reikalavimų išsiaiškinimas arba dar vadinamas reikalavimų atradimas apima:

techninį personalą, dirbantį su užsakovais, kad sužinotų apie PI taikymo sritį, paslaugas, kurias turėtų teikti PI sistema, ir programų sistemos darbo apribojimus.

Reikalavimai gali būti surenkami ir iš galutinių PI sistemos vartotojų, vadybininkų, palaikymo/aptarnavimo inžinierių, srities ekspertų, profsąjungų ir t.t.

Bendrai šie žmonės vadinami užsakovais arba suinteresuotais asmenimis (stakeholders).

Reikalavimų išsiaiškinimas

Reikalavimų išsiaiškinimui naudojami tokie metodai:

Interviu su suinteresuotais asmenimis;

Scenarijai (įvykių sekos, vykdant tam tikrą veiklą

aprašymas);

Atvejų diagramos (use case diagrams).

Reikalavimų surinkimo sunkumai

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

nesuderinamus reikalavimus.

Organizaciniai ir politiniai faktoriai gali įtakoti reikalavimus

sistemai.

Reikalavimai keičiasi analizės proceso metu. Gali atsirasti

naujų suinteresuotų asmenų, ir taip pakeisti verslo aplinką.

Reikalavimų analizės spiralė

Requirementsclassification and

organisation

Requirementsprioritization and

negotiation

Requirements

documentation

Requirements

discovery

Reikalavimų surinkimo ir analizės procesas

Probleminės srities

supratimas

Reikalavimų

surinkimas

Reikalavimų

atestavimas

Prioritetų

nustatymas

Konfliktų

sprendimas

Klasifikavimas

Reikalavimų

apibrėžimas ir

specifikacijos

Proceso

įeiga

Reikalavimų proceso pakopos

Srities supratimas

Reikalavimų surinkimas

Klasifikavimas

Konfliktų analizė ir sprendimas

Prioritetų nustatymas

Reikalavimų atestavimas

Reikalavimų išsiaiškinimas

Bendrai paėmus, suinteresuotų asmenų požiūriai į

problemą ar tam tikrą veiklą yra skirtingi, todėl

susiformuoja skirtingi požiūriai į tą pačia problemą.

Pvz: vadovo, vadybininko, techninio inžinieriaus, IT

specialisto ir t.t.

Ši daugiaperspektyvinė analizė yra svarbi todėl, kad

iš esmės galime teigti, kad nėra vienintelio teisingo

būdo sistemos reikalavimų analizei.

Bankomato pavyzdys

Pavyzdys - bankomatas, kuris teikia tam tikras

automatizuotas banko operacijas.

Naudojama labai supaprastinta sistema, kuri siūlo tam

tikras paslaugas banko.

Paslaugos apima grynųjų pinigų išėmimą, žinutės

siuntimą (tam, kad išsikviesti paslaugą), užsakymus ir

lėšų pervedimą.

Galimi požiūriai į bankomatą

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

Skirtingi požiūriai

Skirtingi požiūriai į problemą yra natūralus reiškinys.

Juos analizuojant suformuluojami struktūrizuoti

reikalavimai.

Interviu yra pagrindinė priemonė skirtingų požiūrių į

problemą išryškinimui.

Skirtingi požiūriai yra tinkami norint suformuoti

struktūrizuotus nefunkcinius reikalavimus.

Interviu tipai

Interviu gali būti dviejų tipų:

Interviu, per kurį suinteresuoti asmenys atsako į iš

anksto sudarytus klausimus. Klausimus sudaro

reikalavimų inžinierius (analitikas).

Atviras interviu, kai klausimai formuluojami

betarpiškai apklausos metu.

Interviu netinka siekiant išsiaiškinti organizacinius

reikalavimus ir apribojimus, nes egzistuoja daug skirtingų

požiūrių ir supratimų apie tai.

Scenarijai

Scenarijus – tai rašytinis veiklos aprašymas, kaip ji

vyksta praktiškai.

Scenarija 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ą.

Scenarijaus aprašymas

Scenarijaus turinys susideda iš tokių skyrių:

Aprašas, ko vartotojai tikisi iš būsimos PI sistemos

Įvykių eigos aprašymas

Aprašymas, kas blogo gali atsitikti ir kaip tai reikia

sutvarkyti

Aprašas, apie kitas veiklas, kurios gali vykti

lygiagrečiai

Sistemos būsena scenarijaus pabaigoje

Įvykių scenarijus

Įvykių (event) 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

Įvykių scenarijus – ATM transakcija

Validate user

Request PIN

Select

serviceTimeout

Return card

Invalid card

Return card

Stolen card

Retain card

Incorrect PIN

Re-enter PIN

Incorrect PIN

Return card

Card

PIN

Card present

Accountnumber

PIN

Account

number

Valid card

User OK

Duomenų ir valdymo analizės žymėjimas

Elipsės. Duomenys tiekiami iš požiūrio taško arba

pristatomi jam.

Valdymo informacija įeina ir išeina kiekvieno

stačiakampio sienų išorėje.

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.

Išimčių aprašymas

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.

Panaudos atvejai (use case)

“Panaudos atvejai – use case” yra scenarijais pagrįstas

UML (Unified Modelling Language) metodas, kuris

identifikuoja veikėjus sąveikos metu ir aprašo pačią

sąveiką.

Panaudos atvejų rinkinys turi aprašyti visas galimas

sąveikas su sistema.

Panaudos atvejai – tai scenarijų grafinis atvaizdavimais.

Sekų diagramos gali būti naudojamos panaudojimo

atvejų detalizavimui, parodant sistemoje vykstančių

įvykių seką.

Panaudos atvejo diagrama

Panaudos atvejus patartina

naudoti kartu su scenarijais t.y.

tekstiniais aprašais.

Reikalavimų analizės modeliai

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ą.

Socialiniai ir organizaciniai faktoriai

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.

Pavyzdys

Nagrinėkime 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ą.

Stebėjimas

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.

Aktyvus stebėjimas

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ę.

Stebėjimas ir prototipai

Sistemos

prototipavimas

Aktyvus

stebėjimas

Apklausa per

susitikimus

Stebėjimų

analizė

Prototipų

vystymas

Bendras sistemos

vystymas

Reikalavimai stebėjimui

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.

Reikalavimų inžinerijos veiklos

Galimybių tyrimas

Reikalavimų išsiaiškinimas ir analizė

Reikalavimų atestavimas (kas nustatoma atestavimo metu, reikalavimų atestavimo metodika, reikalavimų peržiūra,

kokie tikrinimai atliekami peržiūros metu)

Reikalavimų specifikavimas

Reikalavimų vadyba

Reikalavimų atestavimas

Č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.

Pakeitimų kaina

Reikalavimų atestavimas

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 ?

Reikalavimų atestavimo metodika

Reikalavimų apžvalga - peržiūra Sisteminga neautomatizuota reikalavimų analizė.

Prototipų kūrimas Vykdomojo sistemos modelio naudojimas reikalavimų patikrinimui.

Testavimo atvejų generavimas Testų reikalavimams kūrimas testavimo galimybei tikrinti.

Automatizuota nuoseklumo analizė Struktūrizuotų reikalavimų aprašymo nuoseklumo tikrinimas.

Reikalavimų peržiūra

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.

Peržiūros tikrinimai

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?

Automatinis darnos tikrinimas

Reikalavimų

duomenų bazė

Reikalavimų

procesorius

Reikalavimų

problemų ataskaita

Reikalavimai

formaliomis kalbomis

Reikalavimų

analizatorius

Reikalavimų inžinerijos veiklos

Galimybių tyrimas.

Reikalavimų išgavimas ir analizė.

Reikalavimų atestavimas.

Reikalavimų vadyba. (reikalavimų pakeitimai, reikalavimų vystymasis, pastovūs ir kintantys reikalavimai, jų

klasifikavimas, reikalavimų vadybos planavimas, reikalavimų

sekamumas, CASE priemonių palaikymas, reikalavimų

pakeitimų vykdymas)

Reikalavimų vadyba

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.

Reikalavimų pakeitimai

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.

Reikalavimų vystymasis

Pradinis

problemos

supratimas

Pasikeitęs

problemos

supratimas

Pradiniai

reikalavimai

Pasikeitę

reikalavimai

Laikas

Pastovūs ir kintantys reikalavimai

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.

Reikalavimų klasifikavimas

Mutuojantys reikalavimai Reikalavimai, kintantys dėl sistemos aplinkos.

Paaiškėjantys reikalavimai Reikalavimai, išaiškėjantys kuriant sistemą.

Iškylantys reikalavimai Reikalavimai, kylantys diegiant kompiuterinę sistemą.

Suderinamumo reikalavimai Reikalavimai, priklausantys nuo kitų sistemų ar organizacijos procesų.

Reikalavimų vadyba

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

Reikalavimų sekamumas

Sekamumo paskirtis – tai ryšiai tarp reikalavimų, jų

šaltinių ir sistemos kūrimo.

Šaltinių sekamumas Nuoroda iš reikalavimo į užsakovus, pateikusius šį reikalavimą.

Reikalavimų sekamumas Nuorodos tarp priklausomų reikalavimų

Kūrimo sekamumas Nuorodos iš reikalavimų į kūrimą

Reikalavimų pakeitimai

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.

Reikalavimų pakeitimai

Problemos analizė

ir pakeitimų

specifikavimas

Pakeitimų

analizė ir

įkainavimas

Pakeitimų

įgyvendinimas

Nustatyta

problema Ištaisyti

reikalavimai

Esminiai akcentai

Reikalavimų inžinerijos procesas apima galimybių

tyrimą, reikalavimų iškėlimą ir analizę, reikalavimų

specifikavimą, atestavimą 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.

Esminiai akcentai

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ų vykdymą.

Klausimai?