Функціональна чи нефункціональна вимога?

Мені цікаво щодо функціональних чи нефункціональних вимог. Я знайшов багато різних визначень для цих термінів, і я не можу віднести частину своїх вимог до належної категорії.

Мене цікавить вимоги, які не пов'язані з якоюсь дією або мають деякі додаткові умови, наприклад:

1. У списку вибраних пристроїв пристрій можна повторити.
2. База даних повинна містити не менше 100 елементів
3. Валюта деякої вартості повинна бути в доларах США.
4. Пристрій повинен мати ім'я та значення споживання електроенергії у Вт.

є ці вимоги функціональними чи нефункціональними?

Функціональні вимоги визначають, що робитиме система чи додаток, зокрема в контексті зовнішньої взаємодії (з користувачем або з іншою системою).

Під час розміщення нового замовлення система повинна відображати загальну вартість та вимагати підтвердження від користувача.Це функціональна вимога; він описує функцію системи.

Звертатися до Детальнішу інформацію Вікіпедії: Функціональна вимога .

Нефункціональні вимоги - це будь-які вимоги, які не описують поведінку вводу / виводу системи. Зауважте, що ми все ще говоримо про вимоги , а не про деталі щодо впровадження , тому лише тому, що ми використовуємо фразу "нефункціональна", не означає, що в цьому розділі нічого не потрібно чесно грати.

Найпоширеніші типи нефункціональних вимог, які ви побачите, стосуються роботи системи (доступність, безперервність, DR), продуктивності (пропускна здатність, затримка, ємність зберігання) та безпеки (автентифікація, авторизація, аудит, конфіденційність).

Це все наскрізні проблеми, які впливають на кожну "особливість", але насправді самі не є функціями; вони більше схожі на метадані функції, допомагаючи описати не лише те, чи система робить те, що належить, але і наскільки добре це робить. Не приймайте цю аналогію занадто далеко - це лише аналогія.

Нефункціональні вимоги не є суб'єктивними чи рукотворними, всупереч тому, що деякі люди тут, здається, пропонують. Насправді, вони повинні дійсно мати жорсткий метричний прив'язуватися до них (тобто час відгуку не більше 100 мс). Вимоги НФ також не відповідають деталізацією щодо впровадження або завданнями, такими як "оновлення рамки ORM" - немає поняття, де хто б не взяв таку думку.

Детальніше у Вікіпедії: нефункціональна вимога .

Щоб вирішити конкретні приклади у запитанні:

1. У списку вибраних пристроїв пристрій можна повторити.

   • Очевидно функціональна вимога. Описує, як виглядає вихід системи.

2. База даних повинна містити не менше 100 елементів

   • Звучить як правило бізнесу, тому також функціональна вимога. Однак це видається неповним. У чому причина цього правила? Що буде / має відбутися, якщо база даних містить менше 100 елементів?

3. Валюта деякої вартості повинна бути в доларах США.

   • Функціональна вимога, але насправді не правильно викладена. Більш корисним було б формулювання: Система повинна підтримувати одну валюту (USD). Очевидно, що це було б внесено зміни, якщо потрібно підтримати більше однієї валюти, і тоді вимога повинна містити інформацію про конвертацію валюти тощо.

4. Пристрій повинен мати ім'я та значення споживання електроенергії у Вт.

   • Насправді не будь-яка вимога, це більше схоже на технічні умови. Буде заявлена ​​функціональна вимога, оскільки припускається, що номінальна потужність у Ватах. Якщо є декілька UOM, то, як і щодо валюти, функціональні вимоги повинні мати розділи про конверсії одиниць, де / як вони налаштовані тощо (якщо це застосовується).

Адже Aaronaught вже є чудовою відповіддю, але оскільки були видалені інші відповіді, видалені зараз, які були абсолютно помилковими щодо того, що таке нефункціональна вимога, я думаю, було б корисно додати кілька пояснень, щоб уникнути помилок щодо того, що нефункціональна вимога є.

