Как детализировать требования?
Существует подход user story mapping: соберите пользователей и пусть они расскажут детальные требования в процессе размышления о том, как они конкретно выполняют свою деятельность. Данный подход сам по себе хорош, однако он не дает нам метода детализации и проверки полноты всех видов требований.
Если раскрыть некоторые аспекты проектирования, они состоят в том, что:
- Обоснованием детального требования не может быть генерирующее требование, обоснование лежит в области использующих систем.
- При проработке моделей решения появляются вопросы, ответами на которые и являются детальные требования.
- Даже отрицательные ответы на вопросы являются требованиями, которые позволяют иметь полное обоснование модели решения.
- Некоторые вопросы «чтобы что», являющимися фактами и моделями использующей системы и контекста, нельзя предугадать заранее, поскольку они появляются в результате применения методик моделирования. Соответственно не получится заранее получить нужные ответы.
Все эти факторы мы собрали в единый принцип, который назвали U-принципом анализа и проектирования.
Анализ требований и их обоснования
В рассуждениях будет использоваться терминология системной инженерии и некоторые выводы, которые можно узнать в статье.
Допустим, мы получили требование
-
Система должна позволять клиенту накапливать баллы за покупки
-
Система должна позволять клиенту расходовать баллы за покупки
Это требование из области решений, относящейся к ИТ-системе лояльности.
Следующим шагом станет выяснение причины требований — вопрос «Чтобы что?». Причина лежит в области использующей системы. Мы проводим анализ процесса использования требования и создаваемой им ценности.
Задаем вопросы:
- Зачем клиенту нужно накапливать и тратить баллы?
- Зачем бизнесу нужно позволять накапливать и тратить баллы?
Ответами на вопросы будут:
- Чтобы меньше платить за товар.
- Чтобы мотивировать клиентов купить товар сообщениями о скором сгорании баллов, чтобы собрать клиентскую базу, чтобы строить привлечение клиентов через email таким образом увеличивая продажи.
Проработка детализации требований и моделей системы
Есть ряд способов дальнейшей проработки:
- Анализ требования через устранение неоднозначностей.
- Анализ использующей системы и контекста, для понимания, как требование преобразуется при их более детальном рассмотрении.
Мы сталкиваемся с необходимостью детализации при проектировании моделей ИТ системы при создании итогового ТЗ.
Давайте углубимся в некоторые из способов.
Анализ требования
Задаем вопросы к требованию «накопление баллов» — какой алгоритм расчета, какой процент?
Допустим, детальное требование: «Накапливать 10% от суммы покупки, независимо от товара, магазина, клиента».
Можно ли сказать «Нужно Накапливать 10% от суммы покупки независимо от товара, магазина, клиента, потому что нужно накапливать баллы?». Ответа на вопрос «Почему независимо» — нет.
Делаем вывод, что обоснованием детального требования не может быть только генерирующее требование, нужны какие-то другие аргументы.
Как обосновываются суммы процента на практике?
Пример обоснования через модель использующей системы:
Финансовой моделью, где балансируются расходы компании на дополнительную скидку и психологический порог суммы мотивации, достаточный для действия.
Пример обоснования через анализ контекста:
Дополнительным конкурентным анализом, сравнением разных сумм вознаграждения конкурентов и референтных бизнесом, если бизнес работает на конкурентном рынке.
Схематично, процесс проектирования будет выглядеть похожим на букву U.
Анализ использующей системы
В процессе покупки нужно накапливать и расходовать баллы. Но как мы опознаем клиента, баллы которого нужно списать, либо пополнить?
Возникает вопрос - как идентифицировать клиента?
Допустим, мы решили идентифицировать клиента по номеру мобильного телефона.
Создаем модель
Допустим, мы начали прорабатывать логическую схему данных нашей будущей ИТ-системы.
Для этого мы берем объекты будущей системы и начинаем выявлять наличие взаимосвязей и арность этих взаимосвязей.
Мы понимаем, что у нас есть объекты: клиент, бонусные баллы, телефон клиента.
Чтобы понять их взаимосвязь мы должны задать вопросы и получить ответы на них:
Вопрос: Один клиент может накопить/расходовать несколько бонусных баллов?
Ответ: Да, возможны баллы за покупки, баллы которые мы дарим клиенту в рамках маркетинговой компании, например, на день рождение.
Вопрос: Могут ли один остаток бонусных баллов накапливать/расходовать несколько клиентов?
Ответ: Да, возможны семейные баллы, которые могут расходовать разные члены семьи.
Вопрос: Может ли один номер мобильного телефона использоваться как идентификатор для нескольких клиентов?
Ответ: Не может, мы считаем, что один телефон у одного клиента, иначе мы не сможем различать разных членов семьи и делать разную коммуникацию.
Вопрос: Может ли один клиент иметь несколько телефонов для идентификации?
Ответ: Есть клиенты, имеющие несколько номеров телефонов, их около 25%. Чтобы не усложнять системы мы идентифицируем клиента по одному номеру. Если клиент забыл свой номер и не может продиктовать SMS-код, мы позволяем ему накапливать бонусы, но не списывать.
Для обоснования модели мы формализуем все ответы на вопросы в виде требований.
U-принцип проектирования
В итоге, общий принцип аналитического процесса выглядит как:
- Получить обоснование имеющегося требования. Либо имея модель использования создать такое требование.
- Выбрать методику детализации.
- Используя методику будут появляться вопросы, ответы на которые и являются детальными требованиями.
По своей форме на схеме этот принцип напоминает букву U — именно поэтому он так назван.
Балансировка моделей решения
Должны ли мы сразу создавать модель ИТ-системы по всем полученным выше требованиям? Ответ — нет.
Чаще всего в коммерческих проектах ключевым ограничением проекта является ограничение на срок окупаемости инвестиций, обычно это 1-2 года.
Это означает, что следует взвешивать окупится ли усложнение системы при добавлении реализации каждого требования, а для этого нужно иметь оценки:
- Дополнительной прибыли.
- Расходов на реализацию и поддержку.
Если анализ бизнеса показывает, что окупаемость недостаточна, то и нет смысла прорабатывать детальные модели бизнес-процесса и ИТ системы по реализации, например, семейных бонусов. Эта проработка лишь потратит наше время и деньги.
Поэтому мы приходим к оценке, что процесс проработки детальности моделей реализации бизнес-процессов и ИТ систем должен быть синхронизирован и согласован друг с другом.
Подводим итоги
При проектировании нужно учитывать ряд важных аспектов:
- Обоснованием детального требования не может быть генерирующее требование, оно лежит в области использующих систем.
- При проработке моделей решения появляются вопросы, ответы на которые и являются детальными требованиями.
- Отрицательные ответы на вопросы тоже являются требованиями, позволяющие иметь обоснование модели решения.
- Некоторые вопросы «чтобы что», являющиеся моделями использующей системы, нельзя предугадать заранее, они появляются позже в результате применения методик моделирования.
Эти факты мы и собрали в U-принцип анализа и проектирования.
Ссылка на источник
