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

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

Дается ответ на вопрос: почему важно строить синхронизированный процесс проектирования бизнес-процессов и поддерживающих ИТ систем. 

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

Статья показывает некоторые аспекты проектирования, состоящие в том, что:

1. Обоснованием детального требования не может быть генерирующее требование, обоснование лежит в области использующих систем (A).

2. При проработке моделей решения появляются вопросы, ответы на которые и есть детальные требования (B).

3. Отрицательные ответы на вопросы также являются требованиями, позволяющие иметь полное обоснование созданной модели решения (C).

4. Некоторые вопросы “чтобы что”, являющимися фактами и моделями использующей системы и контекста, нельзя предугадать заранее, так как они появляются в результате применения методик моделирования. Соответственно нельзя заранее получить нужные ответы. Иными словами невозможно создать методику описания бизнес-процесса, дающую полную и не избыточную информацию для проектирования поддерживающей этот процесс ИТ-системы   (D)

Эти факты собираются в названный автором u-принцип анализа и проектирования (E)

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

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

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

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

1. “Система должна позволять клиенту накапливать баллы за покупки”, 

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

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

Мы выясняем  причину требования “чтобы что?”. Причина лежит в области использующей системы (https://habr.com/ru/post/697444/), мы проводим анализ процесса использования этого требования и как это требование создает ценность.

Или схематично:

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

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

1. Анализ требования, как такового, через устранение неоднозначностей,

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

3. И другие.

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

Разберем некоторые из способов.

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

“Накапливать баллы” - какой алгоритм расчета, какой процент? 

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

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

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

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

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

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

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

P.S. Подчеркнем, что нельзя просто так взять и написать детальные требования. Можно принять решение о концепции модели ИТ-системы, но без анализа применимости использования любые решения о требованиях и моделях решений будут не обоснованы.

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

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

Нужно как-то идентифицировать клиента. В процессе анализа процесса - порождается требование идентификации клиента, что создает дополнительный шаг идентификации

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

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

Создание модели

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

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

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

Они взаимосвязаны. Но как? Для изучения арности этих связей, мы спрашиваем вопросы, получаем ответы:

Ответы на вопросы при проработке модели решения нужно формализовать в виде требований, чтобы модель была обоснована (B):

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

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

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

4. Один клиент может иметь несколько телефонов для идентификации, так как есть клиенты, регулярно меняющие свой номер телефона, нам нужно понимать, что это один и тот же клиент.

В виде схемы, процесс проектирования выглядит так:

Заметим, что если не записать в виде требования:

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

То мы не сможем обосновать (C) :

Проработка всех ответов на вопросы заранее

Мог ли бизнес заранее проработать ответ на вопрос  

4. Один клиент может иметь несколько телефонов для идентификации?

5. Если случаев много, как работать с клиентом, если он забыл свой основной телефон дома?

Четвертый вопрос возник вследствие применения методики анализа арности взаимосвязей при проектировании модели структур данных. 

Пятый вопрос возник вследствие применения методики анализа возможных исключений при взаимодействии с клиентом.

Мог ли вопрос 4 и ответ на него появится без применения методики создания модели ИТ-системы? Нет, полный список вопросов для построения модели порождается только при ее создании. Бизнес не пророк, чтобы знать заранее вопросы, которые будут порождены при проработки моделей ИТ-системы.

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

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

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

1. Получить обоснование имеющегося требования либо имея модель использования создать требование

2. Выбрать методику детализации 

   1. Уточнение формулировок,

   2. Анализ использующих систем и контекста, 

   3. Проектирование моделей используемой системы,

   4. …

3. Используя методику будут появляться вопросы, ответы на которые и есть детальные требования.

По форме это напоминает букву u, поэтому почему бы не назвать это “u-принципом”?! (Если кто-нибудь сталкивался с этим ранее, прошу указать ссылку в комментариях)

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

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

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

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

1. Какова будет дополнительная прибыль, 

2. Каковы будут расходы на реализацию и поддержку.

Нужно ли делать требование:

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

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

В общем случае, детальная проработка фичи ПО и процесса ее использования имеет смысл только после получения оценок окупаемости.

Следовательно, процесс проработки детальности моделей реализации бизнес-процессов и ИТ систем должен быть синхронизирован и согласован друг с другом (F): 

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

Итого

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

1. Обоснованием детального требования не может быть генерирующее требование, обоснование лежит в области использующих систем (A).

2. При проработке моделей решения появляются вопросы, ответы на которые и есть детальные требования (B).

3. Отрицательные ответы на вопросы также являются требованиями, позволяющие иметь полное обоснование созданной модели решения (C).

4. Некоторые вопросы “чтобы что”, являющимися фактами и моделями использующей системы и контекста, нельзя предугадать заранее, так как они появляются в результате применения методик моделирования. Соответственно, нельзя заранее получить нужные ответы (D)

Эти факты собраны в названный автором u-принцип анализа и проектирования (E)

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

Поэтому модель “Вначале проработаем будущий бизнес-процесс в деталях, а потом ИТ систему в деталях” ошибочна и ведет к потере времени и денег.

Благодарности

Спасибо Сергею Титкову, Сергею Мартыненко и Андрею Корниенко за конструктивную критику.