การจัดการวงจรชีวิตความต้องการ
⚡ สรุปอย่างชาญฉลาด
การจัดการวงจรชีวิตของข้อกำหนดครอบคลุมถึง การกำหนด การตรวจสอบความถูกต้อง การจัดทำเอกสาร การจัดการ tracกระบวนการต่างๆ เช่น การกำหนดลำดับความสำคัญ การประเมินการเปลี่ยนแปลง และการอนุมัติ ช่วยให้ผู้เชี่ยวชาญด้านการวิเคราะห์ธุรกิจมีกรอบการทำงานที่ทำซ้ำได้ เพื่อให้ข้อกำหนดของซอฟต์แวร์สอดคล้องกับความต้องการทางธุรกิจในทุกขั้นตอนของโครงการ
วงจรชีวิตของข้อกำหนดคืออะไร?
วงจรชีวิตของข้อกำหนดประกอบด้วยหลายขั้นตอน และบางครั้งอาจเป็นกระบวนการที่ซับซ้อน ลักษณะของกระบวนการขึ้นอยู่กับวิธีการที่คุณเลือกใช้ในการพัฒนาซอฟต์แวร์ เช่น 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 ร่วมกับสเปรดชีต และค่อย ๆ เปลี่ยนไปใช้แพลตฟอร์มเฉพาะเมื่อขนาดทีมต้องการ


