Чому турбувати розмежування функціональних та нефункціональних вимог?

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

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

Явне розділення вимог спростить проектування правильної системи.

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

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

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

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

Ентоні Латтанзе в архітектурних інтенсивних системах програмного забезпечення: Посібник практиків дає практичний огляд архітектурних драйверів і чому до них слід ставитися інакше, набагато вичерпніше, ніж моє резюме тут.

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

Тим не менш, є кілька причин розділяти дві категорії вимог:

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

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

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

Версіювання Якщо ви знаходитесь у корпоративному середовищі з великою кількістю «стандартів» - ви можете написати специфічні користувальницькі інтерфейси або захисні документи (щоб назвати пару) документів, які можуть бути використані. Таким чином, ви можете записати в програму конкретні вимоги (переважно функціональні вимоги): "Програма повинна дотримуватися V2.3 вимог безпеки, визначених у XYZ-Company-SecReq-DocumnentNamingStandard.docx".

Чому турбувати розмежування функціональних та нефункціональних вимог?

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

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

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

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

Як правило, ви категоризуєте вимоги, щоб допомогти команді виступити проти них. Якщо є вимога, спеціально орієнтована на архітектурну потребу, називаючи це вимогою "Архітектура", це повинно допомогти команді при роботі над архітектурою.

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

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

Є кілька переваг від розлуки.

1. Економте час на тестуванні (тобто лише перевіряйте функціональні вимоги)
2. Економить час на майбутні зміни вимог (тобто нефункціональні вимоги потребують менше часу на перегляд / затвердження / впровадження / тестування)
3. У регульованому світі (тобто FDA тощо) нефункціональні вимоги вимагають 1/10 частини тієї кількості документів, яку вимагає функціональна вимога.
4. Дає команді можливість розподілити роботу між старшими (функціональними) та молодшими (нефункціональними) членами команди.

Я міг би продовжувати ...

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