U ovoj lekciji obrađivaćemo:

    • Oblast softverskih zahteva
    • Podoblasti softverskih zahteva
    • Specifikacija zahteva (Requirements Specification)
    • Validacija zahteva (Requirements Validation)
    • Praktična razmatranja (Practical Considerations)


Specifikacija zahteva

Za većinu inženjerskih profesija, termin specifikacija odnosi se na dodelu numeričkih vrednosti ili ograničenja ciljevima dizajna proizvoda. Tipičan fizički sistem ima relativno mali broj ovih vrednosti. Tipičan softver ima veliki broj zahteva. Specifikacija softverskih zahteva tipično se odnosi na kreiranje dokumenta ili elektronskog zapisa, koji se sistematično revidira, evaluira i poboljšava. Za kompleksne sisteme, kreiraju se i do tri dokumenta:

    • System definition
    • System requirements
    • Software requirements


Specifikacija zahteva obuhvata:

    1. Dokument definicije sistema (The System Definition Document)
    2. Specifikacija sistemskih zahteva (System Requirements Specification)
    3. Specifikacija softverskih zahteva (Software Requirements Specification)


Dokument definicije sistema

Dokument definicije sistema često se drugačije naziva dokument sistemskih zahteva, ili u stranoj literaturi "User Requirements Document" ili "Concept of Operations".

Definiše sistemske zahteve visokog nivoa (kao i sveobuhvatne ciljeve sistema u pozadini), radno okruženje, stavke o ograničenjima, pretpostavkama, nefunkcionalnim zahtevima. Može da uključi konceptualni model radi ilustracije konteksta sistema, kao i entitete, podatke, informacije i dijagrame. Standard "IEEE Std 1362 - Concept of Operations Document", daje uputstvo za pripremu takvog dokumenta.

Specifikacija sistemskih zahteva

Sistemi sa velikim softverskim i nesoftverskim komponentama (npr. moderan avion) imaju odvojene opise sistemskih zahteva od opisa softverskih zahteva. Na taj način specifikuju se sistemski zahtevi, dok se softverski zahtevi izvode iz sistemskih zahteva, pa se onda specificiraju zahtevi za softverske komponente. Strogo posmatrajući specifikacija sistemskih zahteva je aktivnost sistemskog inženjerstva, a ne softverskog inženjerstva.

Specifikacija softverskih zahteva

Specifikacija softverskih zahteva postavlja osnovu za kreiranje ugovora šta softverski proizvod treba da radi i šta nije predviđeno da radi. Podrazumeva uključivanje i vezu sa marketing službom. Radi razumljivosti, netehničkim licima dokument "specifikacija softverskih zahteva" često se nadopunjuje sa dokumentom "definicija softverskih zahteva". Specifikacija softverskih zahteva podrazumeva rigoroznu proveru zahteva pre samog početka dizajna i izbegavanja kasnijeg redizajna. Ona obezbeđuje i realističnu procenu troškova, rizika i rokova.

Takođe, specifikacija softverskih zahteva obezbeđuje osnovne informacije za transfer softverskog proizvoda novim korisnicima ili instalacije na novim mašinama. Specifikacija softverskih zahteva se često piše koristeći formalne ili polu-formalne opise i notacije. Izbor zavisi od potrebe preciznijeg opisa, što je važno kod bezbedonosnih softvera.

Podsetimo se još jednom šeme oblasti softverskih zahteva.

Slika 1.

Validacija zahteva

Gore navedeni dokumenti, predmet su validacije i verifikacije. Zahtevi se validiraju da bi se osiguralo da je softver inženjer razumeo zahteve i da bi se verifikovalo da dokument zahteva zadovoljava standard kompanije, da je razumljiv, konzistentan i kompletan. Više učesnika treba da revidira dokument, uključujući predstavnike kupaca i razvojnog sektora. Dokumenti zahteva su tema istog Software Configuration Management-a kao i ostali ishodi procesa životnog ciklusa softvera. Uobičajeno je da se napravi raspored validacije - definisanje više tačaka u procesnim parametrima (Requirements Process). Cilj je otkriti probleme pre nego što se rasporede resursi u cilju njihovog zadovoljenja. Validacija zahteva je proces ispitivanja dokumenta zahteva (Requirements Document) da bi se osiguralo da definiše ispravan softver (onaj koji očekuje korisnik).

Validacija zahteva obuhvata:

    1. Revidiranje zahteva (Requirements Reviews)
    2. Prototip (Prototyping)
    3. Validacija modela (Model Validation)
    4. Test prihvatljivosti (Acceptance Tests)


Revidiranje zahteva

Najčešći način validacije je inspekcija ili revidiranje dokumenta zahteva. Grupa "revizora" pregleda dokumente u potrazi za greškama, pogrešnim pretpostavkama, odstupanjima od uobičajene prakse i sl. Sastav grupe je takođe veoma važan - najmanje jedan predstavnik kupaca treba da bude uključen. Kreira se lista po kojoj se vrši validacija.

Pregled može biti konstituisan sa ciljem kompletiranja:

    • dokumenta definicije sistema,
    • dokumenta specifikacije sistemskih zahteva,
    • dokumenta specifikacije softverskih zahteva,
    • osnovne specifikacije za novo izdanje.


Dokument IEEE Std 1028 obezbeđuje uputstvo za sprovođenje ovakvih pregleda.

Prototip

