การวางแผนความต้องการที่ดี

แล้วอะไรคือความต้องการที่ดี? ข้อกำหนดที่ดีควรมีคุณค่าและสามารถดำเนินการได้ ควรกำหนดความต้องการรวมทั้งจัดเตรียมเส้นทางสู่การแก้ปัญหา ทุกคนในทีมควรเข้าใจความหมาย ข้อกำหนดแตกต่างกันไปตามความซับซ้อน

• เอกสารข้อกำหนดที่ดีสามารถเป็นส่วนหนึ่งของกลุ่มที่มีข้อกำหนดระดับสูงซึ่งแบ่งออกเป็นข้อกำหนดย่อย

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

• ข้อกำหนดที่ดีต้องรัดกุมและเฉพาะเจาะจงและควรตอบคำถามว่า“ เราต้องการอะไร” แทนที่จะเป็น "เราจะเติมเต็มความต้องการได้อย่างไร"

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

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

การรวบรวมและวิเคราะห์ความต้องการ

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

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

ข้อกำหนดควรเป็น -

• Documented
• Actionable
• Measurable
• Testable
• Traceable

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

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

Eliciting Approach

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

• โครงการนี้จะช่วยให้บรรลุวัตถุประสงค์ทางธุรกิจอะไรของ บริษัท ?

• ทำไมเราถึงทำโครงการนี้ตอนนี้?

• จะเกิดอะไรขึ้นถ้าเราทำในภายหลัง?

• ถ้าเราไม่ทำเลยจะเป็นอย่างไร?

• ใครจะได้รับประโยชน์จากโครงการนี้?

• คนที่จะได้รับประโยชน์จากมันถือว่าเป็นการปรับปรุงที่สำคัญที่สุดที่สามารถทำได้ในเวลานี้หรือไม่?

• เราควรทำโครงการอื่นแทนหรือไม่?

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

ข้อกำหนดประเภทต่างๆ

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

ข้อกำหนดทางธุรกิจ

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

ความต้องการของผู้ใช้

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

เอกสารข้อกำหนดของผู้ใช้ (URD) ​​หรือข้อกำหนดข้อกำหนดของผู้ใช้เป็นเอกสารที่มักใช้ในวิศวกรรมซอฟต์แวร์ที่ระบุสิ่งที่ผู้ใช้คาดหวังให้ซอฟต์แวร์สามารถทำได้

ความต้องการของระบบ

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

ความต้องการการทำงาน

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

ข้อกำหนดที่ไม่ใช่หน้าที่

ข้อกำหนดที่ไม่ใช้งานได้คือข้อกำหนดที่ระบุเกณฑ์ที่สามารถใช้ในการตัดสินการทำงานของระบบมากกว่าพฤติกรรมเฉพาะ สถาปัตยกรรมระบบพูดถึงแผนการดำเนินการตามข้อกำหนดที่ไม่สามารถใช้งานได้

ข้อกำหนดที่ไม่ใช้งานได้พูดถึงลักษณะของระบบว่าควรมีลักษณะอย่างไรหรืออาจกล่าวถึงเช่น“ ระบบจะต้องเป็น” ข้อกำหนดที่ไม่ใช้งานได้ถูกเรียกว่าเป็นคุณสมบัติของระบบ

ข้อกำหนดการเปลี่ยนแปลง

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

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

การตรวจสอบย้อนกลับและการจัดการการเปลี่ยนแปลง

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

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

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

รวมคอลัมน์สำหรับแต่ละรายการต่อไปนี้ใน RTM -

• คำอธิบายความต้องการ
• การอ้างอิงความต้องการใน FRD
• วิธีการตรวจสอบ
• การอ้างอิงความต้องการในแผนการทดสอบ

Example- การเชื่อมต่อจุดเพื่อระบุความสัมพันธ์ระหว่างรายการภายในโครงการของคุณ มันเป็นตัวเชื่อมต่อของการไหลล่องทั่วไป

ความต้องการความคิดออกแบบทดสอบวัตถุประสงค์ทางธุรกิจ

คุณควรจะสามารถติดตามความต้องการแต่ละข้อของคุณกลับไปสู่วัตถุประสงค์ทางธุรกิจเดิมได้

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

การประกันคุณภาพ

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

ข้อกำหนดเฉพาะที่รัดกุมสามารถช่วยให้คุณตรวจพบและแก้ไขปัญหาได้ตั้งแต่เนิ่นๆแทนที่จะแก้ไขในภายหลังเมื่อมีค่าใช้จ่ายสูงกว่ามากในการแก้ไข นอกจากนี้ยังมีราคาสูงถึง100 times เพื่อแก้ไขข้อบกพร่องในกระบวนการพัฒนาในภายหลังหลังจากที่ได้รับการเข้ารหัสแล้วมากกว่าที่จะแก้ไขในช่วงต้นในขณะที่มีข้อกำหนด

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

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

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

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

Note- การวิจัยพบว่าทีมโครงการสามารถกำจัดข้อบกพร่องของโครงการได้ 50-80% โดยการจัดการข้อกำหนดอย่างมีประสิทธิภาพ จากข้อมูลของสถาบันวิศวกรรมซอฟต์แวร์ Carnegie Mellon“ 60-80 เปอร์เซ็นต์ของต้นทุนการพัฒนาซอฟต์แวร์อยู่ระหว่างการปรับปรุงใหม่”

การได้รับความต้องการ Signoff

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

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

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