Формирование видения

Видение / Рамки
Формирование видения
Концепция
Границы
Видение
Рамки
Образ
Контекст

ГОСТ 34.601-90
Формирование видения

RUP
Формирование видения

RUP – шаблон
для формулировки проблемы
Формирование видения

Идентификация совладельцев.
Определение границ системы.
Идентификация совладельцев предполагает поиск и фиксацию интересантов проекта – представителей Заказчика и Исполнителя, инвесторов, внешних экспертов и пр.
Определение границ системы представляет собой нетривиальный процесс. Для этого используют контекстные диаграммы.
RUP в поиске границ предлагает отталкиваться от акторов и вариантов использования.
Формирование видения

Классификация ограничений
Формирование видения

Шаблон документа «Vision» RUP
Введение
Позиционирование
Описания совладельцев и пользователей
Краткий обзор изделия
Возможности продукта
Ограничения
Показатели качества
Старшинство и приоритеты
Другие требования к изделию
Требования к документации
Приложение.
Формирование видения

Vision / Scope (MSF)
Согласно белой книге MSF, на фазе выработки концепции (envisioning phase) закладывается одна из фундаментальных основ успеха проекта – создание и сплочение проектной группы на основе выработки единого видения.
Проектная группа должна четко представить себе, что она хочет сделать для заказчика и сформулировать свою цель таким образом, чтобы максимально мотивировать как заказчика, так и саму проектную команду.
Выработка высокоуровневого взгляда на цели и условия проекта может рассматриваться как ранняя форма планирования.
Формирование видения

MSF – envisioning phase
Основными задачами фазы выработки концепции являются создание ядра проектной группы и подготовка vision/scope document.
Видение (vision) – это ничем не ограничиваемое представление о том, каким должно быть решение
Рамки (scope) же дают четкие границы того, что из предложенного этим видением будет реализовано в условиях существующих проектных ограничений.
Формирование видения

Шаблон документа «Vision/Scope» MSF
Бизнес-преимущества
1.1. Описание преимуществ
1.2. Формулировка видения
1.3. Анализ выгод
Концепция решения
2.1. Цели, задачи, предположения и ограничения
2.2. Анализ применимости
2.3. Требования
Рамки
3.1. Список характеристик/функций
3.2. Вне рамок
3.3. Стратегия подготовки релизов
3.4. Критерии применимости
3.5. Эксплуатационные критерии
Стратегии проектирования решения
4.1. Стратегия проектирования архитектуры
4.2. Стратегия технического проектирования
Формирование видения

Классификация и специфицирование требований
Лекция № 8
Специфицирование требований

Требования совладельцев
Результатом выявления требований, является реестр требований.
Требования совладельцев обычно оформляются в простой письменной форме, без какой-либо особой регламентации.
Пример оформления требования к программе электронной почты – «Система должна позволять набирать текст сообщения с возможностью форматирования текста и вставки смайликов».
Специфицирование требований

Акторы и варианты использования
Самым популярным и весьма эффективным способом повышения информативности требований является оформление их в виде вариантов использования, предложенный И.Якобсоном.
Прежде, чем приступить собственно к специфицированию требований в форме вариантов использования, RUP рекомендует выявить реестр акторов (actors) и вариантов использования (use cases).
Специфицирование требований

Актор
Актор – это некто или нечто, обладающее активностью по отношению к программной системе.
Помимо пользователя в качестве актора может рассматриваться другая программная система, аппаратное устройство, в ряде случаев – активная компонента самой системы.
Специфицирование требований

Вариант использования
Вариант использования (прецедент) в первом приближении можно рассматривать, просто, как функцию, реализуемую системой.
вариант использования должен быть полезен конкретному актору.
вариант использования должен позволять получать ему конкретные законченные результаты
Специфицирование требований

Глоссарий
Служит основой для единообразного понимания описаний требований Заказчиком и Разработчиком.
Является отправной точкой для построения более развёрнутых моделей проблемной области, которые, на стадии реализации информационной системы, ложатся в основу объектной модели (для объектно-ориентированных приложений) и модели данных (для генерации схемы базы данных).
Оформляется, как текст, состоящий из абзацев, каждый из которых определяет значение одного из терминов проблемной области. Термин обычно выделяют полужирным кеглем.
Иногда проблемную область целесообразно сегментировать на ряд «подобластей» (subject areas). Тогда каждой из них в глоссарии выделяется отдельный параграф.
Специфицирование требований

Спецификации прецедента
Свободный
формат
Специфицирование требований
Полный
формат
Таблица
в три
колонки
Язык
описания
алгоритма
Стиль
RUP
Таблица
в две
колонки
Псевдокод
Диаграмма
активности UML
Другие
графические
модели

Полный формат
Название
Контекст использования
Область действия
Уровень
Основное действующее лицо
Участники и интересы
Предусловие
Минимальные гарантии
Гарантии успеха
Триггер
Основной сценарий
Расширения
Список изменений в технологии и данных
Вспомогательная информация
Специфицирование требований

Таблица в 2 колонки
Специфицирование требований

Таблица в 3 колонки
Специфицирование требований

Формат RUP
Наименования и краткое описание
Поток событий
2.1. Основной поток
2.2. Альтернативные потоки
Специальные требования
Предусловия
Постусловия
Точки расширения
Специфицирование требований

Спецификация нефункцио- нальных требований
Описание нефункциональных требований обычно осуществляется в форме, близкой к свободному формату описания варианта использования.
RUP рекомендует концентрировать нефункциональные требования в документе, описывающем вариант использования во всех случаях, когда это возможно.
В случае, если нефункциональные требования носят общий характер, они выносятся в документ «Дополнительная спецификация».
Специфицирование требований