Инженерия требований

Документ «Видение» в RUP

Коротко В Rational Unified Process (RUP) «Видение» (Vision) — короткий документ о том, что представляет собой продукт, зачем его создают, кому он служит и каковы его основные функции. Команда опирается на него при принятии решений на протяжении всего проекта и сверяется с ним при приёмке.

По материалам: шаблон Vision из IBM RUP; статья «Разработка видения системы в методологии IBM RUP»; Ю. А. Маглинец, «Анализ требований к информационным системам», лекция 4; Д. Леффингуэлл, Д. Уидриг, «Принципы работы с требованиями к программному обеспечению», гл. 4 и 17.

На этой странице

Главные идеи#

Почему это важно#

Статья о документе «Видение» в RUP ссылается на отчёт CHAOS Standish Group: наряду с поддержкой руководства и участием пользователей к самым сильным факторам успеха относятся ясные цели и минимальные границы проекта. Документ «Видение» дёшево фиксирует на бумаге и то и другое. В других методах такой документ называют концепцией проекта.

Структура#

Шаблон RUP состоит из шести основных частей: введение, позиционирование, описание заинтересованных сторон и пользователей, обзор продукта, функции продукта и ограничения (диапазоны качества, стандарты, системные требования, требования к производительности и к документации). Что входит в каждую часть, показывает схема в разделе «Шаблон» ниже. Основную работу делают два пункта из части «Позиционирование».

Постановка проблемы (problem statement) состоит из четырёх элементов: проблема, кого она затрагивает, каковы её последствия и что даст хорошее решение. Формат взят из пятишагового анализа проблемы Леффингуэлла и Уидрига. Позиционирование продукта (position statement) строится на ключевых словах Джеффри Мура: целевой клиент, потребность, продукт, категория, ключевая выгода, основная альтернатива, ключевое отличие.

Функции и их атрибуты#

Леффингуэлл и Уидриг рекомендуют описывать продукт примерно 25–99 функциями (features): этого достаточно, чтобы увидеть целое, и достаточно мало, чтобы управлять. У каждой функции есть атрибуты: статус (предложена, одобрена, включена), выгода (критическая, важная, полезная), трудоёмкость, риск, стабильность, целевой релиз, ответственный и обоснование. Те же атрибуты используются в плане управления требованиями, поэтому функции сразу встраиваются в трассировку.

Видение и границы#

Маглинец подчёркивает, что это разные вещи и нужны обе. Видение намеренно ничем не ограничено: оно описывает, каким было бы идеальное решение, чтобы планирование начиналось с целей, а не с сегодняшних ресурсов. Границы (scope) — это ограниченная часть видения, которую вы действительно построите в пределах сроков, бюджета и численности команды.

Хорошее видение помогает заказчику увидеть проблему за проблемой и улучшить бизнес, а не просто автоматизировать сегодняшний процесс. Маглинец приводит слова Г. Калянова: автоматизировать процессы такими, как они есть, — всё равно что асфальтировать коровьи тропы.

Родственные форматы#

  • ГОСТ 34.601-90 («Автоматизированные системы. Стадии создания») выделяет отдельную стадию разработки концепции и требует нескольких альтернативных концепций, чтобы заказчик выбирал, а не придумывал сам. См. ГОСТы на автоматизированные системы.
  • MSF vision/scope (Microsoft Solutions Framework) в изложении Маглинца охватывает бизнес-преимущества, концепцию решения, границы и стратегию релизов, а также стратегии проектирования; параллельно готовится оценка рисков.

Delta Vision для следующих релизов#

Леффингуэлл и Уидриг отмечают, что переписывать полный документ «Видение» для версии 2.0 — пустая трата сил, к тому же так не видно, что изменилось. Сохраните версию 1.0 как базовую и напишите Delta Vision («дельта-видение») — документ только с отличиями: новые функции, удалённые функции (оказавшиеся ненужными или заменённые) и вновь выявленные будущие функции. Вместе два документа описывают продукт версии 2.0.

Та же идея помогает с унаследованными системами: разберитесь в текущем поведении по коду, спецификациям и знаниям команды, а затем документируйте только то, что меняет этот релиз.

