Основные задачи разработки требований

Цели разработки требований

Требования – это спецификация того, что должно быть реализовано. В них описано поведение системы, свойства системы или ее атрибуты. Они могут служить ограничениями в процессе разработки системы.

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

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

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

Целями разработки требований являются:

1. Обеспечение наиболее полного и точного отражения условий или возможностей, необходимых заказчику для решения его проблем и достижения бизнес-целей.

2. Снижение затрат на разработку, обслуживание и поддержку сложного заказного программного обеспечения.

Участники разработки требований

Основные задачи разработки требований

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

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

· заказчик должен быть уверен, что разработчики будут взаимодействовать с ним для создания нужной системы, даже если перед началом работы над проектом он не успел продумать все требования;

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

· менеджер проекта должен быть уверен, что команда разработчиков получила достойного делового партнера, который совместно с разработчиками готов отвечать за качество продукта;

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