IFI6068 ◦ Sissejuhatus infosüsteemidesse ◦ Sügissemester 2014

ÜLESANNE 11 | Nõuete dokumendi koostamine


Valitud arendusidee ja eelmistes iseseisvates töödes teostatud modelleerimiste ja analüüside alusel palun koostage dokument, mis fikseerib nõuded loodavale infosüsteemile sellise täpsusega, et seda dokumenti ("Nõuded loodavale süsteemile") saaks välja saata IT arendusfirmadele pakkumuste tegemiseks. (Märkus. Eesti praktikas kasutatakse nõuete dokumendi asemel tihti ka mõistet "lähteülesanne".)

Üksikasjalikumad seletused praktikumis.

Töörühm: sama, mis eelmistes iseseisvates töödes.

Esitamise tähtaeg: üks nädal alates ülesande andmisest.

 

NÄIDE Isikuandmete töötlejate ja isikuandmete kaitse eest vastutavate isikute registri lähteülesanne, https://riha.eesti.ee/riha/main/inf/isikuandmete_tootlejate_ja_isikuandmete_kaitse_eest_vastutavate_isikute_register, jaotis Tehniline kirjeldus, fail AKI_registri_l2hteylesanne.rtf.

NÄIDE Riigi kinnisvararegister, https://riha.eesti.ee/riha/main/inf/riigi_kinnisvara_register, jaotis Tehniline kirjeldus, Analüüsidokument.

NÄIDE Audiitortegevuse register, https://riha.eesti.ee/riha/main/inf/audiitortegevuse_register, jaotis Tehniline kirjeldus, fail RM_nõuded_arendatavatele_rakendustele.rtf. | Dokumendis võib võib tutvuda: 1) küllalt spetsiifiliste nõudetega tarnitava tarkvara tehnilisele teostusele; 2) nõuetega käideldavusele (mittefunktsionaalsed nõuded).

NÄIDE Nõuete süstemaatiline kirjapanemine on võimas vahend, mida saab kasutada nii süsteemi üldisel kavandamisel kui ka detailsemal spetsifitseerimisel. Tavaliselt sõnastatakse nõuded kompaktselt, lühikeste kuid täpsete lausetena. Väljavõte ühes projektis sõnastatud nõuetest:

Nõue 1: Käidud raja real näidatakse abikuvade nimetusi ja detailkuvade registriobjektide nimetusi ja nende tüüpe linkidena. Nimetused eristatakse tüüpidest kooloni ja tühikuga.

Nõue 2: Kõik lingid toimivad viidetena kuvale, kust kasutaja linke või menüüpunkte kasutades edasi liikus. Käidud rajal näidatakse ka hetkekuva viidet lingina (muidugi vaid juhul kui käesolevad nõuded seda kuva kohta sätestavad).

Nõue 3: Detailkuva jaotiste vahel liikudes käidud rajal infot ei muudeta. Samuti ei näidata seal eraldi muutmiskuvade pealkirju ehk üldisemalt registriobjektiga seotud tegevusi.

Nõue 4: Käidud raja pikkus on fikseeritud antud HTML elemendi kastipiiride maksimaalse pikkusega ehk mitte kunagi ei tohi vahetada rida või minna kasti piiridest üle.

Nõue 5: Kehtib põhimõte, et käidud rajal näidatakse viimaseid külastatud kuvasid/menüüpunkte. Kui käidud raja pikkusest ei piisa, kaotatakse vastavalt varasemalt külastatud kuvade viited käidud rajalt, tehes sellega ruumi värskematele viidetele.

Näide 5.1: Kui käidud raja jaoks ettenähtud ruum lõpeb, siis ei kuvata enam varasemalt külastatud viiteid täpselt sellel hulgal, et uus viide mahuks täpselt ettenähtud reale ära.

Nõue 6: Ühe käidud rajal kuvatava viite maksimaalne pikkus tähemärkides, koos registriobjekti tüübi ja lühendamist tähistava kolme punktiga on 40 tähemärki.

