Làm thế nào để ghi lại các quy tắc kinh doanh

Tôi đang tự hỏi điều gì sẽ là phương pháp chính thức và phổ biến nhất được thực hiện để ghi lại các quy tắc kinh doanh? Ngoài ra, làm thế nào để bạn ghi lại các đặc tả giao diện người dùng của các tạo phẩm phát triển (ví dụ: các trường biểu mẫu Tài liệu và cách các nút hoạt động trên biểu mẫu, văn bản thông tin .. vv)

Đối với các quy tắc kinh doanh, tôi nghĩ rằng @Joppe đã chỉ ra UML mà tất cả chúng ta đều nghĩ.

Sơ đồ ca sử dụng thực hiện tổng quan xuất sắc về cách Diễn viên / Vai trò tương tác với hệ thống và hệ thống làm gì. Đối với trường hợp sử dụng phức tạp, thông tin bổ sung được giải thích bằng văn bản sẽ giúp ích rất nhiều ( điều kiện tiên quyết , hậu điều kiện , sự phụ thuộc vào các lần thực thi UC trước đó , v.v. )

Có những sơ đồ cũng thực hiện tổng quan tuyệt vời về doanh nghiệp ở các cấp độ khác nhau:

• Sơ đồ máy trạng thái nếu có bất kỳ loại trạng thái nào được ghi lại.
• Sơ đồ hoạt động . Đối với trường hợp sử dụng phức tạp, bạn có thể cần phải đi sâu vào chi tiết. Mức độ của các chi tiết là tùy thuộc vào bạn và phụ thuộc vào người sẽ đọc tài liệu. Tài liệu này có thể không giống tài liệu kinh doanh, nhưng với mức độ chi tiết phù hợp, nó có thể trở thành như vậy.

Chỉ cần một lời khuyên, gán mã cho từng Ca sử dụng (ví dụ: UC-1 , UC-n ). Chúng sẽ hữu ích sau này, trong tài liệu UI.

Đối với tài liệu UI, thực tế phổ biến (ngày nay) là làm khung dây . Khá hơn so với ảnh chụp màn hình vì nó trông gọn gàng và đơn giản hơn. Chẳng hạn, hãy xem qua WireframeSketcher

Wireframes có thể không đủ tài liệu, vì vậy, đối với mỗi màn hình, hãy giới thiệu ngắn gọn và mô tả mọi nút. Ngoài ra, hãy tham khảo các UC liên quan đến màn hình ( xem ngay tại sao mã UC hữu ích ). Điều này sẽ làm cho tài liệu của bạn mạch lạc.

Quan điểm của các công cụ như Wireframesketcher là chúng thực hiện các mockup tương tác. Hoàn hảo để cung cấp một cái gì đó tương tác cho khách hàng trong khi bạn vẫn đang thiết kế hoặc phát triển.

Đừng quên ghi lại kế hoạch điều hướng . Hải. Gói không có sơ đồ UML, nhưng Sơ đồ máy trạng thái có thể được sử dụng thay thế. Nó không phải cho những gì nó đã được thực hiện, nhưng vẫn còn.

Cuối cùng hãy ghi nhớ những người bạn đang giải quyết.

• Kỹ thuật viên : bạn có thể đi sâu vào chi tiết và sử dụng các kỹ thuật.

• Không phải Kỹ thuật viên : tránh các kỹ thuật (không liên quan đến languaje cũng như mã). Cố gắng rõ ràng và đơn giản và sử dụng cùng một thuật ngữ / từ mà khách hàng sử dụng. Hãy suy nghĩ như bạn không có ý tưởng về lập trình.

Tài liệu thường được thực hiện trong các trường hợp sử dụng và các hình thức văn xuôi khác. Ngoài ra, có thể cực kỳ hữu ích khi có sơ đồ UML và các dạng đồ họa khác cung cấp cho bạn cái nhìn tổng quan ở cấp độ cao hơn và dễ hiểu trong thời gian ngắn hơn đọc trang và trang ..

Và cuối cùng nhưng không kém phần quan trọng, tài liệu tốt nhất là các trường hợp thử nghiệm thực thi các quy tắc kinh doanh. Bằng cách đó bạn có thể thay đổi mã và phát hiện ra rằng bạn đang vi phạm quy tắc kinh doanh. Nếu không, tài liệu luôn có nguy cơ trở nên cũ kỹ và lỗi thời.

Có lẽ hình thức phổ biến nhất là Trường hợp sử dụng . Bạn có thể bổ sung chúng với các mô tả và mô tả màn hình.

Một cuốn sách tôi muốn giới thiệu là "Viết các trường hợp sử dụng hiệu quả" của Alistair Cockburn. Nó mô tả cách bạn có thể viết các trường hợp sử dụng ở các mức độ chi tiết khác nhau, làm thế nào để tránh rơi vào cách tiếp cận theo hướng 'mẫu' và chỉ cần bám vào tài liệu các bit cần thiết và có liên quan.

Dù bạn sử dụng phương pháp nào, hãy chắc chắn rằng chúng có thể được duy trì tích cực. Chúng nên là tài liệu sống. Việc lưu trữ các tài liệu trong một hệ thống Kiểm soát Phiên bản hoặc một số loại hệ thống quản lý tài liệu như Sharepoint, có thể đi một chặng đường dài hướng tới việc duy trì chúng. Theo dõi các quy tắc kinh doanh thông qua các tài liệu từ được đính kèm trong email là một cách khủng khiếp để giải quyết vấn đề này, vì nó dẫn đến nhiều phiên bản trôi nổi xung quanh.

Tôi đặc biệt khuyên bạn nên tách biệt nghiêm ngặt các quy tắc kinh doanh khỏi đặc tả hệ thống bằng cách chỉ giới thiệu các quy tắc kinh doanh khỏi trường hợp sử dụng và thiết kế UI. Kỹ thuật yêu thích của tôi là: - Có một danh sách các quy tắc kinh doanh được xác định trong một bảng tính. - Trong thiết kế hệ thống, đặc tả trường hợp sử dụng, câu chuyện của người dùng hoặc bất cứ điều gì, chỉ cần chỉ định "Người dùng nhập thông tin theo quy định trong quy tắc kinh doanh BR012", "Hệ thống tính tổng số tiền như quy định trong quy tắc kinh doanh BR510". Tôi đề xuất bài viết này http://www.allaboutrequirements.com/business-rules/

Hãy thử tạo sơ đồ UML bằng mã studio trực quan và plugin Plant UML