2 Ülesande püstitus Töös on olemas organisatsiooni ja hangitava süsteemi kirjeldus, süsteemi eesmärgid ja väärtus organisatsiooni jaoks, süsteemi omadused, huvipooled ja nende ootused. Samuti on kirjeldatud süsteemi huvipooled, eeldatavad kasutajad ja kasutamine organisatsioonis, süsteemi eeldatav arhitektuur ning hangitavad komponendid. Lisaks on kirjeldatud, millised valikulised tööd projektis tehakse ning miks need on valitud. 3.3 Nõuded süsteemile Töös on esitatud nouded kasutusjuhtudena. Projektis on olemas ka vastavalt projekti mahule töö autorite arvu järgi 15 funktsionaalset ja mittefunktsionaalset nouet. Sealhulgas kolm koormustesti. 3.4 Riskid ja vastuvõtutestid Projektis on kirjeldatud riskid, nende moju ning sagedus. Neile on antud prioriteedid ning identifikaatorid, et riskidele saaks viidata. Projektis on projekteeritud ka 30 riskipohist süsteemi voi tarkvara vastuvotutesti. Neist 18 on funktsionaalsete ja 12 mittefunktsionaalsete nouete testi
UML on ,,iseennast kirjeldav" (refleksiivne keel) s.t. tema standard (UML metamudel) on kirjeldatud UML keele enda vahendeid (peamiselt klassidiagramme) kasutades. Miks me teeme kasutusjuhtude diagramme? Mis on kasutusjuhtude diagrammi tegemise põhieesmärgiks? Kasutusjuhtude diagramm võimaldab modelleerida SÜSTEEMI ,,musta kastina" lähtudes temaga seotud tegutsejate ROLLIDEST ja EESMÄRKIDEST süsteemiga seoses, millest tuletatakse süsteemi (kasutusjuhtudena käsitletavad) FUNKTSIOONID ja (muud) NÕUDED süsteemile. Millised on kasutusjuhtude diagrammi põhielemendid? Use Case, Tegutseja, Süsteem, seos Kes/mis võib olla tegutsejaks? on keegi või miski (inimene, organisatsioon, väline süsteem), kes/mis suhtleb Süsteemiga, käivitab/algatab selles ühte või enamat Kasutusjuhtu või vähemalt suhtleb Kasutujuhuga selle täitmise mingis punktis.
Hankimise tegevus on oluline, kuna kokkuvõttes tehakse arendus vaid hankija jaoks. Samuti on tähtis, missugune arendusprotsess on projektis valitud ja kuidas hankija projekti töös osaleb. Läbivaatus on valitud, sest siis toimub süsteemi teksti, spetsifikatsiooni ning dokumentatsiooni analüüs. 2. Nõuded süsteemile Järgnevalt on esitatud funktsionaalsed ja mittefunktsionaalsed nõuded. Need kirjeldatakse kasutusjuhtudena. Iga kasutusjuhu koha tuuakse välja kasutusjuhu ID, kasutusjuhu nimetus, tegutseja, eeltingimused, põhistsenaarium ning järeltingimused. Töös on välja toodud 5 funktsionaalset ja 5 mittefunktisonaalset nõuet ning sealhulgas üks koormusega seotud nõue. 2.1 Funktsionaalsed nõuded süsteemile Kasutusjuhu ID: F1 Kasutusjuht: Töötaja süsteemi autentimine kasutajanime ja parooliga Tegutseja: Töötaja
tegevused ja nende järjekord sõltub valitud süsteemiarenduslähenemisest. Süsteemi nõuete puhul on tegemist nö. "süsteemitasemeliste" nõuetega, mis on teisendatud huvitatute nõuetest ja on omakorda aluseks süsteemi arhitektuuri ja disaini, verifitseerimise, valideerimise ning huvitatute aktsepteerimise aluseks. Süsteemi nõuded on süsteemi arendamisega seotud tehnilise personali suhtlusvahendiks. Süsteemi funktsionaalseid nõudeid esitatakse kas kasutusjuhtudena (Use Cases) või agiilsetes lähenemistes kasutatavate kasutuslugudena (User Stories). Süsteemi loogilise arhitektuuri või disaini eesmärk on esitada loodava süsteemi funktsionaalsus ja käitumine. Väljendatakse erinevat liiki vaadetega sisaldades minimaalselt funktsionaalset, käitumislikku ja ajalist arhitektuuri. Siin esitatakse süsteemi realiseerimise tehnoloogiast sõltumatu arhitektuuri vaade süsteemile
annaabi.ee 