Как применять#

  1. Напишите постановку проблемы вместе со спонсором. Если не удаётся заполнить все четыре элемента, вы ещё не готовы описывать продукт.
  2. Напишите позиционирование продукта и проверьте его на нескольких заинтересованных сторонах, с каждой по отдельности.
  3. Составьте профили заинтересованных сторон и пользователей; перечислите ключевые потребности с приоритетами.
  4. Вместе с заказчиком и разработчиками составьте список из 25–99 функций.
  5. Сделайте экспресс-оценку, как описывает Маглинец вслед за Леффингуэллом: заказчик оценивает приоритет каждой функции, разработчики — трудоёмкость и риск, всё по трёхбалльной шкале. Сведите оценки в одну таблицу и выберите первую базовую версию.
  6. Запишите ограничения, получите подпись и при приёмке сверяйте поставленный продукт с документом «Видение».
  7. Для следующего релиза напишите Delta Vision.

Шаблон#

Шаблон
# Видение: <название продукта>, версия <n>

## 1. Введение — назначение, область действия документа, термины, ссылки
## 2. Позиционирование
- Возможность — почему именно сейчас
- Постановка проблемы — проблема / кого затрагивает / последствия / выгоды хорошего решения
- Позиционирование продукта — клиент / потребность / продукт / категория / выгода / альтернатива / отличие
## 3. Заинтересованные стороны и пользователи
- Профили заинтересованных сторон — представитель, обязанности, критерии успеха, вовлечённость
- Профили пользователей — кто пользуется, как часто, уровень подготовки
- Ключевые потребности — потребность, приоритет, нынешний обходной путь
- Альтернативы — что пользователи делали бы без этого продукта
## 4. Обзор продукта
- Место продукта — самостоятельный продукт или часть более крупной системы
- Возможности, допущения и зависимости
- Стоимость, цена и лицензирование — если применимо
## 5. Функции — 25–99 пунктов; для каждой: ID, описание, статус, выгода, трудоёмкость, риск, целевой релиз
## 6. Ограничения — диапазоны качества, стандарты, платформа, производительность, документация

Пример#

«Мастерская» (вымышленная сеть из 12 веломастерских):

  • Постановка проблемы: клиенты не видят, на каком этапе их ремонт; это затрагивает клиентов и сотрудников стойки приёма; последствия — постоянные звонки и напрасные поездки; хорошее решение сократит число звонков и освободит сотрудников для клиентов в мастерской.
  • Позиционирование продукта: для велосипедистов, которым нужен ремонт без напрасных поездок, «Мастерская онлайн» — сервис записи и отслеживания, который показывает реальный статус ремонта. В отличие от звонка в мастерскую, он работает круглосуточно.
ID Функция Выгода Трудоёмкость Риск Релиз
F1 Онлайн-запись на ремонт Критическая Средняя Низкий 1.0
F2 Уведомления клиентов о статусе Критическая Средняя Средний 1.0
F3 Подсказки управляющим о дозаказе запчастей Полезная Высокая Высокий 2.0

Подводные камни#

  • Сотни функций. Это спецификация, а не видение. Сгруппируйте их в 25–99.
  • Видение, которое описывает только сегодняшний процесс. Спросите, каким должен стать бизнес.

Источники и что почитать#

  • Шаблоны документов IBM Rational Unified Process (RUP): Vision.
  • Разработка видения системы в методологии IBM Rational Unified Process (статья) — структура документа и доводы в пользу «Видения».
  • Ю. А. Маглинец. Анализ требований к информационным системам: конспект лекций. Красноярск: Сибирский федеральный университет, 2007. Лекция 4 (видение и границы, стадия концепции по ГОСТ, MSF vision/scope, экспресс-оценка).
  • D. Leffingwell, D. Widrig. Managing Software Requirements: A Unified Approach. Addison-Wesley, 2000. Рус. изд.: Д. Леффингуэлл, Д. Уидриг. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. М.: Вильямс, 2002. Гл. 4 (постановка проблемы), гл. 17 (документ «Видение», Delta Vision).
  • Standish Group. CHAOS report (цитируется по статье о документе «Видение» в RUP).