1. Риски этапа выявления требований

   Наименование риска	Причина возникновения	Методы уменьшения риска
   Концепция проекта	Если лица, заинтересованные в проекте не имеют ясного мнения о том, что должен представлять собой продукт, то вероятность расползания границ системы возрастает	Разработайте документ об образе и границах продукта, который содержит бизнес-требования и используйте его при выработке решений о принятии или изменении требований
   Время, затраченное на разработку требований	Жесткие сроки проекта заставляют разработчиков и пользователей пренебрегать разработкой требований и сразу переходить к кодированию	Собирайте статистику о времени и усилиях, затраченных на разработку требований в каждом проекте, и используйте ее для улучшения планирования следующего проекта
   Полнота и корректность спецификации требований	Жесткие сроки проекта	Концентрируйтесь на определении пользовательских задач, используйте для определения потребностей пользователя наиболее понятные для него средства: сценарии использования, прототипы и т.п.
   Определение нефункциональных требований	Основное внимание уделяется на функциональность продукта	Выясняйте у пользователей качественные характеристики продукта: надежность, производительность, простота использования и т.п. Документируйте эти требования и критерии их оценки в спецификации
   Единство мнений пользователей относительно требований	Отсутствие или неполное согласование требований со всеми пользователями	Определите основных пользователей, сторонников продукта для получения нужного представительства. Удостоверьтесь, что вы полагаетесь на правильно выбранных людей, имеющих полномочия для принятия решений

2. Риски этапа анализа и спецификации требований

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

3. Риски управления требованиями

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

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

1. Перечислите несколько причин изменения требований.

2. Чем отличаются постоянные и изменяемые требования?

3. Перечислите основные функции по управлению требованиями.

4. Что такое базовая версия требований?

5. Для чего используются атрибуты требований? Назовите несколько атрибутов и обоснуйте их выбор.

6. Что такое статус и состояние требования?

7. Кто принимает решение о внесении изменений в требования?

8. Какие задачи позволяет решить трассируемость требований?

8. Case-средства для управления требованиями

   1. Выбор case-средств для управления требованиями

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

• во внесении изменений, поддержке непротиворечивости и актуальности документов;

• в хранении атрибутов, управлении статусом требований;

• в управлении версиями и т.д.

Поэтому использование инструментальных средств является необходимым условием успешности выполнения проекта. Средства автоматизации и поддержки, используемые в процессе разработки программных систем, принято называть CASE-средствами (Computer-Aided Software Engineering). Нас интересуют средства, которые можно использовать на этапе разработки и анализа требований к программной системе, т.е. средства, поддерживающие: выявление и документирование требований пользователей, разработку системных требований, анализ требований и управление требованиями.

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

• при определении заинтересованных лиц, пользователей системы;

• при выявлении и сборе требований.

CASE-средства не могут заменить «ручные» методы выявления требований.

CASE-средства позволяют более точно и производительно управлять требованиями, но не всегда внедрение автоматизации в этот процесс приводит к успеху. Многие авторы [4, 6] говорят о том, что даже лучшие средства могут не оправдать ожиданий, если их используют разработчики, не имеющие должной квалификации и мотивации. Дело в том, что для перехода к оперативным приемам работы с требованиями необходим новый образ мышления, достаточный уровень зрелости функциональных возможностей.