program ų sistem ų inžinerija reikalavimai programinei įrangai

Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 1

Programų sistemų inžinerija

Reikalavimai programinei įrangai


Tikslai

• Supažindinti su vartotojo ir sistemos reikalavimų sąvoka

• Aprašyti funkcinius ir nefunkcinius reikalavimus

• Išsiaiškinti, kaip programinės įrangos reikalavimai gali būti aprašomi reikalavimų specifikacijos dokumentuose


Nagrinėjamos temos

• Funkciniai ir nefunkciniai reikalavimai

• Vartotojo reikalavimai

• Sistemos reikalavimai

• Sąsajos specifikavimas

• PĮ reikalavimų specifikacija


Reikalavimų inžinerija

• Tai procesas, kurio metu nustatoma, kokias paslaugas turės atlikti kuriama programinė įranga bei su kokiais apribojimais sistemai susidursime kūrimo metu

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


Kas yra reikalavimas?

• Tai gali būti nuo labai abstrakčių teiginių iki detalizuotų matematinių funkcijų.

• Tai neišvengiama, nes reikalavimai gali atlikti dvigubą funkciją

– gali būti kaip pagrindas pasiūlymui ( konkursui) –todėl turi būti atviras interpretacijai

– 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ų tipai• Vartotojo reikalavimai

– Paprasta (ne technine) kalba surašyti vartotojo pageidavimai būsimai sistemai, gali būti pridedamos laisvos formos diagramos, parašyta taip, kad suprastų bet kuris sistemos vartotojas

• Sistemos reikalavimai

– Struktūrizuotas dokumentas, išdėstantis detalius sistemos funkcijų, paslaugų ir operacijų aprašymus. Nusako, kas turi būti padaryta ir gali būti naudojamas kaip kontrakto dalis


Apibrėžimai ir specifikacijos

1.

Programinė įranga turi leisti atvaizduoti ir apdoroti išorinius failus, sukurtus kitomis programomis

1.2

1.2

1.2

1.2

1.21.2

Vartotojo reikalavimų apibrėžimas

Sistemos reikalavimų specifikacija

1.1

1.1 Vartotojai turi turėti galimybę apibrėžti išorinių failų tipą.1.2 Kiekvienas išorinis failo tipas turi turėti susijusias priemones, kurias galima būtų panaudotos failui apdoroti.1.3 Kiekvienas išorinių failų tipas gali būti pristatytas kaip specifinė ikona.1.4 Vartotojas turi turėti galimybę apibrėžti ikonų atvaizdavimą kiekvienam išorinio failo tipui


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

Galutiniai sistemos vartotojai

Kliento inžinieriai


Programinės įrangos tobulintojai(vystytojai)

Galimi kliento inžinieriai


Programinės įrangos tobulintojai(vystytojai)


Funkciniai ir nefunkciniai reikalavimai• Funkciniai reikalavimai

– Sistemos atleikamų paslaugų aprašymas, sistemos reakcijos į tam tikrus įvedimo ar išvedimo duomenis aprašymas, sistemos elgesys tam tikroje situacijoje...

• Nefunkciniai reikalavimai

– Apribojimai sistemos atliekamoms paslaugoms ar funkcijoms, dažniausiai laiko apribojimai, programavimo proceso apribojimai, standartai ir pan.

• Srities reikalavimai

– Reikalavimai, ateinantys iš konkrečios nagrinėjamos srities ir atspindintys tik tai sričiai būdingas problemas ar charakteristikas


Funkciniai reikalavimai

• Nusako sistemos funkcionalumą ar sistemos paslaugas

• Priklauso nuo kuriamos PĮ tipo, būsimų vartotojų ar srities, kur sistema bus 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.


Bibliotekos sistema LIBSYS

• Sistema, kuria naudojantis galima prieiti prie tam tikro skaičiaus straipsnius talpinančių duomenų bazių kitose bibliotekose

