- •Виды, взаимосвязь и свойства требований
- •Что такое «требование»?
- •Виды требований
- •Функциональные требования
- •Нефункциональные требования
- •Нефункциональные требования к продукту
- •Нефункциональные требования к процессу
- •Вопросы для самоконтроля
- •Определение образа и границ проекта
- •Анализ предметной области
- •Анализ осуществимости
- •Определение целей и области действия
- •Документирование образа и границ проекта
- •Вопросы для самоконтроля
- •Выявление требований
- •Определение способа сбора и анализа требований
- •Источники возникновения требований
- •Заинтересованные в проекте лица
- •Опрос (интервью)
- •Подготовка
- •Проведение опроса
- •Определение последующих действий
- •Совместные семинары
- •”Мозговой штурм”
- •Роли во время сеансов
- •Правила проведения сеанса
- •Подготовка к сеансу
- •Проведение сеанса
- •Обработка результатов сеанса
- •Сценарии
- •Сценарии событий
- •Варианты использования
- •Применение модели msc uml
- •Выявление требований на основе различных точек зрения. Метод vord
- •Идентификация точек зрения
- •Структурирование точек зрения
- •Документирование и отображение системы точек зрения
- •Этнографический подход
- •Вопросы для самоконтроля
- •Разработка системных требований
- •Детализация требований пользователей
- •Системные модели
- •Модели потоков данных
- •Модели конечных автоматов
- •Модели данных
- •Прототипы
- •Роль прототипов при разработке требований
- •Виды прототипов
- •Разработка прототипов
- •Экспериментальное прототипирование
- •Эволюционное прототипирование
- •Риски прототипирования
- •Системные требования
- •Структурированный естественный язык
- •Языки описания программ
- •Графические нотации
- •Документирование системных требований
- •Вопросы для самоконтроля
- •Документирование требований
- •Спецификация требований
- •Состав спецификации требований
- •Рекомендации по разработке требований
- •Стандартные шаблоны спецификации
- •Вопросы для самоконтроля
- •Анализ спецификации требований
- •Оценка качества спецификации требований
- •Характеристики качества спецификации
- •Аттестация требований
- •Экспертиза спецификации
- •Прототипирование
- •Автоматизированный анализ
- •Тестирование требований
- •Вопросы для самоконтроля
- •Управление требованиями
- •Причины изменений требований
- •Принципы управления требованиями
- •Управление изменениями
- •Управление версиями
- •Управление связями требований
- •Риски, связанные с требованиями
- •Риски этапа выявления требований
- •Риски этапа анализа и спецификации требований
- •Риски управления требованиями
- •Вопросы для самоконтроля
- •Case-средства для управления требованиями
- •Выбор case-средств для управления требованиями
- •Уровень зрелости и используемые инструменты
- •Моделирование требований
- •Трассировка требований
- •Управление версиями
- •Возможности case-средств управления требованиями
- •Средства idf-моделирования
- •Средства uml
- •Вопросы для самоконтроля
- •Список литературы
Идентификация точек зрения
Первый и наиболее трудный этап формирования требований – выявление и идентификация опорных точек зрения. Для идентификации точек зрения часто используется метод «мозгового штурма», при помощи которого определяются внешние, по отношению к системе и взаимодействующие с ней, сущности и возможные системные сервисы.
«Мозговой штурм» направлен на решение следующих задач:
идентификация потенциальных опорных точек зрения;
идентификация системных сервисов;
определение входных системных данных;
определение нефункциональных требований;
выявление управляющих событий и исключительных ситуаций.
Источниками информации для создания первоначального образа системы являются:
документы, описывающие назначение системы,
знания о предыдущих разработках,
опыт пользователей,
опрос менеджеров, персонала, консультантов, инженеров, клиентов, т.е. лиц, заинтересованных в системе.
Результат «мозгового штурма» – документ, идентифицирующий опорные точки зрения и сервисы системы (см. рис. 3.3).
Структурирование точек зрения
Один и тот же сервис может быть связан с разными точками зрения (если сервис не связан ни с одной точкой зрения, то это значит, что выявлены не все точки зрения). Точки зрения определяют входные данные и управляющую информацию для сервисов.
Информация, полученная при анализе точек зрения и сервисов, служит для организации точек зрения в иерархию наследования. Иерархия определяет, какие подмножества точек зрения наследуют сервисы и управляющую информацию (см. рис. 3.4).
Документирование и отображение системы точек зрения
Следующий этап формирования требований – это детализация информации о сервисах, их входных, выходных и управляющих данных. Эта информация выявляется у лиц, формирующих требования, связанные с каждой опорной точкой зрения. Для этого используются описание точек зрения и описание сервисов в виде сценариев событий.
Пример 3.4.
На рис. 3.4 приведены различные точки зрения на информационную систему архива организации-разработчика программ и некоторые из сервисов этой системы.
Опорные точки зрения (изображены в овалах) – это точки зрения менеджеров проектов, разработчиков систем, сотрудников архива, сторонних организаций (субподрядчиков), службы качества предприятия и службы защиты информации.
На этом же рисунке приведены и некоторые из сервисов, требующихся от системы (приведены в прямоугольниках).
Рис. 3.3
На рис. 3.4 приведена часть иерархии точек зрения на информационную систему архива со связанными с ними сервисами.
Рис. 3.4
Этнографический подход
Программные системы функционируют в определенной социальной и организационной среде, поэтому учет этого факта приводит к повышению комфортности конечного пользователя при ее использовании и, в конечном итоге, к увеличению спроса.
Для определения среды функционирования системы и учета ее в требованиях разработчик должен «погрузиться» в эту среду, каждодневно наблюдая и фиксируя все реальные действия, выполняемые (потенциальными) пользователями, такой подход называется этнографическим [9].
Данный подход позволяет обнаружить неявные требования к системе, которые отражают реальные аспекты ее функционирования и которые часто не определяются другим способом. Наблюдение за каждодневным функционированием организации позволяет выявить ее реальную штатную и топологическую структуру, определить функции организации и их распределение по подразделениям и сотрудникам, установить формы документов, используемых в организации. Этнографический подход позволяет выявить социальные и организационные факторы, влияющие на работу, описать работы, способ выполнения которых определяется, например, их характером, квалификацией и опытом исполнителя.
Этнографический подход используется для выявления требований обычно совместно с другими методами. На рис. 3.5 приведена схема одной из возможных комбинаций методов:
Для сбора начальных требований к системе используется этнографический подход.
Начальные требования обсуждаются и уточняются на совместных семинарах.
Для дальнейшей работы по выявлению и уточнению требований строится прототип системы.
Рис. 3.5