Tarkvarasüsteemile esitatavad nõuded on vägagi mitmesugused ja neid on palju. Seetõttu on nõuete klassifitseerimine oluline. Üks huvitav mittefunktsionaalsete nõuete klassifikatsioon ilmus hiljuti IT-raamatute kirjastuse O’Reilly veebis: Understanding Non-Functional Requirements.

Funktsionaalsete ja mittefunktsionaalsete nõuete eristamine võib tunduda ka mõnevõrra problemaatiline. Funktsioneerimine peaks tähendama ikka seda, et asi töötab – terviklikult. Süsteemide kasutatavus (usability) on nihkunud väga olulisele kohale. Seetõttu on vaieldav, kas kasutatavust on õige käsitada „mittefunktsionaalse“ omaduse või nõudena.

Eesti kontekstis on kindlasti oluline ka tegelik praktika mittefunktsionaalsete nõuete sõnastamisel ja fikseerimisel. Tarkvaraarendusi regulaarselt tellivad organisatsioonid leiavad, et mittefunktsionaalseid nõudeid on otstarbekas ühtlustada üle mitmete projektide. Mitmetes järjepidevalt IT-arendusi tellivates asutustes on kokku pandud ühtne mittefunktsionaalsete nõuete komplekt, mida konkreetsetes projektides kohandatakse. Näiteks Eesti Statistikaametis kasutatavate mittefunktsionaalsete nõuete kohta võib leida teavet ettekandest aadressil http://www.stat.ee/39396. Mitmed asutused on vormistanud oma riist- ja tarkvaralise keskkonna kirjelduse nn "IT profiili" dokumendina. Näiteks Registrite ja Infosüsteemide Keskus (RIK) sõlmib arenduslepinguid nii, et asutuse IT profiili kirjeldus on lepingu osa.

NÄIDE
RIHAs olevate andmete visualiseerimise lahendus

ÄRINÕUDED

Käesolev dokument määratleb ärinõuded (business requirements) RIHA andmete visualiseerimise lahendusele.

1. Visualiseeritavad andmed. Visualiseeritakse RIHAs olevaid andmeid: 1) valdkonnad; 2) asutused; 3) infosüsteemid; 4) X-tee teenused; 5) klassifikaatorid; 6) õigusaktid; 7) kontaktisikud.

2. Visualiseeritavad seosed. Visualiseerimisel kuvatakse objektidevahelised seosed joontega (graafi kaartena). Arvestatakse ja kuvatakse järgmised RIHA andmete omavahelised seosed:
- esitatakse valdkonna seos oma ülemvaldkonnaga (kui selline eksisteerib) ja seosed oma alamvaldkondadega (kui sellised eksisteerivad).
- esitatakse valdkonna seosed oma valdkonna infosüsteemidega; infosüsteem võib olla seotud 0..n valdkonnaga.
- esitatakse infosüsteemi seosed asutusega. Need võivad olla kahte tüüpi: asutus võib olla infosüsteemi vastutav töötleja või volitatud töötleja.
- esitatakse infosüsteemi seosed ülem- ja alaminfosüsteemidega (kui sellised eksisteerivad).
- esitatakse klassifikaatori seosed infosüsteemidega, mis klassifikaatorit kasutavad.
- esitatakse klassifikaatori seos teda haldava asutusega.
- esitatakse X-tee teenuse seos ühelt poolt infosüsteemiga, mis seda teenust pakub ja teiselt poolt asutustega, kellele teenus on avatud.
- esitatakse infosüsteemi seosed kontaktisikutega. Kontaktisikute samasus tuvastatakse isikukoodi järgi.

