Управление требованиями : Хранение требований

Хранение требований

Документы

В результате работы аналитика(ов) на этапе сбора требований появляются 5 документов:

• Vision;
• Требования;
• Use-case survey;
• Functional specification;
• Supplementary specification.

Документ Vision содержит:

• Описание цели продукта;
• Перечень stakeholder(s), их описание;
• Перечень проблем, их описание;
• Перечень Features, их приоритеты.

Требования содержат:

• (отдельно по каждому stakeholder) все окончательно утвержденные формулировки исходных требований;

Use-case survey:

• Описание актёров
• Краткое описание use-cases;

Functional specification:

• (каждый use-case) в своём документе;

Supplementary specification:

• URPS требования, design constraints.

Управление изменениями

Каковы причины изменения требований?

• Изменилось понимание проблемы;
• Изменилась сама проблема;
• Появилась дополнительная информация (не всех спросили, не всё спросили);
• Stakeholder’ы и пользователи поменяли свою точку зрения (например посмотрев прототип);
• Произошли внешние изменения;

Почему так важно управление изменениями? Изменения в требованиях влияют на уже согласованные сроки, ресурсы, время и бюджет проекта. Причем влияют не только напрямую (дополнительная работа по управлению требованиями), но и косвенно – поскольку на требованиях основываются design, code, test design и так далее. Все это требует значительного объема согласований (границы проекта и продукта) и трассировки возможных изменений. В случае, если требования поступают неформально, не факт что это будет произведено, следовательно, влияние изменения непредсказуемо. Таким образом, изменения в требования должен поступать ТОЛЬКО по официальному каналу, утвержденному тем, кто в праве подписывать изменения в границах продукта и проекта. Для рассмотрения изменений в требованиях создается Change Control Board – группа представителей заказчика и разработчика. Только эта группа имеет право вносить изменения в требования. Процесс внесения изменения:

• Корректировка, согласование и утверждения новой редакции требования (однозначность, полнота и так далее: требования к требованиям).
• Проверка влияния изменения в требовании на остальные процессы.
• Согласование нового scope продукта и проекта.
• Доведение информации об изменении в требовании до всех, кого это касается.

Как достигается проверка влияния и пути для доведения информации. Вспомним дерево зависимостей:

Соответственно, цепочка трассировки: проблема->исходное требование->feature->FURPS->(Design, Test, Doc). В идеале, эта трассировка должна осуществляться автоматически. Таким образом, CCB:

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

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

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

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