• Vartotojai gali atlikti straipsnių paiešką, išsaugoti rastus straipsnius bei spausdinti juos asmeniniam naudojimui


Funkcinių reikalavimų pavyzdžiai• Vartotojas privalo turėti galimybę paiešką atlikti

tiek visoje duomenų bazėje, tiek pasirinktame jospoaibyje

• Sistema turi aprūpinti vartotojus tinkamomisstraipsnių peržiūros priemonėmis (viewers), kadjie galėtų skaityti dokumentus tiesiai iš straipsniųsaugyklos/duomenų bazės

• Kiekvienam užsakymui turi būti priskirtasunikalus užsakymo numeris (ORDER_ID), kurįvartotojas galėtų išsaugoti savo užsakymųistorijoje


Reikalavimų netikslumai

• Jei reikalavimai suformuluoti netiksliai, neišvengiamai turėsime problemų

• Netiksliai apibrėžtus reikalavimus programuotojai ir vartotojai supras skirtingai

• Pvz, ką reiškia “atitinkama straipsnių peržiūros priemonė”

– Vartotojo pozicija – kiekvienam dokumento tipui pritaikyta atitnkama peržiūros programa (.pdf, .doc)

– Programuotojo pozicija – tekstinis peržiūros režimas( nes taip greičiau ir lengviau)


Reikalavimų pilnumas ir suderinamumas

• Reikalavimai turi būti ir pilni, ir suderinti.

• Pilni

– Jie turi pilnai aprašyti visas reikalingas sistemos funkcijas

• Suderinti

– Neturėtų būti vienas kitam prieštaraujančių sistemos reikalavimų reikalavimų

• Praktikoje yra sunku pateikti ir pilną, ir suderintą reikalavimų dokumentą.


Nefunkciniai reikalavimai

• Šie reikalavimai apibrėžia sistemos savybes (pvz. patikimumą, atsakymo į užklausą laiką, reikalavimus atminčiai) ir apribojimus (pvz. įvedimo/ išvedimo įrenginio galimybes)

• Proceso reikalavimai gali būti specifikuoti reikalaujant naudoti specialią CASE sistemą, programavimo kalbą ar projektavimo metodą.

• Nefunkciniai reikalavimai gali būti svarbesni už funkcinius reikalavimus. Jei jie nėra tenkinami, sistema gali būti bevertė


Nefunkcinių reikalavimų klasifikacija• 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, pvz. panaudoti procesų standartai, įdiegimo reikalavimai ir pan.

• Išoriniai reikalavimai

– Reikalavimai, atsirandantys iš išorinių sistemos faktorių, pvz sistemos suderinamumo reikalavimai, teisiniai reikalavimai ir pan.


Nefunkcinių reikalavimų tipai

Reikalavimai veikimo greičiui

Apimties reikalavimai

Panaudojamumo reikalavimai

Efektyvumo reikalavimai

Patikimumo reikalavimai

Pernešamumo reikalavimai

Darbingumo reikalavimai

Etiniai reikalavimai

Teisiniai reikalavimai

Kūrimo reikalavimai

StandartaiPristymo reikalavimai

Saugumo reikalavimai

Privatumo reikalavimai

Produkto reikalavimai

Organizaciniai reikalavimai

Išoriniai reikalavimai

Nefunkciniai reikalavimai


Nefunkcinių reikalavimų pavyzdžiai• Produkto reikalavimai

– 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 bei rezultate gauti dokumentai turi tenkinti standarto XYZCo-SP-STAN-95 reikalavimus.

• 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 sunku tiksliai suformuluoti, o netiksliai suformuluotus reikalavimus sunku patikrinti

• Tikslas

– Bendras vartotojo pageidavimas, pvz. lengvai įsisavinama programa

• Nefunkcinio reikalavimo tikrinimas

– Būtina suformuluoti aiškų matavimą, leisiantį patikrinti, ar reikalavimas įvykdytas

• Tokie tikslai yra labai naudingi sistemos kūrėjams, nes galima suprasti, ko iš sistemos tikisi galutiniai vartotojai


