Введение в управление требованиями

Принципы и приемы управления требованиями

Базовая версия требований

Чтобы договориться об изменении требований, сначала нужно их зафиксировать в "первозданном виде".

Базовая версия (baseline) - это набор функциональных и нефункциональных требований, которые разработчики обязались реализовать в определенной версии (итерации).

Управление требованиями - это рабочий процесс, следовательно, он должен подчиняться определенным правилам и процедурам.

Процедуры управления требованиями

Процедуры управления требованиями базируются на:

• инструментах, приемах и соглашениях по управлению версиями различных документов требований и отдельных требований;
• правилах составления базовой версии требований;
• статусах требований, которые будут использоваться, и категориях лиц, которые имеют право изменять их;
• способах, с помощью которых новые требования и изменения существующих требований предлагаются, обрабатываются, обсуждаются и передаются всем заинтересованным лицам;
• методах анализа влияния предложенного изменения;
• отслеживании связей планов и обязательств проекта с изменением требований.

Контроль версий

Каждая версия документа требований должна содержать историю переработки, где указываются внесенные изменения, дата каждого из них, лицо, внесшее изменение, а также причина. Целесообразно добавлять номер версии к названию каждого отдельного требования, который можно последовательно увеличивать при модификации требований.

Для документирования версий используются текстовые процессоры, электронные таблицы. Существуют специализированные средства для контроля версий и конфигураций ^{5Брайен А. Уайт. Управление конфигурацией программных средств. Практическое руководство по Rational ClearCase: Пер. с англ. -М.:ДМК Пресс, 2002. - 272 с.: ил. (Серия "Объектно-ориентированные технологии в программировании").}

Атрибуты требований

С позиций управления, каждое из требований представляет собой самостоятельный объект. Изменения осуществляются в описательной части данного объекта. Контроль изменений удобнее осуществлять с помощью атрибутов требований. Набор атрибутов подбирается для каждого проекта индивидуально, исходя из максимальной результативности для команды проекта. При первом внедрении средств управления изменениями рекомендуется использовать не более пяти атрибутов. Это количество можно будет расширить впоследствии, когда команда "войдет во вкус" процесса управления изменениями и в том случае, если добавление новых атрибутов оправдано практическими соображениями.

В качестве шаблона описания атрибутов требований К.Вигерс [13.1] предлагает следующий набор:

• дата создания требования;
• номер его текущей версии;
• автор требования;
• лицо, ответственное за удовлетворение требования;
• ответственный за требование или список заинтересованных лиц (чтобы принимать решения о предложенных изменениях);
• состояние требования;
• происхождение или источник требования;
• логическое обоснование требования;
• подсистема (или подсистемы), для которых предназначено требование;
• номер версии продукта, для которого предназначено требование;
• используемый метод проверки или критерий тестирования приемлемости;
• приоритет реализации;
• стабильность требования

Контроль статуса требований

В автоматизированных средствах управления проектами, например MS Project, для контроля степени выполнения той или иной работы используется понятие степени выполнения (progress), выражаемой в процентах. Данный способ слабо применим в программистских разработках, где, в силу их слабой формализованности, трудно оценить работу в процентах. При управлении требованиями рекомендуется оперировать не процентом, а статусом. К.Вигерс предлагает следующий шаблон для определения статуса требования:

Измерение трудозатрат, необходимых для управления требованиями

Управление требованиями, как и всякий другой процесс, требует ресурсов. Контроль усилий также позволяет выяснить, выполняют ли разработчики предполагаемые задачи для управления требованиями.

Основные трудозатраты по управлению требованиями [13.1]:

• предложение изменения требований и новых требований;
• оценка предложенных изменений, включая оценку влияния изменения;
• изменение работы;
• обновление документации требований или базы данных;
• сообщение об изменениях требований заинтересованным группам и отдельным лицам;
• контроль и отчет о состоянии требования;
• сбор информации о трассируемости требований.