Как документировать бизнес-правила

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

Что касается бизнес-правил, я думаю, что @Joppe указал на UML, о котором мы все думали.

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

Есть диаграммы, которые также делают отличные обзоры бизнеса на разных уровнях:

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

Просто совет, назначьте код для каждого варианта использования (то есть: UC-1 , UC-n ). Это будет полезно позже, во время документации пользовательского интерфейса.

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

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

Смысл таких инструментов, как Wireframesketcher, в том, что они делают интерактивные макеты. Идеально для того, чтобы предоставить что-то интерактивное клиенту, пока вы все еще проектируете или разрабатываете.

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

Наконец, имейте в виду, к кому вы обращаетесь.

• Техник : вы можете углубиться в детали и использовать технические детали.

• Не Техник : избегайте технических подробностей (не связанных с языком или кодом). Постарайтесь быть ясными и простыми и использовать те же термины / слова, которые использует клиент. Думай, будто ты не имел понятия о программировании.

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

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

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

Книга, которую я бы порекомендовал, - «Написание примеров эффективного использования» Алистера Кокберна. Он описывает, как вы можете писать сценарии использования на разных уровнях детализации, как избежать попадания в подход, основанный на шаблонах, и просто придерживаться документирования необходимых и релевантных битов.

Какой бы метод вы ни использовали, будьте уверены, что их можно активно поддерживать. Они должны быть живыми документами. Хранение документов в системе контроля версий или в какой-либо другой системе управления документами, такой как Sharepoint, может иметь большое значение для их сохранения. Отслеживание бизнес-правил с помощью текстовых документов, прикрепленных к электронным письмам, является ужасным способом решения этой проблемы, поскольку приводит к появлению множества версий.

Я настоятельно рекомендую строго отделять бизнес-правила от спецификации системы, ссылаясь только на бизнес-правила и варианты использования и дизайн пользовательского интерфейса. Моя любимая техника: - иметь список определенных бизнес-правил в электронной таблице. - В проекте системы используйте спецификацию прецедента, пользовательские истории или что-то еще, просто укажите «Пользователь вводит информацию, как указано в бизнес-правиле BR012», «Система вычисляет общую сумму, как указано в бизнес-правиле BR510». Я рекомендую эту статью http://www.allaboutrequirements.com/business-rules/

Попробуйте сгенерировать диаграмму UML, используя код Visual Studio и плагин Plant UML.