วิธีจัดระเบียบข้อกำหนดในฐานะนักวิเคราะห์ธุรกิจ

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

ความต้องการทางธุรกิจสามารถนำเสนอได้ในรูปแบบใดรูปแบบหนึ่งต่อไปนี้:

• ตารางหรือสเปรดชีต
• ไดอะแกรม (เวิร์กโฟลว์)
• กราฟ
• แบบจำลอง (แผนภาพความสัมพันธ์เอนทิตี)
• ต้นแบบหรือการจำลอง
• ประโยคที่มีโครงสร้างหรือเทมเพลตข้อความ

วิธีจัดระเบียบและนำเสนอข้อกำหนดทางธุรกิจ

ด้านล่างนี้คือขั้นตอนในการเขียนและจัดระเบียบข้อกำหนดต่างๆ นักวิเคราะห์ธุรกิจ.

ขั้นตอน 1) จัดหมวดหมู่ข้อกำหนดต่างๆ

• จัดข้อกำหนดแต่ละข้อลงในหมวดหมู่ที่เกี่ยวข้อง
• ผู้มีส่วนได้ส่วนเสียด้านเทคนิคควรเห็นหมวดหมู่ข้อกำหนดทางเทคนิค และผู้มีส่วนได้ส่วนเสียที่ไม่ใช่ด้านเทคนิคควรเห็นหมวดหมู่ข้อกำหนดทางธุรกิจหรือข้อกำหนดทั่วไป
• แต่ละองค์กรควรตัดสินใจว่าหมวดหมู่ใดเหมาะสมกับมาตรฐานของตนเอง
• การจำแนกประเภทอาจพิจารณาจากประเภทของข้อกำหนดได้เช่นกัน เช่น ข้อกำหนดด้านฟังก์ชันการทำงานเทียบกับข้อกำหนดด้านธุรกิจ แม้ว่าการแบ่งประเภทนี้จะไม่เหมาะสมกับทุกโครงการก็ตาม

ขั้นตอน 2) จัดเรียงข้อกำหนด
รวบรวมและจัดเรียงข้อกำหนดตามลำดับอย่างเป็นระบบ เพื่อให้ผู้มีส่วนได้ส่วนเสียสามารถค้นหาข้อมูลในเอกสารได้อย่างง่ายดายและระบุรายการที่ขาดหายไปได้

ขั้นตอน 3) เตรียมรายชื่อ.
จัดทำรายการตรวจสอบข้อกำหนด โดยจัดกลุ่มตามผู้มีส่วนได้ส่วนเสียที่ต้องอนุมัติข้อกำหนดเหล่านั้น

ตัวอย่างเช่น ผู้มีส่วนได้ส่วนเสียที่มีพื้นฐานด้านเทคนิคจะสนใจเฉพาะด้านเทคนิคของผลิตภัณฑ์เท่านั้น

ขั้นตอน 4) ใช้ตัวระบุที่ไม่ซ้ำกัน
If tracการเชื่อมโยงข้อกำหนดต่างๆ เข้าด้วยกันนั้นทำได้ยาก ดังนั้นจึงควรใช้ตัวระบุเฉพาะเพื่อทำให้ง่ายขึ้น tracการทำให้ง่ายขึ้น

ขั้นตอน 5) นำเสนอข้อกำหนดโดยใช้วิธีการที่ผู้มีส่วนได้ส่วนเสียต้องการ
คุณอาจต้องนำเสนอข้อกำหนดเดียวกันในรูปแบบที่แตกต่างกันสำหรับผู้มีส่วนได้ส่วนเสียที่แตกต่างกัน บางคนอาจชอบรูปแบบกราฟิก ในขณะที่บางคนอาจชอบรูปแบบประโยคที่เรียบเรียงอย่างเป็นระบบ

ขั้นตอน 6) เตรียมสารบัญ.
จัดทำสารบัญสำหรับข้อกำหนดทั้งหมด เพื่อช่วยให้ผู้เกี่ยวข้องเข้าใจได้ง่ายขึ้น track และค้นหาพวกมันได้อย่างรวดเร็ว

ขั้นตอน 7) ใช้เครื่องมือวิเคราะห์ธุรกิจ
ใช้ เครื่องมือวิเคราะห์ธุรกิจ ซึ่งจะช่วยนำเสนอและจัดหมวดหมู่ข้อกำหนดต่างๆ ได้อย่างสม่ำเสมอในทุกเวอร์ชัน

