Кто-то сказал “Аналитик разрабатывает требования”. За ним повторили. Много-много раз. Тысячу раз. Но это не так.

Он выявляет потребности, выявляет/проектирует требования и разрабатывает модели решения.

А есть разница ? Давайте разберемся (истиной мы будем считать то, что работает).

Определяем понятия

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

Моделью системы мы будем называть упрощенное представление о системе для ее изучения или проектирования. 

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

Разрабатываем требования

Жил-был дядя Вася. Однажды пришел он к вам, как к аналитику-проектировщику и говорит: “Вот мои требования”.

Я, как дядя Вася, хочу открыть магазин:

1. На в Охотном ряду (модель решения), потому что там очень высокая проходимость, более 100 чел/час людей с средним доходом более 100к, в 30% случаев готовых купить сувенир стоимостью более 1000 руб (требование к системе), что позволит продавать им эти сувениры (модель надсистемы) и иметь оборот более 100*10*0.3*1000 руб в день (ценность = требование качества к надсистеме);

2. Магазин нужен мне завтра (требование к проекту системы), потому что я не хочу ждать (личностная потребность),

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

Жена дяди Васи говорит:

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

Вы записали все требования. Они обоснованы ? Вполне. Каждое обоснование вполне обосновывает требование.

Вы говорите дяде Васе и его жене : “Я закончил свою работу, требования разработаны”. 

Но дядя Васе не нужно, чтобы вы просто записали его требования. 

Он спрашивает: “Так как это сделать ? Ты же умный, придумай!”. Он ждет от вас решения этой задачи (и убеждает вас заняться решением). Или, точнее, ему нужна модель создаваемой системы и проекта ее создания.

Делаем модель решения

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

1. Продавать семечки на вокзале в Тамбове,

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

3. Открыть магазин на Охотном ряду за 100 млн руб,

4. Ограбить банк, открыть магазин на Охотном ряду на полученные деньги,

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

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

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

Итак, вы делаете матрицу сравнения решений и вам вместе с дядей Васей и его женой нужно:

1. Оценить степень удовлетворения требованию,

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

Итак, вы договорились и смотрите на решение с лучшей оценкой и выигрывает решение номер пять.

Дядя Вася скрепя сердцем соглашается на него.

Насколько это решение удовлетворяет требованиям:

1. Проходимость, будет в среднем 10 чел/час людей с средним доходом более 10к, в 10% случаев готовых купить беляш стоимостью 100 руб, это позволит получать оборот =10*10*0.1*50 руб в день;

2. Срок проекта - год,

3. Стоимость проекта 50 000 руб;

4. Риск нарушения закона есть, придется отдавать половину на взятки.

И вот тут внимание !!! То что описано - это требования? Нет. Это атрибуты качества модели решения. 

Почему так? Эти атрибуты нельзя менять независимо, за ними стоит созданная вами модель решения, которая содержит некоторый баланс возможностей. Этот баланс основан на какой-то объективной закономерности. Закономерность нельзя нарушить, изменение одних атрибутов качества влечет изменение других.

Дядя Вася может сказать “Хочу за месяц”, но он не заработает за месяц 50к. А за 5к его не пустят в злачное место с хорошей проходимостью, поэтому оборот упадет в десять раз (вы же провели исследование рынка, а не просто так нарисовали эту модель, правда?).

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

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

Какую ценность вы создали? Мы построили модель системы и пути ее достижения. Дядя Вася не дурак, когда трезвый, и он говорит вам спасибо за работу.

Итого

Аналитик или, более точно, аналитик-проектировщик: 

1. Выявляет требования на систему и проект создания (и на другие обеспечивающие системы), 

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

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

4. Добивается оценки атрибутов качества - степени соответствия требованиям,

5. Сравнивает варианты вместе с заказчиком, выбирая один,

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

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

Попытка потребовать соблюдения улучшения одного атрибута качества влечет усилия по перепроектированию модели. Поэтому правильный ответ на “дайте скидку в 5%” - это “дайте деньги на перепроектирование” (если вы не заложили это в финансовых рисках или если вам нечего допродать).

Если требования, модель решения и атрибуты качества модели называть “требованиями”, то это только запутает аналитика (что автор и наблюдает).

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