Комментарии 7
Не согласен с вами. Аналитик - это специалист, который конечно-же может кое-что предложить, как решить проблему, за что взяться в начале, а за что потом. Но в первую очередь он анализирует. Данные, процессы, условия итд. Да, он должен находить закономерности, но чтобы сразу - в деталях ход и способы достижения требований! Это чересчур. Уже составить правильный каталог с требованиями как фукциональными так и не-функциональными - уже это создать - немалый талант нужен.
Честно говоря, сумбурное впечатление от статьи. Как будто накидали в неё всяко-разного...
Итак:
... реализация которого должна помочь достижению цели ... - так может и начать с цели. Тогда и со всем остальным будет немножко проще. Однако про цель Васи аналитик не спрашивает, должен догадаться сам (если неправильно догадался - есть второе ухо);
- если Вася сказал о магазине на Охотном и завтра, как о требовании (по лору: ... записали все требования ...), тогда почему модель решения их не учитывает. Заказчик приходят с запросом на проектирование условного магазина, а в ответ получает предложение "взаимодействовать" с банком: зачем(?) если магазин должен стоить 1000 руб, которая у Васи уже есть (это всё к вопросу о требованиях - может поговорить об изменении требований?);
... 30% случаев готовых купить сувенир стоимостью более 1000 руб (требование к системе) ... - если это требование к системе, то ... в общем странное требование. Но если это требование, то почему не учтено в модели решения? Так и планируем поиск места для магазина: по чёткому требованию/критерию.
... получать оборот =10*10*0.1*50 ... - откуда взялась цифра? Как минимум желательно указать сколько часов продаём (очень важный параметр, нет?). Вообще расчёты немного непонятны.
В общем, по моему скромному мнению:
либо вы очень крутой аналитик, поэтому читателей пытаетесь научить с букваря, сами себя поправляя и готовя ловушки для читателя;
я к тому, что может начать с примеров по-проще и ближе к реальности.
Вот что за фигня такая? Человек берёт время и прорабатывает кои-какие высказывания из статьи, конструктивно указывает на погрехи или неточности, а ему кто-то слепо минусует.
Жаль, что вам не зашло. Цель статьи - показать на простом жизненном примере чем требования отличаются от модели. Цель Васи (goal) - обеспечить себе достойную прибыль (подразумевается, хотя вы правы, стоило указать), цель Васи (objective) - сделать магазин на Охотном ряду.
Смысл примера в том, что требования заказчика могут (и чаще всего так и бывает, особенно по расходам и срокам) быть не выполнимы. И это нормально. Пока требования не связаны, невозможно проверить выполнимость. Задача аналитика зачастую - выявить функцию штрафа, "на сколько сроки можно нарушить" - или более точно "к каким последствиям для бизнеса приведет какое нарушение этого требования". И создать решение с наименьшим штрафом.
Расчеты в статье, разумеется, взяты с потолка. В реальности, модель анализа рынка в конкретной точке - предмет отдельной статьи (или книги). Смысл - показать, что требование по обороту не выполнено и насколько не выполнено. Или более точно стоит говорить, каким качеством "оборот" обладает спроектированное решение (и не нужно путать оценку качества модели решения с требованием к модели решения)
"Проектирует несколько вариантов моделей решения" - это задачи для методолога, который на основании полученных от аналитика требований и изученных на опыте ограничений и возможностей начнет проектировать.
Почему вы так решили? Методолог, судя по названию, разрабатывает методику реализации каких-то работ. Вероятно, вы имели в виду "архитектора". Но в жизни проектированием моделей (функциональных моделей) занимается именно аналитик. Иначе он не может сопоставить различные требования к решению (и проекту решения) и понять что выполнимо, а что нет. Вариативность возникает из-за того, что требования/потребности не всегда определяют решение однозначно
Не путаем требования и модели решений или что все-таки разрабатывает аналитик