Ключевые области процессов также рекомендуют, какими докумен-
тами
требований
следует управлять посредством приемов контроля
версий и контроля изменений. Контроль версий гарантирует, что из-
вестна версия
требований,
которая используется при разработке и
планировании. Контроль изменений обеспечивает организованное
внесение изменений в требования, при котором учитываются хорошие
бизнес- и технические решения о том, принимать ли предложенные
изменения или отказаться от них. По мере модификации, добавления
или
удаления
требований в процессе разработки важно обновлять
план разработки
ПО,
чтобы он соответствовал новым
требованиям.
Планы,
не отражающие текущую
ситуацию,
не могут с пользой направ-
лять ваш проект.
В отличие от управления требованиями, разработка требований не
стала отдельной ключевой области процессов в
SW-CMM.
На мой
взгляд,
это — крупный недостаток
модели
Большинству организаций
сложнее выявлять и составлять хорошие
требования,
чем управлять
имеющимися требованиями, какими бы они ни были. О разработке
требований говорится в единственном ключевом приеме работы в
ключевой
области технологических процессов, «Конструирование ПО"
на уровне 3 (выделена в табл.
Б-1}.
Действие
2 этой области звучит так;
"Требования
для ПО разрабатываются, сопровождаются, документи-
руются и проверяются посредством систематического анализа разме-
щенных требований согласно определенному в проекте процессу»
Это действие описывает приемы разработки требований, подобные
описанным в данной книге, в том числе:
1 анализ требований на осуществимость и другие желательные каче-
ства;
i документирование требований;
1 проверка документации требований с участием представителей
клиентов;
I определение того, как будет
проверяться
и утверждаться каждое
требование.
Трассирование требований также включено в уровень 3
SW-CMM.
Действие 10 ключевой области «Конструирование ПО» сформулировано
так: «Поддерживается соответствие между различными продуктами ра-
боты над ПО, включающими планы разработки ПО, описания технологи-
ческих процессов, размещение требований, программные требования,
программные конструкции, код, планы и процедуры тестирования».
Подразделы этого действия включают конкретные указания о том, как
следует выполнять трассирование требований в организации.
464 Приложение Б