Programų sistemų inžinerija

6 paskaita

Reikalavimai, reikalavimų inžinerija

Skaidrės paruoštos remianti prof. A.Čaplinsko ir I.Sommerville medžiaga

Reikalavimų inžinerijos įvadas

Reikalavimas

• Sistemos reikalavimu vadinama jos

reikalavimų specifikacija, sandoriu su

užsakovu, standartu arba kokiu nors kitu

juridinę galią turinčiu ir įpareigojančiu

dokumentu numatyta tos sistemos savybė.

– Reikalavimai nusako sistemos galimybes ir

ribojimus (constraints).

Reikalavimų inžinerijos įvadas

Reikalavimų inžinerija (RI)

• Reikalavimų inžinerija – tai PS inžinerijos šaka, nagrinėjanti PS reikalavimų formulavimo, specifikavimo, analizės ir vertinimo klausimus

– Tiksliau, reikėtų sakyti, kad RI yra sistemų inžinerijos šaka, o PS reikalavimų inžinerija (PSRI) yra PSI šaka. Tačiau, trumpumo dėlei, vietoje termino PSRI vartosime terminą RI.

Reikalavimų inžinerijos įvadas

• Reikalavimų inžinerija apima

– poreikių analizę;

– reikalavimų analizę;

– reikalavimų specifikavimas

– reikalavimų atestavimą (validavimą)

– reikalavimų vadybą

• Pagrindinis RI uždavinys yra transformuoti

operacinius poreikius (vartotojų reikalavimus)

į PS reikalavimus.

Reikalavimų inžinerijos įvadas

• Būtina suvokti, kad iš tiesų užsakovui reikia ne kompiuterių, kompiuterių tinklų ir netgi ne programų sistemų.

• Jam reikia tam tikro efekto, kurį sukuria techninės ir programinės įrangos kompleksas. – Jei kalbame apie verslo įmones, tai užsakovai nori

patobulinti savo verslą.

– Todėl, kompiuterizuojant įmonę, darbą reikia pradėti ne nuo programų sistemos reikalavimų, bet visų pirma reikia išsiaiškinti, su kokiomis problemomis susiduria verslas, ką reikėtų versle keisti, kokios programų sistemos reikalingos patobulintam verslui vykdyti.

Priklausomybių modelis

Vidinė analizė

Vizija

Tikslų medis

Operaciniai poreikiai

Scenarijus

Išorinė analizė

Įgyvendinimo planas

Siekis, tikslai, sėkmingumo

matai, vertinimo kriterijai

Problemos, grėsmės, galimybės

Problemų priežastys

Kokiu turėtų tapti verslas?

Kaip įgyvendinti viziją?

Kokių IT paslaugų

reikia?

Kaip naudotis sistema?

Ko reikia scenarijui įgyvendinti?

Reikalavimų inžinerija

Poreikių analizė

Poreikių analizė Operaciniai poreikiai

• Bene pats svarbiausias PS kūrimo žingsnis yra

perteikti tų, kuriems reikia kuriamos sistemos

(vartotojų), operacinius poreikius tiems, kas ją

kurs (PS inžinieriams).

Poreikių analizė

Svarbiausi operacinių reikalavimų ir PS reikalavimų skirtumai

– operaciniai reikalavimai išplaukia iš vartotojų veiklos poreikių (operacinių poreikių)

• Tai reiškia, kad analitikas, bendraudamas su vartotojais ir užsakovais, privalo išsiaiškinti jų poreikius ir dokumentuoti tuos poreikius forma, lengvai suvokiama tiek vertotojams ir užsakovams, tiek vykdytojo organizacijos vadovybei, tiek ir PS inžinieriams.

– PS reikalavimai išplaukia iš operacinių reikalavimų

• Tai reiškia, kad analitikas privalo poreikių specifikaciją į PS reikalavimų specifikaciją ir suformuluoti tuos reikalavimus taip, kad jie būtų lengvai suvokiami tiek vertotojams ir užsakovams, tiek vykdytojo organizacijos vadovybei, tiek ir PS inžinieriams.

Poreikių analizė

Operacinių reikalavimų išgavimas

Analitikas

Užsakovas Vartotojas

Poreikių analizė

Operacinių reikalavimų svarba

Pavyzdys: vaikiškos supuoklės

Vartotojo poreikiai

Poreikių analizė

Operacinių reikalavimų svarba

Taip juos analitikui perteikė užsakovo atstovas

Poreikių analizė

Operacinių reikalavimų svarba

Taip juos suprato ir specifikavo analitikas

Poreikių analizė

Operacinių reikalavimų svarba

Taip juos įgyvendino projektuotojas

Poreikių analizė

Operacinių reikalavimų svarba

Taip projektą įgyvendino

programuotojas

Poreikių analizė

Operacinių reikalavimų svarba

Taip pristatė užsakovui

pateikiamą produktą diegimo

tarnyba.

Poreikių analizė

Verslo poreikių specifikacija (VPS)

• VPS – tai dokumentas, aprašantis:

– sistemos paskirtį (verslo terminais);

– operacinius reikalavimus (poreikius);

– planuojamą sistemos naudojimo scenarijų;

– sistemos aplinką (operacinę ir aptarnavimo);

– pirminę sistemos įgyvendinamumo analizę.

• Paprastai, VPS rengiamas kaip ikiprojektinis dokumentas

– tai reiškia, kad vadovaujantis šiuo dokumentu sprendžiama apie

tikslingumą pradėti projektą.

Poreikių analizė

Verslo poreikių specifikacija (VPS)

