Reikalavimai programinei įrangai

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1

Reikalavimai programinei įrangai

Sistemos aprašymai ir specifikacijos


Tikslai• Supažindinti su vartotojo ir sistemos reikalavimų

sąvoka• Aprašyti funkcinius ir nefunkcinius reikalavimus• Paaiškinti du metodus sistemos reikalavimų

aprašymui• Paaiškinti kaip programinės įrangos reikalavimai

gali būti organizuoti reikalavimų dokumentuose


Aptariamos temos• Funkciniai ir nefunkciniai reikalavimai• Vartotojo reikalavimai• Sistemos reikalavimai• Sistemos modeliavimas• Programinės įrangos reikalavimų dokumentas


Reikalavimų inžinerija• Tai procesas paslaugų, kurių vartotojas

reikalauja iš sistemos ir apribojimų, pagal kuriuos sistema dirba ir yra kuriama, nustatymui

• Patys reikalavimai tai sistemos paslaugų ir apribojimų aprašymai, kurie sugeneruojami reikalavimų inžinerijos proceso metu


Kas tai yra reikalavimas? Tai gali būti nuo labai abstrakčių teiginių iki

detalizuotų matematinių funkcijų. Tai neišvengiama, nes reikalavimai gali atlikti

dvigubą funkciją• tai gali būti kaip pagrindas pasiūlymui ( konkursui) – todėl turi

būti atviras interpretacijai• tai gali būti pagrindas ir pačiai užsakymo sutarčiai – taigi tai

turi būti aprašyta gana smulkiai• abu tokie teiginiai gali būti pavadinti reikalavimais


Reikalavimų abstrakcija (Davis)“Jei kompanija nori sudaryti sutartį dideliam programinės įrangos projektui, ji turi pateikti savo poreikius pakankamai abstrakčiu būdu, kad sprendimas nebūtų iš anksto apibrėžtas.Poreikiai turėtų būti nurodyti dar prieš sutarties sudarymą. Reikalavimai turi būti parašyti taip, kad keli rangovai galėtų vykdyti sutartį, duoti pasiūlymus, kad galėtų siūlyti skirtingais būdai išpildyti užsakovo poreikius. Kai kontrakto laimėtojas jau nustatytas, rangovas turi tiksliai ir smulkiai aprašyti sistemą tam, kad klientai suprastų ką programinė įranga darys. Abu šie dokumentai vadinami reikalavimų dokumentais.”


Reikalavimų tipai Vartotojo reikalavimai

• Natūralios kalbos teiginiai plius paslaugų, kurias teikia sistema ir vykdymo apribojimai. Tai parašyta užsakovams.

Sistemos reikalavimai• Struktūrizuotas dokumentas išdėstantis detalius sistemos

paslaugų aprašymus. Parašytas kaip kontraktas tarp kliento ir rangovo.

Programinės įrangos specifikacija• Tai detalus programinės įrangos aprašymas, kuris tarnauja

kaip pagrindas projektavimui ir realizacijai. Tai parašyta projektuotojams.


