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

ГЕОРГИЙ САВЕЛЬЕВ

Как разработать
Бизнес-требования

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

Давайте поговорим о том, откуда берутся требования. И бизнес-требования (БТ), и нефункциональные требования напрямую вытекают из потребностей бизнеса.

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

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

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

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

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

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

Почему важно выявлять и документировать
бизнес-требования?

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

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

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

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

Кроме того, бизнес-требования в 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»

СМОТРЕТЬ ПРОГРАМММУ

Другие статьи:

Контекстная диаграмма

Зачем нужна, как создавать и как тестировать контекстную диаграмму при разработке системных требований и проектировании систем

Что мы создаём в ИТ-проектах?

Программное обеспечение, информационная система, автоматизированная система — в чём разница?

Книги

Рекомендации литературы по инженерии требований и прикладному системному анализу

Стандарты

Международные и российские стандарты в области прикладного системного анализа и инженерии требований

Remote Analyst. Первые шаги и частые вопросы

Как начать дистанционную работу независимым ИТ-аналитиком

Как выполнить тестовое задание на вакансию ИТ-аналитика

Рекомендации с примерами

Бизнес-требования. Назначение и форма

Как устроены бизнес-требования и как они применяются в проектах

Постановка задачи на реализацию

Разберёмся, что это такое, зачем нужна, как создавать

Как писать требования чтобы их понимали — Anton Lazovskiy на vc.ru

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

18 980
просмотров

Данный материал будет интересен бизнес- и системным аналитикам, менеджерам и владельцам продуктов, CEO небольших стартапов, в общем — всем, кому нужно писать требования к разработке фичей и ИТ-систем.

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

Начнем с обсуждения:

• Общих принципов написания «удобных» требований
• Использования таблиц
• Использования схем и диаграмм

Если тема окажется интересной, то в следующей статье посмотрим на использование более продвинутых инструментов, таких как:

• Подход Specification by Example
• Варианты использования
• Мокапы интерфейса

1. Пишите просто

Требования это не роман и удивлять слогом тут никого не нужно. Я еще не раз это повторю в статье, но тот кто читает ваши требования, должен напрягаться по минимуму.

Здесь, как и в дизайне интерфейсов, отлично работает правило: «Не заставляйте меня думать», про которое писал Стив Круг в одноименной книге.

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

• Используйте простой слог и слова, избегайте общих формулировок.
• Избегайте сложносочиненных предложений. В идеале, одно предложение = одна мысль.
• Если вы встречаете союзы «но», «или», то скорее всего, здесь скрыты два отдельных требования.
• Не используйте двойные отрицания.
• Для требованиий со структурой «если <условие>, то <результат>» пишите сначала результат, а потом — условие. Пример: «Система должна запрещать сохранение заказа, если хотя бы одного товара нет в наличии».

Пример — Упрощаем составное требование

Исходное требование:

«Должна быть возможность удалить конкретный товар или сразу все товары из корзины».

По сути, данное требование содержит два отдельных требования:

1. «Должна быть возможность удалить конкретный товар из корзины».
2. «Должна быть возможность удалить сразу все товары из корзины».

Такое разделение поможет не пропустить скрытое требование разработчику или QA и подскажет менеджеру, что здесь лучше завести две отдельные задачи.

2. Используйте форматирование

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

Используйте средства, которые доступны вам в любом редакторе:

• Списки
• Абзацы
• Полужирный шрифт

Например, если вы используете союз «и» (или несколько таких союзов), то лучше каждое условие написать с новой строки.

Пример — Применяем форматирование

Исходное требование:

«Необходимо перевести заказ в статус «Доставляется», если заказ оплачен и весь товар есть в наличии на складе. »

Давайте упростим восприятие этого требования. Получим следующее:

«Необходимо перевести заказ в статус «Доставляется», если:

• Заказ оплачен
• И весь товар есть в наличии на складе.

Что мы сделали? Мы сняли часть когнитивной нагрузки с того, кто будет изучать данное требование. Уже из форматирования становится видно, что:

