Як документувати ділові правила

Мене цікавить, який би був формальний і найчастіше практикуваний метод документування бізнес-правил? Крім того, як документувати специфікації інтерфейсу для артефактів розробки (наприклад, поля форм форми документації та як кнопки ведуть себе на формі, тексті інформації ... тощо)

Щодо правил бізнесу, я думаю, що @Joppe вказав на UML, про який ми всі думали.

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

Є діаграми, які також роблять прекрасні огляди бізнесу на різних рівнях:

• Діаграма стан машини, якщо є якісь стани, які повинні бути задокументовані.
• Діаграма діяльності . Для складних випадків використання може знадобитися заглибитись у деталі. Рівень деталей залежить від вас і залежить від того, хто буде читати документацію. Ця документація може не здаватися діловою документацією, але при правильному рівні деталей вона може стати такою.

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

Для документації у користувальницькому інтерфейсі звичайною практикою (в наші дні) є здійснення дротяних рамок . Набагато краще, ніж знімки екрана, оскільки він виглядає чистіше і простіше. Наприклад, подивіться на WireframeSketcher

Проводів може бути недостатньо документації, тому для кожного екрану зробіть короткий вступ та опишіть кожну кнопку. Крім того, робіть посилання на UC, що беруть участь у екрані ( дивіться зараз, чому корисні коди UC ). Це зробить вашу документацію узгодженою.

Сенс таких інструментів, як Wireframesketcher, полягає в тому, що вони роблять інтерактивні макети. Ідеально підходить для того, щоб подарувати замовнику щось інтерактивне, поки ви ще розробляєте або розробляєте.

Не забудьте задокументувати план навігації . Nav. План не має діаграми UML, але замість цього може бути використана діаграма стану машини . Це не для того, що було зроблено, але все ж.

Нарешті, пам’ятайте, до кого ви звертаєтесь.

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

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

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

І останнє, але не менш важливе документування - це тестові випадки, які виконують бізнес-правила. Таким чином ви можете змінити код і виявити, що ви порушуєте ділове правило. Інакше документація завжди загрожує застарілими та застарілими.

Напевно, найпоширенішою формою є випадки використання . Ви можете доповнити їх макетами на екрані та описами.

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

Який би метод ви не використовували, будьте впевнені, що їх можна активно підтримувати. Вони повинні бути живими документами. Якщо розмістити документи в системі управління версіями або в такій системі управління документами, як Sharepoint, можна пройти довгий шлях до збереження їх. Відстеження правил бізнесу через текстові документи, додані до електронних листів, - жахливий спосіб вирішити цю проблему, оскільки це призводить до того, що багато версій плавають навколо.

Я настійно рекомендую суворо відокремити бізнес-правила від специфікації системи, лише відправивши бізнес-правила від випадку використання та дизайну інтерфейсу користувача. Моя улюблена методика: - Складіть список ідентифікованих правил бізнесу в електронній таблиці. - У дизайні системи використовуйте специфікацію випадку, розповіді користувачів або будь-яке інше, просто вкажіть "Користувач вводить інформацію, як зазначено в бізнес-правилі BR012", "Система обчислює загальну суму, як зазначено в бізнес-правилі BR510". Я рекомендую цю статтю http://www.allaboutrequirements.com/business-rules/

Спробуйте створити діаграму UML за допомогою візуального коду студії та плагіну Plant UML