Apibrėžimai ir specifikacijosReikalavimų apibrėžimas ( Labai bendras reikalvimų 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 vadybininkaiSistemos galutiniai vartotojai

Kliento inžinieriaiKūrėjų vadybininkaiSistemos architektai

Sistemos reikalavimai

Sistemos galutiniai vartotojaiKliento inžinieriai

Sistemos architektaiPrograminės įrangos tobulintojai(vystytojai)

Galimi kliento inžinieriaiSistemos architektai

Programinės įrangos tobulintojai(vystytojai)


Aptariamos temos• Funkciniai ir nefunkciniai reikalavimai• Vartotojo reikalavimai• Sistemos reikalavimai• Sistemos modeliavimas• 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.


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

Praktiškai, 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

Reikalavimai produktui• 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ų tipaiNefunkciniai 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 ir 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/secondUser/Event response timeScreen refresh timeK BytesNumber of RAM chipsTraining timeNumber of help framesMean time to failureProbability of unavailability

Rate of failure occurrenceAvailabilityTime to restart after failurePercentage of events causing failureProbability of data corruption on failurePercentage of target dependent statementsNumber of target systems

SavybėSavybėss MatavimMatavimaiai

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


Aptariamos temos Funkciniai ir nefunkciniai reikalavimai Vartotojo reikalavimai Sistemos reikalavimai Sistemos modeliavimas 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.




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. Ankstyvasis tokios grafinės kalbos pavyzdys yra SADT. Dar anksčiau buvo naudojamas naudojimo atvejo aprašymai. Aptarsime tai kituose skyriuose.

Matematinės specifikacijosTai 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.


PDL 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:

• PDL 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 specifikacijosclass ATM {

//declarations herepublic 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;


PDL trūkumai PDL 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 pažymėjimai - tai efektyvi technika, specifikuojant sąsają


Sąsajos aprašymas PDL

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




Sistemų modeliavimas Sistemų modeliavimas padeda analitikui suprasti

sistemos veikimą ir sistemos modeliai naudojami bendravimui su užsakovu.

Skirtingi modeliai atvaizduoja sistemą skirtingais požiūriais:• Išorinis požiūris rodo sistemos kontekstą arba aplinką;• Elgsenos požiūris atspindi sistemos veikimą;• Struktūrinis požiūris atspindi sistemos arba duomenų

architektūrą.


Vieninga atvaizdavimo kalba Sukurta iš plačiai naudojamų objektiškai

orientuotų analizės ir projektavimo metodų. Tapo efektyviu objektiškai orientuoto

atvaizdavimo standartu. Žymėjimai:

• Objektinės klasės - stačiakampiai su vardu viršuje, atributais viduje ir operacijomis apačioje;

• Ryšiai tarp klasių yra linijos su rodyklėmis;• Paveldimumas nurodytas hierarchijoje “viršun“ .


Objekto elgesio atvaizdavimas Elgsenos modelis parodo sąveiką tarp

objektų nusakant tam tikrą sistemos elgesį, kuris yra apibrėžtas vartojimo atvejais.

Sekos diagramos (arba bendradarbiavimo diagramos) UML’e yra naudojamos sąveikai tarp objektų atvaizduoti.


Elektroniniai leidiniai

:Library User

Ecat:Catalog

Lookup

Issue

Display

:Library Item Lib1:NetServer

Issue licence

Accept licence

Compress

Deliver


CASE priemonės Suderinta įrankių seka, skirta palaikyti susijusiems

programinės įrangos procesų veiksmams, tokiems kaip analizė, projektavimas ar testavimas.

Analizės ir projektavimo priemonės palaiko sistemos modeliavimą reikalavimų ruošimo ir sistemos projektavimo metu.

Šios priemonės gali palaikyti specifiniu projektavimo metodus arba gali numatyti kelių skirtingų tipų sistemos modelių kūrimą.


Analizės ir projektavimo priemonės

Duomenų žinynas

Kodo generavi

mo priemonė

s

Diagramų redaktoriai

Ataskaitų apibrėžimo

ir generavimo priemonės

Centrinė informacijos

saugyklaUžklausų

kalba

Formų apibrėžimo priemonės

Projektavimo, analizės ir tikrinimo priemonės

Importo/eksporto

transliatoriai


Analizės priemonių komponentai Diagramų redaktoriai - kuria duomenų srautų diagramas, objektų

hierarchijas, esybių-savybių diagramas. Jie renka informaciją apie diagramų esmę ir išsaugo informaciją pagrindinėje saugykloje.

Modelių analizės ir tikrinimo įrankiai – vykdo projektavimą bei praneša apie klaidas ir anomalijas.

Saugykla ir susijusių užklausų kalba – leidžia projektuotojams surasti projektus ir apjungti projektavimo informaciją saugykloje.

Duomenų žinynas – palaiko informaciją apie naudojamas sistemos projektavimui esybes.

Ataskaitų apibrėžimo ir generavimo priemonės – pasiima informaciją iš centrinės saugyklos ir automatiškai generuoja sistemos dokumentaciją.

Formų apibrėžimo priemonės – leidžia klasifikuoti ekrano ir dokumento formatus.

Importo/eksporto transliatoriai – leidžia pasikeisti informacija iš centrinės saugyklos su kitais vystomais įrankiais.

Kodo generavimo priemonės – generuoja kodą arba kodo griaučius automatiškai iš projekto esančio centrinėje saugykloje.




Reikalavimų dokumentas 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.

VadybininkaiNaudoja 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 reikalavimų 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 vystymas Priedai Indeksai


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 turi 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, PDL ar formalia kalba.

Programinės įrangos reikalavimų dokumentas yra sistemos reikalavimų suderinti teiginiai.


Esminiai akcentai Modelis yra abstraktus sistemos vaizdas. Papildomi

modelių tipai teikia skirtingą sistemos informaciją. Konteksto modeliai parodo sistemos poziciją jos

aplinkoje su kitomis sistemomis ir procesais. Objektų modeliai aprašo loginę sistemos esmę, jų

klasifikaciją ir surinkimą. CASE priemonės palaiko sistemos modelių kūrimą. Būsenos modeliai modeliuoja sistemos elgesį atsakant į

vidinius ir išorinius įvykius.

Documents

Reikalavimai programinei įrangai