Pavyzdžiai

• Sistemos tikslas

– Sistema turi būti lengvai įsisavinama patyrusiųvartotojų ir turi būti suprojektuota taip, kad dirbdamivartotojai padarytų kaip galima mažiau klaidų

• Nefunkcinio reikalavimo patikrinimas

– Patyrę vartotojai privalo gebėti naudotis visomissistemos funkcijomis po max. dviejų valandųmokymų. Išklausius mokymus, vidutinis tokiųvartotojų leistinas klaidų sakičius per dieną neturiviršyti dviejų klaidų


Reikalavimų matavimai

Operacijos atlikimo greitis sekundėmis, ekrano persipiešimo greitis, per kiek laiko sureaguojama į vartotojo veiksmą

BaitaiRAM mikroshemų skaičius

Mokymų laikas

Kiek laiko dirba nenulūždama, lūžimų dažnis, išsaugotų po lūžimo duomenų kiekis ar atsatymo greitis

Per kiek laiko persikrauna po lūžimo, kiek procentų veiksmų iššaukia lūžimą, tikimybė prarasti duomenis

Koks kiekis programos kodo tinka pakartotiniam naudojimui, keliose sistemose galima panaudoti kodą

Greitis

Dydis

Naudojimo lengvumas

Patikimumas

Patvarumas

Pernešamumas


Reikalavimų sąveika• Konfliktai tarp skirtingų nefunkcinių reikalavimų

sudėtingose sistemose pasitaiko dažnai

• Lėktuvo valdymo programa

– Siekiant sumažinti svorį, atskirųmikroschemųskaičius sistemoje turi būti minimalus.

– Siekiant sumažinti energijos vartojimą, turi būtipanaudotos mažesnės galios mikroschemos.

– Tačiau naudojant mažesnio galingumomikroschemas, jų gali prireikti daugiau... Kuris reikalavimas yra svarbesnis?


Srities reikalavimai

• Gauti iš sistemos taikymo srities bei nusako tą konkrečią sritį atspindinčias charakteristikas.

• Tai gali būti nauji funkciniai reikalavimai, egzistuojančių reikalavimų apribojimai arbaapibrėžti specifiniai skaičiavimai.

• Jei srities reikalavimai netenkinami, sistemanedirbs.


Bibliotekos sistemos srities reikalavimai• Visos duomenų bazės turi būti prieinamos

naudojantis standartine vartotojo sąsaja, aprašyta Z39.50 standarte.

• Dėl autorinių teisių apribojimų kai kurie dokumentai turi būti sunaikinami iš karto po jų peržiūros. Priklausomai nuo vartotojo teisių, šitie dokumentai arba bus spausdinami bibliotekoje ir po to atiduodami vartotojui, arba nukreipiami į vartotojo nurodytą tinklo spausdintuvą.


Srities reikalavimų problemos

• Suprantamumas (Understandability)

– Reikalavimai yra išreikšti srities taikymo kalba.

– Tokių reikalavimų nesupranta programinę įrangą kuriantys projektuotojai

• Neabejotinumas (Implicitness)

– Srities specialistai situacijoje gaudosi taip gerai, kad jie nė negalvoja apie tikslių srities reikalavimų sudarymą.


Vartotojo reikalavimai

• Turi aprašyti funkcinius ir nefunkcinius reikalavimus taip, kad juos suprastų detalių techninių žinių neturintys sistemos vartotojai.

• Vartotojo reikalavimai yra apibrėžiami naudojant natūralią kalbą, lenteles ir diagramas.


Natūralios kalbos naudojimo problemos

• Aiškumo trūkumas

– Jei norime, kad būtų lengva skaityti, tai nebus aiškumo, jei norime aiškumo, tada teks pridėti papildomų detalių ir skaityti lengva jau nebus...

• Reikalavimų painiava

– Aiškiai neatskiriami funkciniai ir nefunkciniai reikalavimai

• Reikalavimų apjungimas

