
- •Управление качеством требований. Начало
- •Введение
- •Часть 1. Требования
- •Определение требований
- •Классификация требований
- •Бизнес-требования
- •Ключевые возможности
- •Пользовательские требования
- •Функциональные требования
- •Характеристики качества
- •Ограничения
- •Иерархия требований
- •Стоимость ошибок в требованиях
- •Выводы к первой части
- •Литература
- •Часть 2. Управление требованиями
- •Управление требованиями
- •Бизнес-аналитик
- •Бизнес-архитектор
- •Аналитик требований
- •Спецификатор требований
- •Системный архитектор
- •Технический писатель
- •Коммуникатор
- •Основные шаги процесса
- •Планирование процесса
- •Выявление требований
- •Методы выявления требований
- •Интервью
- •Семинары требований
- •Мозговой штурм
- •Фокус-группа
- •Прототипирование
- •Варианты использования
- •Проблемы, возникающие при выявлении требований Проблемы классификации требований
- •Проблемы формулировки требований
- •Терминология
- •Предвзятые решения
- •Анализ требований
- •Уточнение требований
- •Структуризация требований
- •Приоритеты
- •Модели требований
- •Документирование требований
- •Глоссарий
- •Документ – концепция
- •Спецификация требований
- •Проверка требований
- •Управление изменениями требований
- •Выводы ко второй части.
- •Литература
- •Часть 3. Качество требований
- •Качество требований Управление качеством
- •Iso 9001:2000
- •Модель зрелости cmmi Обзор cmmi
- •Внутренняя структура описания уровней зрелости
- •Уровни зрелости
- •Группы ключевых процессов
- •Разделы
- •Ключевые практики
- •Отображение процесса управления требованиями на модель cmmi
- •Критерии качества требований
- •Правильные требования
- •Однозначные требования
- •Полные требования
- •Непротиворечивые требования
- •Ранжированные требования
- •Проверяемые требования
- •Прослеживаемые требования
- •Модифицируемые требования
- •Понимаемые требования
- •Выводы к третьей части
- •Литература
- •Часть 4 Управление качеством требований
- •Уровни зрелости требований Уровень 0 – Отсутствие требований
- •Уровень 1 – Документирование требований
- •Выявление требований
- •Интервью
- •Анализ документации
- •Документирование требований
- •Проверка требований
- •Экспертная оценка
- •Согласование документов
- •Уровень 2 – Организация требований
- •Выявление требований
- •Мозговой штурм
- •Анализ требований Уточнение требований
- •Документирование требований
- •Проверка требований Коллективная проверка
- •Документ замечаний
- •Управление изменениями требований База данных требований
- •Управление версиями
- •Уровень 3 – Структурирование требований
- •Планирование процесса План управления требованиями
- •Типы требований
- •Атрибуты требований
- •Выявление требований
- •Варианты использования
- •Прототипы
- •Анализ требований
- •Структуризация требований
- •Определение значений атрибутов
- •Документирование требований Шаблоны требований
- •Модели требований
- •Проверка требований
- •Контрольные листы
- •Рекомендация
- •Уровень 4 – Трассировка требований
- •Выявление требований
- •Анализ требований Иерархия типов требований
- •Отношения между требованиями
- •Трассировка требований
- •Анализ влияния
- •Анализ сферы деятельности
- •Документирование требований Типовые решения требований
- •Уровень 5 – Комплексность требований
- •Анализ требований Трассировка на элементы проектирования и тестирования
- •Показатели требований
- •Количественная оценка требований
- •Документирование требований
- •Заключение
- •Литература
Коммуникатор
Коммуникатор отвечает за организацию, проведение, моделирование и протоколирование совещаний, фокус-групп и мозговых штурмов.
Основные шаги процесса
На рисунке 2 изображена структурная схема процесса управления требованиями с декомпозицией на основные шаги.
Рисунок 2. Шаги процесса управления требованиями
Каждый представленный выше шаг в процессе управления может повторяться множество раз, причем, переходы от шага к шагу могут быть прямыми и обратными. Обратная связь позволяет уточнять, дорабатывать и корректировать требования. Процесс управления требованиями приведен на рисунке 3:
Рисунок 3. Процесс управления требованиями
Далее подробно рассмотрим каждый шаг процесса.
Планирование процесса
Процесс управления требования начинается с планирования. На этапе планирования системный аналитик создает план управления требованиями и шаблоны необходимой документации. Планирование – первый шаг при работе с требованиями, он начинается на этапе предпроектного обследования.
План управления требованиями является одним из наиболее важных документов в процессе управления требованиями. В данном документе определяются типы требований и атрибуты каждого типа, отношения между требованиями, документы, использующиеся в данном процессе. Также системный аналитик определяет и заносит в план решение об использовании специального инструментального средства для управления требованиями. Расширенный вариант плана управления требованиями может содержать описание ролей, участвующих в процессе; задач, выполняемых каждой ролью, и другую служебную информацию.
Как было сказано выше, на этапе планирования также создаются шаблоны необходимых документов: глоссария, технического задания, документа-концепции. При работе с государственным заказчиком для описания требований чаще всего используется техническое задание, разработанное в соответствие с ГОСТ 34.602-89 или ГОСТ 19.201-78. Если нет жестких требований со стороны заказчика на соответствие государственным стандартам, можно использовать спецификацию требований на основе стандарта IEEE 830-1998.
Современные инструментальные средства позволяют создавать автоматические отчеты с необходимой информацией. Если принято решение о том, что документация будет создаваться автоматически с использованием отчетов, на этапе планирования необходимо создать шаблоны таких отчетов. Шаблоны отчетов, также как и шаблоны документов, должны быть разработаны с учетов требований государственных стандартов.
Более подробно о планировании процесса управления требованиями можно прочитать во втором выпуске журнала Analyze IT
Выявление требований
Выявление требований является самой сложной задачей в процессе управления требованиями. От того насколько полно собраны требования, зависит реализация проекта и последующее удовлетворение заказчика. Часто на практике заказчики и пользователи информационной системы отдалены от команды разработчиков, что вызывает трудности при выявлении требований. Однако, кроме заказчиков и пользователей, существуют и другие источники требований:
документы, описывающие существующие или конкурирующие продукты;
существующие спецификации требований к системе;
отчеты об ошибках и запросы от пользователей по совершенствованию системы;
результаты маркетинговых исследований;
существующая документация с описанием процессов деятельности заказчика и др.
Первой задачей при выявлении требований является определение пользователей информационной системы, которые будут работать с системой, и если не учесть их потребностей, конечный продукт может потерпеть неудачу. При коммуникациях с конечными пользователями аналитик должен определить задачи, которые необходимо решать пользователям с помощью разрабатываемой системы, а также характеристики качества, определяющие то, как пользователи хотят выполнять свои задачи.