U-принцип и проявление детальных требований и потребностей ИТ-системы



U-принцип и проявление детальных требований и потребностей ИТ-системы

1546

       

AWG
Вместе с главным архитектором AWG Евгением Скориковым разбираемся в принципах проработки детальных требований и их обоснований, а также раскроем сложный вопрос важности синхронизации проектирования бизнес-процессов и поддерживающих ИТ-систем.


Как детализировать требования? 


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


Если раскрыть некоторые аспекты проектирования, они состоят в том, что:

  1. Обоснованием детального требования не может быть генерирующее требование, обоснование лежит в области использующих систем.
  2. При проработке моделей решения появляются вопросы, ответами на которые и являются детальные требования.
  3. Даже отрицательные ответы на вопросы являются требованиями, которые позволяют иметь полное обоснование модели решения.
  4. Некоторые вопросы «чтобы что», являющимися фактами и моделями использующей системы и контекста, нельзя предугадать заранее, поскольку они появляются в результате применения методик моделирования. Соответственно не получится заранее получить нужные ответы.

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



Анализ требований и их обоснования


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


Допустим, мы получили требование

  • Система должна позволять клиенту накапливать баллы за покупки

  • Система должна позволять клиенту расходовать баллы за покупки


Это требование из области решений, относящейся к ИТ-системе лояльности.


1.png


Следующим шагом станет выяснение причины требований — вопрос «Чтобы что?». Причина лежит в области использующей системы. Мы проводим анализ процесса использования требования и создаваемой им ценности.


Задаем вопросы:

  1. Зачем клиенту нужно накапливать и тратить баллы?
  2. Зачем бизнесу нужно позволять накапливать и тратить баллы?

Ответами на вопросы будут:

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

Проработка детализации требований и моделей системы


Есть ряд способов дальнейшей проработки:

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

Мы сталкиваемся с необходимостью детализации при проектировании моделей ИТ системы при создании итогового ТЗ.


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


Анализ требования


Задаем вопросы к требованию «накопление баллов» — какой алгоритм расчета, какой процент? 


Допустим, детальное требование: «Накапливать 10% от суммы покупки, независимо от товара, магазина, клиента». 


Можно ли сказать «Нужно Накапливать 10% от суммы покупки независимо от товара, магазина, клиента, потому что нужно накапливать баллы?». Ответа на вопрос «Почему независимо» — нет.


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


Как обосновываются суммы процента на практике?


Пример обоснования через модель использующей системы: 


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


Пример обоснования через анализ контекста: 


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


Схематично, процесс проектирования будет выглядеть похожим на букву U.


2.png


Анализ использующей системы


В процессе покупки нужно накапливать и расходовать баллы. Но как мы опознаем клиента, баллы которого нужно списать, либо пополнить?


Возникает вопрос - как идентифицировать клиента?


Допустим, мы решили идентифицировать клиента по номеру мобильного телефона.


Создаем модель


Допустим, мы начали прорабатывать логическую схему данных нашей будущей ИТ-системы.


Для этого мы берем объекты будущей системы и начинаем выявлять наличие взаимосвязей и арность этих взаимосвязей.


Мы понимаем, что у нас есть объекты: клиент, бонусные баллы, телефон клиента.


Чтобы понять их взаимосвязь мы должны задать вопросы и получить ответы на них:


Вопрос: Один клиент может накопить/расходовать несколько бонусных баллов?


Ответ: Да, возможны баллы за покупки, баллы которые мы дарим клиенту в рамках маркетинговой компании, например, на день рождение.


Вопрос: Могут ли один остаток бонусных баллов накапливать/расходовать несколько клиентов?


Ответ: Да, возможны семейные баллы, которые могут расходовать разные члены семьи.


Вопрос: Может ли один номер мобильного телефона использоваться как идентификатор для нескольких клиентов?


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


Вопрос: Может ли один клиент иметь несколько телефонов для идентификации?


Ответ: Есть клиенты, имеющие несколько номеров телефонов, их около 25%. Чтобы не усложнять системы мы идентифицируем клиента по одному номеру. Если клиент забыл свой номер и не может продиктовать SMS-код, мы позволяем ему накапливать бонусы, но не списывать.


Для обоснования модели мы формализуем все ответы на вопросы в виде требований.


3.png


U-принцип проектирования


В итоге, общий принцип аналитического процесса выглядит как:

  1. Получить обоснование имеющегося требования. Либо имея модель использования создать такое требование.
  2. Выбрать методику детализации. 
  3. Используя методику будут появляться вопросы, ответы на которые и являются детальными требованиями.

По своей форме на схеме этот принцип напоминает букву U — именно поэтому он так назван.


Балансировка моделей решения


Должны ли мы сразу создавать модель ИТ-системы по всем полученным выше требованиям? Ответ — нет.


Чаще всего в коммерческих проектах ключевым ограничением проекта является ограничение на срок окупаемости инвестиций, обычно это 1-2 года.


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

  1. Дополнительной прибыли. 
  2. Расходов на реализацию и поддержку.

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


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


Подводим итоги


При проектировании нужно учитывать ряд важных аспектов:

  1. Обоснованием детального требования не может быть генерирующее требование, оно лежит в области использующих систем.
  2. При проработке моделей решения появляются вопросы, ответы на которые и являются детальными требованиями.
  3. Отрицательные ответы на вопросы тоже являются требованиями, позволяющие иметь обоснование модели решения.
  4. Некоторые вопросы «чтобы что», являющиеся моделями использующей системы, нельзя предугадать заранее, они появляются позже в результате применения методик моделирования. 

Эти факты мы и собрали в U-принцип анализа и проектирования.


Ссылка на источник

С чего начать?

Свяжитесь с нами по номеру

или оставьте свою заявку

Расскажите о своем проекте

Наш специалист свяжется с вами и проконсультирует по интересующему вопросу, подскажет оптимальное решение вашей задачи

Спасибо за обращение. Ваша заявка принята.
File name
Заполняя данную форму, вы принимаете условия Соглашения об использовании сайта, и соглашаетесь с Правилами обработки и использования персональных данных

Мы используем cookies для вашего блага. Продолжая просматривать сайт, вы соглашаетесь с этим.

Хорошо