Шта је анализа захтева и прикупљање у СДЛЦ?

what is requirement analysis

Овај водич објашњава шта је анализа захтева, кораци, примери и циљеви прикупљања захтева у СДЛЦ:

Развој софтвера је неизмеран задатак који ствара радни софтверски производ.

Софтверски производ је направљен према захтеву купца. Овај софтверски производ је углавном у складу са оним што је очекивао крајњи купац / корисник, док понекад овај производ није у потпуности у складу са оним што су очекивали купац / крајњи корисник.

Шта ћете научити:

• Шта је анализа захтева?
  • Фазе / кораци анализе захтева
    • # 1) Окупљање захтева
    • # 2) Анализа прикупљених захтева
    • # 3) Документовање анализираних захтева
  • Претварање пословних захтева у софтверске захтеве
  • Разумевање случајева нефункционалних захтева
  • Разлика између пословних захтева и софтверских захтева
• Закључак
  • Препоручено читање

Шта је анализа захтева?

Да разумемо анализу захтева уз помоћ примера.

Очекивања купца / крајњег корисника:

Купац / крајњи корисник добија:

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

Међутим, као што видите, било да је то разлог погрешне испоруке производа, примарни разлог је захтев. Дакле, да су урађена исправна разумевања захтева, хватање, примена и тестирање, то би помогло да се ублажи погрешна и непотпуна испорука производа купцу / крајњем кориснику.

Добра испорука производа као предуслов захтева тачно прикупљање захтева, ефикасно испитивање прикупљених захтева и коначно јасну документацију о захтевима. Читав овај процес се назива и Анализа захтева у животном циклусу развоја софтвера (СДЛЦ)

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

Као што видите, Анализа захтева је прва активност у СДЛЦ-у, праћена Функционалном спецификацијом и тако даље. Анализа захтева је витални корак у СДЛЦ-у јер одјекује тестом прихватања који је пресудан за прихватање производа од стране купаца.

У овом упутству ћемо објаснити како се анализа захтева врши у СДЛЦ-у. Такође ћемо видети различите кораке који су укључени, исходе, изазове и корективне мере у анализи захтева.

Анализа захтева почиње са:

1. Прикупљање захтева што се назива и извлачењем.
2. Ово следи анализирајући прикупљени захтеви за разумевање исправности и изводљивости претварања ових захтева у могући производ.
3. И коначно, документовање прикупљени захтеви.

# 1) Окупљање захтева

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

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

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

Пример: У некој организацији развијају АДАС производ (систем камера за окружујући поглед за престижног ОЕМ-а) који треба Аутосар стацк и Боотлоадер бинарне датотеке које су примљене од другог добављача.

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

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

Израда овог прототипа зависи од две врсте производа:

1. У организацији постоји сличан производ који су купци намеравали.
2. Нови производ који треба развити.

(и) У првом случају је купцу лакше показати како би изгледао крајњи производ и како би се развијао. У аутомобилском АДАС-у могуће је купцима показати још један производ који је већ на тржишту и развијен је у оквиру организације.

На пример, Систем окружујућег погледа развијен за ОЕМ-а (ГМ, Волксваген, БМВ, итд.) И може се представити другом ОЕМ-у.

Молим обратите пажњу , није паметно показивати производ / прото производ купцу који је у фази израде, јер то може прекршити Уговор о неоткривању података потписан са другим купцем за којег се тај производ развија. То такође може резултирати непотребним правним споровима.

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

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

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

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

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

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

Пример окупљања захтева: У систему АДАС сурроунд-виев камера једна могућа корисничка прича могла би бити: „Као корисник, требало би да могу да видим шта се налази у задњем погледу мог аутомобила“.

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

У горенаведеној корисничкој причи, ако купац каже „Као корисник, требало би да видим шта се налази у задњем погледу мог аутомобила“, постављајући питање 'зашто “Могао да да„ Као корисник, требало би да видим шта се налази у задњем погледу мог аутомобила, тако да могу безбедно да паркирам свој аутомобил ”.

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

уник наредбе са примерима и синтаксом

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

Пример:

# 2) Анализа прикупљених захтева

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

Овај корак је важан у процесу анализе потреба из следећих главних разлога:

(и) Купац може пружити неке захтеве које је немогуће применити због различитих зависности.

Пример: Купциможе затражити да систем за окруживање прегледа са функцијом камере за уназад која ће вам помоћи паркинг ауто. Купац такође може тражити Приколица спојница која такође користи задњу камеру за рад.

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

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

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

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

# 3) Документовање анализираних захтева

Када је анализа захтева завршена, започиње документација са захтевима. Анализом захтева произлазе разне врсте захтева.

Неки од њих су:

(и) Спецификација захтева купца.

(ии) Захтев за софтверском архитектуром.

Пример:

(иии) Захтев за дизајн софтвера.

Пример:

(ив) Спецификација функционалних захтева (директно изведена из спецификација купаца.)

Пример: „Када корисник тапне на икону Блуетоотх на Инфотаинмент ХМИ-у, треба приказати Блуетоотх екран“

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

Пример: „Требало би бити могуће упарити 15 Блуетоотх уређаја са системом за забаву без погоршања перформанси система“.

(ми) Захтеви корисничког интерфејса.

Пример: „На екрану тјунера ФМ требало би да постоји дугме за одабир различитих станица“

Горе наведени захтеви су забележени и документовани у алатима за управљање захтевима, попут ИБМ ДООРС, ХП КЦ. Понекад организације имају своје прилагођене алате за управљање захтевима како би смањиле трошкове.