• VPS paskirtis yra aprašyti pačias bendriausias

operacines būsimos sistemos savybes

– t.y. kaip ja bus naudojamasi versle ir ką verslas iš to laimės.

• Dokumentas naudojamas visų projekto dalyvių

(vartotojų, užsakovo, vykdytojų ir kt.) siekiamiems

tikslams koordinuoti bei derinti.

Poreikių analizė

Verslo poreikių specifikacija (VPS)

• VPS yra koncepcinio lygmens dokumentas ir todėl jame neturi būti kalbama nei apie sistemos projektavimo, nei apie jos įgyvendinimo būdus.

• Kadangi šis dokumentas skirtas ir vykdytojams, ir užsakovams, tai jis turi būti parašytas labai taisyklinga ir paprasta natūralia kalba, vengiant specialių informatikos terminų ir, jei tokių terminų išvengti nepavyksta, išsamiai ir užsakovui suprantamai juos paaiškinant

– Dokumentas turi būti taip parengtas, kad jį skaitant nereikėtų bendrauti su autoriais ir prašyti jų ką nors paaiškinti.

Reikalavimai Kas vadinama reikalavimu?

• PS reikalavimu vadinama sandoriu su užsakovu, specifikacija, standartu arba kokiu nors kitu juridinę galią turinčiu dokumentu numatyta tos sistemos savybė.

– Reikalavimai gali būti labai skirtingo abstrakcijos lygmens – nuo labai bendrų sistemos ar jos teikiamų paslaugų ribojimų iki detalios matematinės tos sistemų savybių specifikacijos.

– To išvengti yra neįmanoma dėl dvigubos reikalavimų paskirties:

• viena vertus, jie naudojami skelbiant konkursą sistemai sukurti ir todėl turi būti pakankamai bendro pobūdžio, kad konkurse galėtų dalyvauti kuo daugiau pretendentų;

• Kita vertus, jie yra pagrindinė sandorio tarp užsakovo ir vykdytojo dalis ir todėl turi būti suformuluoti kuo tiksliau ir išsamiau;

– Taigi turime mažiausiai du reikalavimų abstrakcijos lygmenis.

9 tema 21

Reikalavimai Reikalavimai

• Kokią išeigą generuos sistema?

• Kokia tvarka bus pateikti rezultatai: didėjančia ar mažėjančia? Eilutėje vienas skaičius?

• Ar programa rašys rezultatus į pradinių duomenų failą, ar kurs specialų rezultatų failą? Kaip tas failas vadinsis?

– Reikalavimų specifikacija turi duoti atsakymus į visus tuos klausimus ir dar į daugelį kitų.

9 tema 22

Reikalavimai Reikalavimų nustatymas

• Procesas, kuriuo nustatoma, kokias paslaugas

privalo teikti sistema ir kokius ribojimus ta

sistema turi tenkinti teikdama tas paslaugas.

– Reikalavimai aprašo ir viena, ir kitą.

9 tema 23

Reikalavimai Reikalavimų rūšys • Vartotojo reikalavimai (operaciniai poreikiai): Turi taip aprašyti

reikalavimus, kad jie būtų suprantami žmonėms, tik paviršutiniškai susipažinusiems su tuo, kas yra kompiuteriai ir programų sistemos.

– Šie reikalavimai skirti būsimiems sistemos vartotojams bei jos užsakovams.

• Sistemos reikalavimai: Tam tikru specialiu būdu struktūrizuotas detalus sistemos teikiamų paslaugų ir jos tenkinamų ribojimų aprašas.

– Rašomi kaip sudėtinė užsakovo ir vykdytojo sandorio dalis.

• Programinės įrangos specifikacija Abstraktus programų sistemos įgyvendinimo būdo aprašas, naudojamas kaip išeities ribojimai detaliai projektuojant sistemą.

– Šie reikalavimai skirti vykdytojams. Susieja sistemos reikalavimus su jos realizacija.

9 tema 24

Reikalavimai • Reikalavimų specifikacija

– Reikalavimų specifikacija – tai oficialus, juridinę

galią turintis dokumentas, nustatantis kokį

produktą privalo sukurti vykdytojas.

• Dokumentas gali apimti ir vartotojo reikalavimus (t.y.

operacinius poreikius), ir sistemos reikalavimus.

• Šis dokumentas NĖRA projektinis dokumentas. Jame

aprašoma KĄ sistema turi daryti, bet ne tai, KAIP tai

turi būti realizuota.

Reikalavimai

baigtai sistemai

vertinti

konkursui

organizuoti

projektui

planuoti

sistemai

projektuoti

testams

specifikuoti

Reikalavimų specifikacija

užsakovas projekto vadovas projektuotojas testuotojas

Kam yra naudojama reikalavimų specifikacija.

Pavyzdys

Reikalavimų apibrėžimas ( Labai bendras reikalavimų aprašymas)

• Programinė įranga turi leisti atvaizduoti ir apdoroti išorinius failus,

sukurtus kitomis priemonėmis.

Reikalavimų specifikacija ( Detalesnis reikalavimų aprašymas) − Vartotojai turi turėti galimybę apibrėžti išorinių failų tipą.

− Kiekvienas išorinis failo tipas turi turėti susijusias priemones, kurias

− galima būtų panaudotos failui apdoroti.

− Kiekvienas išorinių failų tipas gali būti pristatytas kaip specifinė ikona

− vartotojo displėjuje.

− Vartotojas turi turėti galimybę apibrėžti ikonų atvaizdavimą kiekvienam išorinio

− failo tipui

