Управление требованиями: практическое руководство для бизнес-аналитика

Требования — это мост между потребностью и системой. Самые дорогие ошибки в проектах случаются не в коде, а раньше: когда неверно поняли проблему, упустили стейкхолдера или размыли границы системы. Управление требованиями делает такие ошибки видимыми и управляемыми, пока их ещё дёшево исправить.

Это не разовый «сбор требований». Требования меняются на протяжении всего проекта, и вопрос лишь в том, ведём ли мы их осознанно — или догоняем постфактум.

И ещё одно, что стоит усвоить сразу: мы описываем проблему пользователя — что ему нужно и зачем, — а не интерфейс, через который он это получит. К этому различию мы ещё не раз вернёмся.

Вся дальнейшая работа подчинена двум целям.

1. Понять границы системы — что входит в систему, а что остаётся во внешнем мире. Пока граница размыта, любые оценки и договорённости зыбки.
2. Определять систему итеративно — определение системы не фиксируется в первый день, а уточняется за несколько проходов, каждый раз становясь точнее.

Эти две цели проходят через всё руководство; к ним мы будем возвращаться в каждой главе.

Материал выстроен от понятий к практике.

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

Итог руководства — не теория, а рабочие мастера: наборы вопросов, отвечая на которые аналитик наполняет каждый артефакт осмысленно и ничего не упуская.

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

Требования делятся на два больших семейства.

• Функциональное требование описывает, что система делает — конкретное поведение или реакцию на событие. Пример: «При смене статуса заявки система уведомляет клиента».
• Нефункциональное требование описывает, какой система должна быть — качества и ограничения, которые касаются работы системы в целом: производительность, надёжность, безопасность, удобство использования, соответствие нормам. Пример: «Уведомление доставляется не позднее 60 секунд».

Разница практична, а не умозрительна: функциональные требования удобно фиксировать в контексте — через юз-кейсы (см. ниже), тогда как нефункциональные пронизывают всю систему и собираются отдельно. К обоим семействам мы вернёмся, когда будем разбирать артефакты.

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

За требованиями стоят потребности. Потребность — это глубинная проблема или цель стейкхолдера, выраженная в его мире, а не в терминах системы: «мне нужно видеть статус заявки, не звоня в отдел». От потребности следует отличать запрос стейкхолдера — конкретную просьбу в формулировке самого стейкхолдера: «сделайте кнопку выгрузки в Excel».

Запрос — это ещё не требование. Запросы приходят сырыми: они бывают противоречивыми, избыточными, а нередко представляют собой замаскированное решение вместо настоящей потребности. Работа аналитика — докопаться до потребности за запросом и перевести её в требование: проверенное, непротиворечивое и проверяемое. Эту цепочку — потребность → запрос → требование — мы будем встречать постоянно.

В отдельную ловушку особенно легко попадает аналитик, пришедший с конкретным продуктом за плечами — BPMS, фреймворком, базой данных. Он невольно описывает потребности в терминах знакомого интерфейса: экранов, форм, кнопок, отчётов. Стейкхолдер говорит «мне нужно сгенерировать отчёт по просроченным заявкам» — и это уже готовое решение, подсмотренное в прежней системе. Настоящая потребность звучит иначе: «мне нужно знать, какие заявки просрочены».

Разница принципиальна. «Сгенерировать отчёт» — это как; «знать, что просрочено» — это что и зачем. Требования живут в проблемном пространстве: они фиксируют, что пользователю нужно и почему, а не через какой экран он это получит. Способ — отчёт, уведомление, дашборд — выбирается позже, при проектировании, и нередко оказывается совсем не тем, что представлялось вначале.

Приём прост: поймав себя на «интерфейсном» существительном («отчёт», «форма», «кнопка», «экран»), спросите «зачем оно нужно?» — и запишите ответ. Он и есть требование.

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

Полезно не путать стейкхолдера и актора. Стейкхолдер заинтересован в системе; актор непосредственно взаимодействует с ней. Эти множества пересекаются, но не совпадают: регулятор — стейкхолдер, но обычно не актор; оператор ночной смены — и актор, и стейкхолдер; спонсор — стейкхолдер, но актором бывает редко.

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

Система — это то, что мы создаём или изменяем; она и есть предмет всей работы с требованиями. А границы системы — это черта, отделяющая то, что внутри системы (за что мы отвечаем, что определяем и строим), от внешнего мира (акторы, внешние системы — всё, с чем система взаимодействует, но чем мы не управляем).

