Specifikacija softverskih zahteva

Embed Size (px)

DESCRIPTION

Specifikacija softverskih zahteva Autor: Goran Radić, dipl.ingNaziv jedinice: Softverski zahtevi (Software Requirements)U ovoj lekciji obradjivaćemo:• • •Oblast Software Requirements Značaj ove oblasti za razvoj kompletnog softvera Podoblasti Software RequirementsRazvoj softverskog inženjerstva Uprkos činjenici postojanja miliona softverskih profesionalaca širom sveta i širokoj prisutnosti softvera u društvu, softversko inženjerstvo je tek nedevano steklo status legitimne inženjerske dis

Text of Specifikacija softverskih zahteva

Specifikacija softverskih zahteva Autor: Goran Radi, dipl.ing

Naziv jedinice: Softverski zahtevi (Software Requirements)U ovoj lekciji obradjivaemo:

Oblast Software Requirements Znaaj ove oblasti za razvoj kompletnog softvera Podoblasti Software Requirements

Razvoj softverskog inenjerstva Uprkos injenici postojanja miliona softverskih profesionalaca irom sveta i irokoj prisutnosti softvera u drutvu, softversko inenjerstvo je tek nedevano steklo status legitimne inenjerske discipline i priznate profesije. Nedavno su usvojeni standardi i dokumentacija nekoliko tela i komiteta. IEEE Computer Society definie softversko inenjerstvo kao sistematian i disciplinovan pristup razvoju, upravljanju i odravanju softvera. Na slici je prikazana ema softverskog inenjerstva prema SWEBOK-u:

Software Requirements Oblast Software Requirements se bavi izvlaenjem, analizom, specifikacijom i validacijom softverskih zahteva. iroko je prihvaena i priznata oblast u sotverskoj industriji. Softverski projekti su posebno ranjivi kada se ove aktivnosti realizuju na lo nain. Temelj je od koga polaze ostale oblasti i razvoj kompletnog softvera. Software Requirements predstavlja sistematsko rukovanje zahtevima. Postoje razlike u pristupu i modelovanju komponenti Software Requirements (npr. requirement engineer ili software engineer ili requirement specialist i sl.). Da bi proces uzimanja zahteva bio uspean mora se posmatrati kao proces kompleksnih i isprepletanih aktivnosti (sekvencijalnih i konkurentnih). Softverski zahtevi (Software Requirements) podrazumevaju osobine koje moraju biti ispitane kako bi se reio problem u realnom svetu. Software Requirements obuhvata sledee podoblasti: 1. Software Requirements Fundamentals 2. Requirements Process 3. Requirements Elicitation 4. Requirements Analysis 5. Requirements Specification 6. Requirements Validation 7. Practical Considerations

Detaljan prikaz podoblasti Software Requirements dat je na sledeoj slici:

Software Requirements Fundamenti Software Requirements Fundamentals obuhvata: 1. Definition of a Software Requirement 2. Product and Process Requirements 3. Functional and Nonfunctional Requirements 4. Emergent Properties 5. Quantifiable Requirements 6. System Requirements and Software Requirements Definicija Softverskih Zahteva Software Requirement je osobina koja mora biti predstavljena (prikazana) u cilju

reavanja nekog problema iz realnog sveta. Obrauje probleme kojima e se upravljati softverski u cilju njihovog reavanja. Primeri problema:

automatizacija procesa pomou softvera, osoba koje e ga koristiti podrka poslovnim procesima organizacije koja je naruila softver ispravljanje nedostataka postojeeg softvera upravljanje nekim ureajem i dr.

Sve navedeno moe biti izuzetno kompleksno, pa su i zahtevi kompleksna kombinacija od strane razliitih ljudi, sa razliitih nivoa u organizaciji i okruenja u kome e se softver koristiti. Osnovna karakterstika svih softverskih zahteva je da moraju biti verifabilni. Nekada je jako skupo i teko verifikovati neki zahtev. Na primer, verifikacija zahteva propusnog opsega call centra neizbeno iziskuje razvoj simulacionog softvera. Rangiranje prioriteta softverskih zahteva - radi kasnije raspodele resursa i praenja progresa. Softverski zahtevi moraju biti jedinstveno identifikovani. Proizvodni i procesni zahtevi Postoji razlika izmeu proizvodnih i procesnih parametara. Proizvodni parametri su zahtevi softveru koji se razvija (npr. softver treba da verifikuje da je student ispunio sve uslove da izae na ispit). Procesni parametri (Process Requirements) se tiu samog razvoja softvera (npr. softver treba da se pie u jeziku Ada). Neki softverski zahtevi generiu implicitne procesne zahteve. Jedan od primera je izbor verifikacione tehnike. Drugi je korienje tehnike analize za smanjenje greaka koje mogu da dovedu do neadekvatne pouzdanosti. Procesni zahtevi mogu biti uslovljeni od strane organizacije, njenih kupaca ili tree strane (safety regulator). Funkcionlani i nefunkcionlani zahtevi Funkcionalni zahtevi (nekada se zovu sposobnosti) opisuju funkciju koji softver treba da izvri (npr. modulacija signala ili formatiranje teksta). Funkcionalni zahtevi preciziraju ponaanja ili funkcije. Nefunkcionalni zahtevi preciziraju kriterijume koji se koriste za procenu funkcionisanja sistema. Nefunkcionalni zahtevi nekada se nazivaju i atributi kvaliteta, ciljevi kvaliteta, kvalitet servisnih zahteva i sl. Kao primer moe se uzeti prikaz broj zapisa u bazi (funkcionalni) i prikaz u realnom vremenu, ili do nekog perioda (nefunkcionalni). Primer nefunkcionalnih zahteva su i:

