
- •Управление качеством требований. Начало
- •Введение
- •Часть 1. Требования
- •Определение требований
- •Классификация требований
- •Бизнес-требования
- •Ключевые возможности
- •Пользовательские требования
- •Функциональные требования
- •Характеристики качества
- •Ограничения
- •Иерархия требований
- •Стоимость ошибок в требованиях
- •Выводы к первой части
- •Литература
- •Часть 2. Управление требованиями
- •Управление требованиями
- •Бизнес-аналитик
- •Бизнес-архитектор
- •Аналитик требований
- •Спецификатор требований
- •Системный архитектор
- •Технический писатель
- •Коммуникатор
- •Основные шаги процесса
- •Планирование процесса
- •Выявление требований
- •Методы выявления требований
- •Интервью
- •Семинары требований
- •Мозговой штурм
- •Фокус-группа
- •Прототипирование
- •Варианты использования
- •Проблемы, возникающие при выявлении требований Проблемы классификации требований
- •Проблемы формулировки требований
- •Терминология
- •Предвзятые решения
- •Анализ требований
- •Уточнение требований
- •Структуризация требований
- •Приоритеты
- •Модели требований
- •Документирование требований
- •Глоссарий
- •Документ – концепция
- •Спецификация требований
- •Проверка требований
- •Управление изменениями требований
- •Выводы ко второй части.
- •Литература
- •Часть 3. Качество требований
- •Качество требований Управление качеством
- •Iso 9001:2000
- •Модель зрелости cmmi Обзор cmmi
- •Внутренняя структура описания уровней зрелости
- •Уровни зрелости
- •Группы ключевых процессов
- •Разделы
- •Ключевые практики
- •Отображение процесса управления требованиями на модель cmmi
- •Критерии качества требований
- •Правильные требования
- •Однозначные требования
- •Полные требования
- •Непротиворечивые требования
- •Ранжированные требования
- •Проверяемые требования
- •Прослеживаемые требования
- •Модифицируемые требования
- •Понимаемые требования
- •Выводы к третьей части
- •Литература
- •Часть 4 Управление качеством требований
- •Уровни зрелости требований Уровень 0 – Отсутствие требований
- •Уровень 1 – Документирование требований
- •Выявление требований
- •Интервью
- •Анализ документации
- •Документирование требований
- •Проверка требований
- •Экспертная оценка
- •Согласование документов
- •Уровень 2 – Организация требований
- •Выявление требований
- •Мозговой штурм
- •Анализ требований Уточнение требований
- •Документирование требований
- •Проверка требований Коллективная проверка
- •Документ замечаний
- •Управление изменениями требований База данных требований
- •Управление версиями
- •Уровень 3 – Структурирование требований
- •Планирование процесса План управления требованиями
- •Типы требований
- •Атрибуты требований
- •Выявление требований
- •Варианты использования
- •Прототипы
- •Анализ требований
- •Структуризация требований
- •Определение значений атрибутов
- •Документирование требований Шаблоны требований
- •Модели требований
- •Проверка требований
- •Контрольные листы
- •Рекомендация
- •Уровень 4 – Трассировка требований
- •Выявление требований
- •Анализ требований Иерархия типов требований
- •Отношения между требованиями
- •Трассировка требований
- •Анализ влияния
- •Анализ сферы деятельности
- •Документирование требований Типовые решения требований
- •Уровень 5 – Комплексность требований
- •Анализ требований Трассировка на элементы проектирования и тестирования
- •Показатели требований
- •Количественная оценка требований
- •Документирование требований
- •Заключение
- •Литература
Пользовательские требования
«Пользовательские требования» (user requirements) описывают цели и задачи, которые пользователи смогут решать при помощи системы.
«Пользовательские требования» описывают систему с точки зрения конечного пользователя, т.е. человека, который непосредственно будет работать с системой. Зачастую на практике «пользовательские требования» идут в разрез с «бизнес требованиями». Для примера, заказчик хочет сделать дешевую систему, пользователь, напротив, желает работать с удобным пользовательским интерфейсом, реализация которого дорого обойдется заказчику. Подобные противоречия должен идентифицировать и решать системный аналитик.
«Пользовательские требования» также могут описываться с помощью вариантов использования. В этом случае строится модель вариантов использования, и пишутся сценарии вариантов использования.
Функциональные требования
«Функциональные требования» (functional requirements) определяют функциональность программного обеспечения, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках «пользовательских» и «бизнес требований». Иногда они называются требованиями поведения (behavioral requirements), т.к. они описывают детальное поведение системы, выполняемые ею действия и отклики, а также информацию, которой система будет управлять. Так как «функциональное требование» является низкоуровневым описанием действий системы, их часто описывают в виде методов (операций) класса и данных, которые обрабатываются в конкретном методе. «Функциональные требования» документируются в спецификации требований к программному обеспечению (техническом задании) или постановках задач на разработку.
Характеристики качества
«Характеристики качества» (quality of service) описывают цели и атрибуты качества разрабатываемой системы. Атрибуты качества системы (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся:
легкость и простота использования (usability)
производительность (performance)
удобство эксплуатации и технического обслуживания (maintainability)
надежность и устойчивость к сбоям (reliability)
взаимодействия системы с внешним миром (interfaces)
расширяемость (scalability)
требования к пользовательским и программным интерфейсам (user and software interface).
«Характеристики качества» определяются для каждого варианта использования системы (совокупности вариантов использования) или для системы в целом.
«Характеристики качества» не описывают то, что система должна делать, они описывают то, как система должна или не должна работать. Например, для варианта использования «Зарегистрировать читателя» могут быть определены:
требование производительности: «После ввода данных о читателе, в случае уникального имени, система должна закончить транзакцию и распечатать чек в течение 3 секунд».
требование к интерфейсам: «Система должна взаимодействовать с существующей системой «Наша библиотека» для доступа к базе данных учебно-методической литературы»
На рис. 1 представлена примерная классификация характеристик качества программного обеспечения:
Рис 1. Классификация характеристик качества