Нефункціональна вимога - це "якість або властивість, яку повинен мати виріб" ¹. Джеймс Тейлор каже, що нефункціональна вимога "[...] є [тим не менше] вимогою, і вона важлива для замовника - іноді навіть важливіша, ніж функціональна вимога" . Потім він наводить два приклади: логотип виробу та точність та надійність обладнання. Ці обидва приклади дуже добре показують, що:

• Нефункціональні вимоги не є маркетинговим рухом, як: "Інтернет є важливим в наш час, і ми хочемо мати веб-сайт".
• Нефункціональні вимоги стосуються покупців, оскільки вони можуть сильно вплинути на їх продуктивність та можливість самостійно використовувати продукт.
• Нефункціональні вимоги є абсолютно об'єктивними.

Останній пункт є суттєвим. Якщо вимога є суб'єктивною, вона не має нічого спільного в списку вимог. Неможливо побудувати перевірки валідації з чогось суб'єктивного . Єдиною метою переліку вимог є перерахування неоднозначних очікувань замовника. "Я хочу, щоб ця площа була червоною" - це вимога. "Я хочу, щоб цей квадрат мав приємний колір" - це бажання, яке потребує пояснення.

Пам'ятайте, що перелік вимог схожий на договір (і в більшості випадків є частиною договору). Він підписується замовником та розробницькою компанією, а у випадку судового розгляду він буде юридично використаний для визначення того, чи правильно ви виконали свою роботу. Що робити, якщо я замовляю вам програмний продукт, вкажіть, що "продукт повинен бути чудовим", і відмовлятись платити, коли продукт зроблений, адже для мене те, що ви насправді зробили, не є чудовим продуктом?

Отже, подивимося кілька прикладів.

  1. Програмний продукт реагує на кінцевого користувача.

Це не вимога. Не функціонал. Не нефункціональний. Це просто не вимога. Зовсім. Він має нульове значення. Ви не можете перевірити, чи відповідає програмна система цій вимозі під час перевірки перевірки. Ні ви - відділ контролю якості, ані замовник.

  2. Перезавантаження статистики користувача виконує 90% часу нижче 100 мс. при випробуванні на машині з робочими характеристиками, зазначеними в додатку G, частина 2 та завантаженням нижче 10% для процесора, нижче 50% для оперативної пам'яті та відсутність активних операцій з R / W на диску.

Це вимога. Якщо додаток G частина 2 є досить точним, я можу взяти машину з аналогічним обладнанням та виконати перевірку перевірки у відділі якості, і я завжди отримаю двійковий результат: пройшов чи не вдався.

Це функціональна вимога? Ні. У ньому не вказано, що повинна робити система. Раніше, ймовірно, були функціональні вимоги, вказуючи, що програмне забезпечення повинне мати можливість перезавантажити статистику користувачів.

Це нефункціональна вимога? Це є. Він визначає властивість, яку повинен мати виріб, тобто максимальний / середній час відгуку з урахуванням порогу відсотка.

  3. Заява написана на C #.

Це вимога? Ми насправді не знаємо без контексту. Це може бути бажання головного розробника, який хоче, вставивши цю вимогу, уникнути подальшої дискусії з колегами щодо мови, якою користуватися. Це також може бути вимога, заснована на апаратному / програмному забезпеченні, застарілих елементах або елементах сумісності. Ми не знаємо.

  4. Кодова база продукту C # відповідає мінімальним рекомендованим правилам Microsoft та Правилам глобалізації Microsoft.