ขั้นตอน 8) จัดระเบียบเอกสารความต้องการตามผังกระบวนการ
ลบข้อกำหนดที่ไม่จำเป็นออกจากเอกสาร และจัดเรียงข้อกำหนดที่เหลืออยู่ตามขั้นตอนการทำงานที่เกี่ยวข้อง

ขั้นตอน 9) จัดทำแผนที่ข้อกำหนด
เชื่อมโยงข้อกำหนดแต่ละข้อที่คุณรวบรวมได้กับขั้นตอนเฉพาะในกระบวนการทำงาน เพื่อให้ผู้ตรวจสอบสามารถเชื่อมโยงข้อกำหนดนั้นกับขั้นตอนการทำงานที่เกี่ยวข้องได้

ขั้นตอน 10) ใช้ตารางและสัญลักษณ์แสดงหัวข้อย่อย
ใช้ตารางเพื่อนำเสนอข้อกำหนดที่ซับซ้อน และใช้หัวข้อย่อยเพื่อเน้นประเด็นสำคัญของแต่ละข้อกำหนด

เคล็ดลับที่มีประโยชน์สำหรับการเขียนและการนำเสนอเอกสารข้อกำหนดทางธุรกิจ

เพื่อการนำเสนอที่ดีขึ้นและ tracเนื่องจากข้อกำหนดทางธุรกิจเป็นหัวใจสำคัญ เคล็ดลับต่อไปนี้จึงมีประโยชน์สำหรับนักวิเคราะห์ธุรกิจ (BA) ทุกคน

• การจัดหมวดหมู่ข้อกำหนดนั้นใช้เวลานาน ดังนั้นควรกำหนดชุดหมวดหมู่มาตรฐานที่นักวิเคราะห์ธุรกิจ ผู้มีส่วนได้ส่วนเสีย ผู้เชี่ยวชาญเฉพาะด้าน และทีมงานด้านเทคนิคสามารถนำไปใช้ซ้ำได้ในโครงการต่างๆ แทนที่จะคิดค้นหมวดหมู่ใหม่ทุกครั้ง
• เตรียมข้อกำหนดแต่ละข้อโดยคำนึงถึงบริบทของกลุ่มเป้าหมาย ทำความเข้าใจผู้มีส่วนเกี่ยวข้อง ผู้มีอิทธิพล และผู้มีอำนาจตัดสินใจ (ผู้มีส่วนได้ส่วนเสีย ทีมงานด้านเทคนิค นักพัฒนาซอฟต์แวร์ และอื่นๆ)
• กำหนดข้อกำหนดทีละข้อ แต่ละข้อควรเป็นอะตอม
• หลีกเลี่ยงความคลุมเครือ — อย่าใช้คำขยายความที่ไม่ชัดเจน เช่น “เป็นต้น” หรือ “ประมาณ” ในข้อความแสดงความต้องการ
• ห้ามอ้างอิงถึงข้อกำหนดที่ยังไม่ได้กำหนดไว้
• ลบข้อความที่ซ้ำซ้อนและขัดแย้งออกจากเอกสาร
• แบ่งข้อกำหนดที่ซับซ้อนออกเป็นประเด็นย่อยๆ ที่จัดการได้ง่ายและตรวจสอบได้สะดวก
• บรรยาย อะไร ระบบจะจัดการเอง ไม่ใช่ อย่างไร มันจะทำได้เอง — การนำไปปฏิบัติควรอยู่ในขั้นตอนการออกแบบ

เทคนิคยอดนิยมในการแสดงภาพความต้องการทางธุรกิจ

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

