7.1 Ітеративна природа процесу роботи з вимогами (Iterative Nature of the Requirements Process)

У більшості випадків розуміння та інтерпретація вимог продовжують еволюціонувати в процесі проектування і розробки програмного забезпечення. Крім того, вимоги часто змінюються в силу змін бізнес-контексту для якого створюється і в якому експлуатується програмне забезпечення. Необхідно розуміти неминучість змін і планувати кроки по зменшенню проблем, пов'язаних зі змінами. У той же самий час, сучасні практики гнучкої розробки говорять про те, що необхідно концентруватися тільки на тому, що вимагає уваги "прямо зараз", не закладаючись на попередження всіх можливих ризиків, у тому числі пов'язаних із змінами, включаючи зміни вимог. Говорити про те, який підхід - попередження або реагування є гарантовано призводить до успіху - складно сказати. Більше того, якщо хтось однозначно наполягає тільки на одній з ідей і повністю відкидає іншу - це профанація. Сприйняття змін та можливість їх своєчасної обробки - питання спроможності проектної команди працювати в умовах постійно мінливих умов, прийнятих архітектурних рішень і багатьох інших культурних, технологічних та організаційних чинників. Так чи інакше, розуміння мінливої ​​природи вимог - один із чинників адекватного реагування на самі зміни, а, отже, і можливості успішного завершення проекту.

 

7.2 Управління змінами (Change Management)

Управління змінами - одна з ключових тем управління вимогами. Необхідність визначення процедур для обробки змін зовсім не те ж саме, що і їх детальна формалізація. Такі процедури необхідні. Їм присвячена тема управління змінами в додатку до вимог. У той же час, розглядати зміну вимог окремо від інших процесів, щонайменше здається дивним. Відповідно, дане питання є складовою частиною управління змінами та конфігураціями програмного забезпечення (Software Configuration and Change Management, SCCM), яке сьогодні прийнято називати просто конфігураційним управлінням (Software Configuration Management, SCM), маючи на увазі, що це не тільки питання контролю версій, але й управління всіма активами проекту, включаючи код, вимоги, запити на зміни - change requests (у тому числі, звіти про помилки - defect чи bug reports), завдання (в термінах проектного менеджменту) і т.п. Загальний комплекс питань конфігураційного управління розглядається в галузі знань SWEBOK "Управління конфігураціями програмного забезпечення" (Software Configuration Management).

 

7.3 Атрибути вимог (Requirements Attributes)

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

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

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