Анализа захтева

Перспектива системског инжењеринга на анализу захтева.

Анализа захтева у системском инжењерингу и софтверском инжењерингу, обухвата оне задатке који се изводе при утврђивању потреба или услова да би се остварио нови или измењени производ или пројекат, узимајући у обзир евентуално конфликтне захтеве различитих карактера, анализа, документовања, процена и управљања софтвером или системске захтеве.

Анализа захтева је од кључног значаја за успех пројекта, система или софтвера. Захтеви треба да буду документовани, делотворни, мерљиви, тестирани, праћени, у вези са идентификованим пословним потребама или могућности и дефинисани до нивоа детаља довољно за пројектовање система.

Преглед

Концептуално, анализа захтева обухвата три врсте активности:

• Формулисање захтева: документације пословних процеса и интервјуи заинтересованих страна. Ово се понекад назива прикупљање захтева.
• Анализирарање захтева: утврђивање да ли су наведени захтеви јасни, потпуни, доследни и недвосмислени, и решавање било каквих сукоба.
• Документовање захтева: Захтеви могу бити документовани у различитим облицима, обично укључујући скраћени списак и могу укључивати физичко-језичке документе, употебне примере, корисничка искуства или процес спецификације.

Анализа захтева може бити дуг и напоран процес током којег су укључене многе деликатне психолошке способности. Нови системи мењају средину и односе међу људима, тако да је важно да се идентификују све заинтересоване стране, узму у обзир све њихове потребе и да се обезбеди да разумеју импликације нових система. Аналитичари могу применити неколико техника за сакушљање захтева од стране купаца. Они могу да обухвате развој сценарија (представљен као корисничка прича у агилним методама), идентификација корисничке употребе, употреба посматрања на радном месту или  етнографија, држање интервјуа, или фокус групе (више пригодно назван у овом контексту као захтеви радионице, или захтеви преиспитивања сесије) и стварање захтева листама. Прототипови могу да се користе да развију пример система који може да се докаже актерима. Уколико је потребно, аналитичар ће запослити комбинацију ових метода да се утврди тачан захтев заинтересованих страна, тако да систем који задовољава пословне потребе се производи. Квалитет захтева се може побољшати кроз њих и других метода

• Визуелизација. Користећи алате који промовишу боље разумевање жељеног крајњег производа такве као визуелизацију и симулацију.
• Доследно коришћење шаблона. Израда доследног скупа модела и образаца да документују услове.
• Документовање зависности. Документовање зависности и међусобности међу захтевима, као и све претпоставке и конгрегације.

Тема захтева анализе

Идентификација заинтересованих страна

Погледајте анализу заинтересованих страна за дискусију људи или организације (правна лица, као што су предузећа, организације за стандардизацију) који имају оправдан интерес у систему. Они могу бити погођени директно или индиректно. Главни нови акценат у 1990. био је фокус на идентификацији актера. Све се више препознаје да актери нису ограничени на организацији послодавца аналитичара. Остали учесници ће укључивати:

• свако ко управља системом (нормални и одржавачки оператери)
• свако ко има користи од система (функционални, политички, финансијски и социјални корисници)
• сви укључени у куповину и набавку система. У организацији масовно тржиште производа, управљању производима, маркетингу и понекад продаје као сурогат актом потрошача (масовном тржишту купаца) да води развој производа
• организације које регулишу аспекти система (финансијски, безбедност и други регулатори)
• људи или организације које се супротстављају систему (негативни актери; видети такође случај злоупотребе)
• организације одговорне за системе који интерфејс са системом под дизајн
• оне организације које интегришу хоризонтално са организацијом за коју је аналитичар пројектовање система

Интервјуи интересних група

Интервјуи интересних група су уобичајене технике које се користе у анализи захтева. Иако су углавном идиосинкратичне у природи и фокусиране на перспективе и уочене потребе заинтересованих страна, често тај недостатак перспектива има општу предност добијања много богатијег разумевања актера јединствених пословних процеса, доношењем одговарајућих пословних правила, и уочене су потребе. Због тога ова техника може да послужи као средство за добијање високо фокусираног знања које се често не изазива у заједничким захтевима за развој сесије, где је пажња заинтересованих страна присиљена да преузме више крос-функционални контекст, и жеља да се избегне контроверза може ограничити спремност заинтересованих страна да допринесу. Поред тога, у-лице природа разговора даје више опуштену атмосферу у којој линије мисли могу бити истражене у дужини.

Заједнички захтеви за развој (JRD)  

