features functional requirements
Този урок обяснява типовете, характеристиките, сравнението на функционални и нефункционални изисквания и бизнес срещу функционални изисквания с примери:
Функционалните изисквания определят какво трябва да прави софтуерната система. Той определя функция на софтуерна система или нейния модул. Функционалността се измерва като набор от входове към тестваната система към изхода от системата.
Внедряването на функционални изисквания в система се планира във фазата на проектиране на системата, докато в случай на нефункционални изисквания се планира в документа за архитектура на системата. Функционалното изискване поддържа генерирането на нефункционални изисквания.
Какво ще научите:
- Функционални изисквания и нефункционални изисквания
- Функционални Vs Нефункционални изисквания
- Заключение
Функционални изисквания и нефункционални изисквания
Функционални изисквания
Нека разберем какви са функционалните изисквания с помощта на примери-
Пример: В автомобилен ADAS проект функционално изискване на системата за съраунд изглед може да бъде „Задната камера трябва да открива заплаха или обект“. Нефункционалните изисквания тук могат да бъдат „колко бързо трябва да се показва предупреждението за потребител, когато заплахата бъде открита от сензорите на камерата“.
Вземете друг пример на проекта Инфотейнмънт системи. Потребителят активира Bluetooth тук от HMI и проверява дали Bluetooth е активиран или не. Забележка , други Bluetooth услуги се активират (от сиво до получер), когато потребителят активира Bluetooth.
най-сигурният конвертор на YouTube в mp3
Така че, функционалните изисквания говорят за конкретен резултат от системата, когато дадена задача се изпълнява върху тях от потребителя. От друга страна, нефункционалното изискване дава цялостното поведение на системата или нейния компонент, а не на функцията.
Видове функционални изисквания
Функционалните изисквания могат да включват следните компоненти, които могат да бъдат измерени като част от функционалното тестване:
# 1) Оперативна съвместимост: Изискването описва дали дадена софтуерна система е оперативно съвместима между различни системи.
Пример: За функционални изисквания на Bluetooth в автомобилната информационно-развлекателна система, когато потребителят сдвои Bluetooth-базиран Android-базиран смартфон към базирана на QNX информационно-развлекателна система, ние трябва да можем да прехвърлим телефонния указател към информационно-развлекателната система или да предаваме музика от нашето телефонно устройство към информационно-развлекателната система.
Така че оперативната съвместимост проверява дали комуникацията между двете различни устройства е възможна или не.
Друг пример е от системите за имейл услуги като Gmail. Gmail позволява импортиране на имейли от друг сървър за обмен на поща като Yahoo.com или Rediffmail.com. Това е възможно поради оперативната съвместимост между имейл сървърите.
# 2) Сигурност: Функционалният изискването описва аспекта на сигурността на софтуерните изисквания.
Пример: Услуги, базирани на Cyber Security в системата, базирана на ADAS съраунд изглед, която използва Controller Area Network (CAN), която защитава системата от заплахата за сигурността.
Друг пример е от сайта за социални мрежи Facebook . Данните на потребителя трябва да бъдат защитени и не трябва да бъдат изтичани от външни лица. Надяваме се, че този пример за Facebook дава по-широк обхват на сигурността на читателите поради скорошната честота на пробиви на данни във Facebook и последствията, с които се сблъсква Facebook.
# 3) Точност: Точността определя, че данните, въведени в системата, са правилно изчислени и използвани от системата и че изходът е правилен.
Пример: В контролната зона, когато стойността на CAN сигнала се предава през CAN шина от ECU (а именно единица ABS, HVAC единица, блок инструментален клъстер и т.н.), друг ECU ще може да идентифицира дали изпратените данни са верни или не чрез CRC проверка.
Друг пример може да бъде от решение за онлайн банкиране. Когато потребителят получи средства, получената сума трябва да бъде кредитирана точно по сметката и не се допуска промяна в точността.
# 4) Съответствие: Функционалните изисквания за съответствие потвърждават, че разработената система отговаря на индустриалните стандарти.
Пример: Дали функциите на Bluetooth профили (а именно аудио стрийминг чрез A2DP, Телефонно обаждане чрез HFP) са съвместими с версиите на профила за освобождаване на Bluetooth SIG.
Друг пример може да бъде тази на Apple Car play в автомобилната информационно-развлекателна система. Приложението в информационно-развлекателната система получава сертификат от Apple ако всички предпоставки, посочени в уебсайта на Apple, са изпълнени от устройства на Car Play на трети страни (в този случай инфотейнмънт).
Друг пример може да бъде от уеб-базирано приложение за системата за железопътни билети. Уебсайтът трябва да следва насоките за киберсигурност и да отговаря на световната мрежа по отношение на достъпността.
Пример за формуляр за изискване:
Вече видяхме какво е функционалното изискване с някои примери. Нека сега видим как би изглеждало функционално изискване, когато се интегрира в инструменти за управление на изисквания като IBM DOORS. Има няколко атрибута, които трябва да се вземат предвид, докато се документира функционално изискване в инструмента за управление на изискванията.
По-долу има няколко атрибута, които трябва да бъдат взети под внимание:
- Тип обект: Този атрибут обяснява кой раздел от документа за изискванията е част от този атрибут. Те могат да бъдат Заглавие, Обяснение, Изискване и др. Предимно раздел „Изискване“ се разглежда за изпълнението и тестването, докато разделите за заглавия и обяснения се използват като подкрепящи описания за изисквания за по-добро разбиране.
- Отговорно лице: Автор, който е документирал изискването в инструмента за управление на изискванията.
- Име на проект / система: Проектът, за който е приложимо изискването, например, „Информационно-развлекателни системи за XYZ OEM (Производител на оригинално оборудване) автомобилна компания или уеб приложение за ABC банково дружество с ограничена отговорност“.
- Номер на версията на изискването: Това поле / атрибут уведомява номера на версията на изискването, ако изискването е претърпяло множество модификации поради актуализации на клиенти или промени в системния дизайн.
- Идентификационен номер: Този атрибут споменава уникалния идентификатор на изискването. Идентификационният идентификатор се използва за лесно проследяване на изискванията в базата данни, както и за ефективно картографиране на изискванията в кода. Той може да се използва и за предоставяне на препратка към изискванията при регистриране на дефекти в инструментите за проследяване на грешки.
- Описание на изискването: Този атрибут е един от най-важните атрибути, които обясняват изискването. Четейки този атрибут, един инженер би могъл да разбере изискването.
- Състояние на изискването: Атрибутът на състоянието на изискването казва за състоянието на изискването в инструмента за управление на изискванията, т.е. дали е приет, задържан, отхвърлен или изтрит проектът.
- Коментари: Този атрибут предоставя на отговорното лице или мениджъра на изискванията възможност да документира всеки коментар относно изискването. Пример: възможен коментар за функционално изискване може да бъде „зависимост от софтуерен пакет на трета страна за прилагане на изискването“.
Снимка от DOORS
Извеждане на функционални изисквания от бизнес изискванията
Това вече е разгледано като част от раздела „ Извеждане на функционални изисквания от бизнес изискванията ' под Анализ на изискванията статия.
Бизнес изисквания срещу функционални изисквания
Тази разлика е слабо покрита в Анализ на изискванията статия. Ще се опитаме обаче подчертайте още няколко точки тук в таблицата по-долу:
Сл. Не. | Бизнес изисквания | Функционални изисквания |
---|---|---|
7 | Например, в системата за онлайн банкиране бизнес изискване би могло да бъде „Като потребител трябва да мога да получа извлечение за парични транзакции“. | Функционално изискване в тази система за онлайн банкиране може да бъде: „Когато потребителят предостави период от време в заявка за транзакция, този вход се използва от сървъра и уеб страницата се предоставя с необходимите данни за касови транзакции“. |
1 | Бизнес изискванията казват „какъв“ аспект на изискванията на клиента. Пример, Какво трябва да бъде видимо за потребителя, след като потребителят влезе. | Функционалните изисквания казват „как“ аспект на бизнес изискванията. Пример, Как уеб страницата трябва да показва страницата за вход на потребителя, когато потребителят се удостовери. |
две | Бизнес изискванията се идентифицират от бизнес анализаторите. | Функционалните изисквания се създават / извличат от разработчици / софтуерен архитект |
3 | Те наблягат на ползата за организацията и са свързани с бизнес целите. | Тяхната цел е изпълнение на изискванията на клиента. |
4 | Бизнес изискванията са от клиента. | Функционалните изисквания се извличат от изискванията на софтуера, което от своя страна се извлича от бизнес изискванията. |
5 | Бизнес изискванията не се тестват директно от софтуерните инженери. Те се тестват от клиента най-вече. | Функционалните изисквания се тестват от инженерите за тестване на софтуер и обикновено не се тестват от клиентите. |
6 | Изискването за бизнес е документ за изисквания на високо ниво. | Функционалното изискване е подробен документ за технически изисквания. |
Нефункционално изискване
Нефункционалното изискване казва за „каква да бъде системата“, а не „какво трябва да прави системата“ (функционално изискване). Те са извлечени най-вече от функционални изисквания въз основа на приноса от клиента и други заинтересовани страни. Детайлите за внедряване на нефункционални изисквания са документирани в документа Системна архитектура.
Нефункционалните изисквания обясняват качествените аспекти на системата, която трябва да се изгради, а именно. производителност, преносимост, използваемост и др. Нефункционалните изисквания, за разлика от функционалните изисквания, се прилагат постепенно във всяка система.
URPS (Употребяемост, надеждност, производителност и поддръжка) от ФУРПИ (Функционалност, използваемост, надеждност, производителност и поддръжка) атрибутите за качество, които се използват широко в ИТ индустрията за измерване на качеството на разработчик на софтуер, са обхванати от нефункционални изисквания. Освен това има и други атрибути на качеството (подробности в следващия раздел).
Уикипедия нарича нефункционалното изискване понякога като „несъвършенства“ поради наличието на различни качествени атрибути като преносимост и стабилност.
Видове нефункционални изисквания
Нефункционалните изисквания се състоят от подтипове по-долу (неизчерпателни):
# 1) Изпълнение:
Тип атрибут за изпълнение на нефункционално изискване измерва производителността на системата. Пример: В системата за съраунд изглед ADAS „изгледът на задната камера трябва да се покаже в рамките на 2 секунди след стартирането на запалването на автомобила“.
Друг пример ефективността може да бъде от информационно-развлекателни системи Навигационна система. „Когато потребителят премине към екрана за навигация и въведе дестинацията, маршрутът трябва да бъде изчислен в рамките на„ X “секунди“. Още едно пример от страницата за вход в уеб приложението. „Време, необходимо за зареждане на страницата на потребителския профил след влизане.“
Моля, не забравяйте, че измерването на производителността на системата се различава от измерването на натоварването. По време на тестването на натоварване зареждаме системния процесор и RAM и проверяваме производителността на системата. В случай на производителност, ние тестваме пропускателната способност на системата при нормални условия на натоварване / стрес.
# 2) Използваемост :
Използваемостта измерва използваемостта на разработваната софтуерна система.
Например , разработено е мобилно уеб приложение, което ви дава информация за водопроводчиците и наличността на електротехник във вашия район.
Входът за това приложение е пощенски код и радиус (в километри) от текущото ви местоположение. Но за да въведете тези данни, ако потребителят трябва да разглежда множество екрани и опцията за въвеждане на данни се показва в малки текстови полета, които не се виждат лесно от потребителя, тогава това приложение не е удобно за потребителя и следователно използваемостта на приложението ще бъде много ниско.
# 3) Поддържане :
Поддържането на софтуерна система е лекотата, с която системата може да се поддържа. Ако средното време между неизправностите (MTBF) е ниско или средното време за ремонт (MTTR) е високо за разработваната система, тогава поддръжката на системата се счита за ниска.
Поддържането често се измерва на ниво код, използвайки цикломатична сложност. Цикломатичната сложност казва, че колкото по-малък е кодът, толкова по-лесно е да се поддържа софтуерът.
Пример: Разработена е софтуерна система, която има голям брой мъртви кодове (кодове, които не се използват от други функции или модули), изключително сложна поради прекомерно използване на условие if / else, вложени цикли и т.н. или ако системата е огромна с работещи кодове в много милиони редове кодове и без подходящи коментари. Такава система е с ниска поддръжка.
Друг пример може да бъде от уеб страница за онлайн пазаруване. Ако на уебсайта има много външни връзки, така че потребителят може да има общ преглед на продукта (това, за да се спести памет), тогава поддръжката на този уебсайт е ниска. Това е така, защото, ако връзката към външна уеб страница се промени, тя трябва да бъде актуализирана и на уебсайта за онлайн пазаруване и това твърде често.
# 4) Надеждност :
Надеждността е друг аспект на наличността. Този атрибут за качество подчертава наличието на система при определени условия. Измерва се като MTBF точно като поддръжката.
Пример: Взаимно изключителни функции като камера за задно виждане и ремарке в системата за съраунд изглед ADAS трябва надеждно да работят в системата, без да се намесват помежду си. Когато потребителят извика функцията на ремаркето, задното виждане не трябва да пречи и обратно, тъй като и двете функции имат достъп до задната камера на автомобила.
Друг пример от онлайн системата за застрахователни искове. Когато потребителят започне отчитане на искове и след това качи съответни сметки за разходи, системата трябва да даде достатъчно време за завършване на качването и не трябва да отменя процеса на качване бързо.
# 5) Преносимост:
Преносимост означава способността на софтуерна система да работи в различна среда, ако основната зависима рамка остане същата.
Пример: Разработената софтуерна система / компонент в информационно-развлекателна система (а именно Bluetooth услуга или мултимедийна услуга) за производител на автомобилни автомобили трябва да позволи използването в друга информационно-развлекателна система с малка или никаква промяна в кода, въпреки че двете информационно-развлекателни системи са напълно различни .
Нека вземем друг пример от WhatsApp. Възможно е да инсталирате и използвате услугата за съобщения на IOS, Android, Windows, Tablet, Laptop и Phone.
# 6) Поддържане:
Сервизността на софтуерна система е способността на сервизен / технически експерт да инсталира софтуерната система в среда в реално време, да наблюдава системата, докато тя работи, да идентифицира всички технически проблеми в системата и да предостави решение за разрешаване на проблема.
Възможността за обслужване е възможна, ако системата е разработена, за да улесни обслужването.
Пример: Предоставяне на периодично изскачащо напомняне на потребителя за актуализация на софтуера, осигуряване на механизъм за регистриране / проследяване за отстраняване на грешки, автоматично възстановяване от повреда чрез механизъм за връщане (връщане на софтуерната система към предишното работно състояние).
qa въпроси и отговори за интервю за анализатор
Друг пример от Rediffmail. Когато имаше актуализация във версията на уеб-базирана пощенска услуга, системата позволи на потребителя да премине към по-нова версия на пощенската система, запазвайки по-старата непокътната за няколко месеца. Това подобрява и потребителското изживяване.
# 7) Адаптивност:
Адаптивността на дадена система се дефинира като способността на софтуерната система да се адаптира към промяна в среда без промяна в нейното поведение.
Пример: Антиблокиращата спирачна система в колата трябва да работи по стандарт при всякакви метеорологични условия (горещо или студено). Друг пример може да е тази на операционна система Android. Използва се в различни видове устройства, а именно. Смартфоните, таблетните компютри и информационно-развлекателните системи са изключително приспособими.
В допълнение към изброените по-горе 7 нефункционални изисквания имаме много други като:
Достъпност, архивиране, капацитет, съответствие, целостта на данните, задържане на данни, зависимост, внедряване, документация, трайност, ефективност, експлоатабилност, разширяемост, управление на неизправности, толерантност към грешки, оперативна съвместимост, модифицируемост, оперативност, поверителност, четливост, докладване, устойчивост, повторна употреба, Здравост, мащабируемост, стабилност, проверяемост, производителност, прозрачност, интегративност.
Покриването на всички тези нефункционални изисквания е извън обхвата на тази статия. Можете обаче да прочетете повече за тези типове нефункционални изисквания в Уикипедия.
Извеждане на нефункционални изисквания от функционални изисквания
Нефункционалните изисквания могат да бъдат извлечени по много начини, но най-добрият и най-изпитаният и изпитан начин е от функционалните изисквания.
Нека вземем примера от нашите информационно-развлекателни системи, които вече сме взели на няколко места в тази статия. Потребителят може да извършва много действия в системата за развлечения, а именно. сменете песента, сменете източника на песен от USB на FM или Bluetooth аудио, задайте дестинация за навигация, актуализирайте софтуера за инфотейнмънт чрез актуализация на софтуера и др.
# 1) Събиране на нефункционални изисквания:
Ще изброим задачите, изпълнявани от потребител, което е част от функционалните изисквания. След като действията на потребителя са отбелязани в диаграмата на случаите на използване на UML (всеки овал), ние ще започнем съответни въпроси (всеки правоъгълник) за действията на всеки потребител. Отговорите на тези въпроси ще дадат нашите нефункционални изисквания.
# 2) Категоризация на нефункционални изисквания:
Следващата стъпка е категоризирането на нефункционални изисквания, които сме идентифицирали чрез въпроси. На този етап можем да проверим възможния отговор и да категоризираме отговорите на възможни нефункционални категории или различни качества.
На изображението по-долу можете да видите възможните качествени атрибути, идентифицирани от отговорите.
Функционални Vs Нефункционални изисквания
Вече видяхме какви са функционалните и нефункционалните изисквания и как се извличат. Нека да разгледаме основните разлики между функционалните и нефункционалните изисквания.
Сл. не | Функционални изисквания (FR) | Нефункционални изисквания (NFR) |
---|---|---|
7 | Функционалните изисквания формират скелета на внедряването на софтуерна система | Нефункционалните изисквания допълват системата за SW, като помагат на функционалните изисквания да се слепват, като мускул. |
1 | Казват, какво трябва да направи една система. | Казват, каква система трябва да бъде. |
две | Те са подробно описани в документа за проектиране на системата. | Те са подробно описани в документа Системна архитектура. |
3 | Те говорят за поведението на функция или функция. | Те говорят за работното поведение на цяла система или компонент на системата, а не на определена функция. |
4 | Потребителят ще предаде вход и ще провери дали изходът е показан правилно. | Когато потребителят премине вход, NFR могат да отговорят на следните въпроси: i) Колко време е необходимо за показване на изхода? ii) Съответства ли изходът на времето? iii) Има ли други начини за предаване на входния параметър? iv) Колко лесно е да се предаде входният параметър? |
5 | В уеб приложението потребителят трябва да може да влезе чрез удостоверяване е FR | В едно уеб приложение колко време отнема влизане в уебсайта, външен вид и усещане на страницата за вход, лекота на използване на уеб страница и т.н. са част от NFR |
6 | Функционалните изисквания се извеждат първо от софтуерните изисквания. | Нефункционалните изисквания са получени от функционални изисквания. |
8 | Функционални изисквания могат да съществуват и без нефункционално изискване. | Нефункционалните изисквания не могат да съществуват без функционални изисквания. |
9 | Функционалното изискване дава конкретна информация за характеристика, Пример , Снимката на профила във Facebook трябва да се вижда при влизане. | Функционалното изискване може да има много атрибути на нефункционални изисквания. Пример, време за влизане (производителност), външен вид и усещане на страницата на профила (използваемост), брой потребители, които могат да влязат в даден момент (капацитет, производителност) |
10 | Извличането на функционални изисквания от изискванията на SW е възможно за почти всички бизнес изисквания | NFR често се пропускат да бъдат документирани, тъй като не се задават съответни въпроси относно FR. |
единадесет | Внедряването на функционално изискване обикновено се извършва в една компилация на софтуера. | NFR се прилагат през целия жизнен цикъл на проекта, докато се постигне желаното поведение. |
12 | Те са видими най-вече за клиента. | Те обикновено не се виждат от клиента, но могат да бъдат изпитани в дългосрочен план. Пример, Използваемостта, производителността и т.н. могат да бъдат изпитани само в дългосрочен план, но изобщо не могат да бъдат видими. |
Заключение
Изискванията представляват основния градивен елемент за разработване на всякаква софтуерна система. Възможно е да се изгради система с функционални изисквания, но нейните способности не могат да бъдат определени или измерени. Като каза това, много е важно да имаме качествени функционални изисквания, произтичащи от бизнес изискване, за да имаме висококачествена работеща софтуерна система.
Следователно функционалните изисквания дават посоката на внедряване на софтуерна система, но нефункционалните изисквания определят качеството на изпълнение, което крайните потребители ще изпитват.
Препоръчително четене
- Как да тествате спецификацията на софтуерните изисквания (SRS)?
- Функционално тестване срещу нефункционално тестване
- Как да тествате приложение без изисквания?
- Какво представлява анализ и събиране на изисквания в SDLC?
- 5 смъртоносни грешки в управлението на изискванията и как да ги преодолеете
- Характеристики на функционалните изисквания и нефункционалните изисквания
- Как да създадете матрица за проследяване на изискванията (RTM): Пример и шаблон за пример
- Топ 20+ Инструменти за управление на най-добрите изисквания (Пълният списък)