• แบบจำลองและสัญลักษณ์กระบวนการทางธุรกิจ (BPMN): แผนภาพ BPMN แสดงกระบวนการทางธุรกิจแบบครบวงจร ตั้งแต่ต้นจนจบ โดยประกอบด้วยกลุ่มงาน ช่องทาง เกตเวย์ และเหตุการณ์ต่างๆ เหมาะอย่างยิ่งสำหรับการแสดงว่าใครทำอะไรและเมื่อไหร่
• แผนภาพกรณีการใช้งานและ Descriptไอออน: บันทึกปฏิสัมพันธ์ระหว่างผู้ใช้งานกับระบบ และผลลัพธ์ที่ผู้ใช้งานแต่ละฝ่ายคาดหวัง เหมาะสำหรับรายการงานค้างที่ขับเคลื่อนด้วยฟีเจอร์
• เรื่องราวของผู้ใช้พร้อมเกณฑ์การยอมรับ: การใช้ประโยคสั้นๆ เช่น “ในฐานะ … ฉันต้องการ … เพื่อให้ … ” ควบคู่กับเกณฑ์ Given-When-Then เป็นรูปแบบมาตรฐานที่ใช้ในทีมแบบ Agile
• แบบร่างโครงร่างและแบบจำลอง: หน้าจอความละเอียดต่ำหรือปานกลางที่ผลิตใน Figmaบัลซามิก หรือ Axure ซึ่งทำให้ข้อกำหนดด้าน UI จับต้องได้สำหรับผู้มีส่วนได้ส่วนเสียที่ไม่ใช่ผู้เชี่ยวชาญด้านเทคนิค
• แผนภาพความสัมพันธ์ระหว่างเอนทิตี (ERD): แสดงเอนทิตีข้อมูลที่โซลูชันต้องจัดเก็บและความสัมพันธ์ระหว่างเอนทิตีเหล่านั้น ซึ่งมีความสำคัญอย่างยิ่งต่อข้อกำหนดด้านการรายงานและการบูรณาการ
• แผนภาพการไหลของข้อมูล (DFD): Trace วิธีที่ข้อมูลเคลื่อนที่ผ่านกระบวนการ จัดเก็บ และผู้เกี่ยวข้องภายนอก โดยเฉพาะอย่างยิ่งในโครงการวิเคราะห์หรือบูรณาการ

เลือกเทคนิคให้เหมาะสมกับกลุ่มเป้าหมาย: ผู้บริหารจะตอบสนองต่อแผนผังกระบวนการและแผนภาพการเดินทาง นักพัฒนาจะตอบสนองต่อแผนภาพ ERD และเรื่องราวของผู้ใช้ และผู้ใช้ปลายทางจะตอบสนองต่อโครงร่างและต้นแบบ

เครื่องมือทั่วไปสำหรับการจัดระเบียบเอกสารข้อกำหนดทางธุรกิจ

เมื่อจำนวนข้อกำหนดเพิ่มขึ้นเกินกว่าสองสามสิบข้อ เอกสาร Word ก็ไม่สามารถรองรับการขยายตัวได้อีกต่อไป นักวิเคราะห์ธุรกิจจึงหันไปใช้เครื่องมือเฉพาะทางที่รองรับการกำหนดเกณฑ์มาตรฐาน การตรวจสอบ และอื่นๆ tracความสามารถในการปรับตัว และการควบคุมการเปลี่ยนแปลง ต่อไปนี้เป็นสิ่งที่ใช้กันอย่างแพร่หลายที่สุดในอุตสาหกรรม

• Jira ร่วมกับ Confluence: นี่คือการผสมผสานมาตรฐานสำหรับทีม Agile ข้อกำหนดต่างๆ จะถูกจัดเก็บในรูปแบบของ Epic และ Story ใน Jira โดยมีหน้า Confluence เป็นส่วนสนับสนุน ซึ่งจะเก็บรายละเอียดและไดอะแกรมของเอกสาร BRD (Business Responsive Document)
• จามา คอนเน็กต์: แพลตฟอร์มระดับองค์กรที่เน้นการจัดการข้อกำหนด การกำหนดฐานข้อมูล และการใช้งานแบบเรียลไทม์ tracความสามารถในการใช้งานสำหรับอุตสาหกรรมที่มีการกำกับดูแล เช่น อุปกรณ์ทางการแพทย์และอุตสาหกรรมการบินและอวกาศ
• IBM Engineering Requirements ฝ่ายบริหาร DOORS: เครื่องมือที่ใช้กันมาอย่างยาวนานในอุตสาหกรรมการป้องกันประเทศ ยานยนต์ และระบบที่มีความสำคัญต่อความปลอดภัย ซึ่งทุกความต้องการจะต้องได้รับการตรวจสอบอย่างละเอียด traceable.
• Modern Requirements สำหรับ Azure นักพัฒนาซอฟต์แวร์: ขยาย Azure DevOps พร้อมการตรวจสอบ การอนุมัติ การกำหนดฐานข้อมูลพื้นฐาน และการส่งออกเอกสาร BRD ในรูปแบบ Word โดยตรงจากรายการงาน
• Miro or Lucidchart: ใช้เครื่องมือไวท์บอร์ดและไดอะแกรมในการร่าง BPMN, ERD, เส้นทางการใช้งานของผู้ใช้ และบันทึกการประชุมเชิงปฏิบัติการ ซึ่งจะนำไปใช้ในการจัดทำ BRD อย่างเป็นทางการในภายหลัง
• บัลซามิกและ Figma: เครื่องมือสร้างโครงร่างและต้นแบบที่ช่วยให้มองเห็นข้อกำหนดด้าน UI ได้ชัดเจนแทนที่จะเป็นข้อความ

