features functional requirements
Овај водич објашњава типове, карактеристике, поређење функционалних и нефункционалних захтева и пословних вс функционалних захтева са примерима:
Функционални захтеви дефинишу шта софтверски систем треба да ради. Дефинише функцију софтверског система или његовог модула. Функционалност се мери као скуп улаза у систем који се тестира на излаз из система.
Имплементација функционалних захтева у систем планира се у фази пројектовања система, док је у случају нефункционалних захтева планирана у документу Архитектура система. Функционални захтев подржава генерисање нефункционалних захтева.
Шта ћете научити:
Функционални захтеви и нефункционални захтеви
Функционални захтеви
Хајде да схватимо шта су функционални захтеви помоћу примера-
Пример: У аутомобилском АДАС пројекту, функционалан систем сурроунд приказа може бити „Задња камера треба да открије претњу или објекат“. Овде нефункционални захтеви могу бити „колико брзо треба приказати упозорење кориснику када сензори камере открију претњу“.
Узми другу пример пројекта Инфотаинмент системи. Корисник овде омогућава Блуетоотх путем ХМИ-а и проверава да ли је Блуетоотх омогућен или не. Белешка , друге Блуетоотх услуге се омогућавају (од сиве до подебљане) када корисник омогући Блуетоотх.
тачкаста питања и одговори за интервјуе
Дакле, функционални захтеви говоре о одређеном исходу система када корисник на њима изврши задатак. С друге стране, нефункционални захтев даје целокупно понашање система или његове компоненте, а не функцију.
Врсте функционалних захтева
Функционални захтеви могу да укључују следеће компоненте које се могу мерити као део функционалног испитивања:
# 1) Интероперабилност: Захтев описује да ли је софтверски систем интероперабилан у различитим системима.
Пример: За функционалне захтеве Блуетоотха у аутомобилском информацијско-забавном систему, када корисник упари паметни телефон заснован на Андроиду са омогућеним Блуетоотх-ом и информацијско-забавни систем заснован на КНКС-у, требали бисмо бити у могућности да пребацимо телефонски именик у инфо-забавни систем или да стримујемо музику са нашег телефонског уређаја на инфо-забавни систем.
Дакле, интероперабилност проверава да ли је могућа комуникација између два различита уређаја или не.
Други пример је из система услуга е-поште попут Гмаил-а. Гмаил омогућава увоз е-адреса са другог сервера за размену поште, као што су Иахоо.цом или Редиффмаил.цом. То је могуће због интероперабилности између сервера е-поште.
# 2) Безбедност: Функционални Захтев описује безбедносни аспект захтева софтвера.
Пример: Услуге засноване на Цибер Сецурити-у у систему заснован на АДАС сурроунд-виев систему који користи Цонтроллер Ареа Нетворк (ЦАН) која штити систем од безбедносних претњи.
Други пример је са странице за друштвене мреже Фацебоок . Подаци корисника треба да буду сигурни и не смеју да процуре у иностранство. Надамо се да овај пример Фацебоок-а пружа ширу надлежност читаоцима због недавних случајева кршења података на Фацебоок-у и последица с којима се Фацебоок суочава.
# 3) Тачност: Тачност дефинише да се подаци унети у систем правилно израчунавају и користе у систему и да је излаз тачан.
Пример: У мрежној мрежи контролера, када се ЕЦУ преноси вредност ЦАН сигнала преко ЦАН магистрале (односно АБС јединица, ХВАЦ јединица, јединица инструмент табле, итд.), Друга ЕЦУ ће моћи да идентификује да ли су послати подаци тачни или не путем ЦРЦ провере.
Други пример може бити из решења за банкарство на мрежи. Када корисник прими средства, примљени износ треба тачно књижити на рачун и не прихвата се никаква разлика у тачности.
# 4) Усклађеност: Функционални захтеви за усаглашеност потврђују да је развијени систем усклађен са индустријским стандардима.
Пример: Да ли су функције Блуетоотх профила (на пример, стримовање звука преко А2ДП-а, Телефонски позив путем ХФП-а) усаглашене са верзијама Блуетоотх СИГ издања.
Други пример може бити оно што игра Аппле Цар у Цар инфотаинмент систему. Апликација у инфотаинмент добија цертификат од Аппле ако сви предуслови наведени на веб локацији Аппле испуњавају независни уређаји Цар Плаи (у овом случају инфотаинмент).
Други пример може бити из веб-апликације за систем железничких карата. Веб локација би требало да следи смернице за сајбер безбедност и да се у погледу приступачности усклади са Интернетом.
Пример обрасца захтева:
Већ смо видели шта је функционални захтев на неким примерима. Погледајмо сада како би функционални захтев могао изгледати интегрисан у алате за управљање захтевима попут ИБМ ДООРС. Постоји више атрибута које треба узети у обзир приликом документовања функционалних захтева у алату за управљање захтевима.
Испод је неколико атрибута које треба узети у обзир:
- Тип објекта: Овај атрибут објашњава који је одељак документа са захтевима део овог атрибута. То би могли бити наслов, објашњење, захтев итд. Углавном се одељак „Захтев“ узима у обзир за примену и тестирање, док се одељци наслова и објашњења користе као пратећи описи захтева за боље разумевање.
- Одговорно лице: Аутор који је документовао захтев у алату за управљање захтевима.
- Назив пројекта / система: Пројекат за који се захтев примењује, на пример, „Инфотаинмент системи за КСИЗ ОЕМ (произвођач оригиналне опреме) аутомобилску компанију или веб апликацију за АБЦ банкарско друштво с ограниченом одговорношћу“.
- Број верзије захтева: Ово поље / атрибут обавештава број верзије захтева ако је захтев претрпео вишеструке измене услед ажурирања купаца или промена у дизајну система.
- ИД захтева: Овај атрибут помиње јединствени ИД захтева. Ид захтева се користи за лако праћење захтева у бази података и такође за ефикасно мапирање захтева у коду. Такође се може користити за упућивање на захтеве током евидентирања недостатака у алатима за праћење грешака.
- Опис захтева: Овај атрибут је један од најважнијих атрибута који објашњавају захтев. Читајући овај атрибут, инжењер би могао да разуме захтев.
- Статус захтева: Атрибут статуса захтева говори о статусу захтева у алату за управљање захтевима, тј. Да ли је пројекат прихваћен, на чекању, одбијен или избрисан.
- Коментари: Овај атрибут пружа одговорној особи или управнику захтева опцију да документује било који коментар о захтеву. Пример: могући коментар функционалног захтева могао би бити „зависност од софтверског пакета треће стране за примену захтева“.
Снимак са ВРАТА
Извођење функционалних захтева из пословних захтева
Ово је већ покривено као део одељка „ Извођење функционалних захтева из пословних захтева ' под Анализа захтева чланак.
Пословни захтеви против функционалних захтева
Ова разлика је слабо покривена у Анализа захтева чланак. Међутим, покушаћемо истакните још неколико тачака овде у доњој табели:
| Сл. Не. | Пословни захтеви | Функционални захтеви |
|---|---|---|
| 7 | На пример, у систему банкарства на мрежи пословни захтев би могао бити „Као корисник, требало би да могу да добијем извод о готовинској трансакцији“. | Функционални захтев у овом систему банкарства на мрежи могао би бити: „Када корисник наведе упитни период у упиту за трансакцију, овај унос користи Сервер, а веб страници се дају потребни подаци о готовинским трансакцијама“. |
| 1 | Пословни захтеви говоре „какав“ аспект захтева купца. Пример, Шта би требало да буде видљиво кориснику након што се корисник пријави. | Функционални захтеви говоре о аспекту пословних захтева „како“. Пример, Како веб страница треба да приказује страницу за пријављивање корисника када се корисник потврди. |
| два | Пословне захтеве идентификују пословни аналитичари. | Функционалне захтеве креирају / изводе програмери / архитекта софтвера |
| 3 | Наглашавају на користи за организацију и повезани су са пословним циљевима. | Њихов циљ је испуњавање захтева купаца. |
| 4 | Пословни захтеви су од купца. | Функционални захтеви су изведени из софтверских захтева, који су, пак, изведени из пословних захтева. |
| 5 | Инжењери за испитивање софтвера директно не тестирају пословне захтеве. Купац их углавном тестира. | Функционалне захтеве тестирају инжењери софтверских тестова, а купци их углавном не тестирају. |
| 6 | Пословни услов је документ захтева високог нивоа. | Функционални захтев је детаљни документ о техничким захтевима. |
Нефункционални захтев
Нефункционални захтев говори о томе „какав систем треба да буде“, а не о томе „шта систем треба да ради“ (функционални захтев). Они су углавном изведени из функционалних захтева заснованих на инпутима купца и других заинтересованих страна. Појединости о примени нефункционалних захтева документоване су у документу Архитектура система.
Нефункционални захтеви објашњавају аспекте квалитета система који ће се градити, тј. перформансе, преносивост, употребљивост итд. Нефункционални захтеви, за разлику од функционалних захтева, примењују се постепено у било ком систему.
УРПС (Употребљивост, поузданост, перформансе и подршка) од ФУРПС Атрибути квалитета (Функционалност, употребљивост, поузданост, перформансе и подршка) који се у ИТ индустрији широко користе за мерење квалитета програмера, покривени су нефункционалним захтевима. Поред тога, постоје и други атрибути квалитета (детаљи у следећем одељку).
Википедиа нефункционални захтев понекад назива „неправилностима“, због присуства различитих атрибута квалитета, као што су преносивост и стабилност.
Врсте нефункционалних захтева
Нефункционални захтеви састоје се од доњих подтипова (неисцрпних):
# 1) Перформансе:
Тип атрибута перформансе, нефункционални захтев, мери перформансе система. Пример: У АДАС систему сурроунд прегледа, „приказ задње камере треба да се прикаже у року од 2 секунде од покретања паљења аутомобила“.
Други пример перформансе могу бити из инфотаинмент система Навигациони систем. „Када корисник пређе на екран за навигацију и унесе одредиште, руту треба израчунати у року од„ Кс “секунди“. Још једно пример са странице за пријаву веб апликације. „Време потребно за учитавање странице корисничког профила након пријављивања.“
Имајте на уму да се мерење перформанси система разликује од мерења оптерећења. Током тестирања оптерећења учитавамо системски процесор и РАМ и проверавамо пропусност система. У случају перформанси, тестирамо пропусност система у нормалним условима оптерећења / напрезања.
# 2) Употребљивост :
Употребљивост мери употребљивост софтверског система који се развија.
На пример , развијена је мобилна веб апликација која вам даје информације о водоинсталатерима и доступности електричара у вашем подручју.
Улаз у ову апликацију је поштански број и радијус (у километрима) од ваше тренутне локације. Али да би унео ове податке, ако корисник мора да прегледава више екрана и ако се опција уноса података прикаже у малим текстуалним оквирима који нису лако видљиви кориснику, онда ова апликација није једноставна за употребу и стога ће употребљивост апликације бити Веома низак.
# 3) Одржавање :
Одржавање софтверског система је лакоћа којом се систем може одржавати. Ако је средње време између кварова (МТБФ) мало или је средње време за поправак (МТТР) високо за систем који се развија, тада се одрживост система сматра ниском.
Одржавање се често мери на нивоу кода коришћењем цикломатичне сложености. Цикломатична сложеност каже да што је код мање комплексан, то је лакше одржавати софтвер.
Пример: Развијен је софтверски систем који има велики број мртвих кодова (кодови које не користе друге функције или модули), изузетно сложен због прекомерне употребе услова иф / елсе, угнежђених петљи итд. Или ако је систем огроман са покренутим кодовима у многе милионе редова кодова и без одговарајућих коментара. Такав систем је слабо одржаван.
Други пример може бити веб страница за куповину на мрежи. Ако на веб локацији постоји много спољних веза, тако да корисник може да има преглед производа (ово ради уштеде меморије), тада је одрживост ове веб локације ниска. То је зато што се, уколико се веза спољне веб странице промени, мора ажурирати и на веб локацији за куповину на мрежи и то пречесто.
# 4) Поузданост :
Поузданост је још један аспект доступности. Овај атрибут квалитета наглашава доступност система под одређеним условима. Мери се као МТБФ, баш као и одрживост.
Пример: Међусобно ексклузивне функције попут камере за задњи поглед и приколице у АДАС систему сурроунд-погледа треба поуздано да раде у систему без икаквих интерференција. Када корисник позове функцију приколице, задњи преглед не би требало да омета и обрнуто, јер обе функције приступају задњој камери аутомобила.
Други пример из система потраживања на мрежи. Када корисник започне извештавање о потраживањима, а затим отпреми одговарајуће рачуне за трошкове, систем би требало да да довољно времена да се отпремање заврши и не би требало брзо да откаже поступак отпремања.
# 5) Преносивост:
Преносивост значи способност софтверског система да ради у другом окружењу ако основни зависни оквир остане исти.
Пример: Софтверски систем / компонента у развијеном инфотаинмент систему (односно Блуетоотх услуга или мултимедијална услуга) за произвођача аутомобила треба да дозволи употребу у другом инфотаинмент систему са мало или нимало промена у коду, иако су два инфотаинмент система потпуно различита .
пример хеш табеле ц ++
Узмимо другу пример из ВхатсАпп-а. Могуће је инсталирати и користити услугу размене порука на ИОС, Андроид, Виндовс, Таблет, Лаптоп и Пхоне.
# 6) Могућност подршке:
Исправљивост софтверског система је способност сервиса / техничког стручњака да инсталира софтверски систем у реалном времену, надгледа систем док је покренут, идентификује све техничке проблеме у систему и пружи решење за решавање проблема.
Могућност сервисирања је могућа ако је систем развијен да олакша сервисирање.
Пример: Пружање повременог скочног подсетника кориснику за ажурирање софтвера, обезбеђивање механизма евидентирања / праћења за отклањање грешака, аутоматски опоравак од квара помоћу механизма враћања (враћање софтверског система у претходно радно стање).
Други пример од Редиффмаил. Када је дошло до ажурирања верзије поштанске услуге засноване на Интернету, систем је омогућио кориснику да пређе на новију верзију система за слање поште, задржавајући старију нетакнуту неколико месеци. Ово побољшава и корисничко искуство.
# 7) Прилагодљивост:
Прилагодљивост система дефинише се као способност софтверског система да се прилагоди променама у окружењу без икаквих промена у његовом понашању.
Пример: Систем против блокаде кочења у аутомобилу треба да ради према стандардима у свим временским условима (врућим или хладним). Други пример може бити оперативни систем Андроид. Користи се у различитим врстама уређаја, тј. Паметни телефони, таблет рачунари и Инфотаинмент системи изузетно су прилагодљиви.
Поред горе наведених 7 нефункционалних захтева, имамо и многе друге попут:
Приступачност, израда резервних копија, капацитет, усклађеност, интегритет података, задржавање података, зависност, примена, документација, трајност, ефикасност, експлоатабилност, проширивост, управљање кваровима, толеранција кварова, интероперабилност, променљивост, оперативност, приватност, читљивост, извештавање, отпорност, поновна употребљивост, Робусност, скалабилност, стабилност, проверљивост, пропусност, транспарентност, интегрисаност.
Покривање свих ових нефункционалних захтева изван је делокруга овог чланка. Међутим, о овим нефункционалним врстама захтева можете прочитати у Википедиа.
Извођење нефункционалних захтева из функционалних захтева
Нефункционални захтеви могу се извести на више начина, али најбољи и већина индустријски испробаних начина је из функционалних захтева.
Узмимо пример из наших Инфотаинмент система које смо већ узели на неколико места у овом чланку. Корисник може да изврши многе радње на Инфотаинмент систему, тј. промените песму, промените извор песме са УСБ-а на ФМ или Блуетоотх аудио, поставите одредиште за навигацију, ажурирајте софтвер за забаву путем ажурирања софтвера итд.
# 1) Прикупљање нефункционалних захтева:
Навешћемо задатке које извршава корисник, што је део функционалних захтева. Једном када су радње корисника забележене у дијаграму случајева коришћења УМЛ-а (сваки овални), покренућемо релевантна питања (сваки правоугаоник) о радњама сваког корисника. Одговори на ова питања даће наше нефункционалне захтеве.
# 2) Категоризација нефункционалних захтева:
Следећи корак је категоризација нефункционалних захтева које смо идентификовали питањима. У овој фази можемо проверити могући одговор и категоризовати одговоре на могуће нефункционалне категорије или различите квалитете.
На доњој слици можете видети могуће атрибуте квалитета препознате из одговора.
Функционални против нефункционалних захтева
Већ смо видели шта су функционални и нефункционални захтеви и како су изведени. Погледајмо главне разлике између функционалних и нефункционалних захтева.
| Сл. не | Функционални захтеви (ФР) | Нефункционални захтеви (НФР) |
|---|---|---|
| 7 | Функционални захтеви чине костур имплементације софтверског система | Нефункционални захтеви довршавају СВ систем помажући да се функционални захтеви држе заједно, попут мишића. |
| 1 | Кажу, шта систем треба да ради. | Кажу, какав систем треба да буде. |
| два | Они су детаљно описани у документу о дизајну система. | Они су детаљно наведени у документу о архитектури система. |
| 3 | Они говоре о понашању функције или обележја. | Говоре о радном понашању читавог система или његове компоненте, а не о одређеној функцији. |
| 4 | Корисник ће проследити улаз и проверити да ли је излаз правилно приказан. | Када корисник проследи улаз, НФР-ови могу одговорити на следећа питања: и) Колико времена је потребно за приказ резултата? ии) Да ли је излаз конзистентан са временом? иии) Постоје ли други начини за прослеђивање улазног параметра? ив) Колико је лако проследити улазни параметар? |
| 5 | У веб апликацији, корисник треба да буде у могућности да се пријави путем потврде идентитета | У веб апликацији, колико је времена потребно за пријаву на веб локацију, изглед и осећај странице за пријаву, једноставност коришћења веб странице итд., Део су НФР |
| 6 | Функционални захтеви су изведени прво из захтева за софтвер. | Нефункционални захтеви су изведени из функционалних захтева. |
| 8 | Функционални захтеви могу постојати и без нефункционалних захтева. | Нефункционални захтеви не могу постојати без функционалних захтева. |
| 9 | Функционални захтев даје конкретне информације о својству, Пример , Фотографија профила на Фацебоок-у треба да буде видљива приликом пријављивања. | Функционални захтев може имати много атрибута нефункционалних захтева. Пример, време за пријаву (перформансе), изглед и осећај странице профила (употребљивост), број корисника који се могу истовремено пријавити (капацитет, перформансе) |
| 10 | Извођење функционалних захтева из СВ захтева могуће је за готово све пословне захтеве | НФР се често пропуштају да се документују, јер се на ФР не постављају релевантна питања. |
| Једанаест | Имплементација функционалних захтева обично се обавља у једној верзији софтвера. | НФР се примењују током животног циклуса пројекта док се не постигне жељено понашање. |
| 12 | Они су углавном видљиви купцу. | Купац их углавном не види, али дугорочно би их могао искусити. Пример, Корисност, перформансе итд. Могу се искусити само дугорочно, али уопште не могу бити видљиве. |
Закључак
Захтеви чине основни блок за развој било ког софтверског система. Могуће је изградити систем са функционалним захтевима, али његове способности се не могу утврдити нити измерити. Имајући то у виду, веома је важно имати квалитетне функционалне захтеве који произилазе из пословног захтева да бисмо имали висококвалитетни радни систем софтвера.
Дакле, функционални захтеви дају правац примене софтверског система, али нефункционални захтеви одређују квалитет имплементације који ће крајњи корисници доживети.
Препоручено читање
- Како тестирати спецификацију софтверских захтева (СРС)?
- Функционално тестирање вс нефункционално тестирање
- Како тестирати апликацију без захтева?
- Шта је анализа захтева и прикупљање у СДЛЦ?
- 5 смртоносних грешака у управљању захтевима и како их превазићи
- Карактеристике функционалних захтева и нефункционалних захтева
- Како створити матрицу сљедивости захтјева (РТМ): Примјер и узорак предлошка
- Топ 20+ најбољих алата за управљање захтевима (комплетна листа)