Статья: https://www.iamba.pro/single-post/2016/03/30/This-is-the-title-of-your-first-post
Автор: Александр Белин
В статье автор очень наглядно разъясняет Модель Базовых Понятий Бизнес Анализа (МБП БА) (Business Analysis Core Concept Model — BACCM) из Свода Знаний по Бизнесс Анализу (BABOK Guide v3.0).
Автору данная модель позволяет дать полезное определение того, что есть бизнес-анализ:
Бизнес анализ — это деятельность, которая делает возможным проведение Изменений в организации, приносящих Пользу заинтересованным сторонам в определенном Контексте, путём выявления Потребностей и обоснования Решений, описывающих возможные пути реализации этих Изменений
В следующей статье «Ещё раз о базовых понятиях» автор ещё раз проходится по основным понятиям модели (и даёт им пояснения).
Мне интересно и приятно, что в этом, более свежем взгляде на бизнес-анализ, слово требование (requirement) отодвигается на второй план. Исторически слишком распространен такой взгляд: «Анализ — это деятельность по выявлению требований». Деятельность аналитика — составление спецификаций требований, которые поступают на вход разработчику, который находит адекватное решение. Такая модель не отражает реальной сути процессов и реального разделения труда между вовлечёнными лицами.
По МБП БА основным понятием является Потребность (Need) (возникающая у заинтересованного лица (Stakeholder) и рассматриваемая в определённом контексте (Context)), для которой ищется адекватное Решение (Solution). Другое распространённое слово для потребности — Проблема (Problem), но оно звучит в английском слишком негативно. И особенно в бизнес-контексте более корректно говорить о реализации возможностей (Opportunity). Слово Потребность объединяет в себе и «решение проблемы» и «реализация потенциальной возможности». Итого (упрощая): мы ищем Решения для Потребностей.
Но куда же всё же деваются требования? По МБП БА:
Требование — это пригодное для практической реализации представление Потребности.
Т.е. требование — это высказанная потребность, причём требование сфокусировано на понимании приносимой пользы и требование не должно содержать в себе конкретного решения.
Для меня это определение остаётся очень размытым и неясным. Обе границы — между требованием и решением остаются нечёткими.
Значительно более продуктивным подходом мне кажется выраженный в статье «What does it mean to say ‘requirement’?» (см. моё изложение). В нём требование понимается как условие или способность (condition or capability), которым должно обладать Решение для того чтобы удовлетворять Потребность. Что здесь интересно — так это что требование зависит и от потребности и от решения! Т.е. требования перестают быть независимы от решения, а напротив, формулируются применительно к конкретному решению лишь после того как оно обозначено в общем виде.
Одну и ту же потребность можно удовлетворить разными решениями, не правда ли? Так вот для каждого из возможных решений будет свой набор требований при неизменной потребности.
И другой очень важный момент. То, что в одном контексте выглядит как Решение, в другом становится Потребностью (достаточно просто глядя на Решение задать вопрос «А как это сделать?»). И в другую сторону — если глядя на потребность задать вопрос «Зачем?», мы найдем другую, более высокую потребность, для которой изначальная потребность будет являться решением.
Понимание этих двух вещей радикально изменило мой взгляд на весь мир разработки ПО.
