Разработка требований к программному обеспечению

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

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

Определение источников требований Чтобы гарантировать, что все за-
интересованные лица понимают, зачем нужно то или иное требование, вы-
явите источники всех требований. Это может быть вариант использования
или другая информация от пользователей, системное требование высокого
уровня или бизнес-правило. Указав всех лиц, заинтересованных в каждом
требовании, вы будете знать, к кому обратиться при поступлении запроса
на изменение. Источники требований устанавливают на основе связей или
определяют для этой цели атрибут требования. Подробнее об атрибутах тре-
бований см. главу

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

В проектах гибкой разработки (agile) планируется выпускать функцио-
нальность каждые несколько недель (Larman, 2004). В таких проектах работа
над требованиями выполняется часто, но небольшими объемам, как показано
на рис. 3-3 точечной линией. Работа начинается с выявления пользователь-
ских требований в форме пользовательских историй, которые описывают
основные задачи, которые пользователи хотят решить с помощью систе-
SR3_ch_03.indd 53 SR3_ch_03.indd 5330.04.2014 12:10:0730.04.2014 12:10:0754 Часть I Требования к ПО: что, почему и кто
мы. В этом подходе из историй нужно извлечь достаточно информации,
чтобы можно было оценить объем и определить приоритеты разработки.
Приоритизация пользовательских требований позволяет определить, ка-
кие из них назначить на те или иные этапы разработки, которые называ-
ются итерациями или спринтами. Более подробно выделенные на ту или
иную итерацию требования изучаются, когда разработка подойдет к этой
итерации.
Независимо от используемой в проекте модели, надо при каждом выпуске
или итерации задавать себе вопрос, какие из действий, описанных на рис. 3-2,
позволят увеличить ценность и снизить риск. По завершении шага 17 для
любой части требований можно приступать к построению соответствующей
части системы. Повторите шаги с 8 по 17 со следующим набором требований,
который ляжет в основу следующего выпуска или итерации