ГЕОРГИЙ САВЕЛЬЕВ
Как разработать
Бизнес-требования
Модель выявления требований
Давайте поговорим о том, откуда берутся требования. И бизнес-требования (БТ), и нефункциональные требования напрямую вытекают из потребностей бизнеса.

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

Из бизнес-требований, помимо функциональных (ФТ) и нефункциональных требований, напрямую могут вытекать ещё и требования причастных сторон. В свою очередь, из требований причастных сторон могут вытекать ФТ и НФТ.

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

Все виды требований возникают в конкретном контексте, то есть следуют из Операционного контекста, к которому относятся активы, спрос, технологии и так далее. Подробнее про влияние контекста на бизнес-требования смотрите в статье Бизнес-требования. Назначение.

В наглядном виде модель выявления требований представлена на схеме:

Модель выявления требований

Почему важно выявлять и документировать
бизнес-требования?
Бизнес-требования играют важную роль на проекте, поскольку помогают определить смысл проекта и обосновать его необходимость. Именно бизнес-требования, как правило, используются для определения рамок проекта, то есть входят в состав концепции проекта.

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

Из БТ вытекают критерии приемки и именно на их основе производится оценка результатов разработки ИТ-решения.

Также бизнес-требования часто используются на проекте для приоритизации решений: если есть понимание, как то или иное решение связано с БТ, приоритизировать его не составит труда. Именно БТ являются снованием для принятия решений в ходе проектирования и внесения изменений в реализацию проекта.

Кроме того, бизнес-требования в Agile — это ключевой инструмент Product Owner для управления бэклогом продукта и ведения переговоров со стейкхолдерами.

Какие бывают бизнес-требования?

