2014-02-12
522
Атрибуты требований
С позиций управления, каждое из требований представляет собой самостоятельный объект. Изменения осуществляются в описательной части данного объекта. Контроль изменений удобнее осуществлять с помощью атрибутов требований. Набор атрибутов подбирается для каждого проекта индивидуально, исходя из максимальной результативности для команды проекта. При первом внедрении средств управления изменениями рекомендуется использовать не более пяти атрибутов. Это количество можно будет расширить впоследствии, когда команда "войдет во вкус" процесса управления изменениями и в том случае, если добавление новых атрибутов оправдано практическими соображениями.
В качестве шаблона описания атрибутов требований К.Вигерс предлагает следующий набор:
- дата создания требования;
- номер его текущей версии;
- автор требования;
- лицо, ответственное за удовлетворение требования;
- ответственный за требование или список заинтересованных лиц (чтобы принимать решения о предложенных изменениях);
|
|
|
- состояние требования;
- происхождение или источник требования;
- логическое обоснование требования;
- подсистема (или подсистемы), для которых предназначено требование;
- номер версии продукта, для которого предназначено требование;
- используемый метод проверки или критерий тестирования приемлемости;
- приоритет реализации;
- стабильность требования
В автоматизированных средствах управления проектами, для контроля степени выполнения той или иной работы используется понятие степени выполнения (progress), выражаемой в процентах. Данный способ слабо применим в программистских разработках, где, в силу их слабой формализованности, трудно оценить работу в процентах. При управлении требованиями рекомендуется оперировать не процентом, а статусом. К.Вигерс предлагает следующий шаблон для определения статуса требования:
| Состояние | Определение |
| Proposed (Предложено) | Требование запрошено авторизированным источником |
| Approved (Одобрено) | Требование проанализировано, его влияние на проект просчитано, и оно было размещено в базовой версии определенной версии. Ключевые заинтересованные в проекте лица согласились с этим требованием, а разработчики ПО обязались реализовать его |
| Implemented (Реализовано) | Код, реализующий требование, разработан, написан и протестирован. Требование отслежено до соответствующих элементов дизайна и кода |
| Verified (Проверено) | Корректное функционирование реализованного требования подтверждено в соответствующем продукте. Требование отслежено до соответствующих вариантов тестирования. Теперь требование считается завершенным |
| Deleted (Удалено) | Утвержденное требование удалено из базовой версии. Опишите причины удаления и назовите того, кто принял это решение |
| Rejected (Отклонено) | Требование предложено, но не запланировано для реализации ни в одной будущих версий. Опишите причины отклонения требования и назовите того, кто принял это решение |
