Принципы и приемы оперирования требованиями (продолжение)

Прием 10. Управление изменениями требований

Этот прием относится к задачам оперирования новыми требованиями в контексте уже существующей системы требований к проекту.

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

Если новое требование не противоречит существующим, оно объявляется дополняющим, так как его принятие не требует отслеживания связей. Этого достаточно, чтобы на основе сведений о приоритетности и с учетом оценки ресурсной потребности решить, будет ли данное требование реализовываться. Если новое требование противоречит существующим, то оно либо корректирует их, либо делает излишними. В первом случае требование является модифицирующим , во втором — отменяющим другие требования. При анализе корректируемых и отменяемых требований необходимо проследить их связи, чтобы выяснить побочные следствия принятия нового требования. Как и в предыдущем случае, оценивается ресурсная потребность для реализации нового требования и его побочных следствий и с учетом приоритетности выносится решение о том, принимается или отвергается требование.

Существенные аргументы в пользу принятия или отклонения требования появляются при проверке, не нарушается ли при расширении целостность системы:

• дополнительные и ранее выделенные субъекты автоматизируемой деятельности совместимы;
• прежний и новый наборы действий каждого субъекта не противоречат друг другу;
• при расширении действия каждого субъекта не перестают соответствовать ранее принятым соглашениям о системе.

При отказе от ранее принятых требований проверяется, не приводит ли связанное с этим удаление субъектов и действий к зависанию ссылок.

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

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

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

Определение целесообразного порядка адаптации проекта к меняющимся условиям эксплуатации разрабатываемого программного изделия следует рассматривать в качестве перманентного результата деятельности по управлению изменениями требований.