Именно граница — самое важное и самое недооценённое понятие в этой главе. Почти все дорогие ошибки на старте — это ошибки границы: когда неясно, где система заканчивается, требования расползаются, оценки плывут, а команда спорит, «наше это или не наше». Точно проведённая граница отвечает сразу на два вопроса: что мы обязаны сделать (то, что внутри) и с чем мы обязаны корректно взаимодействовать (то, что снаружи). Акторы — это как раз обитатели внешнего мира на самой границе: они касаются системы, но в неё не входят.

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

Главная установка: требования нельзя угадать заранее и зафиксировать раз и навсегда. Процесс устроен как цикл, в котором каждый оборот опирается на то, что выяснилось на предыдущем. Диаграмма выше читается не сверху вниз одним махом, а по контурам: есть основной поток и три петли, которые к нему возвращают. Разберём их по порядку.

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

Разные точки входа отражают разное состояние знания. Для новой системы главный риск — неверно понятая проблема; для существующей — упущенные потребности.

Для новой системы за анализом проблемы следует проверка: верно ли мы поняли проблему? Если [неверная проблема] — возвращаемся к анализу. Это первая петля. Только убедившись, что мы работаем над верной проблемой, идём дальше — к определению системы. Эта петля защищает от самой дорогой ошибки в разработке: безупречно решить не ту задачу.

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

Здесь вторая петля. Если [не успеваем весь объём], мы возвращаемся и сужаем границы: что-то выносим за пределы системы, что-то откладываем на будущее. Когда объём укладывается в границы, переходим к уточнению. Управление границами — это не разовое решение, а сознательный торг между желаемым и посильным.

Уточнение определения системы — проход, на котором мы углубляем уже определённое: подробнее описываем юз-кейсы, добавляем нефункциональные требования, снимаем неоднозначности. После уточнения — третья развилка. Если [нужны ещё итерации] — возвращаемся к определению системы и делаем ещё проход, каждый раз с более точными границами. Если определение требований завершено — выходим из цикла.

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

Три петли — проблемная, объёмная и итерационная — это не пустые повторения. На каждом обороте они сближают две цели работы: границы становятся реалистичнее, а определение системы — точнее. Так процесс сходится: каждая итерация сужает неопределённость, пока определение не станет достаточно полным, чтобы на нём можно было строить.

Именно поэтому работа с требованиями итеративна по своей природе. Правильные границы и точное определение системы невозможно угадать в первый день — к ним приходят проходами, и петли обратной связи и есть тот механизм, который ведёт от приблизительного к достаточному.

Каждый артефакт отвечает на свой, отдельный вопрос. Если убрать любой из них, образуется пробел; если добавить ещё — появляется дублирование.

• Виденье — какую проблему мы решаем, для кого и что система собой представляет в целом.
• Запросы стейкхолдеров — что именно просят и в чём нуждаются стейкхолдеры, в их собственных словах.
• Глоссарий — что означают термины проекта, чтобы все понимали их одинаково.
• Спецификация требований к ПО — что система должна делать и какой быть, в подробностях, достаточных для реализации.

Четыре вопроса — четыре артефакта верхнего уровня. Всё остальное — это внутренняя структура одного из них — спецификации требований к ПО.

Набор устроен иерархически: часть артефактов вложена в другие.

Логика вложенности проста. Спецификация требований к ПО — это контейнер требований к системе; она складывается из двух частей: дополнительной спецификации (нефункциональные и сквозные требования — то, что относится ко всей системе) и модели юз-кейсов (функциональные требования, поданные в контексте). Модель юз-кейсов, в свою очередь, — это не единый документ, а структура из акторов и юз-кейсов: ролей снаружи системы и способов, которыми они ей пользуются.

Остальные три артефакта самостоятельны. Виденье смотрит на систему сверху — проблема, стейкхолдеры, ключевые фичи, границы. Запросы стейкхолдеров хранят сырой вход — то, что прозвучало, ещё не превращённое в требования. Глоссарий обслуживает всех — это общий словарь проекта.

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

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

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

Чтобы набор оставался минимальным, оговорим, чего в нём нет и почему.

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

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

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

Виденье собрано из нескольких блоков. Разберём их смысл; наполнять будем в мастере.