Захтеви често имају крос-функционалне импликације које су непознате код појединих учесника и често се пропуштају или су непотпуно дефинисане током разговора са заинтересованим странама. Ове крос-функционалне последице могу бити изазване обављањем ЈРД сесија у контролисаном окружењу, омогућавањем обучених модератора (Пословни аналитичар), где актери учествују у дискусијама на изазове захтева, анализирају своје податке и откривају крос-функционалне импликације. Посвећени писари треба да буду присутни да документују дискусију, чиме се ослобађа пословни аналитичар да води дискусију у правцу који генерише одговарајуће услове који одговарају циљу сесије.

ЈРД Сесије су аналогни заједничкој апликацији дизајн сесија. У првој недељи изазивају услове који воде дизајн, док касније изазивају специфичне карактеристике дизајна које треба спровести у задовољавању услова изазваних.

Листа захтева стилом уговора

Један традиционални начин документовања захтева је списак захтева стилом уговора. У сложеном систему такве захтеве листа могу покренути на стотине страница дуго.

Одговарајућа метафора био би изузетно дуг списак за куповину. Такви спискови су веома пали у немилост у модерној анализи; јер су се показали неуспешни спектакуларно на постизање својих циљева; али се и даље виде до данашњег дана.

Предности

• Пружа списак захтева.
• Обезбеђује уговор између носиоца пројекта и програмера.
• За велики систем може да обезбеди опис високог нивоа од којих услови на нижем нивоу се могу извести.

Слабости

• Такве листе могу покренути на стотине страница. Они нису намењени да служе као читаоци пијатељских описа жељене апликације.
• Такви захтеви листа апстрактују све захтеве и тако да је мало контекста. Пословни аналитичар може укључивати контекст за захтеве у пратеће пројектне документације.
  • Овај сажетак није намењен да опише како су захтеви способни или да раде заједно.
  • Листа можда не одражава односе и зависности између захтева. Док се листа не олакшава приоритет сваке појединачне ставке, уклањање једну ставку из контекста може да пружи читав случај коришћења или пословни захтев бескористан.
  • Листа не задовољава потребу да размотри захтеве пажљиво са заинтересованим странама како би стекли боље заједничко разумевање импликације за пројектовање жељеног система / апликације.
• Једноставно креирање листе не гарантује њену целовитост. Пословни аналитичар мора направити напоре да открију и прикупе знатно свеобухватан попис, и ослањају се на заинтересованим странама да истакну недостајуће захтеве.
• Ове листе могу створити лажни осећај међусобног разумевања између заинтересованих страна и програмера; Пословни аналитичари су од кључног значаја за процес превођења.
• То је готово немогуће да открије све функционалне захтеве пред почетак процеса развоја и тестирања. Ако се ови спискови третирају као непроменљиви уговори, онда захтеви који настају у процесу развоја могу генерисати контроверзну промену захтева.

Алтернатива листе захтева

Као алтернатива листе захтева, Агилни развој софтвера користи корисничке приче да предложи захтеве у свакодневном језику.

Мерљиви циљеви

Најбоље праксе узети састављену листу захтева само као трагове и више пута питати "зашто?" до стварне пословне сврхе су откривене. Заинтересоване стране и програмери могу онда смислити тестове за мерење  нивоа сваког циља који је постигнут до сада. Такви циљеви мењају много спорије него дуге листе конкретних али немерених захтева. Када је основан мали скуп критичких, измерених циљева, брза израда прототипова и кратке итеративне фазе развоја може да настави да испоручи стварну вредност заинтересованих много пре него што је пројекат пола готово.

Прототипови

Прототип је рачунарски програм који показује део имовине другог рачунарског програма, омогућавајући корисницима да визуализују апликацију која још није конструисана. Популаран облик прототипа је макет, који помаже будућим корисницима и другим актерим да би добили идеју о томе како ће систем изгледати. Прототипови олакшавају да се направи дизајн одлуке, јер аспекти примене могу да се виде и деле пре него што је апликација изграђена. Значајна побољшања у комуникацији између корисника и програмера се често посматрају са увођењем прототипа. Рани прегледи апликација довели су до мање промене касније и самим тим се значајно смањују укупни трошкови.

Прототипови могу бити равни дијаграми (често се називају жичани оквири) или радне апликације користећи синтетизовану функционалност. Жичани оквири се праве у различитим графичким пројектним документацијама, а често и уклањају све боје са дизајна (тј користити у сивим тоновима палету боја) у случајевима где се очекује коначан софтвер да има графички дизајн примењен на њега. То помаже да се спречи конфузија да ли прототип представља коначан визуелни изглед и осећај апликације.

