Модели требований

Применение моделей при анализе и документировании требований позволяет решить проблемы понимания требований и дальнейшего моделирования и проектирования программной системы. При использовании моделей для анализа требований возможен плавный и последовательный переход к моделям проектирования. Данный процесс для объектно-ориентированных систем, разрабатываемых с использованием языков C# и Java, удобнее организовывать с использованием диаграмм в нотации UML.

Проверка требований

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

Контрольные листы

Контрольные листы (checklists) используются как технология контроля качества требований. Они представляет собой набор вопросов, которые аналитик или другой член команды, задает себе при проверке требований. Данные вопросы должны быть составлены таким образом, чтобы покрывать полностью проверяемую с их помощью задачу или артефакт. Большое количество готовых контрольных листов описано в [3, Глава 29], [4] и [5].

Рекомендация

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

Уровень 4 – Трассировка требований

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

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

Выявление требований

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