Sudarant techninę užduotį, joje būtinai turi būti išvardyti visi reikalavimai informacinei sistemai, kitaip kūrėjas paprasčiausiai nežinos, kokiu tikslu produktas yra sukurtas, ką jis skirtas įvykdyti ir kaip. Reikalavimų formulavimo užduotis tenka klientui, nors paprastai tai padeda vadovai, per kuriuos pateikiamas užsakymas. Bet studentai, užsiimantys kursinių darbų, disertacijų rašymu, turėtų mokėti savarankiškai sudaryti tokius sąrašus.
Bendras supratimas
IP kūrimo procesas yra gana sudėtingas, susideda iš daugelio vienas po kito einančių etapų. Specialistai, dirbantys prie projekto, yra priversti spręsti įvairius sunkumus. Tam tikru mastu tai galima supaprastinti tiksliai suformulavus reikalavimus informacinei sistemai. Ne visada akivaizdu, kodėl kyla problemų, ypač dirbant su novatoriškais produktais, ir dažnai sudėtinga užduotis yra sukurti išsamų visų veiksmų, kuriems skirtas produktas, aprašymą.
Dėmesys visoms detalėms
Išsamus produkto funkcionalumo vaizdas yra visas informacinei sistemai keliamų reikalavimų sąrašas. Tai taip pat apima aspektus, kuriuos klientas siūlo, o programuotojas įgyvendina kurdamas projektą. Pajėgumų stiprinimo procesas, jų analitinis tyrimas, dokumentacija ir atlikimo tikrinimas yra reikalavimų plėtojimas, kurio metu galima tiksliai nustatyti visus apribojimus ir susitarti tarp „noriu“ ir „tikrai įmanoma“. Svarbu atsiminti, kad šiuolaikiniai inžinieriai nėra magai, o žmonės, kurie naudojasi prieinamomis techninėmis priemonėmis, kurių galimybės, deja, taip pat yra ribotos. Laiko aspektas yra ne mažiau reikšmingas, nes darbas kuriant ir įgyvendinant reikalavimus reikalauja didelių laiko sąnaudų - mėnesių, o kartais ir metų.
Kurie ten yra?
Įprasta kalbėti apie sistemos ir vartotojo reikalavimus informacinei sistemai. Natūrali kalba apibūdina tas, kurias pateikia konkretus vartotojas. Norėdami patikslinti formuluotę, galite kreiptis į įvairaus sudėtingumo diagramas. Tai leidžia susidaryti bendrą įspūdį apie funkcijas, kurioms ketinama įgyvendinti IP, ir apie apribojimus, su kuriais susidursite darbe.
Sistemos reikalavimai yra tos specifinės projekto savybės, kurių žinojimas leidžia kliento norus paversti realybe. Šie techniniai informacinės sistemos reikalavimai apima pristatymą apie įrangos ypatybes, jos galią, taip pat pasirinkimą konkrečios architektūros parinkties naudai. Prie sistemos galima priskirti daugybę kitų aspektų, kurie vartotojui nėra akivaizdūs, tačiau reglamentuojantys, koks bus galutinis produktas.
Reikalavimai: kur juos gauti?
Informacijos sistemos reikalavimų formulavimo ir tvirtinimo užduotys nėra tokios paprastos, kaip gali pasirodyti iš pirmo žvilgsnio. Šis terminas vartojamas tokiam sudėtingam struktūrizuotam procesui, kurio metu sukuriama dokumentacija, patvirtinti užsakovo, rangovo, kuris aiškiai reglamentuoja visas gaminio specifikacijas. Plėtra yra padalinta į keturis veiksmus iš eilės:
- analitinė veikla planuojamo pagrįstumo laipsniui nustatyti;
- tiesiogiai kuriant, analizuojant reikalavimus;
- patvirtinamųjų dokumentų formavimo reikalavimų formulavimas;
- duomenų sistemos reikalavimų informacijai sertifikavimas, taip pat kitos sąlygos, projekto įgyvendinimo taisyklės.
Ne taip paprasta
Jei bus nustatyti informacinių sistemų saugumo reikalavimai, informacijos turinys, formatas, valdymo užduotys ir kiti projekto veikimo aspektai, tai dar nereiškia, kad jie išliks nepakitę iki „pergalingos pabaigos“. Darbo eigą dažnai lydi nustatytų specifikacijų ir reikalavimų pakeitimas. Tai atsitinka ne tik užsakovo, bet ir rangovo, kuris susiduria su tam tikrais techniniais apribojimais, kurie trukdo įgyvendinti daugelį suplanuotų aspektų, iniciatyva. Svarbu atsižvelgti į proceso valdymo ypatybes. Pokyčių valdymas yra vienas iš pagrindinių aspektų, susijusių su reikalavimų kūrimu ir jų įgyvendinimu konkrečioje IP.
Svarbus aspektas, dirbant su reikalavimais, yra apibrėžimas tų, kuriems taikoma įvairiapusė informacijos analizė. Tam naudojamas apibendrintas darbo modelis. Konkrečios įmonės rėmuose diegiama unikali informacinių sistemų reikalavimų valdymo sistema, leidžianti suformuluoti, pakoreguoti, priimti, atmesti pasirinktas sąlygas. Daug kas priklauso nuo darbuotojų kvalifikacijos, intelektinės nuosavybės būdo, su kuriuo jie dirba, nuo standartų, naudojamų darbo eigoje.
Kaip tai atrodo?
Praktiškai formuluojant, analizuojant informacinių sistemų saugumo reikalavimus, duomenų pildymą, struktūrą (ir kitas sistemas bei vartotojus) pirmiausia reikia nustatyti tam tikros dalyko srities ypatybes. Tai tiria kvalifikuoti analitikai, nustatydami specifinius sukurto produkto taikymo sektoriaus parametrus ateityje. Po to jie pradeda rinkti preliminarius reikalavimus, dirbdami su asmenimis, formuojančiais tokią informaciją. Tuo pat metu jie ir toliau tobulina dalykinę sritį.
Kitas žingsnis formuojant reikalavimus savivaldybių informacinėms sistemoms, naudojamoms privačiose, naudojamose vyriausybinėse įstaigose, yra sukurti identifikuotos informacijos hierarchinę sistemą. Jei pirminis informacijos rinkimas suteikia chaotišką duomenų kompleksą, tada sisteminant jį užsakoma, sukuriant elementų grupes, turinčias loginius ryšius tarpusavyje.
Tęsiamas darbas
Kitas žingsnis nustatant informacijos reikalavimus informacinėse sistemose, projekto struktūrą, funkcines, vidines ypatybes - nustatyti prieštaravimus ir išspręsti konfliktus. Gavę informaciją iš įvairių trečiųjų šalių apie suprojektuoto intelektinės nuosavybės darbą, jie susiduria su šia problema: kiekvienas asmuo turi savo unikalių idėjų apie projekto galimybes ir jo tikslą. Dažnai iš skirtingų žmonių gautos idėjos konfliktuoja tarpusavyje, taip pat prieštarauja logikai, esamoms techninėms galimybėms, per kurias diegiama sistema. Norint supaprastinti situaciją, atlikus išsamią analizę, reikia nustatyti visus prieštaravimus ir rasti optimalų kompromisinį sprendimą jiems išspręsti.
Nustačius prieštaravimus ir išanalizavus visų reikalavimų pagrįstumą, būtina sudaryti prioritetų sistemą. Tarp bendrųjų reikalavimų visada yra svarbesnių ir mažiau reikšmingų. Kūrėjų užduotis - glaudžiai bendradarbiauti su tais, kurie sukuria reikalavimus, kad būtų galima nustatyti, kurie iš nustatytų gaminio veikimo aspektų yra patys reikšmingiausi ir kurie gali laukti arba visiškai atšaukti, jei tam įtakos turi neigiamos išorinės sąlygos (pvz., Laiko stoka). Sukūrę prioritetų sistemą galime pradėti tikrinti nustatytų aspektų išsamumą, suderinamumą ir suderinamumą.
Žingsnis po žingsnio
Reikalavimai informacinėms sistemoms (asmens duomenims, informacijai apie įmonės darbą ir visoms kitoms) yra suformuluoti kaip ciklinio proceso dalis. Visi etapai yra sujungti tiek tiesiogiai, tiek atvirkščiai. Žingsniai yra aprašyti aukščiau: pirmiausia turite nustatyti dalykinės srities ypatybes, tada palaipsniui pereikite prie tarpusavio reikalavimų suderinamumo, taip pat jų išsamumo ir kitų parametrų nustatymo žingsnio, leidžiančio kalbėti apie gautų sąlygų pritaikomumą praktikoje. Jei pavyksta sukurti visavertį subjekto vaizdą, jis jau nustato darbo sąlygas, ypač jos veikimą. Ciklo kartojimas suteikia tikslesnį, nuodugnesnį rajono vaizdą, trečiasis ciklas leis dar aiškiau suformuluoti reikalavimus. Kartojimas yra būtinas tol, kol visi proceso eigos dalyviai tiksliai supranta, kam skirta sistema ir kaip ji veiks, ką reikia įdiegti dirbant projektą.
Norint, kad reikalavimų formavimo procesas būtų efektyvus, o jo rezultatai būtų pritaikomi darbe, būtina vadovautis visuotinai priimtais sąlygų formulavimo algoritmais.
Atskaitos taškai
Tai yra pagrindinis būdas nustatyti reikalavimus valstybės informacinėms sistemoms, visų pirma - trumpai tariant, absoliučiai visiems, nepriklausomai nuo to, kur jie naudojami. Apibrėždami sąlygas, kaip pradinę sąlygą būtina pripažinti, kad požiūriai nagrinėjamu klausimu gali skirtis. Jie identifikuojami ir naudojami kaip pagrindas formuojant pirmąjį reikalavimų rinkimo procesą, o paskui tikras sąlygas.
Požiūris yra gana miglota sąvoka, todėl buvo sukurta keletas požiūrių, kurie ją interpretuoja skirtingai. Paprasčiausias sąvokos aiškinimas yra duomenų, apibūdinančių, kaip veiks IP, šaltinis. Atskaitos taškai tampa IP modeliavimo ir informacijos apie produktą naudojimo pagrindu. Reikalavimų rinkimas apima visų reikšmingų atskaitos taškų, kurie toliau naudojami gaminant gaminį, identifikavimą. Taip pat atsižvelgiama į tai, kaip metodai bus naudojami tvarkant duomenis.
Alternatyvus požiūris
Kitas „požiūrio taško“ sąvokos aiškinimas apima termino kaip vaizdavimo struktūros suvokimą. Tiesą sakant, tai yra produkto modelio elementas. Skirtingi požiūriai leidžia sukurti daugybę baigtinių būsenos mašinų modelių, subjektų sąveikos ir ryšius tarp jų konkrečiame projekte. Atsižvelgiama į projekto apimties specifiką.
Požiūris gali reikšti išorinio paslaugos gavėjo, įgyvendinto per IP, nuomonę. Remiantis TK, galima nustatyti duomenis, kurie naudojami įgyvendinant sistemos paslaugas, jų valdymui. Šis požiūris laikomas veiksmingiausiu. Tai sudarė į požiūrį orientuotų reikalavimų apibrėžimo pagrindą - specifinį reikalavimų identifikavimo metodą, leidžiantį nustatyti informaciją ir efektyviai ją analizuoti.
Darbas su požiūriais
Pirmiausia juos reikia identifikuoti, taip pat nustatyti visas paslaugas, susijusias su tam tikru tašku. Tada sistema struktūriškai išdėstoma hierarchiškai, sugrupuojant požiūrio taškus, atskleidžiant bendras IP paslaugas. Tai buvo aukščiausias hierarchinis lygis. Juos paveldės visi žemesnio lygio TK.
TK palaikymas turi būti patvirtintas dokumentais. Atsižvelgiant į identifikavimo rezultatus, ši informacija yra aiškiai aprašyta. Po to galima sudaryti TK sistemą, kurioje atsispindės visi IP objektai, identifikuoti iš surinktos informacijos.
Neskubėkite!
Paprastai darbas su IP prasideda nuo didelio masto „protų šturmo“, skirto nustatyti visus įmanomus projekto reikalavimus. Būtina iš anksto žinoti, kad beveik neįmanoma nustatyti visų galimų reikalavimų viena procedūra. Kuo sudėtingesnė sistema, tuo daugiau reikės procedūrų.Tik jei pakartotinės minčių šturmo sesijos, kuriose dalyvauja ir užsakovas, ir rangovas, neteikia naudingos informacijos, pagrįstai spėjame, kad buvo nustatyti palaikantys TOR ir suformuluoti reikalavimai, galime pradėti juos įgyvendinti techninėmis priemonėmis.
Sertifikavimo reikalavimai
Ši procedūra leidžia suprasti, kiek reikalavimai atitinka kliento idėjas apie galutinį produktą. Tikrinimas yra vienas iš svarbiausių žingsnių nustatant klaidingą specifikaciją ir iš anksto ją pašalinant. Priešingu atveju pakeitimas turės būti atliekamas tuo metu, kai sistema jau yra suprojektuota ir sukonstruota, o tai reiškia ir laikinus, ir kitus išteklių nuostolius. Didžiausias problemas sukelia klaidos, aptiktos įdiegus produktą įmonėje.
Įprastu atveju sistemos koregavimų darbas vertinamas kur kas aukščiau nei netikslumų aptikimas ir taisymas IP projektavimo, kodavimo funkcionalumo projektavimo etape. Kintantys reikalavimai daugeliu atvejų sukelia įspūdingus struktūrinius pokyčius, įskaitant pagrindinį lygį. Tai reiškia, kad atlikę pakeitimus turėsite atlikti visus patikrinimus ir bandymus, kad įsitikintumėte, jog visi suprojektuoti įrankiai veikia tinkamai.