− Kai vartotojas pasirenka ikoną, atvaizduojančią išorinį failą, šio

− pasirinkimo pasekoje failas apdorojamas įrankiais susietais su išorinį

− failą vaizduojančia ikona.

Reikalavimų skaitytojai

Programinės įrangos

projektavimo

specifikacijos

Vartotojo

reikalavimai

Kliento vadybininkai

Sistemos galutiniai vartotojai

Kliento inžinieriai

Kūrėjų vadybininkai

Sistemos architektai

Sistemos

reikalavimai

Sistemos galutiniai vartotojai

Kliento inžinieriai

Sistemos architektai

Programinės įrangos tobulintojai(vystytojai)

Galimi kliento inžinieriai

Sistemos architektai

Programinės įrangos tobulintojai(vystytojai)

Reikalavimai

• Funkciniai ir nefunkciniai reikalavimai (funkcinių reikalavimų pavyzdžiai, netikslumai,

suderinamumas, nefunkcinių reikalavimų klasifikavimas,

pavyzdžiai, tikslas ir reikalavimai, reikalavimų matavimai,

sąveika, srities reikalavimai, problemos)

• Vartotojo reikalavimai

• Sistemos reikalavimai

• Programinės įrangos reikalavimų dokumentas

Funkciniai ir nefunkciniai reikalavimai

Funkciniai reikalavimai

– Sistemos paslaugų aprašymai dar turėtų

paaiškinti, kaip sistema turėtų reaguoti į ypatingus

duomenų įvedimus ir kaip sistema elgsis

ypatingose situacijose.

Nefunkciniai reikalavimai

– Sistemos paslaugų arba funkcijų apribojimai,

tokie kaip laiko apribojimai, kūrimo proceso

apribojimai, standartai, ir pan.

Funkciniai reikalavimai

• Aprašo funkcionalumą arba sistemos paslaugas

• Priklauso nuo programinės įrangos tipo, laukiamų

vartotojų ir sistemos tipo, kur programinė įranga yra

naudojama

• Funkciniai vartotojo reikalavimai gali būti aukšto lygio

teiginiai, apie tai, ką sistema turi daryti, bet funkciniai

sistemos reikalavimai turi detaliai aprašyti sistemos

paslaugas.

Reikalavimai

9 tema 31

Programų sistema

Įvesties ir išvesties duomenys

turi būti specifikuoti detaliai.

DB Įeiga Išeiga

Sistemos viduje esantys duomenys specifikuojami nenurodant jų

vaizdavimo detalių. Tą padarys projektuotojai..

Funkciniai

reikalavimai

Funkcinių reikalavimų pavyzdžiai

• Vartotojas turi turėti galimybę ieškoti arba visus

pradinius duomenų bazės rinkinius, arba išsirinkti

poaibį iš jų.

• Sistema turi aprūpinti vartotojus tinkamomis

peržiūros priemonėmis, kad jie galėtų skaityti iš

saugyklos.

• Kiekvienam užsakymui turi būti paskirtas unikalus

identifikatorius, kuriuos vartotojas galėtų kopijuoti į

pastovų saugojimo lauką.

Reikalavimų netikslumai

• Problemos atsiranda, kai reikalavimai nėra

tiksliai nusakyti.

• Nevienareikšmiai reikalavimai gali būti

skirtingai interpretuojami kūrėjo ir vartotojo.

• Apibrėžkime terminą “tinkamomis peržiūros

priemonėmis” – Vartotojo ketinimai – speciali peržiūros priemonė

kiekvienam skirtingam dokumento tipui.

– Projektuotojo interpretacija – aprūpinti teksto

peržiūros priemonėmis, kurios parodo dokumento

sudedamąsias dalis.

Reikalavimų pilnumas ir suderinamumas

Reikalavimai turi būti ir pilni ir suderinti.

Pilni

– Juose turi būti visi aprašymai apie visas reikalaujamas galimybes

Suderinti

– Neturėtų būti konfliktų ir prieštaravimų sistemos galimybių aprašymuose

Praktikoje yra svarbu pateikti pilną ir suderintą reikalavimų dokumentą.

Nefunkciniai reikalavimai

• Apibrėžti sistemos sistemos savybes ir apribojimus kaip pvz. patikimumą, atsakymo laiką ir reikalavimus atminčiai. Apribojimai yra įvedimo/ išvedimo įrenginio galimybės ir pan.

• Reikalavimai procesui gali būti specifikuoti naudojant specialią CASE sistemą, programavimo kalbą ar projektavimo metodą.

• Nefunkciniai reikalavimai gali būti labiau svarbūs nei funkciniai reikalavimai. Jei jie nėra išpildomi, sistema yra nenaudinga.

Nefunkcinių reikalavimų klasifikavimas

Produkto reikalavimai

– Reikalavimai, kurie apibrėžia, kad pateiktas produktas privalo elgtis specifiniu būdu, pvz. vykdymo greitis ir patikimumas ir pan.

Organizaciniai reikalavimai

– Reikalavimai, kurie yra organizacinės politikos ir procedūrų padariniai kaip pvz. panaudoti procesų standartai, įdiegimo reikalavimai ir pan.

Išoriniai reikalavimai

– Reikalavimai, atsirandantys iš faktorių, kurie yra išoriniai sistemai ir jos kūrimo procesui kaip sistemos suderinamumo reikalavimai, teisiniai reikalavimai ir pan.

Nefunkcinių reikalavimų tipai Nefunkciniai

reikalavimai

Produkto

reikalavimai

Efektyvumo

reikalavimai

Organizaciniai

reikalavimai

