Вопрос 4. Валидация требований

Определение требований напрямую связано с процедурой проверки (verification) и утверждения (validation). Требования считаются описанными не полностью, если для них не заданы правила валидации и верификации.

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

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

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

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

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

Вопрос 5. Управление требованиями

Начальные требования неизбежно корректируются в процессе работы клиентами, менеджерами, специалистами по маркетингу, разработчиками и другими лицами. Для эффективного управления требованиями необходим процесс, позволяющий предлагать изменения и оценивать их возможную стоимость и влияние на проект. Решения о внесении изменений принимает совет по управлению изменениями (change control board, ССВ)„ в который входят все заинтересованные лица. Контроль за выполнением требований на разных стадиях разработки и тестирования системы позволяет лучше понять состояние проекта в целом.

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

Подробнее о способах управления требованиями — в следующих главах:

в главе 18 — о создании базовой версии и управлении версиями требований, о контроле за состоянием всех требований;

в главе 19 — об определении процесса управления изменениям создании совета управления изменениями, оценке изменяемости требований, анализе влияния изменений требований;

в главе 20 — о создании матрицы связей требований;

в главе 21 — об использовании средств управления требованиями.

Процесс управления изменениями содержит ряд этапов:

1) определяется процесс представления, анализа и утверждения или отклонения изменений. Применяется для управления всеми предлагаемыми изменениями.

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

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

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

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

6) контроль за состоянием всех требований. Создается БД, включающая по одной записи для каждого дискретного функционального требования. Заносятся в БД ключевые атрибуты каждого требования, включая его состояние {например «предложено», «одобрено», «реализовано» или «проверено»), чтобы в любой момент можно было узнать количество требований в каждом состоянии.

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

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