การจัดการวงจรชีวิตความต้องการ

⚡ สรุปอย่างชาญฉลาด

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

  • 🌀 ภาพรวมวงจรชีวิตผลิตภัณฑ์: วงจรชีวิตของข้อกำหนดประกอบด้วยสี่ขั้นตอนหลัก ได้แก่ การกำหนด การตรวจสอบความถูกต้อง การจัดทำเอกสาร และการจัดการ ซึ่งเป็นตัวกำหนดวิธีการดำเนินงานของโครงการทุกโครงการ
  • 🧭 ภารกิจของ BABOK: Tracการดำเนินงานต่อเนื่อง 5 อย่างที่กำหนดไว้ในคู่มือ BABOK ได้แก่ การบำรุงรักษา การจัดลำดับความสำคัญ การประเมินการเปลี่ยนแปลง และการอนุมัติข้อกำหนด
  • 🔍 การประเมินผลกระทบ: การวิเคราะห์ความต้องการจะสร้างข้อเท็จจริงและตัวเลขที่ช่วยให้นักวิเคราะห์ธุรกิจสามารถคาดการณ์ผลลัพธ์และลดความเสี่ยงของโครงการได้ตั้งแต่เนิ่นๆ
  • 📄 ขอบเขตของเอกสาร: เอกสารข้อกำหนดที่สมบูรณ์จะครอบคลุมความต้องการของผู้มีส่วนได้ส่วนเสีย แผนการวิเคราะห์ธุรกิจ การวิเคราะห์สถานะปัจจุบัน และข้อกำหนดขอบเขตงาน
  • 🔗 Tracความสามารถ: ข้อกำหนด Tracเมทริกซ์ความน่าจะเป็นเชื่อมโยงข้อกำหนดทุกข้อเข้ากับการออกแบบ โค้ด และการทดสอบ ป้องกันการขยายขอบเขตงานโดยไม่จำเป็น และการไม่ครอบคลุมตามกำหนด
  • 🛠️ เครื่องมือสำหรับภูมิทัศน์: จามา คอนเน็กต์, IBM ประตู Modern Requirementsจิร่ากับ Xrayและ Azure DevOps ช่วยทำให้วงจรชีวิตของผลิตภัณฑ์เป็นไปโดยอัตโนมัติตั้งแต่ต้นจนจบ

การจัดการวงจรชีวิตความต้องการ

วงจรชีวิตของข้อกำหนดคืออะไร?

วงจรชีวิตของข้อกำหนดประกอบด้วยหลายขั้นตอน และบางครั้งอาจเป็นกระบวนการที่ซับซ้อน ลักษณะของกระบวนการขึ้นอยู่กับวิธีการที่คุณเลือกใช้ในการพัฒนาซอฟต์แวร์ เช่น Agile, Waterfall, Incremental เป็นต้น แต่ละขั้นตอนอาจเกี่ยวข้องกับเอกสารและการอนุมัติจำนวนมาก นอกจากนี้ยังเกี่ยวข้องกับเอกสารโครงการ เช่น ข้อเสนอโครงการ แผนการจัดการโครงการ ขอบเขตโครงการ และกรณีศึกษาทางธุรกิจ มาดูกันว่าขั้นตอนทั่วไปของวงจรชีวิตของข้อกำหนดที่นักวิเคราะห์ธุรกิจทุกคนควรรู้มีอะไรบ้าง

แผนภาพวงจรชีวิตความต้องการ

แผนภาพวงจรชีวิตความต้องการ

ระยะที่ 1: คำจำกัดความความต้องการ

นี่เป็นหนึ่งในขั้นตอนหลักของกระบวนการรวบรวมข้อกำหนด ซึ่งโดยทั่วไปเรียกว่าการระดมความต้องการtracการสอบถามหรือการชักชวน

เมื่อรวบรวมความต้องการแล้ว ก็สามารถจัดเรียงในโฟลเดอร์อย่างมีตรรกะตามการเปิดตัวผลิตภัณฑ์หรือสปรินต์ได้

ข้อกำหนดเหล่านี้จะได้รับการวิเคราะห์เพิ่มเติมเพื่อจัดเตรียมข้อเท็จจริงและตัวเลขที่จะช่วยนักวิเคราะห์ธุรกิจ tracผลลัพธ์ที่เป็นไปได้ k แบบจากการวิเคราะห์ กระบวนการนี้เรียกว่า การประเมินผลกระทบ.

ขั้นตอนที่ 2: การตรวจสอบข้อกำหนด

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

การตรวจสอบความถูกต้องของข้อกำหนดมีความสำคัญอย่างยิ่งต่อความสำเร็จของโครงการใดๆ การตรวจสอบความถูกต้องของข้อกำหนดรวมถึงการตรวจสอบข้อกำหนดเฉพาะ โครงร่างเว็บไซต์ การจำลองที่มีความละเอียดสูง และอื่นๆ tracการวิเคราะห์ความเป็นไปได้

มีเครื่องมือตรวจสอบความถูกต้องของข้อกำหนดที่ช่วยทำให้งานส่วนใหญ่เป็นไปโดยอัตโนมัติ โดยมีการแทรกแซงจากมนุษย์น้อยที่สุด

ขั้นตอนที่ 3: เอกสารข้อกำหนด

เอกสารข้อกำหนดควรครอบคลุมหัวข้อต่อไปนี้:

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

ระยะที่ 4: การจัดการความต้องการ

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

ภารกิจหลักห้าประการในการจัดการวงจรชีวิตของข้อกำหนด