– Keli skirtingi reikalavimai gali būti pateikti kaip vienas


LIBSYS vartotojo reikalavimas

4..5 LIBSYS turi pateikti visų vartotjo atliktų mokėjimo operacijų sąrašą. Sistemos administratoriai gali suderinti sistemą taip, kad vartotojas gautų nuolaidas teikiamoms paslaugoms.


LIBSYS vartotojo reikalavimo problema

• Reikalavimas apima tiek koncepcinę, tiek detalią informaciją:

– Aprašo dalį finansų apskaitos sistemos, kuri bus prijungta prie LIBSYS;

– Tuo pačiu pateikia tokios sistemos detales – bus galima gauti nuolaidas


Patarimai reikalavimų rašymui

• Susirasti šabloną ir jį naudoti visų reikalavimų užrašymui (Volere).

• Naudoti kalbą tinkamu būdu, pvz. žodis “turi”privalomiems reikalavimams, “ turėtų” pageidaujamiems reikalavimams.

• Naudoti teksto paryškinimą reikalavimų esminių dalių identifikavimui.

• Vengti kompiuterinio žargono.


Sistemos reikalavimai

• Tai daug detalesnis sistemos funkcioanlumo bei apribojimų aprašymas, negu vartotojų reikalavimai

• Tarnauja kaip pagrindas kuriant sistemą.

• Gali būti įtraukiami į sistemos kontraktą.

• Sistemos reikalavimai gali būti išreiškiami ar papildomi sistemos modeliais


Reikalavimai ir projektavimas

• Reikalavimai turi nurodyti, ką sistema turi daryti, o projektavimo dokumentas nusakyti, kaip tai turi būti daroma.

• Praktikoje reikalavimai ir projektavimas yra neatskiriami:

– Sistemos architektūra gali būti suprojektuota tam, kad patikslintų reikalavimus.

– Sistema gali dirbti su kitomis sistemomis, kurios generuoja projekto reikalavimus.

– Specialaus dizaino parinkimas gali būti srities reikalavimas.


Problemos dėl specifikacijų, parašytų natūralia kalba

• Dviprasmiškumas

– Reikalavimų skaitytojai ir autoriai tą patį žodį turi interpretuoti taip pat. Natūrali kalba yra nevienareikšmė, todėl tą pasiekti yra labai sunku.

• Per didelis lankstumas

– Tas pats dalykas specifikacijoje gali būti pasakytas keliais skirtingais būdais.

• Struktūrizavimo trūkumas

– Natūrali kalba netinka sistemos reikalavimų struktūrizavimui.


Struktūrizuotos kalbos specifikacijos

• Reikalavimų analitiko “žodžio laisvė” yra iš anksto apribota tam tikru šablonu

• Visi reikalavimai užrašomi tuo pačiu stiliumi

• Naudojami tie patys terminai (terminų žodynas)

• Tai panaikina kai kurias problemas, atsiradusias dėl nevienareikšmiškumo, ir suteikia specifikacijai vienodą stilių


Formomis paremtos specifikacijos

• Funkcijos ar objekto apibrėžimas

• Įvedimo duomenų aprašymas, iš kur jie ateina

• Rezultatų aprašymas ir kur jie nueina

• Kitų reikalingų objektų atpažinimas

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

• Pašaliniai efektai (jei yra)


Formomis paremtos specifikacijos pvz.

Insulin Pump/Control Software/SRS/3.3.2

Function Compute insulin dose: Safe sugar level

Description Computes the dose of insulin to be delivered when the current measured sugar level is inthe safe zone between 3 and 7 units.

Inputs Current sugar reading (r2), the previous two readings (r0 and r1)

Source Current sugar reading from sensor. Other readings from memory.

Outputs CompDose Š the dose in insulin to be delivered

Destination Main control loop

