Коллеги, добрый день!

В рамках системы, над которой я сейчас работаю, реализуется большое количество сложных бизнес-правил. Каждое бизнес-правило содержит порядка 10 бизнес-условий.  Для проверки этих условий необходима информация из нескольких внешних систем заказчика. Исторически сложилось, что информацию о бизнес-правиле и технических подробностях его реализации заказчик присылает в одном документе в смешанном виде, причем часто с упором в реализацию: "Параметр X должен иметь значение в диапазоне от N до M (значение параметра смотреть в поле Y таблицы Z системы W)". Структуру всех систем заказчика наша команда знает еще недостаточно хорошо, чтобы не нуждаться в таких пояснениях от заказчика, но и такая структура документа нечитабельна и нежизнеспособна.

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

Что сейчас стараюсь делать для каждого бизнес-условия:
1. Узнать, что означает параметр X в физическом мире, почему для него такие ограничения. Сформулировать условие с точки зрения бизнеса.
2. Доформулировать логические условия проверки бизнес-условия, если необходимо.
3. Указать источники данных, необходимые для проверки логических условий.

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

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

У меня на данный момент используется такая структура:

Для каждого бизнес-правила в таблице указывается набор бизнес-условий и соответствующих им логических условий. Если логическое условие сложное, создается подраздел, в котором оно описывается подробно. Ссылка на этот раздел дается в таблице.

бизнес-условие 1	Логическое условие 1  Логическое условие 2 (подробное описание см. в п.п. 3.2.2)
бизнес-условие 2	Логическое условие 3
3.2.2 Логическое условие 2

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

Проблемы текущего решения:

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

Буду благодарна за комментарии и предложения.

Что такое «недостаточно просто интуитивно»?
Сколько времени занимает у пользователя поиск нужного бизнес-правила? А сколько должно?
Каков процент ошибок при интерпретации пользователем прочитанных правил? Какой % допустим?
Сколько времени тратит пользователь документа на дополнительные разъяснения?

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

Что такое «недостаточно просто интуитивно»?

Например, пользователи документа в упор не видят ссылку на развернутое описание логического условия. Аналитик со стороны заказчика говорил мне, что надо развернуть описание логического условия. Пришлось явно обратить внимание, что есть ссылка и соответствующий пункт, в котором все расписано. Разработчик также задавал вопрос "А как это проверить?", опять же пришлось отдельно обращать его внимание, что описание есть в документе.

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

Расскажи, пожалуйста, что ты имеешь в виду под реестром? Очень интересно!

Коллеги, добрый день!

Привет!

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

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

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

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

Для наглядности я сделал маленький пример (во вложении), на основе твоих вводных, где проиллюстрировал свои предложения.

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

Да, мне про реестр тоже интересно:)

Да, мне про реестр тоже интересно:)

Обычный файл Excel, как вариант.

Обычный файл Excel, как вариант.

Возможно.
Но у меня создалось впечатление что речь идет о чем-то большем.

Например, пользователи документа в упор не видят ссылку на развернутое описание логического условия. Аналитик со стороны заказчика говорил мне, что надо развернуть описание логического условия. Пришлось явно обратить внимание, что есть ссылка и соответствующий пункт, в котором все расписано. Разработчик также задавал вопрос "А как это проверить?", опять же пришлось отдельно обращать его внимание, что описание есть в документе.

Ну так может дело в том, что ты спроекировала маленькую информационную систему в виде документа, а внедрение её не провела? Ты проводила обучение по использованию документа пользователями? Во введении к документа описаны правила работы с ним и ответы на частые вопросы?

С другой стороны, если предполагается, что каждый пользователь обратится к документу порядка 50 раз за квартал, то может то, что ты один раз ответишь на вопросы по документу — не так страшно? Проведёшь обучение, так сказать, по запросу?

Расскажи, пожалуйста, что ты имеешь в виду под реестром? Очень интересно!

Любая учётная структура, которая умеет работать с набором записей — таблица Excel, Sharepoint, Access, Google spreadsheet.