Išoriniai

reikalavimai

Patikimumo

reikalavimai

Mobilumo

reikalavimai

Naudojimo

reikalavimai

Našumo

reikalavimai

Erdvės

reikalavimai

Pristatymo

reikalavimai

Įdiegimo

reikalavimai

Prisiderinamumo

reikalavimai

Etikos

reikalavimai

Standartų

reikalavimai

Teisiniai

reikalavimai

Saugos

reikalavimai

Privatumo

reikalavimai

Nefunkcinių reikalavimų pavyzdžiai

Produkto reikalavimas

– 4.C.8 visus būtinus ryšius tarp APSE ir vartotojo bus

įmanoma išreikšti standartiniu Ada simbolių rinkiniu.

Organizaciniai reikalavimai

– 9.3.2 Sistemos kūrimo procesas ir persiunčiamieji

dokumentai atitiks procesą ir persiunčiamuosius dokumentus

apibrėžtus XYZCo-SP-STAN-95 standartu.

Išoriniai reikalavimai

– 7.6.5 Sistema neturi atskleisti sistemos operatoriams jokios

asmeninės informacijos apie vartotojus, išskyrus jų vardą ir

kreipimosi numerį.

Tikslai ir reikalavimai

Nefunkcinius reikalavimus gali būti labai sudėtinga nustatyti tiksliai, o netikslius reikalavimus gali būti labai sunku patikrinti.

Tikslas

• Pagrindiniai vartotojo ketinimai tokie kaip vartojimo lengvumas.

Patikrinami nefunkciniai reikalavimai.

• Teiginiai naudojantys tam tikrus matavimus, kurie gali būti objektyviai išbandyti.

Tikslai, naudingi kūrėjams, nes jie perduoda sistemos vartotojų ketinimus.

Pavyzdžiai

Sistemos tikslas

– Sistema turi būti lengvai naudojama patyrusių

operatorių ir turi būti organizuota taip, kad

vartotojo klaidos būtų minimizuotos.

Patikrinami nefunkciniai reikalavimai

– Patyrę operatoriai turėtų sugebėti naudoti visas

sistemos funkcijas po dviejų apmokymo valandų.

Po tokio apmokymo vidutinis patyrusių vartotojų

padarytų klaidų skaičius neturi viršyti dviejų per

dieną.

Reikalavimų matavimai

Processed transactions/second User/Event response time Screen refresh time

K Bytes Number of RAM

Training time Number of help frames

Mean time to failure Probability of unavailability

Rate of failure occurrence Availability

Time to restart after failure Percentage of events causing failure Probability of data corruption on failure

Percentage of target dependent statements Number of target systems

Savybės Matavimai

Greitis

Dydis

Naudojimo lengvumas

Patikimumas

Patvarumas

Pernešamumas

Reikalavimų sąveika

Konfliktai tarp skirtingų nefunkcinių reikalavimų yra

bendri sudėtingose sistemose.

Kosminio laivo sistema

– Minimizuojant apimtį, atskirų mikroschemų skaičius

sistemoje turi minimizuotas.

– Minimizuojant galios suvartojimą, turi būti panaudotos

mažesnės galios mikroschemos.

– Tačiau naudojant mažesnio galingumo mikroschemas, jų

gali būti panaudota daugiau.

Kuris reikalavimas yra labiausiai kritiškas?

Srities reikalavimai

• Tai reikalavimai, gauti iš taikymo srities ir

nusako sistemos charakteristikas ir sritį

atspindinčius bruožus.

• Tai gali būti nauji funkciniai reikalavimai,

egzistuojančių reikalavimų apribojimai arba

apibrėžti specifiniai skaičiavimai.

• Jei srities reikalavimai nepatenkinami, sistema

nedirbs.

Bibliotekinės sistemos srities reikalavimai

• Turi būti standartinė sąsaja su vartotoju

visoms duomenų bazėms, paremta Z39.50

standartu.

• Dėl autorinių teisių apribojimų kai kurie

dokumentai turi būti iš karto sunaikinti.

• Priklausomai nuo vartotojo reikalavimų šitie

dokumentai bus atspausdinti vietoje, po to

persiunčiant vartotojui arba nukreipti į tinklinį

spausdintuvą.

Srities reikalavimų problemos

Suprantamumas (Understandability)

– Reikalavimai yra išreikšti taikymo srities

kalboje.

– Tai dažnai nesupranta programinės įrangos

projektuotojai projektuojant sistemą.

Neabejotinumas (Implicitness)

– Srities specialistai situacijoje gaudosi taip gerai,

kad jie nė negalvoja apie tikslių srities

reikalavimų sudarymą.

Reikalavimai

• Funkciniai ir nefunkciniai reikalavimai

• Vartotojo reikalavimai

(problemos dėl natūralios kalbos, patarimai reikalavimų rašymui)

• Sistemos reikalavimai

• Programinės įrangos reikalavimų dokumentas

Vartotojo reikalavimai

• Turi aprašyti funkcinius ir nefunkcinius

reikalavimus taip, kad jie būtų suprantami

sistemos vartotojų, kurie neturi detalių

techninių žinių.

• Vartotojo reikalavimai yra apibrėžti, naudojant

natūralią kalbą, lenteles ir diagramas.

Problemos su natūralia kalba

Aiškumo trūkumas

– Sunku pasiekti tikslumą, nedarant taip, kad

dokumentą būtų sunku skaityti.

Reikalavimų painiava (confusion)

– Funkciniai ir nefunkciniai reikalavimai turi

tendenciją susimaišyti.