Action: CompDose is zero if the sugar level is stable or falling or if the level is increasing but the rate ofincrease is decreasing. If the level is increasing and the rate of increase is increasing, then CompDose iscomputed by dividing the difference between the current sugar level and the previous level by 4 androunding the result. If the result, is rounded to zero then CompDose is set to the minimum dose that canbe delivered.

Requires Two previous readings so that the rate of change of sugar level can be computed.

Pre-condition The insulin reservoir contains at least the maximum allowed single dose of insulin..

Post-condition r0 is replaced by r1 then r1 is replaced by r2

Side-effects None


Lentelės formos specifikacija

• Papildo natūralią kalbą

• Naudinga tada, kai yra daug alternatyvių variantų


Lentelės formos specifikacija

Condition Action

Sugar level falling (r2 < r1) CompDose = 0

Sugar level stable (r2 = r1) CompDose = 0

Sugar level increasing and rate ofincrease decreasing ((r2-r1)<(r1-r0))

CompDose = 0

Sugar level increasing and rate ofincrease stable or increasing. ((r2-r1) �(r1-r0))

CompDose = round ((r2-r1)/4)If rounded result = 0 thenCompDose = MinimumDose


Grafinis modelis

• Naudingas tada, kai reikia parodyti būsenos pasikeitimus ar veiksmų sekas

• Bus daugiau ☺


Sekos diagramos

• Parodo įvykių sekas, kurios atsiras vartotojui dirbant su sistema

• Skaitomos iš viršaus į apačią tam, kad nustatyti, kokia tvarka turi būti atliekami veiksmai.

• Pinigų išėmimas iš bankomato:

– Kortelės identifikavimas;

– Užklausos pateikimas;

– Operacijos užbaigimas.


Sekos diagrama pinigų išėmimui iš automato


Sąsajos specifikacija

• Dauguma sistemų sąveikauja su kitomis sistemomis, todėl sąsaja turi būti specifikuojama kaip reikalavimų dalis.

• Yra trys sąsajų tipai

– Procedūrinė sąsaja;

– Duomenų struktūros, kuriomis keičiasi programos;

– Duomenų vaizdavimas.

• Formalios specifikacijos labiausiai tinka sąsajos specifikavimui.


Procedūrinės sąsajos pavyzdys

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


Reikalavimų specifikacijos dokumentas

• Reikalavimų specifikacija yra oficialus dokumentas, ko reikalaujama iš sistemos kūrėjų.

• Į ją turi būti įtraukiami ir vartotojo reikalavimai, ir sistemos specifikacija

• Tai ne projektavimo dokumentas. Jis akcentuoja KĄ sistema turi padaryti, o ne KAIP ji turi padaryti.


Reikalavimų specifikacijos dokumento naudotojai

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ų specifikacijos dokumentas

• Turi nustatyti išorinį sistemos elgesį.

• Turi nustatyti realizavimo apribojimus.

• Turi būti lengvai keičiamas.

• Turi būti atskaitos taškas programinės įrangos palaikymui.

• Vertinti sistemos gyvavimo ciklą, tai yra nuspėti pakeitimus.

• Charakterizuoti atsakymus į netikėtus įvykius


IEEE reikalavimų standartas

• Nusako bendrą reikalavimų specifikacijos struktūrą:

– Įvadas.

– Bendras aprašymas.

– Specifiniai reikalavimai.

– Priedai.

– Indeksų lentelės.


Reikalavimų specifikacijos dokumento struktūra

• Priešistorė

• Įvadas

• Santrauka

• Vartotojo reikalavimų apibrėžimas

• Sistemos architektūra

• Sistemos reikalavimų specifikacija

• Sistemos modeliai

• Sistemos palaikymas

• Priedai

• Indeksų lentelės


Esminiai aspektai

• 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 aspektai

• Vartotojo reikalavimai turi būti parašyti natūralia kalba, lentelėmis ir diagramomis.

• Sistemos reikalavimai skirti funkcijoms, kurias sistema turi vykdyti.

• Yra specialūs šablonai ir standartai

program ų sistem ų inžinerija reikalavimai programinei įrangai

Documents