• Речь идет о заказе в статусе «Доставляется».
• Действие изменения статуса должно выполняться при соблюдении двух условий.

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

3. Упрощайте требования

Вы должны не только писать просто, но и оптимизировать свои требования, упрощать их. Этот принцип должен работать во всем. Когда вы пытаетесь передать информацию, она неизменно искажается, а часть ее теряется. И, чем больше передается информации, тем больше ее теряется в процессе передачи.

Пример — Оптимизируем длинное требование

Исходное требование:

«Заказ отображается в личном кабинете пользователя, если заказ находится в одном из статусов: «Новый», «Ожидает оплаты», «Оплачен», «Доставляется». Заказ в статусе «Доставлен» не должен отображаться в личном кабинете.»

Как можно его упростить:

«Заказ отображается в личном кабинете пользователя, если его статус не равен «Доставлен».

Во-первых, мы сделали само требование короче, а значит вероятность, что его прочитают стала выше.

Во-вторых, технические специалисты отлично считывают такие конструкции и вы, опять же, снимаете с них когнитивную нагрузку.

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

4. Используйте таблицы

Запомните, таблицы — ваш главный «бро» 🙂

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

• Как я могу упростить эти требования?
• Как эти требования можно оформить в табличном виде?

Почему таблицы лучше работают:

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

Рассмотрим пример части из ТЗ на большую государственную систему из открытых источников:

«Успешно авторизованный пользователь, входящий в группу пользователей c ролью «Исполнитель», должен попадать на «UI-006 Главная страница личного кабинета», а пользователь, входящий в группу пользователей с ролью «Наблюдатель» – на «UI-092 Главная страница Мониторинга (дашборд)» подсистемы «Мониторинг». Если пользователь в личном кабинете настроил страницу по умолчанию, то открываемая страница должна определяться на основе выбранной настройки.»

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

«После успешной авторизации в системе, пользователю должна открываться стартовая страница, согласно условиям ниже:»

Используем таблицы для оформления требований Anton Lazovskiy

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

Таблицы для описания интерфейсов

Таблицы являются отличным инструментом для описания форм и пользовательских интерфейсов.

Пример формы редактирования из того же ТЗ:

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

• Тип поля.
• Значение поля при открытии формы.
• Ограничения на выбираемые данные.
• Можно ли редактировать поле и требования к валидации (если есть).

Использование таблицы для описания интерфейса Anton Lazovskiy

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

Когда использовать таблицы (спойлер — всегда!):

• Вы описываете два и более объектов со одинаковыми свойствами (поля формы; разделы сайта; роли пользователей и т. д.).
• Вы хотите описать реакцию системы при возникновении определенных событий.
• Вы описываете миграцию данных или маппинг полей между системами.

5. Используйте схемы

Схемы и диаграммы — это еще один отличный способ улучшить качество передачи знаний в команде разработки.

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

Далее я поделюсь схемами, которые использую чаще всего.

Контекстная диаграмма

Зачем нужна: Показывает как разрабатываемая система взаимодействует с внешними миром.

Внешний мир может быть представлен: другими ИТ-системами, пользователями или устройствами.

Когда использовать: На этапе проектирования системы, чтобы:

• Понять, с какими системами придется интегрироваться.
• Понять, какие интерфейсы ввода/вывода нужно реализовать.

P.S. Еще эту диаграмму очень любят архитекторы.

Я не сторонник строгих правил разработки диаграмм, но стараюсь придерживаться следующих рекомендаций для контекстной диаграммы:

• Разрабатываемая система изображается в виде круга в центре.
• По ее периметру изображаются внешние акторы (системы, пользователи, устройства) в виде прямоугольников.
• Стрелками рисуются потоки данных (в том числе физических объектов) от актора к системе и наоборот.
• Нужно показывать только основные потоки данных и/или операции.

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

Пример контекстной диаграммы Джой Битти, Карл Вигерс

Схема бизнес-процессов (BPMN-диаграмма)

BPMN — это нотация описания бизнес-процессов в виде набора обозначений и ряда определенных правил.

Зачем нужна: Позволяет зафиксировать описание бизнес-процессов на этапе их дизайна и использовать это «знание» на этапе разработки и внедрения решения.

Когда использовать: Вообще, у BPMN довольно широкий спектр применения.

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

При разработке BPMN-диаграмм (в контексте описания требований) главное — избавиться от перфекционизма.

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

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

• Start/End Events — начальное и конечное события.
• Activity — Действие, которое выполняет пользователь или система.
• Gates — Шлюзы. Используются для принятия решений и запуска параллельных процессов.
• Lanes — Дорожки, которые разграничивают разные типы пользователей и системы.

Пример описания бизнес-процесса обработки инцидентов:

BPMN-диаграмма Anton Lazovskiy

Если вам интересна отдельная статья про примеры построения BPMN-диаграмм на реальных примерах, напишите об этом в комментариях.

Диаграмма состояний

Зачем нужна: показывает как объект переходит из одного состояния в другое.

Когда использовать:

• У объекта много состояний (2+), логика переходов зависит от определенных событий.
• С объектом могут совершать действия сразу несколько пользователей (например, редактирование заказа). Это поможет выявить исключительные ситуации, которые можно заранее продумать, а не фиксить потом на production.

Как и схемы в BPMN, диаграмма состояний отлично читается и техническими специалистами, и бизнес-пользователями, и экспертами.

Пример диаграммы состояний для объекта «инцидент» из BPMN-диаграммы выше:

Диаграмма состояний Anton Lazovskiy

Заключение

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

бизнес-требований против функциональных требований? Какая разница?

Что такое бизнес-требования? Обычный ответ, который я получаю, когда прошу привести пример бизнес-требования, звучит примерно так: «Система должна способствовать автоматизации отправки электронной почты клиенту». Это требование бизнеса? Ну конечно должно быть. Бизнес сказал мне это конкретно и такими словами! Это должно быть бизнес-требованием, так как оно исходит от бизнеса, верно!?

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

Что бизнес-требование НЕ ЯВЛЯЕТСЯ: функциональное требование

Приведенный выше ответ «Система должна способствовать автоматизации электронной почты клиента» не является бизнес-требованием, это функциональное требование. Функциональное требование описывает, как мы выполняем наши бизнес-процессы (или их функциональность). Обычно это субъективно, и это не может быть правильным ответом! Технически вы можете решать свои бизнес-задачи разными способами. Например, вы можете написать клиенту по электронной почте, написать ему в Твиттере или что-то еще, что-то новое, важное.

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

• Утверждение вроде: «Система должна отображать приветственное сообщение для пользователя на домашней странице».
• Прототип
• Схема рабочего процесса
• Описание варианта использования (текстовое описание шагов для выполнения функции)
• Карта-история

Итак, что такое бизнес-требование?

Бизнес-требование — это не то, что система должна выполнять. Это то, что бизнес должен делать или иметь, чтобы оставаться в бизнесе. Например, бизнес-требование может быть следующим:

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

Ваши бизнес-требования меняются меньше (в большинстве случаев), чем ваши функциональные требования, и, как правило, более объективны. «Если мы не найдем лучший способ связаться с нашим клиентом, мы можем остаться без дела!» Таким образом, бизнес-требование будет выглядеть примерно так: «Нам нужно связаться с клиентом с информацией xyz», а не «система будет…».

Помните, что «Система должна делать то или иное…» описывает как (или функциональность). Это проявление бизнес-требований в системе.

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

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

В этом случае история пользователя пишется независимо от как или функциональности и является требованием бизнеса или заинтересованной стороны. (Хотя я мог бы возразить, что на самом деле в нем не говорится об истинной пользе, и его следует переписать.) Однако слишком часто пользовательская история будет написана так:

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

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

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

Зачем выявлять бизнес-требования?

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

Повысьте эффективность сбора информации с помощью нашего быстрого совета по методам сбора требований.

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

Как нам достичь настоящих бизнес-требований?

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

Когда я не преподаю, я управляю ИТ для компании по управлению расходами на телекоммуникации, поэтому я живу и дышу данными. Без правильных и полных данных мой бизнес быстро потерял бы клиентов! Это означает, что я несколько неравнодушен к стороне данных и обычно начинаю с нее. Если вы более «ориентированы на процесс», вы можете начать с этого. Неважно, с чего вы начнете, главное, чтобы вы хорошо разбирались в бизнесе.

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

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

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

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

Я надеюсь, что мы в ИТ-индустрии не станем жертвой старого мышления «просто начни строить, и все будет отлично». Я делал это раньше; это не здорово. Это приводит к дорогостоящему редизайну и переделке, и даже это не делается хорошо, потому что теперь мы отстаем, а бизнес разочаровывается. Как насчет того, чтобы сделать это правильно с первого раза? Я сказал да!

Спасибо,

– Али

Хотите больше моментов Aha?

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

Краткое описание курса

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

Как написать документ с бизнес-требованиями

Время чтения: 11 минут

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

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

Документация по программному обеспечению, объяснение

Бизнес-требования и другие типы требований

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

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

Схема классификации требований к продукту

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

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

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

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

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

Каким бы ни был случай и тип требований, вам необходимо определить их как можно более четко, чтобы проект был успешным.

Что такое документ бизнес-требований (BRD)?

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

Люди, участвующие в создании BRD

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

Почему важны документы с бизнес-требованиями

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

При тщательно разработанном BRD вы можете

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

Как начать работу с BRD

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

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

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

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

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

Как написать документ с бизнес-требованиями

Хотя каждый проект уникален с точки зрения таких вещей, как цели, требования, бюджет, сроки и т. д., базовая структура BRD часто содержит следующие разделы.

• Резюме
• Цели проекта
• Объем проекта
• Заинтересованные стороны
• SWOT-анализ
• Финансовая отчетность
• Функциональные требования
• График и сроки
• Анализ затрат и результатов

Ключевые разделы документа с бизнес-требованиями

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

Резюме

Резюме представляет собой краткое изложение, в котором излагаются предыстория и основные положения проекта. Он задает тон всему документу и является первым, что увидят те, кто собирается его читать. Итак, убедитесь, что раздел привлекает внимание читателей, передает всю необходимую информацию в сжатой форме и связывает документ с общими бизнес-целями. Кроме того, если BRD является результатом каких-либо предыдущих встреч или документов, вы можете предоставить соответствующие ссылки.

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

Пример: [Название компании] в настоящее время сталкивается с рядом проблем, которые мешают пользователям взаимодействовать с ее веб-сайтом электронной коммерции. Среднее время, проведенное на странице, составляет около 1 минуты. Потенциальные покупатели отказываются от корзины в 70% случаев. Рост новых посетителей сайта снизился на 10 процентов по сравнению с предыдущим годом. [Название компании] необходимо изменить дизайн целевой страницы и популярных страниц продуктов на своей платформе электронной коммерции и улучшить функциональность оформления заказа, чтобы решить проблемы.

Цели проекта

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

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

Пример:

Редизайном веб-сайта наша компания стремится достичь следующих целей:

1. Запустить 3 рекламные кампании для продвижения обновленного веб-сайта электронной коммерции в течение месяца.
2. Получите не менее 100 000 уникальных посетителей сайта к концу четвертого квартала 2021 года.
3. Увеличить среднее время пребывания на веб-сайте с 1,2 до 3 минут к концу четвертого квартала 2021 года.
4. Сократить количество брошенных корзин на 40 процентов к концу четвертого квартала 2021 года.

Объем проекта

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

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

Пример:

В рамках проекта:

• Редизайн пользовательского потока на целевой странице.
• Изменить порядок оформления заказа.
• Редизайн страниц продукта.
• . . .

Этот проект не охватывает:

• формы и цвета кнопок и
• фоновая тема платформы.
• . . .

Заинтересованные стороны

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

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

Пример:

Формат таблицы, который можно использовать для перечисления заинтересованных сторон

SWOT-анализ0009 угрозы.