เลือกชุดเครื่องมือให้เหมาะสมกับขนาดของโครงการและความต้องการด้านการตรวจสอบ โครงการขนาดเล็กสามารถเริ่มต้นด้วย Confluence และ Jira ในขณะที่โครงการที่มีข้อกำหนดเข้มงวดมักต้องการ Jama หรือ DOORS เพื่อตอบสนองความต้องการดังกล่าว tracการตรวจสอบความเหมาะสม

ข้อผิดพลาดทั่วไปในการนำเสนอข้อกำหนดทางธุรกิจ

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

• การผสมผสานสิ่งต่างๆ และวิธีการผสมผสาน: ลื่นping การระบุรายละเอียดการนำไปใช้ลงในข้อกำหนดจะทำให้ทีมออกแบบติดอยู่กับแนวทางแก้ไขก่อนที่การวิเคราะห์จะเสร็จสมบูรณ์
• ถ้อยคำที่คลุมเครือ: คำต่างๆ เช่น “เร็ว” “ใช้งานง่าย” หรือ “ยืดหยุ่น” ไม่สามารถทดสอบได้ ควรแทนที่ด้วยเกณฑ์การยอมรับที่วัดผลได้
• รูปแบบเดียวเหมาะสำหรับผู้มีส่วนได้ส่วนเสียทุกฝ่าย: การนำเสนอมุมมองเดียวกันให้กับผู้บริหาร นักพัฒนา และผู้ใช้ปลายทาง มักจะไม่ทำให้ใครพอใจ ดังนั้นควรปรับรูปแบบให้เหมาะสมกับกลุ่มเป้าหมาย
• หายไป tracความสามารถ: ข้อกำหนดที่ไม่เชื่อมโยงกับวัตถุประสงค์ทางธุรกิจ องค์ประกอบการออกแบบ และกรณีทดสอบ จะไม่สามารถนำมาอ้างเหตุผลได้เมื่อมีการร้องขอเปลี่ยนแปลง
• ไม่มีการจัดลำดับความสำคัญ: การนำเสนอข้อกำหนดหลายร้อยข้อโดยปราศจาก MoSCoW การให้คะแนนแบบถ่วงน้ำหนัก หรือกรอบการทำงานที่คล้ายคลึงกัน จะทำให้ผู้มีส่วนได้ส่วนเสียต้องโต้เถียงกันเรื่องขอบเขตแทนที่จะเป็นเรื่องคุณค่า
• เอกสารที่มีข้อมูลมากเกินไป: การยัดเยียดแผนภาพ บันทึก และเหตุผลทั้งหมดลงในไฟล์ PDF ขนาด 200 หน้าเพียงไฟล์เดียว จะบดบังข้อกำหนดที่สำคัญ ควรแบ่งเอกสาร BRD ออกเป็นส่วนๆ อย่างเป็นระบบ พร้อมจัดทำสารบัญที่ชัดเจน
• ข้ามไปping ลงชื่อ: การนำเสนอเอกสาร BRD โดยไม่มีขั้นตอนการอนุมัติอย่างเป็นทางการ จะเปิดช่องให้เกิดการขยายขอบเขตงานโดยไม่จำเป็น และการโยนความผิดให้กันในภายหลังระหว่างการส่งมอบงาน

Revการตรวจสอบเอกสาร BRD เทียบกับรายการนี้ก่อนการประชุมผู้มีส่วนได้ส่วนเสียทุกครั้ง จะช่วยตรวจพบปัญหาต่างๆ ที่ก่อให้เกิดการทำงานซ้ำในขั้นตอนต่อๆ ไปได้ส่วนใหญ่

คำถามที่พบบ่อย