Reikalavimų susijungimas (amalgamation)

– Keletas skirtingų reikalavimų gali būti išreikšti

kartu.

Patarimai reikalavimų rašymui

• Pasiūlyti standartinį formatą ir naudoti jį

visiems reikalavimams.

• Naudoti kalbą tinkamu būdu. Naudoti “turi”

priverstiniams reikalavimams, “ turėtų”

pageidaujamiems reikalavimams.

• Naudoti teksto paryškinimą tam, kad pabrėžti

esmines reikalavimų dalis.

• Vengti kompiuterinių žargonų naudojimo.

Reikalavimai

• Funkciniai ir nefunkciniai reikalavimai

• Vartotojo reikalavimai

• Sistemos reikalavimai (reikalavimai ir projektas,

problemos, alternatyvos natūralios kalbos specifikacijoms,

forma pagrįstas specifikavimas, PDL naudojimas, trūkumai,

sąsajos specifikavimas)

• Programinės įrangos reikalavimų dokumentas

Sistemos reikalavimai

• Tai vartotojų reikalavimų detalesnės

specifikacijos.

• Tarnauja kaip bazė, kuriant sistemą.

• Gali būti naudojama kaip dalis sistemos

kontrakto.

• Sistemos reikalavimai gali būti išreikšti,

naudojant sistemos modelius, modeliavimą.

Reikalavimai ir projektas

Iš principo reikalavimai turi skelbti ką sistema

turi daryti, o projektas turi apibūdinti, kaip tai

padaryti.

Praktiškai, reikalavimai ir projektas yra

neatskiriami. • Sistemos architektūra gali būti suprojektuota tam, kad

struktūrizuotu reikalavimus.

• Sistema gali dirbti su kitomis sistemomis, kurios

generuoja projekto reikalavimus.

• Specialaus projektavimo naudojimas gali būti srities

reikalavimas.

Problemos dėl specifikacijų natūralia kalba

Dviprasmiškumas

– Reikalavimų skaitytojai ir autoriai tą patį žodį turi

interpretuoti taip pat. Natūrali kalba yra

nevienareikšmė, taigi tai pasiekti yra labai sunku.

Per didelis lankstumas

– Tas pats dalykas gali būti pasakytas specifikacijoje

daugeliu skirtingų būdų.

Moduliarizacijos trūkumas

– Natūrali kalba netinka struktūrizuoti sistemos

reikalavimus.

Alternatyvos natūralios kalbos

specifikacijoms Įvardinimas Aprašymas

Struktūrizuota natūrali kalba Šis priėjimas priklauso nuo apibrėžtų standartinių formų ar šablonų

tam, kad išreikšti specifikacijos reikalavimus.

Projekto aprašymo kalba Šis metodas naudoja kalbą, panašią į programavimo kalbą, bet su

abstraktesnėmis savybėmis tam, kad aprašant sistemos operacinį

modelį, išskirtų reikalavimus.

Grafiniai pažymėjimai Grafinė kalba, papildyta teksto anotacijomis yra naudojama sistemos

funkcinių reikalavimų apibrėžimui.Pvz UML sekų, veiklos, atvejų

diagramos.

Matematinės specifikacijos Tai yra pažymėjimai, paremti matematinėmis sąvokomis, tokiomis

kaip baigtiniai automatai ar aibės. Šios vienareikšmės specifikacijos

sumažina ginčus tarp klientų ir vykdytojų dėl sistemos

funkcionavimo. Kaip bebūtų dauguma klientų nesupranta formalios

specifikacijos ir atsisako priimti tai kaip sistemos kontraktą. Formalią

specifikaciją aptarsime 9 skyriuje.

Struktūrizuotos kalbos specifikacijos

• Natūralios kalbos ribota forma gali būti

naudojama reikalavimų išreiškimui.

• Tai panaikina kai kurias problemas,

atsiradusias dėl dvireikšmiškumo ir lankstumo

ir tai uždeda specifikacijoms vienodumo

laipsnį.

Formomis pagrįstose specifikacijose nurodoma

• Funkcijos ar objekto apibrėžimas

• Įvesčių aprašymas ir iš kur jos yra

• Rezultatų aprašymas ir kur jie eina

• Kitų reikalingų objektų atpažinimas

• Pradinės ir galutinės sąlygos ( jei tinka)

• Pašaliniai efektai(jei yra)

Forma pagrįstas mazgo specifikavimas

ECLIPSE/Workstation/Tools/DE/FS/3.5.1

Function Add node

Description Adds a node to an existing design. The user selects the type of node, and its position.When added to the design, the node becomes the current selection. The user chooses the node position bymoving the cursor to the area where the node is added.

Inputs Node type, Node position, Design identifier.

Source Node type and Node position are input by the user, Design identifier from the database.

Outputs Design identifier.

Destination The design database. The design is committed to the database on completion of theoperation.

Requires Design graph rooted at input design identifier.

Pre-condition The design is open and displayed on the user's screen.

Post-condition The design is unchanged apart from the addition of a node of the specified typeat the given position.

Side-effects None

Definition: ECLIPSE/Workstation/Tools/DE/RD/3.5.1

Forma pagrįstas mazgo specifikavimas

• Funkcija – Prideda mazgą

• Aprašymas – Prideda mazgą prie egzistuojančio projekto. Vartotojas pasirenka mazgo tipą ir jo poziciją. Kada prideda prie projekto, mazgas tampa einamu pasirinkimu. Vartotojas, judindamas kursorių po sritį, kur yra pridėtas mazgas, parenka mazgo poziciją.

