Приликом формирања техничког задатка, он мора нужно да наведе све захтеве за информациони систем, иначе програмер једноставно неће знати за које сврхе је производ креиран, шта треба да испуни и како. Задатак формулисања захтева лежи на купцу, мада у пракси менаџери преко којих се врши налог обично помажу у томе. Али студенти укључени у писање семинарских радова, дисертација, требали би бити у могућности да самостално састављају такве спискове.
Заједничко разумевање
Процес креирања ИП-а је прилично компликован, састоји се од многих узастопних фаза. Специјалисти, који раде на пројекту, принуђени су да се суоче са разним потешкоћама. То се у неку руку може поједноставити тачним формулисањем захтева за информационим системом. Није увек очигледно зашто настају проблеми, посебно када се ради на иновативним производима, а стварање свеобухватног описа свих акција којима је производ намењен често је тежак задатак.
Пажња на све детаље
Комплетна слика функционалности производа је потпуна листа захтева за информационим системом. Такође укључује аспекте које купац предлаже, а програмер имплементира током креирања пројекта. Процес изградње могућности, њихово аналитичко истраживање, документација, тестирање радне способности је развој захтева, током којих је могуће тачно идентификовати сва ограничења и постићи консензус између „ја желим“ и „стварно изводљиво“. Важно је запамтити да модерни инжењери нису мађионичари, већ људи који користе приступачне техничке алате, чије су могућности, нажалост, такође ограничене. Временски аспект није мање значајан, јер рад на стварању и спровођењу захтева захтева значајне временске трошкове - месеце, а понекад и године.
Који су тамо?
Уобичајено је говорити о системским и корисничким захтевима за информационим системом. Природни језик описује оне које је представио одређени корисник. Да бисте разјаснили формулацију, можете прибећи дијаграмима различитих степена сложености. То вам омогућава да направите општи утисак о функцијама за које је ИП намењен да се имплементира и ограничењима на која ћете наићи у свом раду.
Системски захтеви су оне специфичне карактеристике пројекта, чије познавање вам омогућава да жеље клијента преведете у стварност. Ови технички захтеви за информациони систем укључују презентацију о карактеристикама опреме, њеној снази, као и избор у корист одређене опције архитектуре. Многи други аспекти могу се приписати системским, који кориснику нису очигледни, али који регулишу шта ће бити крајњи производ.
Услови: где их набавити?
Задаци формулисања и одобравања захтева за информационим системом нису тако једноставни као што се може чинити на први поглед. Израз се користи за означавање тако сложеног структурираног процеса, у оквиру којег се креира документација, коју потврђује купац, извођач, која јасно регулише све спецификације производа. Развој је подељен у четири узастопна корака:
- аналитичке активности за утврђивање степена изводљивости планираног;
- креирање, аналитичко проучавање захтева директно;
- формулисање захтева за формирање пратеће документације;
- цертификација захтева за систем података за информације, као и других услова, правила за спровођење пројекта.
Није тако једноставно
Ако се једном успоставе захтеви за сигурност информационих система, информационог садржаја, формата, управљачких задатака и других аспеката функционисања пројекта, то не значи да ће они остати непромењени до „победничког краја“. Ток рада често прати промена утврђених спецификација и захтева. То се догађа не само на иницијативу купца, већ и извођача радова, који се суочава са одређеним техничким ограничењима која спречавају спровођење низа планираних аспеката. Важно је размотрити карактеристике контроле процеса. Управљање променама један је од кључних аспеката развијања захтева и њихове примене у оквиру одређеног ИП-а.
Важан аспект рада са захтевима је дефиниција оних који имају накнадну свестрану анализу информација. За то се користи генерализовани модел рада. У оквиру одређеног предузећа имплементира се јединствени систем управљања захтјевима информационог система који омогућава формулисање, прилагођавање, прихватање, одбијање одабраних услова. Много тога зависи од квалификације радника, врсте ИП-а на којем раде, стандарда који се користе у току рада.
Како то изгледа?
У пракси, формулација, аналитика захтева за сигурношћу информационих система, попуњавање података, структура (и других системских и корисничких) укључују прво идентификовање карактеристика одређеног предметног подручја. Истражују је квалификовани аналитичари, одређујући специфичне параметре примене сектора развијеног производа у будућности. Након тога почињу сакупљати прелиминарне захтеве, радећи са особама које формулишу такве информације. Паралелно са тим, настављају да раде на усавршавању предметне области.
Следећи корак у формулисању захтева за општинске информационе системе, приватне који се користе у државним агенцијама, је стварање хијерархијског система идентификованих информација. Ако иницијално прикупљање информација даје хаотичан комплекс података, онда се у оквиру систематизације наручује, стварајући групе елемената који имају логичке везе једни са другима.
Наставак рада
Следећи корак у одређивању захтева за информацијама у информационим системима, структури пројекта, функционалним, унутрашњим особинама је идентификација супротности и решавање сукоба. Када добију информације од широког спектра трећих страна о раду дизајниране ИП адресе сусрећу се са следећим проблемом: свака особа има своје јединствене идеје о могућностима пројекта и његовој сврси. Често идеје добијене од различитих људи долазе у сукоб једни с другима, а такође супротстављају логици, постојећим техничким могућностима преко којих се систем имплементира. Да би се ситуација поједноставила, након детаљне анализе неопходно је идентификовати све контрадикције и наћи оптимално компромисно решење за њихово разрешење.
Идентификујући контрадикције и анализирајући изводљивост свих захтева, такође је потребно да се направи систем приоритета. Увек постоји важнији и мање значајан општи скуп захтева. Задатак програмера је да уско сарађују са онима који стварају захтеве како би препознали који су од утврђених аспеката функционисања производа најзначајнији и који могу да сачекају или да се потпуно откажу ако негативни спољни услови томе допринесу (на пример, недостатак времена). Стварајући систем приоритета, можемо почети да проверавамо идентификоване аспекте за комплетност, компатибилност међу собом и доследност.
Корак по корак
Захтеви за информационим системима (лични подаци, информације о раду предузећа и било који други) формулишу се као део цикличког процеса. Све фазе су повезане директно и обрнуто. Кораци су горе описани: прво морате идентификовати карактеристике предметног подручја, а затим постепено пријећи на корак утврђивања компатибилности захтјева међу собом, као и њихову потпуности и других параметара, што нам омогућава да разговарамо о примјењивости добијених услова у пракси. Ако успете да створите пуну слику предметног подручја, она већ поставља услове рада, посебно функционисање. Понављање циклуса даје прецизнији, дубински приказ области, трећи циклус ће омогућити јасније формулисање захтева. Понављање је потребно све док сви учесници у току рада не схвате тачно за шта је систем креиран и како ће радити, шта треба применити током рада на пројекту.
Да би процес формирања захтева био ефикасан и да би његови резултати били применљиви у раду, потребно је следити опште прихваћене алгоритме за формулисање услова.
Референтне тачке
Ово је основна метода идентификације захтева за државним информационим системима, укратко, апсолутно било ко, без обзира на то где се користе. Као део дефиниције услова, потребно је препознати као почетни услов да се тачке гледишта о предметном питању могу разликовати. Они су идентификовани и коришћени као основа за формулацију првог поступка прикупљања захтева, а потом и стварних услова.
Стајалиште је прилично нејасан концепт, тако да је развијено неколико приступа који то различито тумаче. Најједноставнија интерпретација концепта је извор података који описују како ће ИП функционирати. Референтне тачке постају основа за моделирање ИП-а и кориштење информација унутар производа. Прикупљање захтева укључује идентификацију свих значајних референтних тачака које се даље користе у процесу израде производа. Такође узима у обзир како ће се технике користити за обраду података.
Алтернативни приступ
Друга интерпретација концепта „гледишта“ укључује поимање термина као структуре репрезентације. У ствари, ово је елемент модела производа. Различита гледишта вам омогућавају да створите бројне моделе машина са коначним стањем, интеракције ентитета и односе међу њима у оквиру одређеног пројекта. У обзир се узимају специфичности обима пројекта.
Тачка гледишта може значити мишљење спољног примаоца услуге имплементиране кроз ИП. На основу ТК-а могуће је идентификовати податке који се користе у примени системских сервиса и њиховом управљању. Овај приступ се сматра најефикаснијим. То је основа основа дефиниције усмерених на гледиште - специфичне методе за препознавање захтева која вам омогућава да одредите информације и ефикасно их анализирате.
Радите са становиштима
Прво их треба идентификовати, као и одредити све услуге које су повезане са одређеном тачком. Тада се систем структуира на хијерархијски начин, груписујући ставове међу собом, откривајући заједничке услуге за ИП. Они су рангирани као највиши хијерархијски ниво. Наследиће их сви ТК нижег нивоа.
Подржавање ТК-а мора бити документовано. Ове информације су јасно описане, имајући у виду резултате идентификације. Након тога могуће је израдити ТК систем у коме ће се рефлектирати сви ИП објекти идентифицирани из прикупљених информација.
Узми си времена!
По правилу, рад на ИП-у започиње великом сесијом браинсторминга која је намењена утврђивању свих могућих захтева за пројекат. Потребно је унапред бити свестан да је готово немогуће одредити све могуће захтеве једним поступком. Што је систем сложенији, то ће бити потребно и више таквих поступака.Само ако опетоване сесије браинсторминга које укључују и купца и извођача не дају корисне информације, они оправдано претпостављају да су подржани ТОР-ови идентификовани и захтеви формулисани, можемо наставити с њиховом применом техничким средствима.
Захтеви за сертификацију
Овај поступак вам омогућава да разумете у којој мери захтеви одговарају купчевим идејама о крајњем производу. Верификација је један од најважнијих корака у откривању погрешне спецификације и њеном уклањању унапред. У супротном, измена ће се морати извршити у фази када је систем већ пројектован и изграђен, што подразумева и привремене и друге губитке ресурса. Највеће проблеме доносе грешке откривене након увођења производа у предузеће.
У општем случају, рад на подешавању система је оцењен много вишим од откривања и исправљања неточности у фази дизајнирања ИП, кодне функционалности. Промјена захтева у већини случајева изазива импресивне структурне промјене, укључујући основни ниво. То значи да ћете након увођења измена морати да прођете читав спектар верификације и тестирања да бисте били сигурни да сви дизајнирани алати исправно функционишу.