Prototip je najčešći način za validaciju interpretacije softverskih zahteva od strane softver inženjera. Postoji više prototipskih tehnika i više tačaka u procesu gde je prikladna prototipska validacija. Prednost prototipa je što olakšavaju interpretaciju pretpostavki softver inženjera i daju korisne povratne informacije (Feedback - npr. User Interface se bolje razume kroz animacioni prototip nego kroz tekstualni opis). Postoje i nedostaci protitipa:

    • skretanje pažnje korisnika sa ključnih funkcionalnosti softvera
    • bavljenje kvalitetom prototipa


Mnogi stoga preporučuju da se prototip realizuje ne preko softvera već npr. flip-chart-a.

Prototipovi mogu biti skupi za realizaciju, ali ako štede resurse u pokušajima zadovoljavanja određenih zahteva, svakako su troškovi opravdani.

Validacija modela

Validacija modela podrazumeva validaciju kvaliteta modela razvijenog tokom analize. Npr. u objektnom modelu poželjno je uraditi statičku analizu u cilju provere komunikacionih veza između objekata.

Test prihvatljivosti

Jedna od osobina softverskih zahteva je da bude moguće validirati da li ih finalni proizvod zadovoljava. Zahtevi koji se ne mogu validirati ostaju samo želje. Treba pažljivo planirati kako se verifikuje svaki zahtev. Jedan od načina je dizajniranje testa prihvatljivosti:

    • dizajniranje testa prihvatljivosti može biti teško za nefunkcionalne zahteve
    • da bi bili validirani, moraju se analizirati do tačke gde mogu biti izraženi kvantitativno


Praktična razmatranja

Procesni zahtevi se proširuju na ceo životni ciklus softvera. Upravljanje promenama i upravljanje zahtevima u stanju koje vodi do ispravne proizvodnje softvera ili već izgrađenog softvera, ključ je uspeha procesa softverskog inženjerstva. Javlja se i problem - nema svaka organizacija kulturu dokumentacije i upravljanja zahtevima. Često se u nedostatku resursa i vremena pregled dokumentacije zahteva zanemaruje. Dobra dokumenta zahteva (Requirements documentation) i upravljanje promenama su ključ uspeha svakog procesnog zahteva.

Praktična razmatranja obuhvataju:

    1. Iterativnu prirodu procesa uzimanja zahteva (Iterative Nature of the Requirements Process)
    2. Upravljanje promenama (Change Management)
    3. Atributi zahteva (Requirements Attributes)
    4. Praćenje zahteva (Requirements Tracing)
    5. Merenje zahteva (Measuring Requirements)


Iterativna priroda procesa uzimanja zahteva

U praksi je gotovo nemoguće implementirati procesni zahtev kao linearan, deterministički i predati ga razvojnom timu. Perfektno shvatanje i razumevanje zahteva kada su u pitanju veliki projekti je teško izvodljivo. Zahtevi se iteriraju do nivoa kvaliteta i detalja koji su dovoljni za propuštanje na fazu dizajna. Neki zahtevi se izdvajaju kao osnovni i razmatraju se do potpunog razumevanja, zbog rizika skupe ponove izvedbe zahteva, ako se problem pojavi kasnije tokom procesa softverskog inženjerstva.

Uvek postoji revizija zahteva koja se javlja kasnije tokom životnog ciklusa. Značajna mera promena zahteva će se desiti, nekada zbog grešaka tokom analize, ali najviše zbog promena u okruženju.

Upravljanje promenama

Upravljanje promenama predstavlja centralno mesto za upravljanje zahtevima. Važno je valojano procesirati promene zahteva, primeniti usvojene procedure i uraditi analize za predložene promene. Upravljanje promenama je vezano i za oblast "upravljanje softverskom konfiguracijom".

Atributi zahteva

Zahtevi se ne sastoje samo od specifikacija, već i od informacija koje pomažu da se upravljaju i interpretiraju zahtevi. Ovo uključuje i različite dimenzije klasifikacije (kao što je opisano u "klasifikaciji zahteva") i verifikacionog metoda i prihvatanja test plana. Mogu da se uključe i dodatne informacije, kao što su izvor svakog zahteva, istorija promena i dr. Svaki zahtev treba da ima identifikator koji ga jednoznačno identifikuje.

Praćenje zahteva

Praćenje zahteva se bavi utvrđivanjem izvora zahteva i predviđanja efekata zahteva. Praćenje je fundamentalno za primenu analize kada se promeni zahtev. Zahtevi se često prosleđuju napred (onima koji ih kompletiraju – razvojni tim) i nazad (onima koji ih iniciraju). Često praćenje zahteva za tipičan projekat rezultuje formiranjem Directed Acyclic Graph (DAG) zahteva.

Merenje zahteva

Često su nam potrebne i praktične merljive brojke zahteva za dati softverski proizvod. Brojevi se koriste i radi utvrđivanja veličine promena u zahtevima, kao i proceni troškova razvoja ili određenog taska za održavanje. Jedna od tehnika za evaluaciju veličine zahteva je Functional Size Measurement (FSM). IEEE Std 14143.1 definiše FSM koncept.

Dodaj komentar Sviđa mi se - (1) Ne sviđa mi se - (1)    

  • Specifikacija i validacija softverskih zahteva 1
  • Specifikacija i validacija softverskih zahteva 2
  • Specifikacija i validacija softverskih zahteva 3