• Введение. Назначение документа, границы системы (что внутри, что снаружи), определения терминов и ссылки на смежные документы. Блок границ здесь — письменное продолжение того, о чём шла речь в главе о понятиях: именно тут граница системы впервые закрепляется на бумаге.

• Позиционирование. Зачем система бизнесу. Держится на двух коротких, но важных шаблонных формулировках. Первая — формулировка проблемы:

  Таблица 1.: Формулировка проблемы — шаблон из четырёх строк.

  Проблема
  затрагивает
  и её последствие —
  а удачным решением было бы

  Вторая — формулировка позиционирования продукта: одно ёмкое утверждение о том, кому и зачем нужен продукт и чем он отличается от существующего:

  Таблица 2.: Формулировка позиционирования продукта — шаблон.

  Для	(целевые стейкхолдеры)
  которые	(их роль или задача)
  название системы — это	(категория продукта)
  который	(ключевая выгода)
  В отличие от	(нынешнее решение, альтернатива)
  наш продукт	(в чём отличие)

• Описание стейкхолдеров и пользователей. Кто заинтересован и кто пользуется: сводка стейкхолдеров, сводка пользователей, их рабочая среда, ключевые потребности и существующие альтернативы. Ключевые потребности удобно свести в таблицу:

  Таблица 3.: Ключевые потребности стейкхолдеров.

  Потребность	Приоритет	Что беспокоит сейчас	Текущее решение	Предлагаемое решение

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

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

Пройдите блоки по порядку. На каждый — один-два вопроса; отвечайте кратко, только самое важное. Если ответа пока нет — это сигнал, что здесь нужна ещё одна беседа со стейкхолдером.

Границы (Введение)

1. Что входит в систему, а что остаётся снаружи, во внешнем мире?
2. На какие смежные системы, подразделения или процессы проект повлияет?

Позиционирование

1. Проблема: в чём она? кого затрагивает? в чём её последствия? каким было бы удачное решение? — четыре ответа складываются в формулировку проблемы.
2. Для кого продукт и в чём его ключевая выгода? чем он отличается от того, что есть сейчас? — ответы складываются в формулировку позиционирования.

Стейкхолдеры и пользователи

1. Кто основные стейкхолдеры и в чём интерес каждого?
2. Кто пользователи и в какой среде они работают?
3. Каковы их ключевые потребности? Для каждой: насколько она приоритетна, что беспокоит сейчас, как задача решается сегодня и как предлагается решать. Формулируйте потребность как проблему («узнать…», «убедиться…»), а не как экран или отчёт (см. «Что» и «зачем», а не «как»).
4. Есть ли альтернативы или конкуренты, с которыми нас будут сравнивать?

Обзор продукта

1. Как система вписывается в окружение — с чем соседствует и от чего зависит?
2. Каковы её ключевые возможности в двух-трёх фразах?
3. Какие допущения мы принимаем и от чего зависим?

Фичи

1. Назовите самые важные фичи — по одной строке на каждую. Список держите коротким; мелочи сюда не попадают.

Ограничения и приоритеты

1. Какие ограничения заданы заранее (технологии, стандарты, сроки, бюджет)?
2. Какие верхнеуровневые ориентиры по качеству важны (скорость, доступность, безопасность)?
3. В каком порядке важности идут фичи?

Ответив на эти вопросы коротко, вы получаете Виденье — общую рамку, на которую дальше опираются глоссарий, запросы стейкхолдеров и спецификация требований. Помните, что Виденье уточняется от итерации к итерации: первый проход даёт грубый набросок, последующие — всё более точную картину.

Правило простое: одно слово — одно значение на весь проект. Большинство скрытых разногласий рождается там, где люди используют одно слово в разных смыслах — «заявка», «клиент», «счёт», — и замечают это слишком поздно. Глоссарий снимает эти споры заранее.

Глоссарий растёт вместе с проектом: как только термин начинает требовать пояснения, он попадает в словарь. Остальные артефакты — Виденье, запросы стейкхолдеров, спецификация требований — опираются на него и не переопределяют термины у себя на месте.

Реальный шаблон краток и состоит всего из двух блоков.

• Введение. Назначение глоссария и его охват — на какую предметную область он распространяется.
• Определения. Собственно термины и их значения. Каждый термин — короткое, однозначное определение своими словами; при необходимости термины группируют по темам. Синонимы и сокращения указывают рядом с термином.