Це дивна річ. Особисто я б не назвав це вимогою, а виклав би її в окремий документ із зазначенням стандартів та найкращої практики.

  5. У головному вікні програми є синя (# 00f) рамка 10 пікселів із рожевими (#fcc) заповненими колами, причому ці кола розміщуються у внутрішньому краї кордону та мають діаметр 3 пікселя, відокремлені один від одного 20 пікселями.

Це вимога, і нефункціональна. Він визначає те, що ми можемо перевірити під час перевірки валідації, і вказує властивість продукту, а не те, що продукт призначений.

  6. Система відстеження автомобіля вимірює швидкість з точністю ± 0,016 миль / год.

Також нефункціональна вимога. Це дає вимірюваний поріг точності системи. Він не говорить про те, що система повинна робити, але розповідає, наскільки точно вона робить свою роботу. Але чекати? Це говорить, що система відстеження автомобіля вимірює швидкість, чи не так? Тож це також функціональна вимога? Ну, ні, оскільки ми акцентуємо увагу на точності вимірювання, а не на тому, що вимірювання зроблено.

  7. Система відстеження транспортного засобу вимірює швидкість руху транспортного засобу.

Тепер це функціональна вимога. Він не вказує, як працює система, а що робить. Завдяки функціональним вимогам ми могли б дізнатися, що система відстеження транспортного засобу вимірює швидкість, потужність акумулятора, тиск. Я не знаю, що і якщо світло чи увімкнено.

  8. Сторінки веб-сайту займають 850 мс. завантажувати.

Це не вимога. Намагається бути одним, але абсолютно недійсним. Як би ви активували це? Які сторінки? Усі? Тестується через локальну мережу 1Gbps на чотирьохядерній клієнтській машині та восьмиядерному сервері з SSD, що використовується на 2%, або через модем старого і хитрого ноутбука, коли веб-сайт розміщений на невеликому сервері, який використовується на 99% ? Що означає «завантажувати»? Чи означає це завантаження сторінки? Завантажити та відобразити його? Надіслати запит POST з деякими великими даними, потім завантажити відповідь і відобразити його?

На закінчення, нефункціональна вимога - це завжди вимога, яка означає, що вона описує щось, що є цілком об'єктивним і може бути перевірено за допомогою автоматизованого або ручного тестування перевірки, але замість того, щоб розповідати, що робить система, це пояснює, як система щось робить чи як сама система .

^{¹ Управління проектами інформаційних технологій: застосування стратегій управління проектами до програмних, апаратних та інтеграційних ініціатив, Джеймс Тейлор, ISBN: 0814408117.}

Функціональне вимога описує результат взаємодії з системою (що система робить в даній ситуації), в той час як нефункціональні вимоги , як правило , відносяться до специфіки продуктивності, потужності, час відгуку, і т.д. ... речі , які не уявляють функціональність, A процес у системі або результат взаємодії.

Сказавши це, нефункціональна вимога, яку ви описуєте, насправді є функціональною вимогою з технічною специфікацією (що насправді зробить це поганою вимогою). Прикладом нефункціональної вимоги до вашої справи є щось подібне:

- Користувальницький інтерфейс не повинен бути заблокований під час роботи анімації з кістки.

Вимоги користувачів, як правило, є специфічними вимогами до інтерфейсу користувача, які залежно від контексту можуть бути функціональними або нефункціональними, тоді як системні вимоги (наприклад, одночасний користувальницький потенціал) зазвичай більшість часу нефункціональні.

Просто додати до деяких існуючих хороших відповідей, що нефункціональні вимоги іноді називають «ілюзіями» - якостями, якими система повинна володіти додатково до своєї простої функціональності. "недоліки" включають доступність, зручність, безпеку, гнучкість - і навіть більш суб'єктивну естетику.

Деякі з них дуже складно визначити та оцінити. Проте вони мають значення. Якщо ви підписуєтесь на них за контрактом, то вам захочеться уникати безглуздих рукохвильових версій, наприклад "Система повинна бути захищеною". Проблема спроби зменшити такі вимоги полягає в тому, що люди прагнуть тяжіти до речей, що легко піддаються вимірюванню, а не до речей, які мають значення (а вимоги цілком можуть бути написані людьми, які не мають підстав для відповідних спеціальностей ). Кінцевим підсумком є ​​те, що ви, як правило, працюєте із системами, які не є ні безпечними, не зручними, ні гнучкими (доступність не так складна визначити та виміряти, хоча це все ще викликає велику кількість головних болів).

Тут існують культурні відмінності між людьми, які займаються контрактами та офіційними матеріалами, та людьми, які займаються більш загальним аналізом, архітектурою, дослідженнями тощо. Неясна вимога, що хвилюється рукою, все ще є вимогою , що стосується останнього, тому що це виражає речі, які мають значення для замовника, навіть якщо вони повністю співчувають контрагентам, що це не є корисною контрактною вимогою, поки вона не буде детально досліджена та ретельно прибита.

Останнє питання - якщо ви ще не можете (ще) придумати об'єктивну міру "неправдивості", це не означає, що клієнт цього не потребує. Неясне! = Зайве. Однак це може означати, що нам потрібно розробити кращі способи вимірювання таких речей, запроваджувати та уточнювати нефункціональні вимоги поступово, або укладати контракти способами (Agile тощо), які можуть працювати без попередніх об'єктивних заходів для всього.

Ці коментарі є дуже хорошими, але вони є надто приготованими і не пропонують чіткого шаблону для роботи. Чи не було б зрозуміло вказати це як:

На мою думку, функціональна вимога - це те, що відчуває користувач під час використання програми. Це вимога повинна бути виконана, коли розробник намагається реалізувати це з нуля, вносити вдосконалення або модифікації. Наприклад: користувач повинен увійти. Скажімо, якщо ви також додасте новий спосіб запуску програми через командний рядок, тоді користувач все одно повинен увійти.

Нефункціональна вимога трапляється під капотом. Користувач цього не знає, але він повинен бути там, проте він реалізований. Наприклад: Додаток слід розробити на C #. Якщо він розроблений будь-якою іншою мовою, користувач не помітить. Але це може бути вимогою, оскільки вона базується на існуючому коді. Іншим прикладом може бути те, що він повинен бути встановлений на певному сервері. Користувач не помітить переміщувані сервери, які не помітять.

Функціональна чи нефункціональна? Я б не сказав жодного. Більшість, якщо не всі перелічені приклади, схожі на мене для ділових правил (із зазначенням обмежень, пов’язаних з процесом, та правил прийняття рішень, які повинні дотримуватися системні процеси).

Вони щось, про що багато інженерів забувають або не знають про них, оскільки правила ведення бізнесу, як правило, збираються в рамках аналізу бізнесу (і часто вбудовані в технічні характеристики вимог, а не з посилань назовні).

Функціональна вимога, як правило, є те, що система може чи хоче робити. Він може бути виражений у результаті дії (негативного результату). Невитратна вимога - це те, про що клієнт / кінцевий користувач не піклується і не впливає на результат - наприклад
- Windows матиме синю облямівку з рожевими крапками. - Програма буде написана на Java
- Все, що стосується стандартів, методів та процесів кодування.

Будьте попереджені, хоча нефункціональні вимоги можуть бути перетворені на функціональні вимоги клієнтів. Приклади можуть бути - програма буде написана в Ерланге, оскільки замовник прочитав статтю журналу і хоче, щоб вона була написана в Ерланге. - Програма повинна використовувати DB 2. оскільки замовник збирається запускати її на своїх існуючих системах DB 2, має багаторічний досвід роботи та ІТ-команду, знайому з цією платформою.
- Вихідний код повинен відповідати всім рекомендаціям MISRA.

Підсумовуючи це - якщо клієнт про це піклується, це функціональна вимога, інакше це нефункціональна вимога або, можливо, навіть не вимога.

я думаю, що функціональні вимоги є необхідною річчю, що описує систему та її поведінку, але нефункціональні вимоги не потрібні системі і не зібрані під час переговорів про проектування системи - це лише вихід із системи, такий як якість покриття швидкості , безпека, ремонтопридатність тощо з побудованої системи.