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

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

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

1. Большие системы обычно имеют многообразный контингент пользователей. Раз­ные пользователи имеют различные требования и приоритеты, которые могут быть противоречивыми или несовместимыми. Окончательный вариант системных требований представляет неизбежный компромисс между ними, который часто принимается только на заключительном этапе разработки системы.

2. Заказчики системы и ее пользователи — редко одни и те же люди. Заказчики фор­мулируют требования, руководствуясь своими организационными и бюджетными ограничениями. Они могут входить в противоречие с требованиями конечных пользователей.

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

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

Описание процесса управления требованиями приведено ниже. Но прежде следует об­судить, почему требования неизбежно меняются, и объяснить, почему одни типы требо­ваний более подвержены изменениям, чем другие.

Постоянные и изменяемые требования

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

Рис. 6.14. Эволюция требований

С точки зрения разработки требования можно разделить на два класса.

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

2. Изменяемые требования. Эти требования отображают изменения, сделанные во вре­мя разработки системы или после ввода ее в эксплуатацию.