Погледајмо сада процес конверзије Пословни захтеви до Захтеви за софтвер (функционални и нефункционални).

Претварање пословних захтева у софтверске захтеве

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

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

Да бисте то урадили, могли би се следити следећи кораци:

1. Поделите пословне захтеве на високом нивоу на детаљне корисничке приче.
2. Извођење дијаграма тока за дефинисање тока активности.
3. Пружање услова који оправдава изведене корисничке приче.
4. Оквирни дијаграми који објашњавају ток рада објеката.
5. Дефинисање нефункционалних захтева изван пословних захтева.

Почнимо од узимања примера аутомобилског информационо-забавног система.

У пословном захтеву се каже, „Крајњи корисник треба да има могућност приступа навигационом оквиру виџета из ХМИ Инфотаинмент система и треба да буде у могућности да постави адресу одредишта“.

Дакле, горе наведени кораци могу се применити као:

# 1) Поделите пословне захтеве на високом нивоу на детаљне корисничке приче.

Претворимо овај пословни захтев у корисничку причу на високом нивоу, “ Као корисник, требало би да могу да приступим пољу виџета за навигацију како бих могао да унесем одредишну адресу ”. Ова корисничка прича говори шта је крајњем кориснику потребно. Покушаћемо да дефинишемо како да применимо овај захтев.

Почнимо са постављањем могућих питања овој корисничкој причи, тј.

1. Ко су корисници?
2. Како могу да приступим навигацији, на броду (са СД картице) или са паметног телефона?
3. Какве уносе одредишта могу да унесем?
4. Да ли ми треба дозволити улазак на одредиште чак и када је аутомобил на паркингу?

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

У овом тренутку можемо узети једну од корисничких потприча и започети испитивање. Узмимо (бр. 3):

1. Могу ли унијети одредишне уносе попут Гео координата, поштанске адресе, препознавањем говора итд.?
2. Да ли ми треба ГПС за унос гео-координата?
3. Могу ли да унесем тренутну адресу одредишта претрагом из историје адреса?

# 2) Извођење дијаграма тока за дефинисање тока активности.

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

# 3) Пружање услова који оправдавају изведене корисничке приче.

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

најбољи иоутубе видео довнлоадер за пц

• Време учитавања екрана за приказ уноса одредишта требало би да буде 1 сек.
• Тастатура за унос одредишта треба да има алфанумеричке знакове и посебне симболе.
• Дугме за укључивање / искључивање ГПС-а требало би да буде присутно на екрану за унос одредишта за навигацију.

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

# 4) Оквирни дијаграми који објашњавају ток рада објеката.

Из горњег случаја употребе извешћемо жичани оквир који ће кориснички интерфејс учинити јаснијим.

# 5) Дефинисање нефункционалних захтева изван пословних захтева.

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

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

Примери:

а) Узећемо пример горњег аутомобилског инфотаинмент система.

Ако возач (крајњи корисник) аутомобила пушта музику са УСБ-а, а навигација је у току, такође прима долазни позив путем Блуетоотх-а у режиму без руку, тада се оптерећење процесора и РАМ-а повећава на максималан ниво јер се одвија више процеса трчање у позадини.

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

б) Други случај је стресни сценарио.

Узмимо пример, систем за информисање и забаву прима узастопне СМС-ове (можда 20 СМС-ова у року од 10 секунди) путем повезаног Блуетоотх телефона. Инфотаинмент систем треба да буде у стању да обрађује све долазне СМС-ове и ни у једном тренутку не сме да пропусти ниједно обавештење о долазном СМС-у на Инфотаинмент ХМИ-у.

Горњи примери су случајеви нефункционалних захтева који се не могу тестирати само путем функционалних захтева. Иако понекад купци пропуштају да пруже ове нефункционалне захтеве. Одговорност је организације да им достави ове информације када се производ испоручи купцу.

Разумевање случајева нефункционалних захтева

Табела у наставку објашњава нефункционалне захтеве:

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

Дакле, овако изводимо софтверске захтеве из пословних захтева.

Разлика између пословних захтева и софтверских захтева

Изнад смо видели како извести захтеве за софтвером из пословних захтева високог нивоа. Софтверски захтеви омогућавају програмеру и инжењеру за испитивање да развију систем и ефикасно га тестирају. Дакле, сада знамо да су пословни захтеви захтеви купца за природним језиком на високом нивоу, док су захтеви за софтвером детаљни захтеви за нижи ниво који помажу у примени софтверског система.

Погледајмо детаљну разлику између две врсте захтева.

Закључак

Анализа захтева је окосница сваког СДЛЦ модела.

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

На крају би организација извршавала задатке контроле штете, попут анализе основног узрока, припремајући зашто, документе, анализу стабла квара, 8Д документ итд., Уместо да се концентрише на развој софтвера и квалитет.

У најгорим случајевима, организација би била увучена у правне тужбе које купац подноси ако је погођена карактеристика везана за безбедност / безбедност, као што је безбедносни приступ, ваздушни јастук, АБС (систем против блокаде кочења) итд.

Препоручено читање

• СДЛЦ (животни циклус развоја софтвера) фазе, методологије, процеси и модели
• Карактеристике функционалних захтева и нефункционалних захтева
• Како тестирати спецификацију софтверских захтева (СРС)?
• 5 смртоносних грешака у управљању захтевима и како их превазићи
• Како тестирати апликацију без захтева?
• Мере за ССДЛЦ (животни циклус сигурног развоја софтвера)
• Спирални модел - шта је СДЛЦ спирални модел?
• Шта је СДЛЦ модел водопада?