Случајеви употребе

Употреба случаја је структура за документовање функционалних захтева за систем, обично укључује софтвер, да ли је нови или се мења. Сваки случај употребе обезбеђује низ сценарија који преносе како систем треба да комуницира са људским корисником или неким другим системом, да би се постигао конкретан пословни циљ. Случајеви употребе обично избегавају технички жаргон, уместо тога језика крајњег корисника или домена стручњака. Случајеви употребе су често коаутори са захтевима инжењера и заинтересованих страна.

Случајеви употребе су варљиво једноставни алати за описивање понашања софтвера или система. Случајеви употребе садрже текстуални опис начина на који су корисници намењени за рад са софтвером или системом. Случајеви употребе не би требало да опишу унутрашње функционисање система, нити треба да објасне како ће тај систем бити имплементиран. Уместо тога, они показују кораке потребне за обављање задатка.

Спецификација захтева

Излаз процеса анализе захтева је спецификација захтева.

Типови захтева

Захтеви су категорисани на неколико начина. Следе уобичајене категоризације услова који се односе на техничка управљања:

Захтеви купаца

Изјаве чињенице и претпоставке које дефинишу очекивања система у погледу циљева мисије, животне средине, ограничења и мере ефикасности и подобности (МОЕ / Мос). Потрошачи су они који обављају осам примарних функција система инжењеринга, са посебним нагласком на оператора као кључног купца. Оперативни услови ће дефинисати основну потребу и, у најмању руку, одговорити на питања која су у следећем попису:

• Оперативна дистрибуција и размештање: Где ће систем се користи?

• Профил мисије или сценарија: Како ће систем остварити свој циљ мисије?

• Перфомансе и везани параметри: Који су критични параметри система за постизање циља?

• Коришћење средине: Како се различите компоненте система користе?
• Захтеви ефикасности: Како ефикасније и економичније мора систем бити у обављању своје мисије?

• Оперативни животни циклус: Колико дуго ће систем бити у употреби од стране корисника?

• Животна средина: Како се од средине очекује да ће систем да ради на ефикасан начин?

Архитектонски захтеви 

Архитектонски захтеви објашњавају шта треба да се уради за идентификацију потребних система за архитектуру система.

Структурни захтеви

Структурни услови објашњавају шта треба да се уради за идентификацију неопходне структуре система

Понашање захтева

Понашање захтева објашњава шта треба да се уради кроз идентификацију потребну за понашање система.

Функционални захтеви

Функционални захтеви објашњавају шта треба да се уради кроз идентификацију потребних задатака, акцију или активност која мора бити постигнута. Функционална анализа захтева ће се користити као врхунска функција нивоа за функционалне анализе.

Нефункционални захтеви

Нефункционални захтеви су захтеви који одређују критеријуме који се могу користити да се суди рад система, уместо конкретних понашања.

Основна функционалност и помоћни захтеви функционалности

Murali Chemuturi дефинисао је услове у основној функционалности и помоћним захтевима функционалности. Основни захтеви Функционалности су они без испуњавања којима производ не може бити од користи уопште. Помоћни захтеви функционалности су они који подржавају основне функционалности. Производ може наставити да ради чак и ако су испуњени неки или сви пратећи захтеви функционалности, али са неким споредним ефектима. Безбедност, сигурност, лакоћа и тако даље су примери помоћних услова Функционалностит

Перформансе захтева

Обим у којем мисија или функција мора бити погубљена; углавном се мери у погледу квантитета, квалитета, покривености, рокова или спремности. Током анализе захтева, перформансе (како добро то треба да се уради) захтеви ће се интерактивно развијати у свим идентификованим функцијама на основу система животног циклуса фактора; и карактерише се у смислу степена сигурности у њиховој процени, степен критичности према успеху система, и њихов однос према другим захтевима. 

Дизајн захтеви

Захтеви који се подразумевају или трансформишу из захтева вишег нивоа. На пример, захтев  дугог домета или велике брзине може довести до захтева за дизајн мале тежине.

Издвојени захтеви

Услов да се успостави дељењем или на други начин доделом услова на високом нивоу у више захтева нижег нивоа. Пример: предмет 100-фунти који се састоји од два подсистема може да доведе до тежине захтевима 70 фунти и 30 фунти за две ставке нижег нивоа.

Добро познати захтеви модела за категоризацију укључују FURPS i FURPS+, развијени у Хјулет-Пакард-у.

