Атрибути вимог
Контроль версій
Контроль версій - це важливий аспект управління специфікаціями вимог та іншими проектними документами. Кожній версії слід присвоїти унікальний ідентифікатор. У кожного члена команди повинен бути доступ до поточної
версії вимог, а зміни необхідно ясно документувати і передавати всім зацікавленим сторонам. Щоб мінімізувати плутанину, конфлікти і нерозуміння, потрібно призначити право поновлення вимог строго певним особам і переконатися, що ідентифікатор версії змінюється при кожній зміні вимоги.
Кожна версія документу повинна містити історію переробки, де вказуються внесені зміни, дата кожної з них, особу, що внесла зміни, а також причина.
Найпростіший механізм управління версіями - іменувати вручну кожну версію специфікації вимог до ПЗ згідно з угодою.
Спроба розрізняти версії документів за датою зміни часто призводить до помилок і плутанини, її не рекомендовано використовувати. Деякі команди доволі успішно застосовували таку угоду: перша версія будь-якого нового документа називається «Версія 1.0, начерк 1 ». Наступна називається «Версія 1.0, начерк 2 ». Автор послідовно збільшує номер начерку при кожній зміні і так до тих пір, поки документ не буде затверджена базова версія документа. Тоді назва змінюється на «Версія 1.0, затверджена». Наступні версії називаються «Версія 1.1, начерк 1» при невеликій зміні або «Версія 2.0, начерк 1» при значній зміні. При застосуванні цієї схеми ясно розрізняються начерки й версії базового документа, однак необхідно дотримуватися суворий порядок у веденні документації.
Варто додавати номер версії до назви кожної окремої вимоги і послідовно збільшувати її при модифікації.
Для документування версій використовуються текстові процесори, електронні таблиці.
Найбільш надійний метод контролю версій полягає в зберіганні вимог у базі даних комерційного засоби управління вимогами. Ці засоби відстежують повну історію змін вимог, що особливо важливо, якщо потрібно
повернутися до більш ранньої версії вимоги. Такий засіб дозволяє вносити коментарі, де можна розумно обґрунтувати рішення про додавання, зміну або видалення вимоги; ці коментарі можуть виявитися корисними при необхідності обговорення вимоги у майбутньому.
На додаток до тестового опису, кожна функціональна вимога повинна мати кілька підтримуємих їх фрагментів інформації, або атрибутів (attributes), пов'язаних з ним, Ці атрибути представляють вміст кожної вимоги, вони розташовуються за описом передбачуваної функціональності. Атрибути можна зберегти в таблиці, бази даних або, що найбільш ефективно, в засобі керування вимогами. Останні надають декілька згенерованих системою атрибутів, а також надають можливість визначити інші атрибути. Ці засоби дозволяють фільтрувати, сортувати вибрані підмножини вимог на підставі значень їх атрибутів і запитувати базу даних для іх перегляду.
Контроль змін зручніше здійснювати за допомогою атрибутів вимог. Набір атрибутів підбирається для кожного проекту індивідуально, виходячи із максимальної результативності для команди проекту. При першому впровадженні засобів управління змінами рекомендується використовувати не більше п’яти атрибутів. Ця кількість може буди розширена в подальшому, коли команда «розсмакує» процес управління змінами.
В якості шаблону опису атрибутів вимог К. Вігерс пропонує наступний набір:
- Дата створення вимоги;
- Номер поточної версії;
- Автор вимоги;
- Особа, що відповідає за задоволення вимоги;
- Відповідальний за вимогу або список зацікавлених осіб (щоб прийняти рішення про запропоновані зміни);
- Стан вимоги;
- Походження або джерело вимоги;
- Логічне обґрунтування вимоги;
- Підсистема (або підсистеми), для яких призначена вимога;
- Номер версії продукту, для якого призначена вимога;
- Метод перевірки, що використовується або критерії тестування прийнятності;
- Пріоритет реалізації;
- Стабільність вимоги.