features functional requirements
Цей посібник пояснює типи, особливості, порівняння функціональних та нефункціональних вимог та бізнес проти функціональних вимог на прикладах:
Функціональні вимоги визначають, що повинна робити програмна система. Він визначає функцію програмної системи або її модуля. Функціональність вимірюється як набір входів в систему, що перевіряється, на виході з системи.
Реалізація функціональних вимог в системі планується на етапі проектування системи, тоді як, у випадку нефункціональних вимог, це планується в документі Архітектура системи. Функціональна вимога підтримує генерування нефункціональних вимог.
Що ви дізнаєтесь:
Функціональні вимоги та нефункціональні вимоги
Функціональні вимоги
Давайте розберемося, що таке функціональні вимоги за допомогою прикладів -
Приклад: У автомобільному проекті ADAS функціональною вимогою системи об'ємного огляду може бути 'Задня камера повинна виявляти загрозу або об'єкт'. Нефункціональними вимогами тут може бути «як швидко повинно відображатися попередження для користувача, коли датчики камери виявляють загрозу».
Візьміть інший приклад проекту Інформаційно-розважальні системи. Користувач вмикає тут Bluetooth через HMI і перевіряє, чи ввімкнено Bluetooth. Примітка , інші служби Bluetooth вмикаються (від сірого до напівжирного), коли користувач вмикає Bluetooth.
як відкрити файл eps на ПК -
Отже, функціональні вимоги говорять про конкретний результат системи, коли користувач виконує над ними завдання. З іншого боку, нефункціональна вимога надає загальну поведінку системи або її компонента, а не функцію.
Типи функціональних вимог
Функціональні вимоги можуть включати такі компоненти, які можна виміряти в рамках функціонального тестування:
# 1) Сумісність: Вимога описує, чи програмна система сумісна з різними системами.
Приклад: Для функціональних вимог Bluetooth в автомобільній інформаційно-розважальній системі, коли користувач поєднує смартфон на базі Android із підтримкою Bluetooth та інформаційно-розважальну систему на базі QNX, ми повинні мати можливість перенести телефонну книгу в інформаційно-розважальну систему або передавати музику з нашого телефонного пристрою в інформаційно-розважальну систему.
Тож взаємодія перевіряє, чи можливий зв’язок між двома різними пристроями.
Інший приклад від систем електронної пошти, таких як Gmail. Gmail дозволяє імпортувати електронні листи з іншого сервера обміну поштою, наприклад Yahoo.com або Rediffmail.com. Це можливо завдяки взаємодії між серверами електронної пошти.
# 2) Безпека: Функціональний вимога описує аспект безпеки вимог до програмного забезпечення.
Приклад: Послуги Cyber Security в системі камер об'ємного огляду ADAS, що використовує контрольну мережу (CAN), яка захищає систему від загрози безпеці.
Інший приклад від сайту соціальних мереж Facebook . Дані користувача повинні бути в безпеці та не повинні передаватися стороннім особам. Ми сподіваємось, що цей приклад Facebook надає ширшу сферу безпеки читачам через нещодавню частоту порушення даних у Facebook та наслідки, з якими стикається Facebook.
# 3) Точність: Точність визначає, що дані, що вводяться в систему, правильно обчислюються та використовуються системою, і що вихідні дані є правильними.
Приклад: У мережі контролера, коли значення сигналу CAN передається через шину CAN за допомогою ЕБУ (а саме: блок ABS, блок HVAC, блок клавіатури тощо), інший ЕБУ зможе визначити, чи надіслані дані правильні чи ні через перевірку CRC.
Інший приклад може бути з рішення Інтернет-банкінгу. Коли користувач отримує кошти, отримана сума повинна бути точно зарахована на рахунок, і не допускається жодної зміни точності.
# 4) Відповідність: Функціональні вимоги щодо відповідності підтверджують відповідність розробленої системи промисловим стандартам.
Приклад: Чи відповідають функції профілів Bluetooth (зокрема, потокове передавання аудіо через A2DP, телефонний дзвінок через HFP) версіям профілю випуску Bluetooth SIG.
Інший приклад може бути таким, як Apple Car грати в інформаційно-розважальній системі Car. Додаток в інформаційно-розважальному комплексі отримує сертифікат від Яблуко якщо всі передумови, зазначені на веб-сайті Apple, виконуються сторонніми пристроями Car Play (в даному випадку - інформаційно-розважальним).
Інший приклад може бути з веб-додатку для системи залізничних квитків. Веб-сайт повинен відповідати інструкціям з кібербезпеки та відповідати Всесвітній павутині з точки зору доступності.
Приклад форми вимоги:
Ми вже бачили, що таке функціональна вимога, на деяких прикладах. Давайте тепер подивимось, як би виглядала функціональна вимога, інтегрована до таких інструментів управління вимогами, як IBM DOORS. Існує декілька атрибутів, які слід враховувати, документуючи функціональну вимогу в інструменті управління вимогами.
Нижче наведено кілька атрибутів, які слід взяти до уваги:
- Тип об'єкта: Цей атрибут пояснює, який розділ документа про вимоги є частиною цього атрибута. Це можуть бути заголовки, пояснення, вимоги тощо. Здебільшого розділ „Вимога” розглядається для впровадження та тестування, тоді як розділи заголовка та пояснення використовуються як допоміжні описи вимог для кращого розуміння.
- Відповідальна особа: Автор, який задокументував вимогу в інструменті управління вимогами.
- Назва проекту / системи: Проект, до якого застосовна вимога, наприклад, «Інформаційно-розважальні системи для XYZ OEM (виробник оригінального обладнання), автомобільна компанія або веб-додаток для банківської компанії з обмеженою відповідальністю ABC».
- Номер версії вимоги: Це поле / атрибут повідомляє номер версії вимоги, якщо вимога зазнала численних модифікацій через оновлення клієнта або зміни в дизайні системи.
- Ідентифікатор вимоги: Цей атрибут згадує унікальний ідентифікатор вимоги. Ідентифікатор вимоги використовується для легкого відстеження вимог у базі даних, а також для ефективного відображення вимог у коді. Він також може використовуватися для посилання на вимоги під час реєстрації дефектів в засобах відстеження помилок.
- Опис вимоги: Цей атрибут є одним з найважливіших атрибутів, що пояснюють вимогу. Читаючи цей атрибут, інженер зміг би зрозуміти вимогу.
- Статус вимоги: Атрибут статусу вимоги говорить про статус вимоги в інструменті управління вимогами, тобто прийнятий, призупинений, відхилений чи видалений проект.
- Коментарі: Цей атрибут надає Відповідальній особі або менеджеру вимог можливість задокументувати будь-який коментар щодо вимоги. Приклад: можливим коментарем щодо функціональної вимоги може бути 'залежність від стороннього програмного пакету для реалізації вимоги'.
Знімок із DOORS
Виведення функціональних вимог із бізнес-вимог
Це вже висвітлено в рамках розділу “ Виведення функціональних вимог із вимог бізнесу ' під Аналіз вимог статті.
Бізнес-вимоги проти функціональних вимог
Ця різниця вільно висвітлена в Аналіз вимог статті. Однак ми спробуємо виділіть ще кілька пунктів у таблиці нижче:
| Сл. Ні. | Вимоги до бізнесу | Функціональні вимоги |
|---|---|---|
| 7 | Наприклад, в системі онлайн-банкінгу бізнес-вимогою може бути: «Як користувач я повинен мати можливість отримати виписку з готівкових операцій». | Функціональною вимогою в цій системі онлайн-банкінгу може бути: «Коли користувач вказує діапазон дат у запиті на транзакцію, цим входом користується Сервер, а веб-сторінці надаються необхідні дані про касові операції». |
| 1 | Вимоги бізнесу говорять про «який» аспект вимог замовника. Приклад, Що має бути видимим для користувача після входу користувача. | Функціональні вимоги говорять про «аспект» бізнес-вимог. Приклад, Як веб-сторінка повинна відображати сторінку входу користувача під час автентифікації користувача. |
| два | Бізнес-вимоги визначаються бізнес-аналітиками. | Функціональні вимоги створюються / виводяться розробниками / архітектором програмного забезпечення |
| 3 | Вони наголошують на вигоді для організації та пов’язані з бізнес-цілями. | Їх метою є виконання вимог замовника. |
| 4 | Бізнес-вимоги замовника. | Функціональні вимоги походять від вимог до програмного забезпечення, що, в свою чергу, походить від вимог бізнесу. |
| 5 | Вимоги бізнесу не перевіряються безпосередньо інженерами-програмістами. Вони переважно перевіряються замовником. | Функціональні вимоги перевіряються інженерами з тестування програмного забезпечення та, як правило, не перевіряються замовниками. |
| 6 | Вимога бізнесу - це документ високого рівня. | Функціональна вимога - це детальний документ про технічні вимоги. |
Нефункціональна вимога
Нефункціональна вимога говорить про „якою повинна бути система”, а не „що повинна робити система” (функціональна вимога). Вони здебільшого походять від функціональних вимог, заснованих на вкладі замовника та інших зацікавлених сторін. Деталі реалізації нефункціональних вимог задокументовані в документі Архітектура системи.
Нефункціональні вимоги пояснюють якісні аспекти системи, що будується, а саме. продуктивність, портативність, зручність використання і т. д. Нефункціональні вимоги, на відміну від функціональних вимог, впроваджуються поступово в будь-якій системі.
URPS (Юзабіліті, надійність, продуктивність і підтримка) від ФУРПСИ (Функціональність, зручність, надійність, продуктивність та підтримка) атрибути якості, які широко використовуються в ІТ-галузі для вимірювання якості розробника програмного забезпечення, охоплюються нефункціональними вимогами. Крім того, є й інші ознаки якості (подробиці в наступному розділі).
Вікіпедія іноді називає нефункціональну вимогу „незрозумілістю” через наявність різних атрибутів якості, таких як портативність та стабільність.
Типи нефункціональних вимог
До нефункціональних вимог належать наступні підтипи (невичерпні):
# 1) Продуктивність:
Тип атрибута продуктивності нефункціональної вимоги вимірює продуктивність системи. Приклад: У системі оточення ADAS, 'вигляд задньої камери повинен відображатися протягом 2 секунд після запуску запалювання автомобіля'.
Інший приклад продуктивність може бути від інформаційно-розважальних систем Навігаційна система. “Коли користувач переходить на екран навігації та вводить пункт призначення, маршрут слід розрахувати протягом“ X ”секунд”. Ще один приклад зі сторінки входу до веб-програми. 'Час, необхідний для завантаження сторінки профілю користувача після входу в систему.'
Пам'ятайте, що вимірювання продуктивності системи відрізняється від вимірювання навантаження. Під час тестування навантаження ми завантажуємо системний процесор і оперативну пам’ять і перевіряємо пропускну здатність системи. У випадку продуктивності ми перевіряємо пропускну здатність системи в нормальних умовах навантаження / напруги.
# 2) Юзабіліті :
Юзабіліті вимірює юзабіліті програмної системи, що розробляється.
Наприклад , розроблено мобільний веб-додаток, який надає інформацію про сантехніків та наявність електриків у вашому районі.
Даними для цього додатка є поштовий індекс та радіус (у кілометрах) від вашого поточного місцезнаходження. Але для введення цих даних, якщо користувачеві доводиться переглядати кілька екранів, а опція введення даних відображається в невеликих текстових полях, які користувач не легко бачить, тоді ця програма не зручна для користувача, а отже, зручність використання програми буде дуже низький.
# 3) Технічне обслуговування :
Ремонтопридатність програмної системи - це легкість підтримки системи. Якщо середній час між відмовами (MTBF) низький або середній час до ремонту (MTTR) високий для системи, що розробляється, то ремонтопридатність системи вважається низькою.
Ремонтопридатність часто вимірюється на рівні коду, використовуючи цикломатичну складність. Цикломатична складність говорить, що чим менше складний код, тим простіше підтримувати програмне забезпечення.
Приклад: Розроблена програмна система, яка має велику кількість мертвих кодів (коди, що не використовуються іншими функціями або модулями), дуже складна через надмірне використання умови if / else, вкладених циклів тощо, або якщо система величезна із запущеними кодами на багато мільйонів рядків кодів і без належних коментарів. Така система має низьку ремонтопридатність.
модель розвитку життєвого циклу водоспад
Інший приклад може бути веб-сторінка Інтернет-магазину. Якщо на веб-сайті багато зовнішніх посилань, щоб користувач міг мати огляд товару (це для економії пам’яті), тоді ремонтопридатність цього веб-сайту є низькою. Це пов’язано з тим, що, якщо посилання на зовнішню веб-сторінку змінюється, її також слід оновлювати на веб-сайті Інтернет-магазину, і це занадто часто.
# 4) Надійність :
Надійність - ще один аспект доступності. Цей атрибут якості підкреслює доступність системи за певних умов. Він вимірюється як MTBF, як і ремонтопридатність.
Приклад: Взаємовиключні функції, такі як камера заднього огляду та причіп в системі камер зовнішнього вигляду ADAS, повинні надійно працювати в системі без будь-яких перешкод один одному. Коли користувач викликає функцію причепа, заднє огляд не повинно заважати, і навпаки, оскільки обидві функції мають доступ до задньої камери автомобіля.
Інший приклад з онлайн-системи страхових відшкодувань. Коли користувач починає звітувати про претензії, а потім завантажує відповідні рахунки за витрати, система повинна дати достатньо часу для завершення завантаження та не повинна швидко скасовувати процес завантаження.
# 5) Переносимість:
Переносимість означає здатність програмної системи працювати в іншому середовищі, якщо основний залежний фреймворк залишається незмінним.
Приклад: Розроблена програмна система / компонент в інформаційно-розважальній системі (а саме послуга Bluetooth або мультимедійна послуга) для виробника автомобільних автомобілів повинна дозволяти використовуватись в іншій інформаційно-розважальній системі з незначними або відсутніми змінами в коді, хоча дві інформаційно-розважальні системи абсолютно різні .
Візьмемо інший приклад від WhatsApp. Можна встановити та використовувати службу обміну повідомленнями на iOS, Android, Windows, планшетах, ноутбуках та телефонах.
# 6) Підтримка:
Справність програмної системи - це здатність сервісного / технічного експерта встановлювати програмну систему в реальному часі, контролювати систему під час її роботи, виявляти будь-які технічні проблеми в системі та надавати рішення для вирішення проблеми.
Працездатність можлива, якщо система розроблена для полегшення справності.
Приклад: Надання періодичного спливаючого нагадування користувачеві для оновлення програмного забезпечення, забезпечення механізму реєстрації / трасування для налагодження проблем, автоматичне відновлення після відмови за допомогою механізму відкоту (повернення програмної системи до попереднього робочого стану).
Інший приклад від Rediffmail. Коли відбулось оновлення версії веб-служби розсилки, система дозволила користувачеві перейти на нову версію поштової системи, зберігаючи стару цілою протягом декількох місяців. Це також покращує взаємодію з користувачем.
# 7) Адаптованість:
Адаптованість системи визначається як здатність програмної системи пристосовуватися до змін у середовищі без будь-яких змін у її поведінці.
Приклад: Антиблокувальна гальмівна система в автомобілі повинна працювати в стандартному режимі за будь-яких погодних умов (жарких або холодних). Інший приклад може бути операційною системою Android. Він використовується в різних типах пристроїв, а саме. Смартфони, планшетні комп’ютери та інформаційно-розважальні системи є дуже пристосованими.
На додаток до 7 перелічених вище нефункціональних вимог, ми маємо ще багато таких, як:
Доступність, резервне копіювання, ємність, відповідність, цілісність даних, збереження даних, залежність, розгортання, документація, довговічність, ефективність, експлуатаційність, розширюваність, управління відмовами, відмовостійкість, сумісність, модифікація, працездатність, конфіденційність, читабельність, звітування, стійкість, повторне використання, Надійність, масштабованість, стабільність, перевіряність, пропускна здатність, прозорість, інтегрованість.
Висвітлення всіх цих нефункціональних вимог виходить за рамки цієї статті. Однак ви можете прочитати більше про ці типи функціональних вимог у Вікіпедія.
Виведення нефункціональних вимог із функціональних вимог
Нефункціональні вимоги можуть бути отримані різними способами, але найкращий і найбільш перевірений та перевірений спосіб - це функціональні вимоги.
Візьмемо приклад з наших інформаційно-розважальних систем, який ми вже брали в кількох місцях у цій статті. Користувач може виконувати багато дій з інформаційно-розважальною системою, а саме: змінити пісню, змінити джерело пісні з USB на FM або аудіо Bluetooth, встановити пункт призначення навігації, оновити інформаційно-розважальне програмне забезпечення за допомогою оновлення програмного забезпечення тощо.
# 1) Збір нефункціональних вимог:
Ми перелічимо завдання, які виконує користувач, що є частиною функціональних вимог. Після того, як дії користувача зазначені у схемі випадків використання UML (кожен овал), ми почнемо відповідні запитання (кожен прямокутник) щодо дій кожного користувача. Відповіді на ці запитання дадуть наші нефункціональні вимоги.
# 2) Категоризація нефункціональних вимог:
Наступним кроком є категоризація нефункціональних вимог, які ми визначили за допомогою запитань. На цьому етапі ми можемо перевірити можливу відповідь і класифікувати відповіді на можливі нефункціональні категорії чи різні якості.
На зображенні нижче ви можете побачити можливі ознаки якості, визначені з відповідей.
Функціональні проти нефункціональних вимог
Ми вже бачили, що таке функціональні та нефункціональні вимоги та як вони виведені. Давайте розглянемо основні відмінності між функціональними та нефункціональними вимогами.
| Сл. ні | Функціональні вимоги (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+ найкращих інструментів управління вимогами (повний список)