• Įvestis – Mazgo tipas, mazgo pozicija, projekto identifikatorius.

• Šaltinis – mazgo tipas ir mazgo pozicija yra įvedami vartotojo, Projekto identifikatorius iš duomenų bazės.

• Išvestis – Projekto identifikatorius.

• Paskirtis – Projektavimo duomenų bazė. Pabaigus veiksmą projektas yra įrašomas į duomenų bazę.

• Reikalaujama– Projekto grafo susieto su identifikatoriumi.

• Pradinės sąlygos – Projektas yra atidarytas ir rodomas vartotojo ekrane.

• Galinės sąlygos – Projektas yra nepakeistas išskyrus pridėtą duotoje pozicijoje nurodyto tipo mazgą.

• Šalutiniai efektai - nėra.

Design Description Languages (DDL) pagrįstas reikalavimų apibrėžimas

Reikalavimai gali būti apibrėžti, operatyviai naudojant kalbą, tokią kaip programavimo kalbą, bet su lankstesnėmis išraiškomis.

Daugiausiai vyrauja dviejose situacijose:

– Kur operacija yra specifikuota, kaip veiksmų seka ir svarbi tvarka;

– Kai aparatūrinės ir programinės įrangos sąsajos turi būti nustatytos.

Trūkumai yra:

– DDL negali būti pakankamai išraiškinga, kad apibrėžtų srities sąvokas;

– Specifikacija bus suprasta greičiau kaip projektas, o ne

kaip specifikacija.