Согласно концепции Six Sigma, бизнес-требования — это критичные активности предприятия, подлежащие выполнению для достижения целей организации, вне зависимости от конкретного решения.

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

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

      Примеры БТ:
      • Скорость обслуживания — очередь на кассе должна быть не длиннее 4 покупателей.
      • Своевременность доставки — клиент должен получить пиццу горячей и не умереть ожидая ее.
      • Простота получения услуги — оформление предварительно одобренного кредита должно завершаться за одно посещение клиента.

      Вид БТ: Распознавание и обработка событий

      Примеры БТ:
      • Банк должен своевременно получать оповещения о сбоях в работе банкоматов.
      • К моменту начала этапа работ, все нужные материалы и оборудование должны находиться на объекте строительства и быть готовыми к использованию.
      • Сотрудники должны быть своевременно проинформированы о назначенных им задачах.

      Вид БТ: Принятие решений

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

      Примеры БТ:
      • С момента обнаружения дефекта и до его полного устранения должна регистрироваться и храниться следующая информация.
      • Инвестиционный банк в конце каждого рабочего дня должен направлять Регулятору информацию о…
      • Для принятия решений об участии в тендере необходимы результаты предварительной оценки себестоимости проекта.

      Вид БТ: Обеспечение возможности выполнения действий

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

      Вид БТ: Предотвращение возможности выполнения действий

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

      Требование, заданное с позиции «Система должна делать…», задает конкретное направление действиям разработчика, а также дает некоторые ограничения — в отличие от формулировки требований с позиции «Система не должна…»

      Но, конечно, существуют ситуации, когда необходимо сформулировать требования именно в негативной форме и, чаще всего, это касается решения задач безопасности.
      Признаки проблем в бизнес-требованих
      Можно выделить несколько типичных признаков проблем с бизнес-требованиями.
      • Неконкретность (слишком абстрактная формулировка)
      • Невозможность проверки (нет понимания, что является индикатором выполнения требования)
      • «Магические» числа (приведены какие-то необоснованные данные: «время обработки заявки 14 минут»)
      • Непонятная польза (не написано, для чего делаем то, что делаем; действительно ли это необходимо)
      • Избыточная детализация (зачастую делает требование слишком жестким и нечитаемым)
      • Невыполнимость (например, требование «обеспечить 100%-ую достоверность данных». Для чего это требование? Почему возникают недостоверности? С этой проблемой можно как-то бороться или это просто факт?)
      • Несогласованность (противоречивость; с одной стороны Покупатель хочет найти продукт с наилучшими качествами по наименьшей цене, а с другой — Продавец хочет стимулировать покупку продуктов, приносящих наибольшую прибыль)
      • Нерелевантность (приведено требование, которое вообще не понятно, какое отношение имеет к данному проекту)
      • Привязка к конкретному решению, в том числе — конкретный бизнес-процесс
      Хотелось бы сделать акцент на работе с «Магическими числами», поскольку зачастую такие ошибки в требованиях встречаются даже у опытных аналитиков.
      Работа с «магическими» числами

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

      Любое число (разместим его в центральном круге) проверяется на чувствительность (на рисунке это столбец «чуть-чуть»). Что будет, если число будет немного больше? Есть ли какие-то последствия в таком случае для системы, стейкхолдеров? А если число будет чуть-чуть меньше?

      Затем мы задаем вопросы, пытаясь выявить реальные границы требования. Что, если число будет значительно больше? На что это повлияет? А если влияние достаточно серьезно, то нельзя ли предложить дополнительный способ обойти проблему? Границы обозначены в модели как столбец «гораздо».

      Тест «магических» чисел

      Расмотрим пример требования, которое содержит «магическое» число:
      Требование: Сократить среднее время обработки заявки до 14 минут

      Проверим это требование на чувствительность. Для этого зададим вопросы:

      1. Что будет, если время обработки заявки будет не 14, а 12 минут?
      2. Что, если увеличить до 14,5 мин? Насколько это критично?
      В процессе проверки может выясниться, что обработка заявки может занимать даже 30 минут, не принося никакого ущерба бизнесу.

      Проверим границы требования, ответив на вопросы:
      1. Может быть, целесообразно сократить время обработки до 0 минут, т. е. не обрабатывать заявки и перевести клиента на самообслуживание?
      2. Что будет, если одна заявка будет обрабатываться день? Это плохо? Как это скажется на бизнесе?

      Данный тест помогает понять, является ли число «магическим». Если число связанно с какими-то объективными процессами (например, требованиями законодательства),
      то мы можем определить его чувствительность и границы, а значит появление этого числа в требованиях вполне обосновано.

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

      Попробуем переформулировать требование на примере:
      Исходное требование:
      Оповестить надлежащих стейкхолдер не позднее 5 минут, после наступления события.

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

      Примеры некорректных бизнес-требований

      1. Обеспечить высокое качество обслуживания — Как проверить, что качество обслуживания высокое?
      2. Сократить среднее время обработки заказа до 14 минут — Почему до 14 минут, чем это обосновано? А почему не до 1 минуты? Какую пользу принесет сокращение времени обработки заказа?
      3. Обеспечить 100% достоверность учетных данных — Как мы узнаем какая достоверность? Как можно определить, что данные достоверны? В результате чего возникает недостоверность? С этим реально можно что-то сделать? Выполнимо ли данное требование?
      4. Гарантировать правильность принимаемых решений — Что выступает гарантом? Это выполнимо?
      5. Внедрить ERP — Кому и зачем это нужно? В чем проблема?

        Типовые ловушки аналитика

        Проблемы с требованиями, как правило, возникают, когда аналитик попадает в одни и те же типовые ловушки. Вот основные ловушки аналитика при работе с бизнес-требованиями:

        • Формальность — «пишу, потому что надо здесь что-то написать».
        • Узкие рамки анализа — не рассматриваем ничего, что выходит за рамки проекта.
        • Превращение в аудит — выясняем все обо всем «на всякий случай».
        • Превращение метода в цель — строгое следование определенному шаблону с превращением средств в цель и потерей основной цели проекта.

        Что можно сделать с каждой из этих ловушек?

        Как документируются бизнес-требования?
        В практике бизнес-аналитика присутствует два основных подхода документирования требований:

        1. Монолитно
        • Все требования описываются вместе в виде структурированного повествовательного текста.
        • Возможны ссылки на элементы требований (цели, метрики, предположения, риски и т. п.).

        2. Дробно
        • Каждое требование описывается отдельно.
        • Каждому требованию присваивается уникальный идентификатор.
        • Возможна трассировка к конкретному бизнес-требованию.

        Ниже будет приведен шаблон для каждого из этих видов документирования.

        Где документируются бизнес-требования?
        Стандартом ISO предполагается, что бизнес требования будут отражены монолитно в Спецификации требований стейкхолдеров (StRS). Для этого предусмотрен отдельный раздел Introduction, который включает в себя Business Purpose (цели), Business Scope (границы), Business Overview (обзор бизнеса).

        В ГОСТе 34.602−89 предполагается, что бизнес-требования будут описаны также, монолитом, в техническом задании на создание автоматизированной системы. в разделе Назначение и цели создания системы и Характеристика объектов автоматизации.

        Если говорить о дробном документировании, то чаще всего это подходы, подразумевающие использование Спецификации бизнес-требований (BRD).

        В Agile бизнес-требования могут быть отражены по-разному. Это не формализовано, нет стандарта документов и способов описания.

        Шаблон монолитного описания БТ

        Карл Вигерс в своей книге «Разработка требований к программному обеспечению. Руководство» предлагает хороший шаблон описания БТ монолитом в рамках документа Scope and Vision (рамки и видение). В этом документе выделяется раздел Бизнес-требования, который включает в себя:

        • Контекст.
        • Описание возможности.
        • Бизнес-цели.
        • Метрики успешности.
        • Образ результата (Vision).
        • Деловые риски.
        • Предположения и зависимости бизнеса.

        Советы Вигерса по описанию БТ

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

          Ниже представлен авторский шаблон дробного описания бизнес-требований. Он состоит из нескольких ключевых элементов:
          1. Заголовок, который включает в себя:

          • Уникальный идентификатор.
          • Краткое описание.
          2. Определение, развернутое объяснение, что из себя представляет БТ.
          3. Источник, откуда это требование взялось.
          4. Зависимости, если они есть между другими требованиями.
          5. Обоснование, краткое пояснение мотивации.
          6. Комментарий, любые пояснения. В приведенном ниже примере представлено описание диаграммы состояний.

            Шаблон дробного описания БТ

            Как документировать —
            объединять или дробить?
            Для того чтобы определиться с тем, как документировать, придерживайтесь следующих правил:

            1. Нет нужды документировать, если:
            • Узко-технический проект небольшого объема.
            • Всем все понятно и вряд ли кому-то когда-то что-то будет непонятно.
            2. Объединяем, если:
            • Компактный проект с узкими целями.
            • Узкая предметная область.
            • Бизнес-требования умещаются на паре страниц.
            3. Дробим, если:
            • Много бизнес-требований.
            • Сложные бизнес-требования.
            • Могут реализовываться по отдельности.
            • Высокая степень неопределенности.
            Что делать с отсутствующими или плохими БТ?
            Прежде всего стоит пересмотреть уже имеющиеся требования, разобраться в их назначении и перепроектировать при необходимости. Подобное фундаментальное переосмыс­ление бизнес-процессов называется реинжиниринг.

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

            Полученную информацию необходимо задокументировать одним из нескольких способов:
            1. Создать отдельный документ. Например, «Каталог целей» с дробным документированием бизнес-требований, на которые будем ссылаться.

            2. Добавить комментарии к уже существующим требованиям, поясняя откуда оно взялось.

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

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

            Вопросы и ответы
            Вопрос:
            Что делать, если, помимо ТЗ, есть еще и пользовательские требования?
            Ответ:
            Зачастую пользовательские требования объединяются с бизнес-требованиями, т.к. объем БТ не очень большой, если они правильно определены, а значит делить эти требования на 2 отдельных документа нецелесообразно.
            Во избежание возможного недопонимания, в названии документа можно явно указать «Требования бизнеса и пользователей».

            Вопрос:
            Имеет ли смысл создание промежуточных документов таких как VSD (Vsion & ScopeDocument) и BRD (Business Requirement Document)?
            Ответ:
            С точки зрения Agile практик, бизнес-требования — это епархия Product Owner. Следовательно, работать нужно так, как удобно, и не создавать лишних документов для соблюдения формального протокола. Чем документов меньше, чем они компактнее и проще, тем эффективнее.
            Вопрос:
            Должны ли в описание БТ быть включены требования к описанию «хотелок» в части User Interface?
            Ответ:
            Отрицать «хотелки» или указывать стейкхолдерам на их неуместность — не всегда хорошо. Поэтому можно написать требования так, как считаете нужным, а в примечании написать комментарий для разработчиков с пожеланиями конкретного стейкхолдера относительно реализации данного требования.
            Вопрос:
            Обязательно ли современному аналитику владеть навыками программирования?
            Ответ:
            Не обязательно, но желательно. Чем шире кругозор аналитика, чем больше диапазон его возможностей, тем от более эффективным он будет выполнять свою работе и продвигаться по карьерной лестнице.
            Вопрос:
            Должен ли аналитик просматривать баги проекта и принимать решения о их важности?
            Ответ:
            Иногда аналитик должен просматривать баги, а иногда - нет. Зависит от договоренностей в рамках проекта и распределения ролей в команде.

            Что касается принятия решений о важности, то чаще всего их принимает аналитик. Но стоит помнить, что не всегда стоит загружать аналитика рутиной работой, т.к. из всех обнаруженных багов 80% не требуют, чтобы их прогоняли через формальный процесс, потому что и так всем понятны.
            Вопрос:
            Должен ли аналитик проводить тестирование и валидацию продукта?
            Ответ:
            К функциям бизнес-аналитика относятся определение критериев приемки и оценки для продукта, поэтому они часто участвуют в приемо-сдаточных испытаниях и могут разрулить какую-то ситуацию. Т.е. аналитик не должен проводить тестирование, но хорошо, когда он участвует в приемо-сдаточных испытаниях.
            Вопрос:
            Что является объектом требований вида «Должна собираться информация о недоступности банкомата» — к чему это бизнес требование? К организации? Подразделению? К бизнес-процессу?
            Ответ:
            Это требование бизнеса, объектом является банкомат, которым мы должны управлять. Управление состоит в том, что мы умеем различать его состояния, умеем отслеживать то, что с ним происходит, умеем реагировать на эти события и изменять состояния объекта управления, т. е. банкомата. Получается, это бизнес-требование, связанное с необходимостью и способностью организации управлять определенными типами объектов (например, банкоматами).
            Вопрос:
            Что делать с функциями, если они не мапятся на конкретное БТ или мапятся сразу на два (при этом функция должна быть в скоупе)?
            Ответ:
            Важно понимать, для чего мы делаем трассировку. В данном случае мы делаем трассировку, чтобы понять — БТ выполняется или нет?
            Нам не важно замапить все на все. Если мы делаем трассировку к модулям, это не значит, что нам надо оттрасировать каждую функцию и каждое требование. Достаточно понимать, данное требование — оно выполнено или нет? Если понимания достигнуто, то дальше можно не трассировать. Если мы пытаемся оттрасировать в другую сторону и видим какую-то висячую функцию, то это не значит, что у нас не должно быть никаких висячих функций, которые мы не можем замапить на какую-то функцию.
            Стоит помнить, что трассировка — это инструмент, а не цель.
            Георгий Савельев
            Эксперт по бизнес-анализу, член Международного института бизнес-анализа (IIBA), первый CBAP в России. Соавтор BABOK v.3. Вице-президент IIBA Russian Chapter.
            Имеет 20-летний опыт работы в качестве бизнес-аналитика, архитектора решений, консультанта и тренера в сфере производства и дистрибуции FMCG, складской и транспортной логистики, управления продажами, дорожного строительства, металлургии, нефтедобычи, гостиничного бизнеса, занятости, здравоохранения.

            Участвовал в реализации более 50 проектов по разработке, внедрению и совершенствованию программного обеспечения.

            С 1990 года занимается проведением тренингов и деловых игр для руководителей и специалистов. Автор статей по бизнес-анализу.

            Создатель авторских аналитических методик и моделей оперативного планирования. Участвовал более чем в 20 консалтинговых проектах по увеличению прибыльности и совершенствованию операционной эффективности компаний.

            Участник профессиональных ассоциаций IASA, ABPMP Russian Chapter.
            Подписаться на новые статьи
            Научиться создавать эффективные бизнес-требования в Agile
            Научиться создавать эффективные бизнес-требования в стиле Agile под руководством опытного наставника с использованием формата User Story, техник Impact Map и Story Map можно на нашем онлайн-курсе «Основы бизнес-анализа и Разработки требований в Agile»
            Другие статьи: