Классификация требований: бизнес-требования, требования заинтересованных сторон, требования к решению, переходные требования
Коротко Руководство BABOK® делит требования на четыре типа: бизнес-требования, требования заинтересованных сторон, требования к решению (функциональные и нефункциональные) и переходные требования. Если пометить каждое требование его типом, сразу видно, чего не хватает, а цепочку от бизнес-цели до функции системы можно трассировать.
По материалам: IIBA, Руководство BABOK® v3, разд. 2.3; IIBA, Global Business Analysis Core Standard, гл. 1; К. Вигерс, Дж. Битти, «Разработка требований к программному обеспечению», 3-е изд., гл. 1 (для сравнения).
На этой странице
Главные идеи#
Схема классификации впервые появилась в версии 2.0 Руководства BABOK и сохранилась в версии 3. Она сортирует требования по назначению и уровню детализации.
Бизнес-требования#
Бизнес-требования (business requirements) говорят, зачем происходит изменение: каких целей организация хочет достичь и каких результатов ждёт. Они могут относиться ко всей организации, к одной области бизнеса или к отдельной инициативе и редко упоминают систему.
Требования заинтересованных сторон#
Требования заинтересованных сторон (stakeholder requirements) описывают, что должна получить или иметь возможность сделать каждая группа заинтересованных сторон, чтобы бизнес-требования были выполнены. Это мост: с одной стороны — бизнес-цели, с другой — возможности решения.
Требования к решению#
Требования к решению (solution requirements) описывают, что должно делать само решение и насколько хорошо, чтобы требования заинтересованных сторон были удовлетворены. Руководство BABOK делит их на две группы:
- Функциональные требования описывают поведение: действия, которые выполняет решение, и данные, с которыми оно работает.
- Нефункциональные требования (их также называют требованиями к качеству сервиса) описывают не поведение, а качества: насколько быстрым, защищённым, удобным и доступным должно быть решение и в каких условиях оно должно продолжать работать.
Переходные требования#
Переходные требования (transition requirements) описывают то, что нужно только на время перехода от старого способа работы к новому: конвертацию данных, обучение людей, бесперебойную работу бизнеса во время переключения. Когда изменение завершено, они теряют силу. Этот тип забывают чаще всего, потому что после запуска им никто не пользуется.
Другие способы классифицировать требования#
Классификация Руководства BABOK не единственная. Вигерс и Битти выделяют уровни бизнес-требований, пользовательских и функциональных требований, а также нефункциональные требования и бизнес-правила (см. Уровни и типы требований). Другие авторы предлагают более детальные схемы (см. концептуальную модель типов требований). Названия разные, но идея одна: отделить «зачем», «что и для кого» и «что должно делать решение».
Как применять#
- Добавьте каждому требованию поле «тип». Используйте пять значений (бизнес, заинтересованная сторона, решение — функциональное, решение — нефункциональное, переходное) в бэклоге, электронной таблице или инструменте управления требованиями.
- Начинайте сверху. Сначала запишите бизнес-требования, пусть даже их будет всего три-четыре. Без них нельзя судить, стоит ли реализовывать требование к решению.
- Связывайте каждый уровень с вышестоящим. Каждое требование заинтересованной стороны должно поддерживать хотя бы одно бизнес-требование; каждое требование к решению — хотя бы одно требование заинтересованной стороны. Требования-«сироты» — кандидаты на удаление или признак пропущенной бизнес-цели. Подробнее — в разделе о трассировке требований.
- Проверьте каждую группу заинтересованных сторон. Есть ли для каждой группы из вашего списка заинтересованных сторон хотя бы одно требование? Если нет, вы, скорее всего, с ней не поговорили.
- Сделайте отдельный проход по нефункциональным требованиям. Сами по себе они всплывают редко. В качестве чек-листа используйте анализ нефункциональных требований.
- Планируйте переходные требования заранее. Спросите: какие данные переносятся, кого нужно обучить, что происходит в день переключения, как откатиться назад?
Пример#
Аналитик «Мастерской», вымышленной сети из 12 веломастерских, размечает первый набор требований:
| ID | Тип | Требование | Трассируется к |
|---|---|---|---|
BR-1 |
Бизнес | Вдвое сократить звонки на стойку приёма о статусе ремонта в течение шести месяцев после запуска. | — |
BR-2 |
Бизнес | Сократить число ремонтов, задержанных из-за отсутствия запчастей. | — |
SR-1 |
Заинтересованная сторона (клиент) | Клиенты могут узнать статус ремонта, не звоня по телефону. | BR-1 |
SR-2 |
Заинтересованная сторона (механик) | Механики могут за считаные секунды обновить статус заказа прямо из цеха. | BR-1 |
SR-3 |
Заинтересованная сторона (управляющий) | Управляющие видят, какие заказы ждут запчастей. | BR-2 |
FR-1 |
Решение, функциональное | Система отправляет клиенту сообщение, когда заказ переходит в статус «готов к выдаче». | SR-1 |
NFR-1 |
Решение, нефункциональное | Обновления статуса доходят до клиента в течение 5 минут. | SR-1 |
TR-1 |
Переходное | Открытые заказы с бумажных карточек заказов вносятся в новую систему до запуска. | — |
TR-2 |
Переходное | Сотрудники стойки приёма во всех 12 мастерских обучены до запуска. | — |
Разметка сразу показывает пробел: для механиков есть требование заинтересованной стороны (SR-2), но пока нет функционального требования, которое его реализует.
Подводные камни#
- Смешение уровней в одной формулировке. «Сократить число звонков, отправляя SMS из системы записи» — это бизнес-цель и решение в одном предложении. Разделите их.
- Пропуск требований заинтересованных сторон. Если перепрыгнуть от бизнес-целей сразу к функциям, теряется слой «кому что нужно», а с ним и возможность проверить полноту охвата.
- Нефункциональные требования как необязательное дополнение. Проблемы с производительностью или безопасностью могут погубить решение, полностью готовое функционально.
- Забытые переходные требования. Перенос данных и обучение — реальная работа с реальными трудозатратами и рисками.
- Споры о ярлыках. Тип — инструмент для проверки полноты, а не повод для дискуссий. Если требование подходит под два типа, выберите один и двигайтесь дальше.
Источники и что почитать#
- IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Рус. изд.: Руководство к своду знаний по бизнес-анализу (Руководство BABOK®), версия 3.0. Разд. 2.3 (схема классификации требований).
- IIBA. Global Business Analysis Core Standard. International Institute of Business Analysis. Гл. 1 (та же схема в сжатом виде).
- K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013. Рус. изд.: К. Вигерс, Дж. Битти. Разработка требований к программному обеспечению, 3-е изд. М.: Русская редакция; СПб.: БХВ-Петербург, 2014. Гл. 1 (альтернативная классификация).