1. Вопросы для самоконтроля

1. Какие характеристики определяют качество спецификации?

2. Как определяется полнота и согласованность требований?

3. Почему важны способность к модификации спецификации и трассируемость требований?

4. Что такое экспертиза спецификации? Почему этот процесс должен быть документирован?

5. Каковы основные роли участников экспертизы?

6. Чем тестирование требований отличается от аттестации?

7. Что определяет критерий приемлемости?

8. Кто должен разрабатывать тесты приемочных испытаний?

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

   1. Причины изменений требований

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

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

• понимание пользователями возможностей системы, решаемых ею задач, может измениться;

• происходят изменения в деловой среде, техническом, программном (и т.д.) обеспечении системы, которые должны быть учтены;

• понимание разработчиками поставленных перед ними задач меняется.

Кроме этого достижение компромисса между требованиями и приоритетами разных группы пользователей (часто противоречивыми) – это длительный процесс, который может завершиться только на последних стадиях проекта.

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

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

2. Изменяемые требования отображают изменения, происходящие во время разработки и эксплуатации системы. На рис. 7.1 приведена классификация изменяемых требований и источники их возникновения.

Рис. 7.1

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

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

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

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

2. Принципы управления требованиями

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

К действиям по управлению требованиями относятся:

1. Определение основной (базовой) версии спецификации требований для конкретной версии продукта;

2. Анализ предлагаемых изменений требований, оценка воздействия и стоимости каждого изменения до его принятия;

3. Включение одобренных изменений при помощи определенной процедуры;

4. Согласование плана проекта с требованиями;

5. Отслеживание отдельных требований от проектирования до кода приложения и его тестирования;

6. Отслеживание статуса требований и действий по изменению на протяжении всего проекта.

Базовая версия требований

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

Процесс управления требованиями

В организации (или проекте) должны быть определены действия по управлению требованиями. Эти действия должны быть задокументированы и выполняться всеми участниками проекта. При разработке процесса нужно определить:

• методы и средства управления версиями спецификации и отдельных требований;

• процесс разработки, согласования, экспертизы и утверждения базовой версии;

• процесс присвоения, контроля и изменения статуса требования;

• процесс передачи новых требований и изменений существующих требований заинтересованным лицам;

• методы анализа влияния и стоимости внесения изменения.

Кроме этого описание процесса должно содержать определение участников проекта, ответственных за выполнение каждой конкретной задачи.

Контроль версий

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

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

Идентификация отдельных требований

Минимальной единицей управления в спецификации требований является отдельное требование, поэтому вопрос идентификации требования достаточно важен.

Форма представления требования может быть различной (текстовая, графическая и т.д.), поэтому для идентификации требования обычно используют связанный с ним набор атрибутов. Атрибутами могут быть: дата создания требования, номер текущей версии требования, номер версии продукта, для которой предназначено требование, автор требования, ответственный за реализацию требования, состояние требования, происхождение и обоснование требования, подсистема, для которой предназначено требование и т.д. Главное при выборе атрибутов, чтобы они однозначно идентифицировали требование его состояние и статус.

Статус требования

В процессе выполнения проекта требование, обычно, изменяет свое состояние от начального («предложено»), до конечного, например, «реализовано». Статус требований позволяет оценить степень готовности проекта. В [4] рекомендуют использовать состояния требования, приведенные в табл. 7.1.

Таблица 7.1.

Состояние	Определение
Предложено (proposed)	Требование запрошено авторизированным источником
Одобрено (approved)	Требование проанализировано, его влияние на проект просчитано, и оно было размещено в базовой версии определенной версии продукта. Ключевые заинтересованные в проекте лица согласились с этим требованием, а разработчики обязались его реализовать
Реализовано (implemented)	Код, реализующий требование разработан, написан и протестирован. Требование отслежено до соответствующих элементов дизайна и кода
Проверено (verified)	Корректное функционирование реализованного требования подтверждено в соответствующем продукте. Требование отслежено до соответствующих вариантов тестирования. Теперь требование считается завершенным
Удалено (deleted)	Утвержденное требование удалено из базовой версии. Зафиксируйте причины и лицо, принявшее это решение
Отклонено (rejected)	Требование предложено, но не запланировано для реализации ни в одной из будущих версий. Зафиксируйте причины и лицо, принявшее это решение

В процессе управления требованиями должны быть определены лица, которые могут изменить статус требования. Управление статусом позволяет численно определить степень готовности проекта, считая, например, что основная часть работы закончена, если все требования имеют статус «Проверено» или «Удалено».