мини|320x320п|Перспектива системског инжењеринга на анализу захтева.Systems Engineering Fundamentals Defense Acquisition University Press, 2001 Анализа захтева у системском инжењерингу и софтверском инжењерингу, обухвата оне задатке који се изводе при утврђивању потреба или услова да би се остварио нови или измењени производ или пројекат, узимајући у обзир евентуално конфликтне захтеве различитих карактера, анализа, документовања, процена и управљања софтвером или системске захтеве.Kotonya, G. and Sommerville, I. 1998.

Анализа захтева је од кључног значаја за успех пројекта, система или софтвера.Executive editors: Alain Abran, James W. Moore; editors Pierre Bourque, Robert Dupuis, ed. Захтеви треба да буду документовани, делотворни, мерљиви, тестирани, праћени, у вези са идентификованим пословним потребама или могућности и дефинисани до нивоа детаља довољно за пројектовање система.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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