Какие термины включать

1. Термины предметной области, у которых на этом проекте есть особое значение.
2. Слова, которые разные стейкхолдеры понимают по-разному.
3. Сокращения и аббревиатуры.

Как писать определение

1. Одно-два предложения, не ссылаясь на само определяемое слово; на языке предметной области, а не реализации.
2. Если у термина есть синонимы — перечислите их; если есть похожий термин, с которым его путают, — отметьте различие.

Когда добавлять

1. Как только термин впервые вызвал вопрос «а что мы под этим понимаем?» — он готов к внесению в глоссарий.

Назначение артефакта — собрать в одном месте все запросы, поступившие на проект, и зафиксировать, что с каждым из них стало. Это входная воронка требований.

Здесь важно вспомнить цепочку из главы о понятиях: потребность → запрос → требование. Запрос — это ещё не требование, а сырой вход, который предстоит осмыслить. Источники запросов разнообразны: интервью и совещания, запросы на изменение, запросы предложений, обращения в поддержку. Через этот же артефакт проходит и новый вход из параллельной ветви процесса — управления изменяющимися требованиями.

Главное правило: не терять ни один запрос. Даже отклонённый запрос остаётся в списке — с пометкой, почему он отклонён.

• Введение. Назначение, охват и источники запросов.

• Список запросов. Каждый запрос сопровождается набором атрибутов. Набор подбирается под проект, но полезный минимум таков:

  Таблица 4.: Атрибуты запроса стейкхолдера.

  Атрибут	Что фиксирует
  Источник / стейкхолдер	кто высказал запрос
  Формулировка	что именно просят — в словах стейкхолдера
  Обоснование	какая потребность стоит за запросом
  Приоритет	насколько это важно
  Статус	как запрос обработан

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

По каждому запросу

1. Кто его высказал — конкретный стейкхолдер или источник?
2. Что именно просят — в словах самого стейкхолдера, а не в вашей интерпретации?
3. Зачем это нужно — какая потребность стоит за запросом?
4. Насколько это приоритетно для стейкхолдера?
5. Каков статус: принят, отклонён, отложен, уже превращён в требование? Если отклонён — почему?

Охват

1. Всем ли стейкхолдерам дали возможность добавить свои запросы? Пропущенный стейкхолдер — это пропущенный пласт запросов, который всплывёт поздно.

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

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

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

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

За несколько итераций мы:

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

Вместе это — спецификация требований и Виденье: минимальный, но полный набор артефактов.

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

И это ровно то, что нужно для следующего этапа — проектирования системы. На чистом проблемном пространстве проектировщик выделяет ограниченные контексты, определяет подсистемы, выстраивает слоистую архитектуру. Наши артефакты дают ему весь необходимый вход — и ни одним преждевременным решением не связывают ему руки.

Требования не застывают. Они уточняются от итерации к итерации, а параллельная ветвь управления изменениями постоянно приносит новый вход. Значит, артефакты постоянно обновляются — и это порождает отдельную дисциплину: хранение их версий. Кто, когда и что изменил; какая редакция действует сейчас; чем текущая отличается от согласованной. Управление версиями артефактов выходит за рамки этого руководства, но помнить о его необходимости важно: без него набор артефактов быстро перестаёт отражать реальность.

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

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

Два продолжения этой работы лежат за пределами руководства, но о них стоит знать.

• Матрица трассируемости. Для крупной системы связи между требованиями и тем, что из них следует, оформляют в виде матрицы трассируемости. Она позволяет при изменении требования наверху увидеть и поправить всё, что от него зависит внизу — вплоть до решения и кода. Построение и ведение такой матрицы — отдельная дисциплина (мы уже оговаривали, что трассируемость живёт вне этого руководства).
• Приёмочные тесты. Приёмочные тесты формируются напрямую из юз-кейсов и нефункциональных требований и поддерживаются в согласии с ними при каждом изменении. Идея проста: если система проходит приёмочные тесты, значит, она в основном удовлетворяет требованиям. Так требования замыкаются на проверку, а не остаются декларацией.

На этом набор мастеров завершается. Следуя им, аналитик описывает систему честно и полно — со стороны потребности, — и передаёт дальше не догадки, а проверяемую основу для проектирования, договорённостей и приёмки.