Питања захтева анализе

Питања интересних група

Стив Меконел, у својој књизи Брзи развој, детаље о неколико начина корисници могу да инхибирају прикупљањем захтева:

• Корисници не разумеју шта они желе или корисници немају јасну представу о њиховим захтевима
• Корисници се неће обавезати на скуп писаних захтева
• Корисници инсистирају на новим захтевима након што су фиксни трошкови и распоред 
• Комуникација са корисницима је спора
• Корисници често не учествују у критикама или су неспособни да раде тако
• Корисници су технички софистицирани
• Корисници не разумеју процес развоја
• Корисници не знају о овој технологији

То може да доведе до ситуације у којој се захтеви корисника мењају, чак и када систем или развој производа је стартован. Такође значи да је услов под дејством процеса.

Инжењерска/програмерска питања

Могући проблеми изазвани од стране инжењера и програмера у току анализе захтева су:

• Природна склоност ка писању кода може да доведе до реализације на почетку пре него што се анализа захтева заврши, потенцијално доводи до прављења неелегантног задовољавања стварних потреба након што су познати.
• Техничко особље и крајњи корисници могу имати различите речнике. Сходно томе, они погрешно верују да су у савршеном споразуму док се готов производ испоручује.
• Инжењери и програмери ће можда пре покушати да направе захтеве за постојећи систем или модел, него развити систем специфичан за потребе клијента.
• Анализа често може бити спроведена од стране инжењера или програмера, него особља са знањем домена да правилно разуме потребе клијента. 

Покушај решења

Један покушај решења за комуникационе проблеме је да се запосле стручњци у пословном или систему анализе.

Технике уведене у 1990 као израда прототипова, Unified Modeling Language (UML), користи случајеве, и агилни развој софтвера је такође намењен као решење проблема са претходним методама.

Такође, нова класа симулације апликација или дефиниције примена алата је ушли на тржиште. Ови алати су дизајнирани да премосте јаз комуникације између пословних корисника и ИТ организације - као и да омогући апликацијама да буду 'тест на тржишту "пре него што се произведе код. Најбољи од ових алата нуде: 

• електронске беле табле за скицирање апликација токова и тест алтернативе
• способност да се ухвати пословна логика и  потребни подаци
• способност за генерисање прототипова високе верности да блиско опонаша коначну пријаву
• интерактивност
• способност да додају контекстуалне захтеве и друге коментаре
• способност за удаљене и дистрибуиране кориснике да раде и интерагују са симулацијом

Види још

• Софтверски дизајн
• Дебаговање
• Софтверско распоређивање
• Одржавање софтвера
• Конструкција софтвера
• Тестирање софтвера
• Развојни циклус софтвера
• Софтверско инжењерство

Литература

• Berenbach, Brian; Paulish, Daniel; Katzmeier, Juergen; Rudorfer, Arnold (2009). Software & Systems Requirements Engineering: In Practice. New York: McGraw-Hill Professional. ISBN 978-0-07-160547-2. 
• Hay, David C. (2003). Requirements Analysis: From Business Views to Architecture (1st изд.). Upper Saddle River, NJ: Prentice Hall. ISBN 978-0-13-028228-6. 
• Laplante, Phil (2009). Requirements Engineering for Software and Systems (1st изд.). Redmond, WA: CRC Press. ISBN 978-1-4200-6467-4. Архивирано из оригинала 22. 10. 2014. г. Приступљено 20. 1. 2016. 
• McConnell, Steve (1996). Rapid Development: Taming Wild Software Schedules (1st изд.). Redmond, WA: Microsoft Press. ISBN 978-1-55615-900-8. 
• Nuseibeh, B.; Easterbrook, S. (2000). Requirements engineering: a roadmap (PDF). Proceedings of the conference on the future of Software engineering; conference: ICSE'00. ISBN 978-1-58113-253-3. doi:10.1145/336512.336523. CiteSeerX: 10.1.1.131.3116. 
• Stellman, Andrew & Greene, Jennifer (2005). Applied Software Project Management. Cambridge, MA: O'Reilly Media. ISBN 978-0-596-00948-9. 
• Wiegers, Karl & Beatty, Joy (2013). Software Requirements (3rd izd.). Redmond, WA: Microsoft Press. ISBN 978-0-7356-7966-5. 

Спољашње везе

• Рецензирана Encyclopedia Entry on Requirements Engineering and Analysis
• Defense Acquisition University Stakeholder Requirements Definition Process
• MIL-HDBK 520 Systems Requirements Document Guidance