Тема 5.2. Управление требованиями к программному продукту

Тема 5.2.1 Общие сведения об управлении требованиями

Одно из первых действий при проектировании ПП — сбор и упорядочение требований к нему. Изначально собираемые требо­вания представляют собой первичные требования заказчика (ПТЗ), протоколы совещаний и интервью с заказчиками и пользователя­ми, копии и оригиналы различных документов, отчеты о суще­ствующих аналогичных ПП и массу других материалов. После сбо­ра их начинают упорядочивать и очищать от противоречий. Затем на их основе вырабатывают требования к компонентам ПП — ба­зам данных, программным и техническим средствам. При этом приходится иметь дело с большим количеством неструктуриро­ванных, часто противоречивых требований и пожеланий, разбро­санных по всевозможным соглашениям о намерениях, приложе­ниям к договорам, протоколам рабочих совещаний, черновым материалам обследований.

Таким образом, без организованных усилий по регистрации и контролю выполнения этих требований велик риск их не учесть. Решение проблемы достаточно очевидно: следует вести учет со­бираемых требований и контролировать их обработку, оценку и реализацию (или отказ от реализации). Такая работа называется работой по управлению требованиями.

Управление требованиями (requirements management) представ­ляет собой:

систематический подход к выявлению, организации и доку­ментированию требований к ПП;

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

Управление требованиями преследует следующие цели:

достижение соглашения с заказчиком и пользователями о том, что ПП должен делать;

улучшение понимания требований к ПП со стороны разработ­чиков;

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

Тема 5.2.2 Составление спецификаций по требованиям заказчика

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

Утверждение требований исполнителем и заказчиком опреде­ляет момент достижения соглашения между ними по всем пунк­там спецификаций требований. Заказчик может потребовать пре­доставить ему прототип или иной пример, иллюстрирующий про­верку некоторых требований к ПП, может определить множество проверочных примеров или многократно изменить параметры от­дельных требований к ПП. В этом случае такие пожелания заказ­чика необходимо оформлять в приложении к спецификациям тре­бований.

Собираемые метрики, используемые методы, стандарты и шаблоны

На этапе составления спецификаций требований заказчика необходимо выполнять оценки затраченных на составление спе­цификаций требований ресурсов (время, необходимое для полу­чения утвержденной версии спецификаций требований, число человек, участвующих в составлении требований, время создания компьютерной версии спецификаций требований и ее бумажной копии, длительность процедуры согласования и утверждения спе­цификаций требований и т. п.). По этим оценкам следует опреде­лить производительность составления спецификаций требований.

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

Используемый инструмент: система подготовки документов (например, MS Word).

Используемые методы и стандарты: процесс организации; мет­рическая программа организации.

Используемые шаблоны: спецификации требований; отчета по обзору; отчета о статусе проекта.