Сильные и слабые стороны относятся к внутренним факторам, а возможности и угрозы — к внешним. Рекомендуется дополнять документ с бизнес-требованиями SWOT-анализом бизнеса и видением того, как проект вписывается в него. Эта часть особенно полезна, если вам нужно повысить доверие к себе в глазах других сторон, участвующих в проекте.

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

Пример:

SWOT-анализ на примере магазина электронной коммерции будет приходиться на расходы и доходы компании.

Полезный совет: Этот раздел должен сопровождаться подробной информацией о том, как будет финансироваться проект.

Пример:

Этап стратегии и планирования проекта составляет в общей сложности 51 000 долларов США, при этом производственные затраты должны быть оценены после утверждения карты сайта, каркасов и композиций клиентом. В настоящее время мы оцениваем производственные затраты на этапе 1 в диапазоне 80 000 долларов США. Мы определили дополнительные функции и функции веб-сайта, которые могут быть реализованы на дополнительных этапах по мере поступления дополнительных средств.

Функциональные требования

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

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

Пример:

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

Расписание и сроки

Ваш документ с бизнес-требованиями также должен содержать подробное расписание вместе со всеми важными сроками и важными вехами для отслеживания прогресса и получения своевременных результатов. Это поможет вам поддерживать подотчетность вашей команды и держать заинтересованные стороны в курсе проекта на определенных этапах.

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

Пример:

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

Этап I – Стратегия и планирование (сроки: 3-4 недели) . . .

Фаза II – Дизайн (сроки: 10-12 недель). . .

Анализ затрат и результатов

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

Как это сделать: Чтобы провести анализ затрат и результатов, вам необходимо сначала определить все сопутствующие расходы. Влияние может включать первоначальные затраты на разработку, непредвиденные затраты, будущие эксплуатационные расходы, материальные и нематериальные затраты.

То же самое следует сделать с потенциальными преимуществами. Определите рентабельность инвестиций вашей компании и способы ее измерения. Принесут ли сегодняшние инвестиции прибыль?

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

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

Пример:

Пример анализа рентабельности разработки новой автоматизированной системы выставления счетов. Источник: TechnologyUK

При первоначальных инвестициях в размере 50 000 фунтов стерлингов, прогнозируемом сроке окупаемости в пять лет и ставке дисконтирования в 15 процентов организация уже может рассчитывать на положительный доход в течение второго года с общей внутренней ставкой вернуться к 133 686 фунтов стерлингов.

Готовые к использованию шаблоны документов бизнес-требований

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

• В TechWhirl вы можете загрузить подробный шаблон BRD, специально разработанный для технологического проекта. Он состоит из нескольких разделов для документирования требований, правок, согласований и т. д., а также кратких описаний того, какая информация должна там быть, и образцов текста.
• Stanford University IT предлагает хорошо структурированный шаблон бизнес-требований в форматах Microsoft Word и Google Docs. В каждом разделе вы найдете подробные инструкции по необходимому содержанию.
• TemplateLab предоставляет для загрузки большое количество различных шаблонов BRD. Некоторые из них, такие как предоставленный правительством Британской Колумбии, содержат подробные инструкции по заполнению документов. Другие документы также включают настраиваемые диаграммы и графики.
• Ресурс «Эксперты по требованиям» предоставляет хороший шаблон BRD для тех, кто предпочитает работать с форматом Excel, а не с Word. Это довольно просто, но каждый раздел снабжен кратким описанием необходимой информации.

Теперь, когда у вас есть несколько шаблонов и примеров BRD, мы хотели бы дать вам несколько полезных советов о том, как эффективно документировать требования.

Передовой опыт документирования бизнес-требований

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

Обратитесь к прошлым проектам

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

Включите визуальные эффекты

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

Исследования показали, что наш мозг обрабатывает визуальные данные в 60 000 раз быстрее, чем текстовые. Таким образом, вместо того, чтобы писать стены текста, подумайте о том, чтобы смешать его с инфографикой, блок-схемами, диаграммами Венна и т. д.

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

This entry was posted in Популярное