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

Документ концепции и границ

Коротко Документ концепции и границ (vision and scope document) фиксирует бизнес-требования проекта: зачем он нужен, как будет измеряться успех и что входит и не входит в каждый выпуск. После согласования он становится фильтром для каждого нового запроса на функцию.

По материалам: К. Вигерс, Дж. Битти, «Разработка требований к программному обеспечению», 3-е изд., гл. 5.

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

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

Концепция — это не границы#

Вигерс и Битти разделяют две вещи, которые команды часто смешивают:

  • Концепция продукта (product vision) описывает продукт целиком и то, куда он движется. Она меняется медленно, вместе со стратегией.
  • Границы проекта (project scope) описывают, что даст один выпуск или одна итерация. Они меняются гораздо чаще, и чем дальше выпуск, тем размытее его границы.

Каждый уровень должен укладываться в рамки уровня выше: пользовательские требования служат бизнес-целям, функциональные требования — пользовательским. Если что-то не удаётся проследить вверх, поставьте это под сомнение.

Что содержит документ#

Шаблон авторов состоит из трёх частей: бизнес-требования (зачем), границы и ограничения (что — по выпускам — и чего не будет) и бизнес-контекст (кто и с какими приоритетами). Структура в разделе «Шаблон» ниже повторяет эту схему.

Список того, что не входит в границы, окупает затраченные усилия. Если записать, чего вы не будете делать, спор решится один раз, а не будет возобновляться каждый месяц.

Цели, которые можно проверить#

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

Вигерс и Битти предупреждают и о другом: измеряйте то, что важно, а не то, что легко измерить. Цель «сократить производственные затраты на 20%» можно выполнить за счёт увольнений, а спонсор редко имеет в виду именно это.

Чтобы перейти от расплывчатых проблем к измеримым целям, авторы описывают модель бизнес-целей (business goal model), которую они возводят к Битти и Чену (Chen). Вы по кругу задаёте спонсору три вопроса:

  • Что мешает нам достичь этой цели? (ведёт вниз, к более конкретной проблеме)
  • Почему эта цель для нас важна? (ведёт вверх, к проблеме более высокого уровня)
  • Как мы поймём, что проблема решена? (ведёт к измеримой цели)

Положение о концепции#

Краткое положение о концепции (vision statement) строится по ключевым словам «презентации для лифта» (elevator pitch) Джеффри Мура: целевой клиент, потребность, продукт, категория, ключевое преимущество, текущая альтернатива и главное отличие. Его настоящая ценность — в проверке: когда несколько заинтересованных сторон пишут его по отдельности, расхождения выявляют несовпадающие ожидания ещё до начала работы.

Риски, предположения и приоритеты#

  • Отделяйте бизнес-риски (конкуренция, время выхода, принятие пользователями) от рисков проекта (кадры, технологии).
  • Записывайте предположения. За целью по выручке часто стоит невысказанное представление о числе клиентов или их тратах. Если оно окажется неверным, записанное предположение объяснит промах и убережёт от поиска виноватых.
  • Отнесите каждое из пяти измерений проекта (функции, качество, сроки, затраты, персонал) к одной из категорий: ограничение (зафиксировано), ведущий фактор (важен, но допускает небольшую гибкость) или степень свободы (здесь менеджер может идти на уступки). Вигерс отмечает, что все пять не могут быть ограничениями — иначе проекту нечем поглощать изменения.

Как показать границу#

Выберите одно представление: контекстную диаграмму (система — один круг, вокруг — внешние сущности и потоки), карту экосистемы (Битти и Чен; на ней видны и системы, связанные лишь косвенно, через общие данные), дерево функций или список событий. То, чего нет на контекстной диаграмме, — тоже информация.

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

  1. Начните с полного шаблона, затем ужмите его под проект. Если обязательный раздел пуст, так и напишите («Бизнес-риски не выявлены»), а не удаляйте его — тогда читатель поймёт, что раздел проверяли.
  2. Задавайте спонсору три вопроса модели целей, пока у каждой проблемы не появится измеримая цель.
  3. Напишите черновик положения о концепции, соберите три-четыре независимые версии и сведите их воедино.
  4. Нарисуйте одну диаграмму границ и составьте список исключений.
  5. Согласуйте пять измерений со спонсором и руководителем проекта.
  6. Пропускайте запросы через фильтр целей: какой цели служит эта функция и какой вклад она вносит?
  7. Объявляйте проект завершённым, когда критерии успеха показывают, что цели, скорее всего, будут достигнуты, а не когда реализована каждая идея. Расплывчатые цели дают проект без ясного конца.

Гибкие (agile) команды редко оформляют этот документ формально, но его содержание по-прежнему важно. Они либо фиксируют длину итерации и позволяют меняться набору историй, либо фиксируют общие границы и дату и подстраивают число итераций. Многие проводят «нулевую итерацию», чтобы согласовать концепцию.

Шаблон#

Шаблон
# Концепция и границы: <название продукта или проекта>

## 1. Бизнес-требования
### 1.1 Исходные данные — ситуация, из-за которой возник проект
### 1.2 Возможность — проблема или рыночный шанс, которым вы занимаетесь
### 1.3 Цели — действие + число + единица измерения + срок
### 1.4 Критерии успеха — как и когда вы проверите каждую цель
### 1.5 Положение о концепции — клиент, потребность, продукт, категория, преимущество, альтернатива, отличие
### 1.6 Бизнес-риски — рынок, время выхода, принятие (риски проекта ведите отдельно)
### 1.7 Предположения и зависимости — допущения, на которых держатся цели

## 2. Границы и ограничения
### 2.1 Основные функции — короткий нумерованный список с постоянными ID
### 2.2 Первый выпуск — какие функции и в каком объёме
### 2.3 Последующие выпуски — предварительное распределение
### 2.4 За границами проекта — что вы точно не будете делать

## 3. Бизнес-контекст
### 3.1 Заинтересованные стороны — кто они, что ценят, чего опасаются
### 3.2 Приоритеты проекта — каждое из пяти измерений: ограничение, ведущий фактор или степень свободы
### 3.3 Развёртывание — площадки, обучение, перенос данных, сроки

Пример#

Для «Мастерской», вымышленной сети из 12 веломастерских:

  • Цель: вдвое сократить число звонков о статусе ремонта в течение шести месяцев после запуска (вымышленный показатель).
  • Положение о концепции: для велосипедистов, которые хотят починить велосипед без лишних поездок, «Мастерская онлайн» — сервис бронирования и отслеживания ремонта, который позволяет записаться на удобное время и следить за ремонтом с телефона. В отличие от звонка в мастерскую, он работает круглосуточно и показывает фактический статус.
  • За границами проекта: онлайн-продажа велосипедов и аксессуаров.
  • Предположение: большинство клиентов могут получать уведомления на телефон.
  • Приоритеты: сроки — ограничение (запуск до весеннего сезона), затраты — ведущий фактор, функции — степень свободы.

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

  • Лозунги вместо целей. Перепишите каждую цель с числом, единицей измерения и сроком.
  • Документ написали один раз и забыли. Возвращайтесь к нему при каждом изменении границ.

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

  • K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013. Рус. изд.: К. Вигерс, Дж. Битти. Разработка требований к программному обеспечению, 3-е изд. М.: Русская редакция; СПб.: БХВ-Петербург, 2014. Гл. 5 (шаблон документа концепции и границ, модель бизнес-целей, измерения приоритетов проекта).