
- •Управление качеством требований. Начало
- •Введение
- •Часть 1. Требования
- •Определение требований
- •Классификация требований
- •Бизнес-требования
- •Ключевые возможности
- •Пользовательские требования
- •Функциональные требования
- •Характеристики качества
- •Ограничения
- •Иерархия требований
- •Стоимость ошибок в требованиях
- •Выводы к первой части
- •Литература
- •Часть 2. Управление требованиями
- •Управление требованиями
- •Бизнес-аналитик
- •Бизнес-архитектор
- •Аналитик требований
- •Спецификатор требований
- •Системный архитектор
- •Технический писатель
- •Коммуникатор
- •Основные шаги процесса
- •Планирование процесса
- •Выявление требований
- •Методы выявления требований
- •Интервью
- •Семинары требований
- •Мозговой штурм
- •Фокус-группа
- •Прототипирование
- •Варианты использования
- •Проблемы, возникающие при выявлении требований Проблемы классификации требований
- •Проблемы формулировки требований
- •Терминология
- •Предвзятые решения
- •Анализ требований
- •Уточнение требований
- •Структуризация требований
- •Приоритеты
- •Модели требований
- •Документирование требований
- •Глоссарий
- •Документ – концепция
- •Спецификация требований
- •Проверка требований
- •Управление изменениями требований
- •Выводы ко второй части.
- •Литература
- •Часть 3. Качество требований
- •Качество требований Управление качеством
- •Iso 9001:2000
- •Модель зрелости cmmi Обзор cmmi
- •Внутренняя структура описания уровней зрелости
- •Уровни зрелости
- •Группы ключевых процессов
- •Разделы
- •Ключевые практики
- •Отображение процесса управления требованиями на модель cmmi
- •Критерии качества требований
- •Правильные требования
- •Однозначные требования
- •Полные требования
- •Непротиворечивые требования
- •Ранжированные требования
- •Проверяемые требования
- •Прослеживаемые требования
- •Модифицируемые требования
- •Понимаемые требования
- •Выводы к третьей части
- •Литература
- •Часть 4 Управление качеством требований
- •Уровни зрелости требований Уровень 0 – Отсутствие требований
- •Уровень 1 – Документирование требований
- •Выявление требований
- •Интервью
- •Анализ документации
- •Документирование требований
- •Проверка требований
- •Экспертная оценка
- •Согласование документов
- •Уровень 2 – Организация требований
- •Выявление требований
- •Мозговой штурм
- •Анализ требований Уточнение требований
- •Документирование требований
- •Проверка требований Коллективная проверка
- •Документ замечаний
- •Управление изменениями требований База данных требований
- •Управление версиями
- •Уровень 3 – Структурирование требований
- •Планирование процесса План управления требованиями
- •Типы требований
- •Атрибуты требований
- •Выявление требований
- •Варианты использования
- •Прототипы
- •Анализ требований
- •Структуризация требований
- •Определение значений атрибутов
- •Документирование требований Шаблоны требований
- •Модели требований
- •Проверка требований
- •Контрольные листы
- •Рекомендация
- •Уровень 4 – Трассировка требований
- •Выявление требований
- •Анализ требований Иерархия типов требований
- •Отношения между требованиями
- •Трассировка требований
- •Анализ влияния
- •Анализ сферы деятельности
- •Документирование требований Типовые решения требований
- •Уровень 5 – Комплексность требований
- •Анализ требований Трассировка на элементы проектирования и тестирования
- •Показатели требований
- •Количественная оценка требований
- •Документирование требований
- •Заключение
- •Литература
Критерии качества требований
В соответствии со стандартом ISO 9001:2000 качество продукта должно быть измеряемым. Очевидно, что одной из мер качества является получение в результате завершения проекта хорошего продукта, но как говорилось ранее, помимо требований существует множество других факторов, влияющих на результат. Исходя из этого, необходимо оценивать качество документов с требованиями и моделей требований. Основные «критерии качества» требований приведены в таблице 1. Таблица 1 - Критерии качества требований
Критерий качества |
Англ. название |
Краткое описание |
Правильное |
Correct |
Критерий того, насколько требование соответствует предметной области и потребностям заказчика |
Однозначное |
Unambiguous |
Критерий, характеризующий однозначность толкования требования и однозначность понимания его всеми заинтересованными лицами. |
Полное |
Complete |
Критерий, характеризующий требования с точки зрения полноты предоставленной информации для дальнейшего его проектирования и реализации. |
Непротиворечивые |
Consistent |
Критерий, характеризующий то, что два или несколько требований не противоречат друг другу, т.е. при реализации одного требования не возникало конфликтов или невозможности реализации другого требования. |
Ранжированное |
Prioritized |
Критерий, характеризующий важность требований |
Проверяемое |
Testable |
Критерий, характеризующий возможность проверки требования с использованием механизмов тестирования (функционального, нагрузочного и др.) |
Прослеживаемое |
Traceable |
Критерий, характеризующий отношения между требованиями. |
Понимаемое |
Understandable |
Критерий, характеризующий возможность заинтересованному лицу понять данное требование |
Модифицируемое |
Modifiable |
Критерий, характеризующий возможность сохранения структуры и стиля описания набора требований при изменении требований. |
Приведенные выше критерии качества требований являются обобщенным набором, полученным из различных источников ([1], [2], [3], [4]). Рассмотрим более подробно основные из критериев качества, так как они придают дополнительную глубину процессу разработки требований, а также позволяют понять природу «хороших» требований.
Правильные требования
Корректность требований отражает степень того, насколько задокументированные требования к разрабатываемой системе соответствуют потребностям пользователей и предметной области. На рисунке 4 показано множество потребностей пользователей (А) и множество сформулированных и специфицированных требований (Б). Область пересечения (В) областей А и Б является областью правильных требований, т.е. тех требований, которые точно выражают потребности заказчика.
Рис. 4. Область правильных требований
Очевидно, что чем больше потребностей выявлено и задокументировано, тем большая вероятность получения правильных требований. Оптимальным является вариант совпадения всех трех областей, но, к сожалению, на практике такого никогда не бывает. Для увеличения области В необходим четко поставленный процесс выявления, документирования и проверки требований. Наверное хочется задать вопрос откуда взялись требования в области Б не совпадающие с областью В. Информация из области Б может представлять собой детали проектирования и/или реализации системы, а также требования, которые пользователь или заказчик никогда не высказывали. Иногда подобную информацию высказывают маркетологи и технические специалисты, которые уверены, что пользователи и заказчик придут в восторг от добавленной функциональности, и аналитики, которые считаю, что знают предметную область заказчика или проблемы пользователя лучше самих заказчиков. К таким требованиям необходимо относится очень серьезно и убеждаться в их действительной необходимости. Единственным способом оценки правильности требований является их проверка заказчиком системы, пользователем или экспертом предметной области.