วิธีจัดทำเอกสารกฎเกณฑ์ทางธุรกิจ

ฉันสงสัยว่าอะไรจะเป็นวิธีที่เป็นทางการและเป็นวิธีที่ได้รับการฝึกฝนกันมากที่สุดในการทำเอกสารกฎเกณฑ์ทางธุรกิจ คุณจะทำเอกสารข้อกำหนดของ UI ของสิ่งประดิษฐ์เพื่อการพัฒนาได้อย่างไร (เช่นฟิลด์เอกสารแบบฟอร์มและวิธีการทำงานของปุ่มบนฟอร์มข้อความข้อมูล ฯลฯ )

สำหรับกฎเกณฑ์ทางธุรกิจฉันคิดว่า @Joppe ชี้ให้เห็นถึง UML ที่เราทุกคนกำลังคิด

ใช้ Case Diagrams ทำภาพรวมที่ยอดเยี่ยมของ Actors / Roles โต้ตอบกับระบบและระบบอะไร สำหรับกรณีการใช้ Complexe ข้อมูลเพิ่มเติมอธิบาย textually จะช่วยได้มาก ( ปัจจัยพื้นฐาน , postconditions , อ้างอิงในการประหารชีวิต UC ก่อนหน้า , ฯลฯ )

มีไดอะแกรมที่สามารถมองเห็นภาพรวมของธุรกิจในระดับต่าง ๆ ได้ดี:

• State Machine Diagramหากมีเอกสารสถานะใด ๆ ให้จัดทำเอกสาร
• กิจกรรมแผนภาพ สำหรับกรณีการใช้งานที่ซับซ้อนคุณอาจต้องลงรายละเอียด ระดับของรายละเอียดขึ้นอยู่กับคุณและขึ้นอยู่กับว่าใครจะอ่านเอกสาร เอกสารนี้อาจดูไม่เหมือนเอกสารทางธุรกิจ แต่ด้วยรายละเอียดในระดับที่เหมาะสม

เพียงคำแนะนำให้กำหนดรหัสให้กับแต่ละกรณีการใช้งาน (เช่น: UC-1 , UC-n ) สิ่งเหล่านี้จะมีประโยชน์ในภายหลังในระหว่างเอกสารของ UI

สำหรับเอกสาร UI ปฏิบัติทั่วไป (วันนี้) คือการทำwireframes ค่อนข้างดีกว่าภาพหน้าจอเพราะดูสะอาดตาและเรียบง่ายขึ้น ตัวอย่างเช่นลองดูWireframeSketcher

Wireframes อาจมีเอกสารไม่เพียงพอดังนั้นสำหรับแต่ละหน้าจอจะมีการแนะนำสั้น ๆ และอธิบายทุกปุ่ม นอกจากนี้ทำการอ้างอิงถึง UC ที่เกี่ยวข้องกับหน้าจอ ( ดูตอนนี้ทำไมรหัส UC มีประโยชน์ ) สิ่งนี้จะทำให้เอกสารของคุณสอดคล้องกัน

จุดของเครื่องมือเช่น Wireframesketcher คือพวกเขาทำการจำลองแบบโต้ตอบ สมบูรณ์แบบที่จะให้สิ่งที่โต้ตอบกับลูกค้าในขณะที่คุณยังคงออกแบบหรือพัฒนา

อย่าลืมให้เอกสารแผนนำทาง Nav แผนไม่มีไดอะแกรม UML แต่สามารถใช้State Machine Diagramแทนได้ มันไม่ใช่สิ่งที่ทำ แต่ยัง

ในที่สุดโปรดจำไว้ว่าคุณเป็นใคร

• ช่างเทคนิค : คุณสามารถลงลึกในรายละเอียดและใช้เทคนิค

• ไม่ใช่ช่างเทคนิค : หลีกเลี่ยงการใช้เทคนิค (ไม่เกี่ยวข้องกับ languaje หรือรหัส) พยายามที่จะชัดเจนและเรียบง่ายและใช้คำ / คำเดียวกันกับที่ลูกค้าใช้ คิดว่าคุณไม่มีความคิดในการเขียนโปรแกรม

เอกสารมักจะทำในกรณีการใช้งานและรูปแบบร้อยแก้วอื่น ๆ นอกจากนี้ยังมีประโยชน์อย่างยิ่งที่จะมีไดอะแกรม UML และรูปแบบกราฟิกอื่น ๆ ที่ให้ภาพรวมในระดับที่สูงขึ้นและง่ายต่อการเข้าใจในเวลาที่สั้นกว่าการอ่านหน้าและหน้า ..

และสุดท้าย แต่ไม่ท้ายสุดเอกสารที่ดีที่สุดคือกรณีทดสอบที่ดำเนินการตามกฎเกณฑ์ทางธุรกิจ ด้วยวิธีนี้คุณสามารถเปลี่ยนรหัสและพบว่าคุณละเมิดกฎทางธุรกิจ มิฉะนั้นเอกสารจะอยู่ภายใต้อันตรายจากการค้างและล้าสมัยอยู่เสมอ

น่าจะเป็นรูปแบบที่พบมากที่สุดคือกรณีการใช้งาน คุณสามารถเสริมพวกเขาด้วยการจำลองหน้าจอและคำอธิบาย

หนังสือที่ฉันแนะนำคือ "การเขียนกรณีใช้งานอย่างมีประสิทธิภาพ" โดย Alistair Cockburn มันอธิบายถึงวิธีที่คุณสามารถเขียนกรณีการใช้งานในระดับรายละเอียดต่าง ๆ วิธีหลีกเลี่ยงการล้มสำหรับวิธีการที่ขับเคลื่อนด้วย 'เทมเพลต' และเพียงติดกับเอกสารที่จำเป็นและเกี่ยวข้องกับบิต

ไม่ว่าคุณจะใช้วิธีใดให้แน่ใจว่าพวกเขาสามารถรักษาไว้ได้ พวกเขาควรจะเป็นเอกสารที่มีชีวิต การจัดเก็บเอกสารในระบบการควบคุมเวอร์ชันหรือระบบการจัดการเอกสารบางประเภทเช่น Sharepoint สามารถช่วยดูแลรักษาเอกสารเหล่านี้ได้ในระยะยาว การติดตามกฏทางธุรกิจผ่านเอกสาร word ที่แนบมากับอีเมลเป็นวิธีที่น่ากลัวในการจัดการกับปัญหาเนื่องจากมันนำไปสู่หลาย ๆ เวอร์ชันที่ลอยไปมา

ฉันขอแนะนำให้แยกกฎธุรกิจออกจากข้อกำหนดของระบบอย่างเคร่งครัดโดยอ้างอิงเฉพาะกฎธุรกิจจากกรณีการใช้งานและการออกแบบ UI เทคนิคที่ฉันโปรดปรานคือ: มีรายการกฎเกณฑ์ทางธุรกิจที่ระบุในสเปรดชีต - ในการออกแบบระบบให้ใช้ข้อมูลจำเพาะกรณีเรื่องราวของผู้ใช้หรืออะไรก็ตามเพียงระบุ "ผู้ใช้ป้อนข้อมูลตามที่ระบุไว้ในกฎธุรกิจ BR012", "ระบบจะคำนวณจำนวนเงินทั้งหมดตามที่ระบุไว้ในกฎธุรกิจ BR510" ฉันแนะนำบทความนี้http://www.allaboutrequirements.com/business-rules/

ลองสร้างแผนภาพ UML โดยใช้รหัส visual studio และปลั๊กอิน Plant UML