Dalis ATM specifikacijos class ATM {

//declarations here

public static void main (String args[]) throws InvalidCard {

try {

thisCard.read () ; // may throw

InvalidCard exception

pin = KeyPad.readPin () ; attempts = 1 ; while( !thisCard.pin.equals (pin) & attempts < 4 )

{

pin = KeyPad.readPin () ;

attempts = attempts + 1 ;

}

if (!thisCard.pin.equals (pin)

}

throw newInvalisCard(“Bad PIN”);

thisBalance = thisCard.getBalance();

do { Screen.prompt ( “Please select a service” );

servise = Screen.touchKey();

switch (service) {

case Services.withdrawalWithReceipt:

receiptRequired = true;

DDL trūkumai

• DDL negali būti pakankamai išraiškingas, kad

suprantamu būdu išreikštų sistemos funkcines

galimybes.

• Pažymėjimai suprantami tik žmonėms,

žinantiems programavimo kalbą.

• Reikalavimai gali būti greičiau priimti kaip

projekto specifikacija negu kaip modelis,

padedantis suprasti sistemą.

Sąsajos specifikavimas

• Dauguma sistemų turi dirbti su kitomis

sistemomis ir bendravimo interfeisai turi būti

nurodyti, kaip dalis reikalavimų

• Galima apibrėžti tris sąsajų tipus

– Procedūriniai interfeisai

– Struktūros duomenų, kuriais vyksta apsikeitimas

– Duomenų atvaizdavimas

• Formalūs aprašymai - tai efektyvi technika,

specifikuojant sąsają

Sąsajos aprašymas DDL

interface PrintServer { // defines an abstract printer server // requires: interface Printer, interface PrintDoc // provides: initialize, print, displayPrintQueue, cancelPrintJob, switchPrinter void initialize ( Printer p ) ; void print ( Printer p, PrintDoc d ) ; void displayPrintQueue ( Printer p ) ; void cancelPrintJob (Printer p, PrintDoc d) ; void switchPrinter (Printer p1, Printer p2, PrintDoc d) ; } //PrintServer

Reikalavimai

• Funkciniai ir nefunkciniai reikalavimai

• Vartotojo reikalavimai

• Sistemos reikalavimai

• Programinės įrangos reikalavimų

dokumentas (reikalavimų dokumento vartotojai,

reikalavimai dokumentui, reikalavimų dokumento struktūra)

Reikalavimų dokumentas (specifikacija)

• Reikalavimų dokumentas yra oficialus

pareiškimas, ko reikalaujama iš sistemos

kūrėjų.

• Turi būti įtraukta reikalavimų apibrėžimas ir

specifikacija.

• Tai ne projekto dokumentas. Kaip galima

labiau jis turi nustatyti KĄ sistema turi

padaryti, negu tai, KAIP ji turi tai padaryti.

Sistemos

klientai

Nustato reikalavimus ir skaito juos tam, kad

patikrintų, ar jie atitinka jų poreikius. Jie

nustato reikalavimų pakeitimus.

Vadybininkai Naudoja reikalavimų dokumentą tam, kad

suplanuotų sistemos kainą ir suplanuotų

sistemos kūrimo procesą.

Sistemos

projektuotojai

Naudoja reikalavimus tam, kad suprastų ,

kaip projektuoti sistemą.

Sistemos testo

projektuotojai Naudoja reikalavimus tam, kad sukurtų

sistemai atestavimo testą.

Sistemų

palaikymo

inžinieriai

Naudoja reikalavimus, kad padėtų suprasti

sistemą ir santykius tarp jos dalių.

Reikalavimų dokumento vartotojai

Reikalavimai dokumentui

• Turi nustatyti išorinį sistemos elgesį.

• Turi nustatyti realizavimo apribojimus.

• Turi būti lengvai keičiamas.

• Turi būti kaip vadovas programinės įrangos

palaikymui.

• Vertinti sistemos gyvavimo ciklą, tai yra

nuspėti pakeitimus.

• Charakterizuoti atsakymus į netikėtus įvykius.

IEEE standartas reikalavimams

• Įvadas

• Bendras aprašymas

• Konkretūs reikalavimai

• Priedai

• Indeksas

• Tai yra bendra struktūra, kuri turi būti

priderinta konkrečioms sistemoms

Reikalavimų dokumento struktūra

• Įvadas

• Sąrašas techninių terminų

• Vartotojo reikalavimų apibrėžimas

• Sistemos architektūra

• Sistemos reikalavimų specifikacija

• Sistemos modeliai

• Sistemos tobulinimas

• Priedai

• Indeksai

Reikalavimų dokumentas Gerai parašytos reikalavimų dokumento

(specifikacijos) savybės:

– Visų pirma reikalavimų specifikacija yra gerai

parašyta, jeigu ji tenkina projektuotojų poreikius.

• Tai reiškia, kad dokumento savybes lemia tikslai,

kuriems jis yra naudojamas.

• Vienų savybių reikia tam, kad dokumentą būtų patogu

skaityti, kitų tam, kad būtų nesunku patikrinti, ar

projektuotojai tikrai įgyvendino visus reikalavimus, dar

kitų tam, kad dokumentą būtų nesunku keisti.

Reikalavimų dokumentas

• Gerai parašytos reikalavimų specifikacijos

savybės

– Nėra kokio nors visuotinai pripažinto reikalavimų

specifikacijos formato standarto, tačiau yra įprasta

numeruoti visus reikalavimus:

Reikalavimų dokumentas

• Gerai parašytos reikalavimų specifikacijos

savybės – Konceptualumas (appropriateness): reikalavimų

specifikacija yra konceptuali, jei visi joje pateikti

reikalavimai yra abstraktūs, t.y. joje nėra liečiami sistemos

projektavimo ar įgyvendinimo klausimai.

• Nekonceptuali specifikacija per daug suvaržytų projektuotojus ir

programuotojus, trukdytų jiems parinkti geriausią sistemos

įgyvendinimo būdą.

• Kita vertus, dažnai yra labai sunku išvengti kai kurių projektavimo

ar realizavimo ribojimų.

Reikalavimų dokumentas • Gerai parašytos reikalavimų specifikacijos

savybės – Koncepcinė skaidra: apima specifikacijos paprastumą,

aiškumą ir suprantamumą. Ši savybė siejasi su

specifikacijos konceptualumu.

• Jei reikalavimai saugomi duomenų bazėje ir tvarkomi

programiškai, koncepcinė skaidra dažniausiai yra paaukojama

siekiant padidinti reikalavimų apdorojimo našumą.

Reikalavimų dokumentas • Gerai parašytos reikalavimų specifikacijos

savybės – Konkretumas (constructability): specifikacija yra konkreti,

jei gali būti patikrintas visų joje suformuluotų reikalavimų

įgyvendinimo laipsnis.

• Tai labai svarbi specifikacijos savybė, nes šis dokumentas yra

užsakovo ir vykdytojo sandorio dalis ir jos pagrindu yra

sprendžiama ar sandoris buvo įvykdytas.

Reikalavimų dokumentas Gerai parašytos reikalavimų specifikacijos

savybės – Geras struktūrizavimas: joje griežtai išlaikytas turinių

atskyrimo principas.

– Tikslumas: visi joje suformuluoti reikalavimai yra tikslūs.

• Tai labai svarbi specifikacijos savybė, nes šis dokumentas yra

užsakovo ir vykdytojo sandorio dalis ir jos pagrindu yra

sprendžiama ar sandoris buvo įvykdytas.

Reikalavimų dokumentas

Gerai parašytos reikalavimų specifikacijos savybės

– Išsamumas: specifikacijoje aprašytas visas reikalingas sistemos funkcionalumas ir visi joje pateikti reikalavimai yra išsamūs.

• Tai reiškia, kad specifikacijoje yra viskas, kas joje turėtų būti.

– Patikrinti, ar specifikacija tikrai yra išsami, yra labai sunku.

– Nagrinėjant tai, kas yra aprašyta, labai sunku pastebėti, ko gi ten trūksta.

– Geriausias būdas išsamumui patikrinti yra sukurti sistemos prototipą.

Reikalavimų dokumentas

Gerai parašytos reikalavimų specifikacijos

savybės

– Išsamumas

• Išsamioje specifikacijoje turi būti aprašyta, kaip sistema

reaguoja į kiekvieną iš galimų įvesties tipų kiekvienoje

galimoje situacijoje.

– Reikia nagrinėti ne tik kaip reaguoja sistema į leistinas (teisingas)

įvestis, bet ir kaip ji reaguoja į klaidingas įvestis.

Reikalavimų dokumentas

Gerai parašytos reikalavimų specifikacijos savybės

– Išsamumas

• Išsamioje specifikacijoje turi būti visos reikalaujamos to dokumento dalys, visi puslapiai, visi paveikslėliai ir visos lentelės turi būti sunumeruoti, paveikslėliai ir lentelės turi turėti pavadinimus, turi būti pateiktos tvarkingos nuorodos į visus naudojamus išorinius informacijos šaltinius.

– Tai formalus dokumento išsamumas, kurį galima vadinti ir dokumento tvarkingumu.

– Kokias dalis turi turėti dokumentas, nustato vidiniai organizacijos (arba projekto) standartai.

78

Reikalavimų dokumentas

Gerai parašytos reikalavimų specifikacijos savybės

– Išsamumas

• Kartais analizės metu visų reikalavimų specifikuoti nepavyksta, kai kurių reikalavimų specifikavimą tenka atidėti vėlesniam laikui. Tokie reikalavimai pažymimi žyme AVL.

– Išsamioje specifikacijoje kiekvienam AVL žyme pažymėtam reikalavimui turi būti nurodyta:

» kodėl reikalavimo formulavimas yra atidėtas;

» kas turi būti atlikta, kad reikalavimą būtų galima suformuluoti;

» iki kada reikalavimas turi būti suformuluotas;

» kas atsakingas už tai, kad reikalavimas būtų suformuluotas nurodytu laiku.

79

Reikalavimų dokumentas

Gerai parašytos reikalavimų specifikacijos savybės

– Vienareikšmiškumas: joje neturi būti jokių dviprasmybių. • Tai labai svarbi specifikacijos savybė, nes šis dokumentas yra

užsakovo ir vykdytojo sandorio dalis ir jos pagrindu yra sprendžiama ar sandoris buvo įvykdytas.

– Trasuojamumas: reikalavimai yra lokalizuojami ir reikalavimų ir projektinę specifikacijas galima tarpusavyje susieti kryžminėmis nuorodomis. • Jei visi reikalavimai yra sunumeruoti, į juos galima daryti nuorodas.

9 tema 80

Reikalavimų dokumentas Gerai parašytos reikalavimų specifikacijos

savybės – Darnumas: visi joje suformuluoti reikalavimai yra

integruojami, jokių prieštaravimų dokumente nėra.

• Nedarna gali atsirasti dėl įvairių priežasčių, pavyzdžiui, dėl:

– terminų konflikto: skirtingose dokumento vietose tas pats daiktas yra

vadinamas skirtingai;

– savybių konflikto: skirtinguose reikalavimuose yra reikalaujama, kad

sistema turėtų kokias nors nesuderinamas savybes;

– naudojimo režimų konflikto: pavyzdžiui, vienoje vietoje

reikalaujama, kad su sistema būtų dirbama dialogo režimu, kitoje, kad

ji būtų sistema, veikianti paketinio duomenų apdorojimo režimu.

Reikalavimų dokumentas • Gerai parašytos reikalavimų specifikacijos

savybės

– Keičiamumas: dokumentas turi būti lengvai keičiamas.

• Specifikaciją lengva keisti, jei ji parašyta griežtai prisilaikant turinių atskyrimo principo ir visi reikalavimai turi unikalius numerius.

– Naudojimo patogumas: mažai kas skaito visą dokumentą, kiekvienam reikia tik to, kas jam svarbu. Todėl dokumentas turi būti parašytas taip, kad juo būtų galima naudotis kaip žinynu.

Reikalavimai

“Reikalavimai yra didelis dalykas. Aš juos rašau visą

gyvenimą. Ten aš sudedu viską apie tai, ką turėtų daryti

programų sistema: kokias verslo taisykles ji turi tenkinti,

ką turi daryti vartotojo interfeisas, paspaudus tą ar kitą

klavišą, kokias užduotis vartotojas norės vykdyti ir taip

toliau, ir taip toliau. Čia tikrai yra apie ką pagalvoti.”

Kevin Brennan

Reikalavimai

“Kartais ko nors pritrūksta. Kartais nieko netrūksta, bet vykdytojai klaidingai supranta mano mintį. Aš susidūriau su daugybe situacijų, kurios yra visiškai akivaizdžios verslo žmonėms, bet praranda savo akivaizdumą arba dėl jų perpasakojimo kitais terminais, arba dėl to, kad nors ir nesunku įsivaizduoti tokias situacijas realizuojančias juodąsias dėžes, labai sunku realizuoti pačias tokias juodąsias dėžes.

Ir visa tai vyksta nepaisant to, kad mes visi dirbame kartu jau daugiau kaip metai, sėdimi tame pačiame pastate ir daugelis iš mūsų jau ištisus dešimtmečius dirba tokį darbą.”

Kevin Brennan

Reikalavimai

“Rasti ir pataisyti klaidą sistemoje testavimo metu, o juo labiau po

to, kai ji pradėta eksploatuoti, kainuoja dešimt kartų daugiau,

negu ją rasti ir pataisyti reikalavimuose ar projektinėje sistemos

specifikacijoje.

Blogai valdomame projekte klaidoms surasti ir pataisyti jūs galite

sugaišti daugiau laiko, negu jo buvo sugaišta sistemai sukurti.”

Kevin Brennan

9 tema 85

Reikalavimai

Poreikių

analizė

Aiškinimasis

ir analizė

Specifikavimas

Vertinimas

Dokumentavimas

Prototipai

Technologinis reikalavimų

inžinerijos procesas

Esminiai akcentai

• Reikalavimai išdėsto, ką sistema turi daryti ir

apibrėžia jos vykdymo ir realizavimo apribojimus.

• Funkciniai reikalavimai išdėsto paslaugas, kurias

turi užtikrinti sistema.

• Nefunkciniai reikalavimai apriboja kuriamą

sistemą arba kūrimo procesą.

• Vartotojo reikalavimai yra aukšto abstrakcijos

lygio sakiniai, ką sistema turi daryti.

Esminiai akcentai

• Vartotojo reikalavimai gali būti parašyti natūralia

kalba, lentelėmis ir diagramomis.

• Sistemos reikalavimai skirti funkcijoms, kurias

sistema turi vykdyti.

• Sistemos reikalavimai gali būti parašyti

struktūrizuota natūralia kalba, DDL, grafinėmis

diagramomis (UML) ar formalia (matematine) kalba.

• Programinės įrangos reikalavimų dokumentas

(specifikacija) yra sistemos reikalavimų suderinti

teiginiai.