3. Arhitektuur. Visualiseerimislahendus realiseeritakse InfoVis JavaScripti teegi (http://thejit.org/) abil, täiendades seda ja liidestades RIHA rakendusega. Andmete edastamiseks Java rakendusest JavaScripti kasutatakse JSON andmevormingut. Andmete täiendavaks pärimiseks pöördub visualiseerimismoodul RIHA andmebaasi poole Ajaxi abil.

Märkus. JSON andmevorming tuleb fikseerida, lähtudes prototüübis (käesoleva dokumendi jaotis 2) kasutatud struktuurist.

4. Visualiseerimismeetod. Visualiseerimisena mõistame andmete graafi kujul esitamist. Alusena kasutatakse InfoVis paketti RGraph (vt InfoVis-iga kaasaolev näide Jit-1.1.3\Jit\Examples\RGraph\example1), mis realiseerib nn dünaamilise radiaalgraafi esitusmeetodit. Dünaamilise radiaalgraafi esitusmeetodi näidet vt http://thejit.org/docs/files/RGraph-js.html, teoreetilist tausta artiklist http://bailando.sims.berkeley.edu/papers/infovis01.htm.

5. Graafi tippude nimedena kasutatakse valdkonna, asutuse, infosüsteemi, õigusobjekti ja kontaktisiku puhul objekti nime; X-tee teenuse puhul - teenuse nime [ asendatud: lühinime -> nime; klassifikaatori puhul - klassifikaatori lühinime.

NÄIDE Funktsionaalsete nõuete spetsifitseerimine

Nõuded Kohaliku omavalitsuse universaalsele teenusportaalile KOVTP (väljavõte)

7. Funktsionaalsed nõuded
Süsteemi funktsionaalsus on grupeeritud loogilisteks tervikuteks (mooduliteks). Moodulite koostamisel on lähtutud põhimõttest, et erinevad moodulid oleksid võimalikult iseseisvad.

7.1. Tarkvaras kasutatavad moodulid

7.1.1. Moodul asutuse avaliku dokumendiregistri andmete kuvamiseks. Moodul saab infot asutuse dokumendiregistrist ja publitseerib selle avaliku vaate, vastavalt avaliku teabe seadusele. Luuakse standard, kuidas kohaliku omavalitsuse dokumendiregister annab infot KOVTP-le ja tagastatakse menetluse staatuse infot.

7.1.2. Sisuhaldussüsteemi kasutajate haldamise moodul. KOVTP-s toimub sisuhaldussüsteemi kasutajate õiguste haldamine. Sisuhaldussüsteemi kasutajaid hallatakse AAR-s.

7.1.3. Veebilehe disaini kirjeldamise/muutmise moodul.
Saab hõlpsasti valida koduleheküljele disaini malli (ingl template). Süsteemiga on kaasas juba varem valmis tehtud disaini kavandid. Kohalik omavalitsus saab muuta ainult teatud osa veebilehe disainist. Määratakse ära lehemallide (üldine layout ja disain) ja sisumallide (lehesisene, nt nimekiri, artikkel kahes veerus) haldamise loogika. Administreerimisliideses peab olema võimalik defineerida KOVi-põhiseid sisumalle (CSSi ja /GFX kataloogi tasandil), võttes aluseks nt mõne olemasoleva disaini malli või luues uue. Eraldatakse stiilid, mida kasutavad tsentraalselt hallatavad moodulid (nt autentimine, taotlusvormid). Kavandite maht selgub projekti käigus.

7.1.4. Digitaalse meedia lisamise ning publitseerimise moodul. (Antud moodulit on võimalik aktiveerida avalikus vaates erinevate infoarhitektuuri osades).

7.1.4.1. Dokumendifailide lisamine/kuvamine. Failide kuvamisel peab olema võimalik visuaalselt eristada failide tüüpe (xls, doc, pdf, rtf jne), faili viimati muutmise aega ning andmemahtu KB.
Dokumendi failidie kuvamise näide (vt lehe alla): http://dw.riik.ee/files/kovtp_kuvad/files/layout1_sinine_02_alamleht.html.

NÄIDE Tallinna avalike teenuste andmekogu SMS-teavituse süsteem. Funktsionaalne spetsifikatsioon. https://riha.eesti.ee/riha/main/inf/tallinna_avalike_teenuste_andmekogu, jaotis Tehniline kirjeldus, dokument SMS_saatja_funktsionaalne_dokument_30.11.11.pdf.

Lisa kommentaar