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

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

В зависимости от уровня описания процессов применяются разные подходы: BPMN для сложного ПО с несколькими процессами. Статусные модели (таблицы принятия решений) для сложных бизнес-правил. UML для детализации алгоритмов. Таблицы и схемы для дополнения UML или для совсем простых потоков информации. Чтобы описание процесса было законченным следует обратить внимание на следующие детали: входные данные, преобразования, выходные данные, зависимости, и ошибочные и исключительные ситуации.Такое описание благотворно скажется на сопровождении вашего ПО и на дальнейшем развитии. Представители бизнеса и аналитики смогут лучше формулировать свои требования - это упрощает взаимодействия с заказчиками или стейкхолдерами. Лучше и быстрее будет процесс описания новых требований и внесения изменения в старые. Будет легче искать ошибки и оптимизировать ПО. С документацией полного процесса команда разработки видит полную картину, а не только свою зону ответственности - это повышает качество разработки. Вы будете менее зависимы от ухода ключевых сотрудников, так как экспертиза будет частично зафиксирована внутри команды, и новым сотрудникам будет легче начинать знакомство с новой системой.