dovoljan mreni protok maintainability requirements, availability requirements i dr.

Emergent Properties Emergance je centralni termin kompleksnih sistema. Emergent Properties javljaju se kada vie jednostavnih entiteta operie u jednom okruenju i formiraju kompleksno ponaanje kao kolektiv. Zahtevi koji predstavljaju izlazne karakteristike. To su zahtevi koji se ne mogu obraditi jednom komponentom, ali e njihovo zadovoljenje zavisiti od sadejstva vie softverskih komponenti. Npr. zahtevi za propusnim opsegom call centra mogu da zavise od toga kako telefonski sistem, informacioni sistem i operatori rade pod odreenim operacionim uslovima. Emergent properties utiu na arhitekturu sistema. Kvantifabilni Zahtevi (Quantifiable Requirements) Softverski zahtevi treba da se navedu jasno i kvantitativno. Vano je izbei nejasne i neverifabilne zahteve koji zavise od interpretacije subjektivnog rasuivanja:

npr. softver mora biti pouzdan npr. softver mora biti user-friendly

Ovo je posebno vano kod nefunkcionalnih zahteva. Slede dva primera kvantifabilnih zahteva:

Softver za call centar: o softver mora poveati propusni opseg centra za 20% (propusni zahtev) o sofver treba da ima verovatnou generisanja fatalne greke tokom svakog sata rada sa manje od 10-8 (zahtev pouzdanosti)

System Requirements and Software Requirements Prema definiciji International Council on Systems Engineering (INCOSE00) sistem predstavlja interaktivnu kombinaciju elemenata (hardvera, softvera, ljudi, informacija, servisa, tehnika, objekata i dr.) u cilju postizanja zacrtanog cilja. Sistemski zahtevi su zahtevi za sistem kao celinu. Ako sistem sadri softverske komponente, softverski zahtevi su izvedeni iz sistemskih zahteva. U litetraturi se nekada umesto sistemskih zahteva koristi termin korisniki zahtevi (to bi ipak bili zahtevi krajnjih korisnika (enduser)). Sistemski zahtevi obuhvataju korisnike zahteve, zahteve regulatornih tela i dr. Requirements Process Requirements Process obuhvata: 2.1 Process Models 2.2 Process Actors

2.3 Process Support and Management 2.4 Process Quality and Improvement Modeli Procesa (Process Models) Cilj ove podoblasti je razumevanje procesa uzimanja zahteva. Aktivnost koja nije u prvom planu razvoja softvera, ali jeste proces koji se inicira na poetku projekta i usavrava tokom ivotnog ciklusa. Identifikacija softverskih zahteva kao konfiguracionih stavki i njihovo upravljanje pomou software configuration management vetina, kao i ostalih proizvoda procesa ivotnog ciklusa softvera. Treba da se prilagode organizaciji i kontekstu projekta. Ova podoblast obuhvata kako se aktivnosti izvlaenja, analize, specifikacije i validacije zahteva konfiguriu za razliite tipove projekata. Ukljuene su i aktivnosti koje obezbeuju ulaze za requirements process, kao to su marketing i studija izvodljivosti (feasibility studies). Uesnici u procesu (Process Actors) Podrazumeva opis uloge uesnika u requirements process-u. To je interdisciplinaran proces. Requirements specialist ima ulogu medijatora izmeu uesnika stakeholder-a (oni koji imaju interes od rezultata projekta ili oni na koje utie projekat) i software inenjera. Obino je vie uesnika ukljueno pored requirements specialist-a. Stakeholderi variraju od projekta do projekta, ali uvek ukljuuju korisnike i kupce. Tipini primeri softver stakeholdera ukljuuju:

korisnici - koji e koristiti softver, heterogene grupe kupci - obuhvata one koji naruuju softver ili one koji predstavljaju ciljnu grupu softvera marketing saradnici - istraivai trita, utvrivanje potreba trita regulatori - za aplikacije koje zahtevaju kontrolu (bankarstvo i sl.) i koji mora zadovoljiti zahteve regulatornih tela software engineers - ove osobe imaju legitiman interes u razvoju softvera, izvlaei i korist iz ve razvijenih kontrola (reuse u novim reenjima), paljiva analiza

Nije uvek mogue potpuno zadovoljenje zahteva svakog stakeholdera - preraspodela je odgovornost softver inenjera. Podrka i Upravljanje Procesom (Process Support and Management) Ova podoblast bavi se potrebama za resursima. Obuhvata project management resources. Koliko i kakvih resursa je potrebno i potroeno u toku procesa uzimanja zahteva

(requirements process). Vezano je sa podoblasti Initiation and scope definition iz oblasti znanja Software Engineering Management. Uspostavljanje veze izmeu podoblasti Process Models-a i pitanja trokova, ljudskih resursa, treninga i alata. Poboljanje i Kvalitet Procesa (Process Quality and Improvement) Ova podoblast se bavi procenom kvaliteta (quality) i poboljanja (improvement) procesa uzimanja zahteva (requirements process). Kljuna uloga u requirements procesu u pogledu termina su trokovi i vremenski rokovi proizvodnje softvera i zadovoljavanje potreba korisnika. Takoe ova podoblast pomae u orijentaciji requirements process-a ka standardima kvalitata. Process quality and improvement je blisko vezan sa oblastima:

Software Quality Software Engineering Process

Od posebnog znaaja je tema atributa i merenja softverskog kvalitata i definicije softverskog procesa. Process Quality and Improvement podrazumeva:

pokrivanje requirements procesa sa standardima unapreenja procesa i modela merenje i benchmarking requirements procesa planiranje poboljanja i nji