Рис. 1.2 Требования в V-модели.
Классическая V-модель (V-model), описывающая различные стадии проекта, в основном базируется на связи между требованиями и их тестированием.
Рис. 1.2 показывает связь требований и тестирования на каждом этапе проекта.
V-модель также отображает системную разработку в терминах уровней (layers), где каждый уровень соотноситься с определенным этапом разработки. Несмотря на то, что на каждом уровне могут быть использованы несколько различных процессов, основной принцип работы с требованиями не меняется.
Этот вопрос будет рассмотрен подробнее в Главе 2 по ходу введения в общий процесс разработки. Рис. 1.3 демонстрирует цель работы с требованиями на каждом уровне.
Рис.1.3 Уровни разработки требований.
Другая роль, которую могут играть требования в организации, это выстуать в роли средства связи между проектами. Это очень хорошая идея, потому что многие организации желают:.
• максимально увеличить использование наработок в разных проектах;.
• управлять семействами сходных продуктов;.
• использовать программное управление для согласования действий;.
• оптимизировать разработку, используя опыт предыдущих проектов.
Хороший набор пользовательских требований (stakeholder requirements) может обеспечить краткое и не техническое описание того, что будет разработано, на уровне, который доступен для понимания высокого руководства.
Аналогичным образом, системные требования могут представлять собой прекрасное техническое описание проекта.
Два этих шага служат основой для всех последующих действий в рамках проекта, что и проиллюстрировано на рис. 1.4.
Рис 1.4 Разработка требований в компании.
Поскольку требования играют такую важную роль в разработке систем, то с ними необходимо постоянно работать.
Если, например, изменить технические спецификации (design) системы без одновременного и соответствующего изменения всех требований более высокого уровня, то это может привести к огромным проблемам в дальнейшем. Таким образом, разработка требований и управление их изменениями тесно связаны между собой.
Если при работе над проектом возникает необходимость внести изменения (например, возникла техническая проблема, связанная с деталями технического проектирования, или, заказчик настаивает на корректировке первичных формулировок), то должно быть обязательно учтено влияние такого изменения на качество, стоимость и график работ.
При внесении изменения необходимо в основном выполнить следующее:.
• принять или отклонить изменение;.
• согласовать стоимость изменения с заказчиками/поставщиками;.
• организовать работы по переделке.
Основной концепцией, позволяющей проводить анализ влияний такого рода, является возможность установления и последующего контроля связей между требованиями (requirements traceability). Этот метод рассмотрен более подробно в разделе 1.5, а также в Главах 2 и 7.
Таким образом, можно утверждать, что управление изменениями (change management) является важной частью процесса работы с требованиями. Это хорошо проиллюстрировано на рис. 1.5.
Рис.1.5 Риски управления изменениями связанные с взаимосвязанностью требований.
Становится очевидным, что совершенно независимо от управления изменениями, способность руководителя управлять проектом в целом в значительной степени зависит от хорошего поставленного процесса работы с требованиями.
Без требований, руководитель проекта не имеет средств оценки того, на сколько хорошо идет работа над проектом и в правильном ли направлении все это движется. Если требований нет как таковых, то в тот момент, когда нужно сделать изменение, не будет той базовой точки, относительно которой можно будет оценивать влияние этого изменения на ход проекта. Более того, когда в такой ситуации - при отсутствии требований - возникают изменения, то все что может сделать руководитель проекта, это лишь вмешиваться в технические детали, что недопустимо для его роли в проекте, поскольку решения на техническом уровне должны принимать технические эксперты - инженеры.
Требования, хорошо сформулированные на каждом из соответствующих уровней, дают руководителю проекта правильное представление о проекте, о ходе его выполнения и дают ему шанс правильно выполнять свою роль.
Таким образом, требования очень важны для любого системной разработки.
Они влияют на весь процесс разработки от самого начала до его полного завершения. Без эффективного процесса управления требованиями, процесс разработки системы будет выглядеть как корабль, который во время шторма дрейфует без управления.
Более того, только хорошее управление требованиями, с учетом мнения заказчиков и потребителей, дает компании основу для плодотворного общения и взаимодействия в процессе выполнения проекта.