23. Атрибути вимог.

На додаток до текстового опису кожна функціональна вимога повинна мати атрибути. Ці атрибути представляють собою вміст кожної вимоги та розташування за описом передбачення функціонаьності. Атрибути можна зберігати в таблиці БД або засобах керування вимогах. Контроль змін зручніше здійснювати за допомогою атрибутів вимог. Набір атрибутів підбирається індивідуально виходячи із максимальної результативності для команди. В якості шаблону опису атрибутів вимог Карл Віверс:

- Дата створення створення вимог, Номер поточної версії, Автор вимог, Особа, що відповідає за задоволення вимог

- Стан вимог, джерело вимог, обгрунтування вимог

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

- Приорітет реалізації та стабільність вимоги

24. Шаблон опису атрибутів вимог за к. Вігерсом.

В якості шаблону опису атрибутів вимог Карл Віверс:

• Дата створення створення вимог, Номер поточної версії, Автор вимог, Особа, що відповідає за задоволення вимог

• Стан вимог, джерело вимог, обгрунтування вимог

• Підсистема або підсистеми для яких призначена вимога, номер версії продукту для якого призначена вимога, метод перевірки, що використовується або критерії тестування прийнятності

• Приорітет реалізації та стабільність вимоги

25. Контроль статусу вимог.

Для визначення статусу вимог використовують поняття стану вимог:

- стан вимоги запропоновано – стан коли вимога запропонована клієнту

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

- Стан реалізовано – код, що реалізує вимогу розроблений, написаний та протестованих

- Стан перевірено – коректне функціонування реалізованої вимоги підтверджено у відповідному продукті

- Стан видалено – із ю\базової версії. При цьому необхідно зазначити причини видалення та зазначити того хто прийняв таке рішення

- Стан відхилено – вимога запропонована, але не заплановано для реалізації в жодній із версії, причини та особа прийняла таке рішення.

Основні трудовитрати по управлінню вимогами

- Пропозиції зміни вимог та нових вимог

- Оцінка запропонованих змін, включаючи оцінку впливу змін

- Зміна роботи

- Оновлення документації вимог

- Повідомлення про зміну вимог зацікавлених осіб

- Контроль та збір про стан вимог та збір інформації про перевіряємість вимог.

26. Управління змінами.

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

своїми проектами з розробки ПЗ, повинна переконатися, що:

· запропоновані зміни вимог ретельно оцінені до їх у введення у справу;

· відповідні особи приймають (беруть) бізнес-рішення, будучи добре інформованими про запитані зміни;

· схвалені зміни доведені до відома всім учасникам проекту;

· зміни вимог, внесені в проект, узгоджені один з іншим.

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