คู่มือ IIBA BABOK อธิบายการจัดการวงจรชีวิตของข้อกำหนดว่าเป็นงานห้าอย่างที่เชื่อมโยงกัน ซึ่งนักวิเคราะห์ธุรกิจจะดำเนินการก่อน ระหว่าง และหลังการส่งมอบ งานเหล่านี้ไม่ได้เป็นไปตามลำดับอย่างเคร่งครัด แต่เกิดขึ้นอย่างต่อเนื่องขณะที่โครงการพัฒนาไป

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

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

ข้อกำหนด Tracคำอธิบายเมทริกซ์ความน่าจะเป็น (RTM)

ข้อกำหนด Tracเมทริกซ์ความน่าจะเป็น หรือ RTM คือเอกสารที่ใช้ในการทำงาน ซึ่งเชื่อมโยงข้อกำหนดทุกข้อเข้ากับที่มา องค์ประกอบการออกแบบ ส่วนประกอบของโค้ด และกรณีทดสอบ เป็นเครื่องมือเชิงปฏิบัติที่เปลี่ยน “Tracแปลงงาน "ข้อกำหนด" ให้เป็นบันทึกที่สามารถค้นหาได้

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

ในโครงการแบบ Agile นั้น RTM จะเชื่อมโยง Epic และ User Story เข้ากับเกณฑ์การยอมรับและการทดสอบอัตโนมัติ เครื่องมือสมัยใหม่ เช่น Jama Connect, Modern Requirementsจิระ Xrayและ Azure DevOps สร้างเมทริกซ์โดยอัตโนมัติเพื่อให้ข้อมูลเป็นปัจจุบันอยู่เสมอในทุกสปรินต์ แทนที่จะปล่อยให้มันกลายเป็นสเปรดชีตที่ไม่มีใครเชื่อถือ

เครื่องมือบริหารจัดการความต้องการยอดนิยม

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

  • จามา คอนเน็กต์: แพลตฟอร์มกำหนดความต้องการระดับองค์กร พร้อมฟังก์ชันการกำหนดฐานข้อมูล การตรวจสอบ การวิเคราะห์ความเสี่ยง และการทำงานแบบเรียลไทม์ tracความสามารถในการทำงานร่วมกันของทีมวิศวกรรมระบบ
  • IBM Engineering Requirements ฝ่ายบริหาร DOORS: เครื่องมือที่ใช้กันมาอย่างยาวนานในอุตสาหกรรมการบินและอวกาศ การป้องกันประเทศ และยานยนต์ สำหรับชุดข้อกำหนดขนาดใหญ่ที่มีการควบคุมอย่างเข้มงวด
  • Modern Requirements สำหรับ Azure นักพัฒนาซอฟต์แวร์: ขยาย Azure รายการงาน DevOps พร้อมการตรวจสอบ การกำหนดเกณฑ์พื้นฐาน และ tracคุณสมบัติของ eability ที่ออกแบบมาสำหรับทีมงานแบบ Agile และ Hybrid
  • จิร่าและ Xray: การผสมผสานวิธีการพัฒนาซอฟต์แวร์แบบ Agile ที่ได้รับความนิยม ซึ่งเชื่อมโยง Epic และ User Story เข้ากับ Test Case และ Defect ทำให้การจัดการข้อกำหนดมีความยืดหยุ่นมากขึ้นสำหรับทีมพัฒนาซอฟต์แวร์หลายทีม
  • ข้อกำหนดของ Visure สำหรับ ALM: แพลตฟอร์มการจัดการวงจรชีวิตแอปพลิเคชันที่รวมข้อกำหนด การทดสอบ ความเสี่ยง และการควบคุมการเปลี่ยนแปลงไว้ในพื้นที่ทำงานเดียว
  • นักเล่าเรื่องตามแบบพิมพ์เขียว: มุ่งเน้นการเปลี่ยนวัตถุประสงค์ทางธุรกิจให้เป็นข้อกำหนดที่มีโครงสร้างพร้อมสำหรับการใช้งานเครื่องมือส่งมอบในขั้นตอนต่อไป

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

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

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

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

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

โปรเจกต์แบบ Waterfall จะกำหนดความต้องการพื้นฐานทั้งหมดให้แน่นอนก่อนเริ่มการพัฒนา ในขณะที่โปรเจกต์แบบ Agile จะมอง Product Backlog เป็นชุดความต้องการที่เปลี่ยนแปลงได้ตลอดเวลา โดยจะได้รับการปรับปรุงในทุกๆ Sprint ทั้งสองแบบต่างก็มีข้อดีข้อเสียเหมือนกัน tracเช่น ดำเนินการจัดลำดับความสำคัญและอนุมัติข้อกำหนดต่างๆ แต่จังหวะและรูปแบบการดำเนินการจะแตกต่างกัน

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

ข้ามไปping tracข้อผิดพลาดที่ก่อให้เกิดการทำงานซ้ำและการพลาดกำหนดส่งงานมากที่สุด ได้แก่ การตรวจสอบความเหมาะสมของงาน การตรึงขอบเขตงานโดยไม่มีการควบคุมการเปลี่ยนแปลง การผสมผสานแนวคิดการแก้ปัญหากับความต้องการทางธุรกิจ และการมองข้อกำหนดเป็นเพียงเอกสารฉบับเดียวแทนที่จะเป็นสิ่งที่สามารถปรับปรุงแก้ไขได้ตลอดเวลา

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

เอกสารข้อกำหนดทางธุรกิจ (Business Requirements Document หรือ BDI) กำหนดความต้องการทางธุรกิจ ขอบเขตของโครงการ วัตถุประสงค์ของผู้มีส่วนได้ส่วนเสีย และข้อกำหนดระดับสูง โดยจะอยู่เหนือกว่าข้อกำหนดด้านฟังก์ชันและด้านเทคนิค และมักเป็นข้อมูลหลักในการออกแบบโซลูชันและการคัดเลือกผู้ขาย

สรุปโพสต์นี้ด้วย: