Software Requirements Specification

za

<Projekt>
Verzija 1.0 odobrena

Kreirao <autor>

<organizacija>

<datum kreiranja>

Software Requirements Specification za <Projekt>

Strana ii

Sadraj
1. Uvod............................................................................................................................................ 1 2. Cjelokupni opis...........................................................................................................................2 3. Osobine sustava..........................................................................................................................3 4. Zahtjevi vanjskih poveznica......................................................................................................4 5. Ostali nefunkcionalni zahtjevi ................................................................................................. 5 6. Ostali zahtjevi ............................................................................................................................5

Povijest prepravaka
Ime Datum Razlog za promjenom Verzija

Software Requirements Specification za <Projekt>

Strana 1

1.
1.1

Uvod
Svrha

<Identificirajte za koji proizvod su specificirani zahtjevi u ovom dokumentu, ukljuivi i broj revizije ili verzije proizvoda. Opiite SCOPE proizvoda koji je pokriven ovim dokumentom, pogotovo ako ovaj dokument opisuje samo dio sustava ili odreeni podsustav.>

1.2

Standardi dokumentiranja

<Po potrebi opiite sve tipografske i druge standarde koji su se pratili tijekom pisanja ovog dokumenta, kao to su fontovi slova ili neke oznake koje imaju specijalno znaenje. Na primjer, objasnite da li su prioriteti u viim razinama zahtjeva nasljeeni od strane detaljiziranih zahtjeva ili da li svaki dokumentiran zahtjev ima svoj prioritet.>

1.3

Kome je dokument namjenjen i kako ga koristiti

<Opiite razliite osobe ili grupe osoba kome je ovaj dokument namjenjen, kao to su programeri, projekt manageri, marketinko osoblje, korisnici, SW testeri ili sastavljai dokumentacije. Opiite od ega se sastoji ostatak ovog dokumenta i kako je dokument organiziran. Predloite nain na koji treba itati dokument, poevi sa uvodnim dijelovima te kasnije nastaviti kroz dijelove dokumenta koji su najbitiniji pojedinom tipu osobe koja koristi dokument.>

1.4

Project Scope

<Iznesite kratki opis aplikacije za koju se rade specifikacije i njenu svrhu, ukljuujui prednosti i ciljeve koje sa sobom nosi razvoj te aplikacije. Opiite kako se aplikacija odnosi prema poslovnim ciljevima i strategijama organizacije koja naruuje proizvod. Ukoliko postoji zaseban dokument u kojem je iznesena vizija i scope proizvoda, tada ovaj lanak referirajte na taj dokument. Nema potrebe da se dupliciraju navodi. Software requirements specification dokument koji specificira zahtjeve nove verzije proizvoda, treba sadravati poseban scope opis koji se odnosi ba za tu verziju i to kao podskup od dugorone strategije vizije proizvoda.>

1.5

Reference

<Nabrojite sve ostale dokumente ili web adrese na koje se odnosi ovaj SRS dokument. To mogu biti vodii za dizajn user interface-a, ugovori, standardi, zahtjevi sustava, use case dokumenti ili vision and scope dokumenti. Dajte dovoljno informacija tako da itatelj moe doi do kopije od svake reference, ukljuujui naslov, autor, broj verzije, datum i izvor ili lokaciju.>

Software Requirements Specification za <Projekt>

Strana 2

2.
2.1

Cjelokupni opis
Perspektiva proizvoda

<Opiite kontekst u kojem se proizvod razvija i njegove razloge za razvoj. Opiite da li je to nova verzija ve implementiranog proizvoda, zamjena za postojeu aplikaciju, novi lan rastueg skupa proizvoda ili potpuno novi proizvod. Ako SRS dokument definira komponentu nekog veeg sustava, navedite kako se ovaj sustav odnosi prema cjelokupnom sustavu i identificirajte glavne njihove poveznice. Context diagram nam tu moe biti od velike koristi.>

2.2

Osobine i mogunosti proizvoda

<Nabrojite glavne osobine koje proizvod posjeduje ili znaajne funkcije koje proizvod moe izvoditi. Detalji o funkcijama e biti opisani i sekciji 3 SRS dokumenta, dakle ovdje trebamo samo povran opis. Organizirajte funkcije na nain da budu razumljive svakom itatelju. Tu nam moe pomoi grafika prezentacija glavne grupe zahtjeva i u kakvom su meusobnom odnosu, npr. data-flow diagram koji opisuje protok informacija ali na vioj razini, use case diagram ili dijagram klasa.>

2.3

Klase korisnika i njihove karakteristike

< Identificirajte razliite klase korisnika za koje mislite da e koristiti proizvod i opiite njihove karakteristike. Klase korisnika mogu se razlikovati prema uestalosti koritenja proizvoda, tehnikoj ekspertizi, razini privilegija i sigurnosti koje posjeduju, razini obrazovanja ili iskustvu. Neki zahtjevi mogu se odnositi samo na odreene klase korisnika. Identificirajte one klase koirisnika koji imaju vei znaaj od ostalih (pokazali smo kako se to radi). Klase korisnika predstavljaju podklasu od stakeholders-a i to grupa koja je naruila proizvod..>

2.4

Operativno okruje

<Opiite okruje u kojem e SW proizvod biti implementiran, ukljuujui hardware platforme, operativne sustave i verzije, zemljopisne lokacije korisnika, servere i baze podataka. Nabrojite sve ostale komponente ili aplikacije sa kojim sustav mora istovremeno djelovati.>

2.5

Ogranienja dizajna i implementacije

<Opiite sve faktore koji mogu ograniavati opcije koje su dane programerima i razloge za njihovo postojanje. To mogu biti korporativna politika poslovanja, ogranienja hardware opreme (npr. ogranienja memorije i procesora ), poveznice sa ostalim aplikacijama, specifine tehnologije, alati, baze podataka koje e se koristiti, paralelne operacije koje e se izvoditi, ogranienja u izboru programskih jezika, komunikacijski protokoli, sigurnost, standardi programiranja i dizajniranja (npr. ako e klijentova organizacija biti odgovorna za odravanje aplikacije).>

Software Requirements Specification za <Projekt>

Strana 3

2.6

Korisnika dokumentacija

< Nabrojite sve dokumente koji e se dostaviti zajedno sa software-om. To mogu biti korisniki prirunici, online help i udbenici. Identificirajte sve formate, standarde ili alate u kojima dokumentacija treba biti kreirana. >

2.7

Pretpostavke

< Nabrojite sve predpostavljene injenice (kao suprotnost poznatim injenicama) koji mogu utjecati na zahtjeve izneene u ovom dokumentu. To mogu biti COTS (Commercial of-the-shelfs) komponente koje planirate koristiti, problemi oko razvoja ili operativnog okruja ili ograninja. Problemi mogu nastati ako su predpostavke netone, ne dijeljive, ili promjenjive tako da tada odreene predpostavke mogu aktivirati rizike projekta. Isto tako identificirajte sve vanjske objekte koje utjeu na proizvod i o kojima isti ovisi te su van njegove kontrole, kao to su na primjer SW komponente iz drugog projekta koje planirate iskoristiti u ovom.>

3.

Osobine sustava

<Ovaj predloak pokazuje organizaciju funkcionalnih zahtjeva proizvoda prema osobinama sustava - glavne usluge koje proizvod prua, to je samo jedan od moguih naina da se posloe funkcionalni zahtjevi. Ostale mogunosti su organizacija te sekcije prema use case, operativnom modelu, klasama korisnika, funkcionalnoj hijerarhiji ili njihovoj kombinaciji - to se god ini logino za va proizvod.>

3.1

Osobina sustava 1

<Ne trebate ba pisati Osobina sustava 1., izrazite ime osobine u samo nekoliko rijei.>

3.1.1

Opis i prioritet
<Iznesite kratki opis osobine i pokaite da li ima visoku, srednju ili nisku prioritetnost. Moete isto ukljuiti specificiranu ocjenu prioriteta za pojedinu komponentu, npr. za korist, kaznu, troak ili rizik (za svaku primjenite relativnu skalu od 1 za najniu do 9 za najviu).>

3.1.2

Stimulus/Response Sequences
<Nabrojite sve sljedove ulaznih parametara koji potiu sustav na akciju i odgovor sustava kao njegova reakcija koji definira ponaanje sustava za tu osobinu. To e se podudarati sa elementima pripadajueg use cases dijaloga.>

3.1.3

Functional Requirements
<Navedite detaljne funkcijske zahtjeve koji se odnose na tu osobinu. To su mogunosti aplikacije koje moraju biti implementirane da bi korisnik izvrio use case (opisni scenario) ili da bi izvrio opisanu uslugu. Opiite kako bi sustav trebao reagirati ukoliko se pojavi pogreka ili ukoliko se unese nepravilan input. Zahtjevi moraju biti precizni, kompletni, nedvojbeni, potrebni i sa mogunou da se mogu ovjeriti. Koristite TBD (To Be Determined) notaciju da indicirate kako sve potrebne informacije jo nisu dostupne.> <Jedinstveno i sa smislom oznaite svaki funkcionalan zahtjev.>

Software Requirements Specification za <Projekt>

Strana 4

REQ-1: REQ-2:

3.2

Osobina sustava 2 (itd)

4.
4.1

Zahtjevi vanjskih poveznica

User Interfaces

< Opiite logike karakteristike svakog user interface-a koji su potrebni sustavu. Neke mogue stavke su reference za GUI ili dizajn standarde koji se moraju sljediti, standardi za fontove, ikone, button labels, slike, color schemes, uobiajeno koritene kontrole, izgled ekrana i ogranienja rezolucije, standard buttons, funkcije ili linkovi navigacije koji e se pojavljivati na svakom ekranu, (npr. help button), shortcut keys, standardi prikazivanja upozorenja i poruka, mogunost prilagodbe za ljude sa oteenjima vida. >

4.2

Hardware Interfaces

<Opiite logike i fizike karakteristike svake poveznice izmeu software i hardware komponenti sustava. Ovaj opis moe ukljuivati tipove ureaja za koje postoji podrka, kontrola software/hardware interakcije i protoka podataka te komunikacijski protokoli koji e se koristiti.>

4.3

Software Interfaces

<Opiite konekcije izmeu ovog proizvoda i drugih aplikacija (identificirajte sa imenom i verzijom), ukljuivi baze podataka, operativne sustave, alate, libraries i integrirane komercijalne komponente. Iznesite svrhu poruka, podataka i kontrolnih procesa koje SW komponente meusobno izmjenjuju. Opiite usluge koje su potrebne vanjskim poveznicama i prirodu njihove komunikacije. Identificirajte podatke koji e se dijeliti meu komponentama - ako se radi toga treba na poseban nain implementirati mehanizam za diljeljenje podataka, tada to specificirajte kao ogranienje.>

4.4

Communications Interfaces

<Navedite zahtjeve za sve komunikacijske funkcije koje e proizvod koristiti, ukljuivi e-mail, Web browser, mrene protokole i elektronske forme. Identificirajte sve komunikacijske standarde koji e se koristiti, kao to su HTTP ili FTP. Specificirajte sve injenice koje se tiu sigurnosti komunikacije i mogue enkripcije, rate transfera podataka i mehanizme njihovih usklaivanja.>

Software Requirements Specification za <Projekt>

Strana 5

5.
5.1

Ostali nefunkcionalni zahtjevi

Performance Requirements

<Ako postoje specifini zahtjevi za performance sustava koji su povezani sa razliitim operacijama sustava, tada ih navedite u ovom odjeljku. Objasnite njihove razloge tako da budu vodi programerima prilikom odabira dizajna. Specificirajte vremensko usklaivanje za real-time sustave. Specificirajte takve zahtjeve to je mogue preciznije. Ako odreeni funkcionalni zahtjevi imaju zasebne performance zahtjeve, tad je prikladno specificirati te performance ciljeve odmah sa pripadajuim funkcionalnim zahtjevima .>

5.2

Zahtjevi zatite

< Ovdje specificirajte zahtjeve koji se odnose na moguu tetu ili oteenja koji mogu nastati sa koritenjem proizvoda. Definirajte sve akcije koje se trebaju u tom sluaju poduzeti kao i potencijalne opasne aktivnosti koje se trebaju sprijeiti. Identificirajte sve certifikate i regulative o zatiti sustava koje proizvod mora zadovoljiti..>

5.3

Zahtjevi sigurnosti

<Specificirajte sve zahtjeve koji se odnose na sigurnost, cjelovitost ili privatnost a koji utjeu na pristup i koritenje sustava te na ouvanje podataka koje proizvod koristi ili kreira. Definirajte sve zahtjeve za autentifikaciju korisnikog indetiteta. Zahtjevi sigurnosti uobiajeno dolaze iz pravila poslovanja, tako da se trebaju prepoznati sva siguronosna pravila i regulative koje proizvod treba zadovoljavati.>

5.4

Atributi SW kvalitete

< Navedite sve dodatne karakteristike kvalitete proizvoda koji mogu biti vani ili klijentima ili programerima. Neke od njih su: adaptability, availability, correctness, flexibility, interoperability, maintainability, portability, reliability, reusability, robustness, testability i usability. Te karakteristike trebaju, kad je god to mogue, biti specificirane, mjerljive i imati sposobnost provjere. Navedite relativne prioritete razliitih atributa, npr. lakoa upotrebe prema lakoi uenja upotrebe ili prenosivost u odnosu na efikasnost.>

6.

Ostali zahtjevi

<Definirajte sve ostake zahtjeve koji nisu nigdje pokriveni u ovom SRS dokumentu. To mogu biti zahtjevi u vezi sa meunarodnim poslovanjem, zahtjevi baze podataka, pravni zahtjevi itd. Dodajte predloku svaku novu sekciju koja je neophodna vaem projektu.>

Software Requirements Specification za <Projekt>

Strana 6

Dodatak A: Rijenik
<Definirajte sve specificirane pojmove koje itatelj treba znati da bi ispravno intepretirao SRS dokument, ukljuivi i kratice. Razmotrite razvijanje rijenika na nivou cijele organizacije koji bi se tada mogao protegnuti i na razliite projekte>

Dodatak B: Modeli analize

<Proizvoljno ukljuite postojee modele analize kao to su modeli protoka podataka, diagrami klasa, state-transition diagrami ili entity-relationship diagrami.>

Dodatak C: Lista problema

< Ovo je dinamika lista svih otvorenih stavki glede zahtjeva, a koje se moraju rijeiti ukljuujui TBDs, odluke na ekanju, informacije koje su potrebne, konflikti koji se moraju rijeiti...>