Projekto Apribojimai

Tai apribojimai, kurie įtakoja reikalavimų specifikaciją bei sistemos kūrimo eigą bei charakteristikas.

1.  Įpareigojantys apribojimai. (Mandated constraints)

1.1. Apribojimai sprendimui

Tai išankstiniai apribojimai sistemos kūrimo eigai ar charakteristikoms. Jie turi nurodymo (griežto reikalavimo) pobūdį. Juos reikia tiksliai aprašyti, nepamirštant numatyti, kaip galima “išmatuoti” (testuoti) jų laikymąsi sukurtoje sistemoje. Čia galima apibūdinti ir tokio apribojimo atsiradimo priežastis.

Šiuos apribojimus dažniausiai pateikia užsakovas, pirkėjas arba vartotojas dėl įvairiausių priežasčių. Neįvertinus šių apribojimų, sistema gali būti nepriimta. Šie apribojimai apibrėžia tam tikrą galimų sprendimų kontekstą, todėl juos reikia registruoti itin kruopščiai. Negalima apriboti laisvės priimti geresnį sprendimą. Čia gali būti pateikiami tik neginčytini apribojimai.

1.2.Diegimo aplinka

Charakterizuojama technologinė ir fizinė aplinka, kurioje sistema bus įdiegta. Tai apima automatizavimo, mechanizavimo, organizacinius ir kitokius įrenginius, kurie atspindi su kuriama sistema bendradarbiausiančias sistemas (nevertinant žmogaus)

Tai technologinės aplinkos aprašas, kuris leidžia sistemos projektuotojams įvertinti ir realizuoti reikalingas komunikavimo tarp sistemos ir technologinės aplinkos priemones. Šio aprašo pagrindu sudaroma šablono punkto 4.3 specifikacija. Čia pateikiamos diegimo aplinkos visos pagrindinės charakteristikos. Jei sistema įtakos organizacinę struktūrą, tuomet galima įdėti organizacinę schemą (organization chart).

1.3.Bendradarbiaujančios sistemos

Carakterizuojama sisteminė aplinka (posistemės) – su kuria kuriama sistema turės bendradarbiauti. Tai gali būti: kitos taikomosios sistemos (posistemiai), sukurtos išimtinai šiai organizacijai; specializuoti komerciniai programų paketai ir t.t. Šis punktas apibrėžia integravimo uždavinius ir problemas. Patikrinkite veiklos konteksto modelį, kad nustatyti, ar nėra gretimų sistemų, kurias galima įvardinti kaip komunikuojančias sistemas.

1.4.Komerciniai specializuoti programų paketai

Carakterizuojami specializuoti į kuriamą sistema numatomi įtraukti programų paketai, kurie bus reikalingi kuriamos sistemos funkcionalumui užtikrinti. ai reikalinga įvertinti, kadangi papildomų paketų charakteristikos, sąsajos sudėtis bei “elgesys” turi įtaką formuojant reikalavimus kuriamai sistemai;

Formuojant reikalavimus gali išryškėti prieštaravimai tarp reikalavimų ir numatomų naudoti specializuotų paketų. Tuomet tenka svarstyti, ar įmanoma tokius prieštaravimus išspręsti, ar specializuotas paketas yra geras sprendimo variantas.

1.5.Numatoma darbo vietos aplinka

Carakterizuojama aplinka, kurioje dirbs sistemos vartotojas. Aprašomos darbo vietos savybės, kurios gali turėti įtakos sistemos projektavimui. Punkto tikslas – fizinės darbo vietos charakteristikų, kurios gali įtakoti reikalavimus sistemai, identifikavimas. Sistema turės kompensuoti darbo vietos keliamus sunkumus ir įvertinti esamus apribojimus. Tai gali būti, pavyzdžiui: “spausdintuvas bus toli nuo vartotojo darbo vietos” – matyt nereikėtų teikti prioriteto spausdintiems sistemos rezultatams; “darbo vieta yra lauke”; “darbo vieta triukšminga “ – garsiniai signalai neduos efekto; “darbo vieta mobili”.

1.6.Sistemos kūrimo terminai

Numatomi visi laiko apribojimai arba galimi terminų keitimo (tikslinimo) faktoriai. Būtina numatyti konkrečias datas ir argumentus, kodėl tokie terminai fiksuojami. Gali būti numatomos ir atskirų sistemos dalių užbaigimo ar parengimo testavimui datos. Gali būti pateikiamos įvairios griežtų terminų priežastys: tenka laikytis numatyto sistemos paleidimo grafiko; kitų veiklos sričių ar sistemų priklausomybė nuo kuriamos sistemos; rinkos tyrimo rezultatų pagrindu (susidaro palanki situacija); veiklos, naudosiančios sistemą, vystymas pagal grafiką. Tikslinga įvertinti terminų nesilaikymo pasekmes (“Kas bus jei…”)

1.7.Sistemos kūrimo biudžetas

Numatomi sistemos kūrimo finansiniai ištekliai kiekine išraiška. Reikalavimai negali viršyti biudžeto, todėl dalies reikalavimų gali tekti atsisakyti. Įvertinus numatomą skirti biudžetą, galima identifikuoti, ar sistema tikrai reikalinga (ar jos tikrai pageidaujama).

2.  Terminų žodynas

Pateikiamas terminų, kurie bus naudojami specifikuojant reikalavimus, žodynas. Žodyne sukaupiamos dalykinėje srityje naudojamos standartinės sąvokos. Kiekvienai sąvokai pateikiamas glaustas paaiškinimas. Sąvokos turi būti priimtinos dalykinės srities atstovams. Šio punkto paskirtis – sudaryti dalykinės srities sąvokų žodyną, dėl ko gali būti sutaupyta daug laiko įvairiems paaiškinimams. Taip išvengiama nesusipratimų. Žodynas naudojamas bei papildomas sistemos projektavimo metu

3.  Svarbūs faktai ir prielaidos

Išoriniai faktoriai, įtakojantys kuriamą sistemą, tačiau nepriklausantys iš anksto nustatomiems apribojimams, kurie įtakoja reikalavimų specifikaciją. Šiame punkte charakterizuojami kiti išoriniai veiksniai, sistemos, veiklos (pasaulio mastu), galintys įtakoti sistemą. Svarbūs faktai ne visuomet transformuojami į reikalavimus, tačiau toks atvejis galimas. Į šį punktą įtraukiami tie faktai, kurie nepatenka į kitus šablono punktus, tačiau numanoma, kad jie įtakoja reikalavimų specifikaciją

Pateikiamas prielaidų sąrašas, kurias pateikia sistemos kūrėjai. Jos gali liesti įvairius sistemos kūrimo aspektus. Prielaidos, tam tikra prasme, yra faktų priešingybė, nes gali būti neteisingos, tačiau gali ir pasiteisinti. Šis punktas turi dvi paskirtis: suteikti galimybę pateikti prielaidas; susipažinti su pateiktomis prielaidomis.

Tai gali būti prielaidos dėl:

•   kitų sistemos dalių, kitų sistemų, programų paketų ar komponentų parengtumo naudojimui, kai to reiks projektuotojui;

•  sistemos veikimo technologinės aplinkos (suderinamumo aspektas);

•  vartotojo galimybių;

•  kitų sistemų, kurios kuriamos kartu su pastarąja sistema;

•  kitų (pirktinių) komponentų panaudojimo galimybių;

•  priklausomybių nuo išorinių sistemų ar asmenų;

•  naujų įstatymų ar politinių sprendimų.