Каждая версия документа требований должна содержать историю переработки, где указываются внесенные изменения, дата каждого из них, лицо, внесшее изменение, а также причина. Целесообразно добавлять номер версии к названию каждого отдельного требования, который можно последовательно увеличивать при модификации требований.
Атрибуты требований
Контроль изменений удобнее осуществлять с помощью атрибутов требований. Набор атрибутов подбирается для каждого проекта индивидуально, исходя из максимальной результативности для команды проекта.
В качестве шаблона описания атрибутов требований можно применить следующий набор:
- дата создания требования;
- номер его текущей версии;
- автор требования;
- лицо, ответственное за удовлетворение требования;
- ответственный за требование или список заинтересованных лиц (чтобы принимать решения о предложенных изменениях);
- состояние требования;
-происхождение или источник требования;
-логическое обоснование требования;
|
|
-подсистема (или подсистемы), для которых предназначено требование;
-номер версии продукта, для которого предназначено требование;
- используемый метод проверки или критерий тестирования приемлемости;
- приоритет реализации;
- стабильность требования
Контроль статуса требований
Для контроля степени выполнения той или иной работы используется понятие степени выполнения, выраженного в %.
Измерение трудозатрат, необходимых для управления требованиями
Управление требованиями, как и всякий другой процесс, требует ресурсов. Контроль усилий также позволяет выяснить, выполняют ли разработчики предполагаемые задачи для управления требованиями.
Основные трудозатраты по управлению требованиями:
- предложение изменения требований и новых требований;
- оценка предложенных изменений, включая оценку влияния изменения;
- изменение работы;
- обновление документации требований или базы данных;
- сообщение об изменениях требований заинтересованным группам и отдельным лицам;
- контроль и отчет о состоянии требования;
- сбор информации о трассируемости требований.