การวิเคราะห์ความต้องการซอฟต์แวร์พร้อมตัวอย่าง
ชาร์ลส มัวร์
ตัวอย่างเช่น ในบริบทของแอปพลิเคชันธนาคาร ข้อกำหนดด้านการทำงานคือเมื่อลูกค้าเลือก "ดูยอดคงเหลือ" พวกเขาจะต้องสามารถดูยอดคงเหลือในบัญชีล่าสุดได้
ข้อกำหนดของซอฟต์แวร์อาจเป็นข้อกำหนดที่ไม่สามารถใช้งานได้ แต่อาจเป็นข้อกำหนดด้านประสิทธิภาพก็ได้ ตัวอย่างเช่น ข้อกำหนดที่ไม่สามารถใช้งานได้คือผู้ใช้ควรมองเห็นทุกหน้าของระบบได้ภายใน 5 วินาที
โดยพื้นฐานแล้ว ความต้องการซอฟต์แวร์คือก
- ฟังก์ชั่นหรือ
- ไม่ทำงาน
จำเป็นต้อง ที่จะต้องนำไปปฏิบัติในระบบ ข้อกำหนดของซอฟต์แวร์มักจะแสดงเป็นข้อความ
ประเภทของข้อกำหนด
- ข้อกำหนดทางธุรกิจ:เป็นข้อกำหนดระดับสูงที่นำมาจากกรณีทางธุรกิจของโครงการ ตัวอย่างเช่น ระบบบริการธนาคารบนมือถือให้บริการธนาคารแก่เอเชียตะวันออกเฉียงใต้ ข้อกำหนดทางธุรกิจที่ตัดสินใจสำหรับอินเดียคือสรุปบัญชีและการโอนเงิน ในขณะที่สำหรับจีนคือสรุปบัญชีและการชำระบิลจะตัดสินใจเป็นข้อกำหนดทางธุรกิจ
| ประเทศ | บริษัทที่ให้บริการฟังก์ชันหรือบริการด้านการธนาคาร |
|---|---|
| อินเดีย | สรุปบัญชีและการโอนเงิน |
| สาธารณรัฐประชาชนจีน | สรุปบัญชีและ Bill การชำระเงิน |
- Archiข้อกำหนดด้านเทคโนโลยีและการออกแบบ:ข้อกำหนดเหล่านี้มีรายละเอียดมากกว่าข้อกำหนดทางธุรกิจ ซึ่งจะกำหนดการออกแบบโดยรวมที่จำเป็นในการนำข้อกำหนดทางธุรกิจไปปฏิบัติ สำหรับองค์กรการศึกษาของเรา กรณีการใช้งานด้านสถาปัตยกรรมและการออกแบบจะเป็นการเข้าสู่ระบบ รายละเอียดหลักสูตร เป็นต้น ข้อกำหนดจะเป็นดังแสดงด้านล่าง
| กรณีการใช้งานของธนาคาร | ความต้องการ |
|---|---|
| Bill การชำระเงิน | กรณีการใช้งานนี้จะอธิบายวิธีที่ลูกค้าสามารถเข้าสู่ระบบ net banking และใช้งานได้อย่างไร Bill สิ่งอำนวยความสะดวกการชำระเงิน
ลูกค้าสามารถดูแดชบอร์ดของใบแจ้งหนี้ค้างชำระของผู้เรียกเก็บเงินที่ลงทะเบียนไว้ได้ สามารถเพิ่ม แก้ไข และลบรายละเอียดผู้เรียกเก็บเงินได้ ลูกค้าสามารถกำหนดค่าการแจ้งเตือนทาง SMS และอีเมลสำหรับการดำเนินการเรียกเก็บเงินต่างๆ ได้ สามารถดูประวัติของใบแจ้งหนี้ที่ชำระไปแล้ว ผู้ดำเนินการที่เริ่มต้นกรณีการใช้งานนี้คือลูกค้าธนาคารหรือเจ้าหน้าที่ฝ่ายสนับสนุน |
- ข้อกำหนดของระบบและบูรณาการ:ในระดับต่ำสุด เรามีข้อกำหนดของระบบและการบูรณาการ ซึ่งเป็นคำอธิบายโดยละเอียดของข้อกำหนดแต่ละข้อ อาจอยู่ในรูปแบบเรื่องราวของผู้ใช้ซึ่งอธิบายภาษาธุรกิจในชีวิตประจำวัน ข้อกำหนดมีรายละเอียดมากมายเพื่อให้นักพัฒนาสามารถเริ่มเขียนโค้ดได้ ต่อไปนี้คือตัวอย่าง Bill โมดูลการชำระเงินที่จะกล่าวถึงข้อกำหนดในการเพิ่ม Biller
| Bill การชำระเงิน | ความต้องการ |
|---|---|
| เพิ่ม BillERS |
|
บางครั้งสำหรับบางโครงการคุณอาจไม่ได้รับข้อกำหนดหรือเอกสารใดๆ ในการทำงานด้วย แต่ยังคงมีข้อกำหนดอื่นๆ ที่คุณสามารถพิจารณาสำหรับข้อกำหนดหรือข้อมูล เพื่อให้คุณสามารถใช้ซอฟต์แวร์หรือทดสอบการออกแบบตามข้อกำหนดเหล่านี้ได้ ดังนั้นแหล่งข้อมูลอื่นๆ สำหรับความต้องการที่คุณวางใจได้ก็คือ
แหล่งที่มาของข้อกำหนดอื่น ๆ
- การถ่ายทอดความรู้จากเพื่อนร่วมงานหรือพนักงานที่ทำงานในโครงการนั้นอยู่แล้ว
- พูดคุยเกี่ยวกับโครงการกับนักวิเคราะห์ธุรกิจ ผู้จัดการผลิตภัณฑ์ หัวหน้าโครงการ และนักพัฒนา
- วิเคราะห์เวอร์ชันของระบบก่อนหน้าที่ถูกนำไปใช้ในระบบแล้ว
- วิเคราะห์เอกสารข้อกำหนดเก่าของโครงการ
- ดูรายงานข้อบกพร่องที่ผ่านมา รายงานข้อบกพร่องบางรายการจะกลายเป็นคำขอการปรับปรุงซึ่งอาจนำไปใช้กับเวอร์ชันปัจจุบันได้
- ดูคู่มือการติดตั้งหากมีเพื่อดูว่าจำเป็นต้องติดตั้งอะไรบ้าง
- วิเคราะห์ความรู้ด้านโดเมนหรืออุตสาหกรรมที่ทีมพยายามนำไปใช้
ไม่ว่าคุณจะได้รับข้อกำหนดจากแหล่งใด อย่าลืมจัดทำเอกสารในรูปแบบใดรูปแบบหนึ่ง ให้รับการตรวจสอบจากสมาชิกในทีมที่มีประสบการณ์และมีความรู้คนอื่นๆ
วิธีการวิเคราะห์ข้อกำหนด
พิจารณาตัวอย่างระบบซอฟต์แวร์เพื่อการศึกษาที่นักเรียนสามารถลงทะเบียนเรียนหลักสูตรต่างๆ ได้
มาศึกษาวิธีวิเคราะห์ความต้องการกัน ข้อกำหนดจะต้องรักษาคุณภาพมาตรฐานของข้อกำหนด รวมถึงคุณภาพข้อกำหนดประเภทต่างๆ
- Atomic
- มีเอกลักษณ์เฉพาะตัว
- สมบูรณ์
- สม่ำเสมอและไม่คลุมเครือ
- ติดตามได้
- จัดลำดับความสำคัญ
- ทดสอบได้
ให้เข้าใจสิ่งนี้ด้วยตัวอย่าง มีสามคอลัมน์ในตารางที่แสดงที่นี่
- คอลัมน์แรกระบุ- “คุณภาพความต้องการ”
- คอลัมน์ที่สองระบุว่า- “ข้อกำหนดที่ไม่ดีและมีปัญหาบางอย่าง”
- คอลัมน์ที่สามเหมือนกับคอลัมน์ที่สอง แต่ – “เปลี่ยนเป็นข้อกำหนดที่ดี”
| คุณภาพความต้องการ | ตัวอย่างความต้องการที่ไม่ดี | ตัวอย่างความต้องการที่ดี |
|---|---|---|
| Atomic |
|
|
| มีเอกลักษณ์เฉพาะตัว | 1- นักศึกษาจะสามารถลงทะเบียนเรียนหลักสูตรระดับปริญญาตรีได้1- นักศึกษาจะสามารถลงทะเบียนเรียนหลักสูตรระดับสูงกว่าปริญญาตรีได้ |
|
| สมบูรณ์ | ผู้ใช้ที่เป็นศาสตราจารย์จะเข้าสู่ระบบโดยระบุชื่อผู้ใช้ รหัสผ่าน และข้อมูลอื่นๆ ที่เกี่ยวข้อง | ผู้ใช้ที่เป็นศาสตราจารย์จะเข้าสู่ระบบโดยระบุชื่อผู้ใช้ รหัสผ่าน และรหัสแผนก |
| สม่ำเสมอและไม่คลุมเครือ | นักศึกษาจะต้องเรียนหลักสูตรระดับปริญญาตรีหรือสูงกว่าปริญญาตรี แต่ไม่ใช่ทั้งสองหลักสูตร บางหลักสูตรจะเปิดรับทั้งระดับปริญญาตรีและสูงกว่าปริญญาตรี | นักศึกษาจะสำเร็จการศึกษาระดับปริญญาตรีหรือสูงกว่าปริญญาตรี แต่ไม่ใช่ทั้งสองอย่าง |
| ติดตามได้ | รักษาข้อมูลนักเรียนที่แมปกับ BRD req.ID หรือไม่ | รักษาข้อมูลนักเรียน - แมปกับ BRD req ID 4.1 |
| จัดลำดับความสำคัญ | นักเรียนที่ลงทะเบียน-ลำดับความสำคัญ 1รักษาข้อมูลผู้ใช้-ลำดับความสำคัญ 1ลงทะเบียนหลักสูตร-ลำดับความสำคัญ 1ดูการ์ดรายงาน-ลำดับความสำคัญ 1 | ลงทะเบียนนักเรียน-ลำดับความสำคัญ 1รักษาข้อมูลผู้ใช้-ลำดับความสำคัญ 2ลงทะเบียนหลักสูตร-ลำดับความสำคัญ 1ดูการ์ดรายงาน-ลำดับความสำคัญ3 |
| ทดสอบได้ | แต่ละหน้าของระบบจะโหลดในกรอบเวลาที่ยอมรับได้ | ลงทะเบียนนักศึกษาและลงทะเบียนหลักสูตรหน้าระบบจะโหลดภายใน 5 วินาที |
ตอนนี้เรามาทำความเข้าใจข้อกำหนดแต่ละข้อเหล่านี้โดยละเอียดโดยเริ่มจาก Atomเข้าใจแล้ว.
Atomic
ดังนั้นข้อกำหนดแต่ละข้อที่คุณมีควรเป็นแบบอะตอม ซึ่งหมายความว่าควรมีรายละเอียดในระดับต่ำมาก จึงไม่สามารถแยกออกเป็นส่วนประกอบได้ เราจะดูตัวอย่างข้อกำหนดสองตัวอย่างต่อไปนี้ Atomic และระดับข้อกำหนดที่ระบุเฉพาะ
ดังนั้นเรามาดูตัวอย่างการสร้างระบบสำหรับโดเมนการศึกษากันต่อ ในที่นี้ ข้อกำหนดที่ไม่ดีคือ “นักเรียนจะต้องสามารถลงทะเบียนเรียนหลักสูตรระดับปริญญาตรีและปริญญาโทได้” ซึ่งเป็นข้อกำหนดที่ไม่ดีเนื่องจากไม่ใช่ข้อกำหนดแยกย่อย เพราะเป็นข้อกำหนดเกี่ยวกับหลักสูตรระดับปริญญาตรีและปริญญาโทที่แตกต่างกันสองหน่วย ดังนั้น จึงเห็นได้ชัดว่าข้อกำหนดนี้ไม่ใช่ข้อกำหนดที่ดี แต่เป็นข้อกำหนดที่ไม่ดี ดังนั้น ข้อกำหนดที่ดีด้านการติดต่อสื่อสารจึงควรแยกข้อกำหนดนี้ออกเป็นสองข้อกำหนด ข้อกำหนดหนึ่งพูดถึงการลงทะเบียนเรียนหลักสูตรระดับปริญญาตรี ในขณะที่อีกข้อกำหนดหนึ่งพูดถึงการลงทะเบียนเรียนหลักสูตรปริญญาโท
มีเอกลักษณ์เฉพาะตัว
ในทำนองเดียวกัน คุณภาพข้อกำหนดถัดไปคือการตรวจสอบการระบุที่ไม่ซ้ำกัน ที่นี่เรามีข้อกำหนดสองประการแยกกัน แต่ทั้งสองมี ID#1 เดียวกัน ดังนั้น หากเราอ้างถึงข้อกำหนดของเราโดยอ้างอิงถึง ID# แต่ไม่ชัดเจนว่าข้อกำหนดใดที่เราอ้างถึงเอกสารหรือส่วนอื่น ๆ ของระบบ เนื่องจากทั้งสองมี ID#1 เดียวกัน ดังนั้น เมื่อแยกออกด้วยรหัสเฉพาะ ข้อกำหนดที่ดีจะถูกส่งกลับอีกครั้งในการลงทะเบียนหลักสูตรส่วนที่ 1 และมีข้อกำหนดสองประการ 1.1 รหัสคือการลงทะเบียนในหลักสูตรระดับปริญญาตรี ในขณะที่ 1.2 รหัสคือการลงทะเบียนในหลักสูตรระดับสูงกว่าปริญญาตรี
สมบูรณ์
นอกจากนี้ข้อกำหนดแต่ละข้อควรครบถ้วนด้วย ตัวอย่างเช่น ข้อกำหนดที่ไม่ดีที่นี่ระบุว่า "ผู้ใช้ศาสตราจารย์จะเข้าสู่ระบบโดยระบุชื่อผู้ใช้ รหัสผ่าน และข้อมูลอื่น ๆ ที่เกี่ยวข้อง" ข้อมูลอื่นๆ ที่เกี่ยวข้องในที่นี้ยังไม่ชัดเจน ดังนั้นข้อมูลอื่นๆ ที่เกี่ยวข้องควรได้รับการสะกดให้เป็นข้อกำหนดที่ดีเพื่อให้ข้อกำหนดครบถ้วน
สม่ำเสมอและไม่คลุมเครือ
ถัดไป ข้อกำหนดแต่ละข้อควรสอดคล้องกันและไม่คลุมเครือ ตัวอย่างเช่น เรามีข้อกำหนด “นักศึกษาจะต้องมีหลักสูตรระดับปริญญาตรีหรือสูงกว่าปริญญาตรี แต่ไม่ใช่ทั้งสองอย่าง” นี่เป็นข้อกำหนดหนึ่ง มีข้อกำหนดอื่นที่ระบุว่า “บางหลักสูตรจะ เปิดรับทั้งนักศึกษาระดับปริญญาตรีและสูงกว่าปริญญาตรี”
ปัญหาในข้อกำหนดนี้คือจากข้อกำหนดแรกดูเหมือนว่าหลักสูตรจะแบ่งออกเป็นสองประเภทภายใต้หลักสูตรระดับบัณฑิตศึกษาและหลักสูตรหลังระดับบัณฑิตศึกษา และนักศึกษาสามารถเลือกอย่างใดอย่างหนึ่งจากสองข้อ แต่ไม่ใช่ทั้งสองอย่าง แต่เมื่อคุณอ่านข้อกำหนดอื่น ๆ มันขัดแย้งกับข้อกำหนดแรก และบอกว่าบางหลักสูตรจะเปิดสำหรับทั้งระดับสูงกว่าปริญญาตรีและระดับปริญญาตรี
ดังนั้นจึงเห็นได้ชัดว่าการเปลี่ยนข้อกำหนดที่ไม่ดีนี้เป็นข้อกำหนดที่ดี ซึ่งก็คือ “นักศึกษาจะต้องเรียนหลักสูตรระดับปริญญาตรีหรือสูงกว่าปริญญาตรี แต่ไม่ใช่ทั้งสองหลักสูตร” ซึ่งหมายความว่าทุกหลักสูตรจะถูกทำเครื่องหมายว่าเป็นหลักสูตรระดับปริญญาตรีหรือสูงกว่าปริญญาตรี
ติดตามได้
ข้อกำหนดแต่ละข้อควรสามารถตรวจสอบได้ เนื่องจากข้อกำหนดต่างๆ ก็มีระดับที่แตกต่างกันอยู่แล้ว เราได้เห็นแล้วว่าในขั้นสูงสุด เรามีข้อกำหนดทางธุรกิจ จากนั้นเราก็มีข้อกำหนดด้านสถาปัตยกรรมและการออกแบบ ตามด้วยข้อกำหนดด้านการรวมระบบ
เมื่อเราแปลงความต้องการทางธุรกิจเป็นความต้องการด้านสถาปัตยกรรมและการออกแบบ หรือแปลงความต้องการด้านสถาปัตยกรรมและการออกแบบเป็นความต้องการด้านการบูรณาการระบบ จะต้องมีการตรวจสอบย้อนกลับ ซึ่งหมายความว่าเราควรสามารถนำความต้องการทางธุรกิจแต่ละข้อมาจับคู่กับความต้องการด้านสถาปัตยกรรมและการออกแบบซอฟต์แวร์หนึ่งรายการหรือมากกว่านั้นได้ ดังนั้น นี่คือตัวอย่างของความต้องการที่ไม่ดีซึ่งระบุว่า "รักษาข้อมูลนักเรียน - จับคู่กับรหัสคำขอ BRD" รหัสคำขอไม่ได้ระบุไว้ที่นี่
ดังนั้นการแปลงเป็นข้อกำหนดที่ดีจึงพูดสิ่งเดียวกัน แต่ถูกแมปด้วยรหัสข้อกำหนด 4.1 ดังนั้นการทำแผนที่จึงควรมีไว้สำหรับทุกความต้องการ เช่นเดียวกับที่เรามีข้อกำหนดการแมประดับสูงและระดับต่ำ การแมปยังอยู่ที่นั่นระหว่างระบบและข้อกำหนดการรวมเข้ากับโค้ดที่ใช้ข้อกำหนดนั้น และยังมีการแมประหว่างระบบและข้อกำหนดการรวมกับกรณีทดสอบที่ทดสอบข้อกำหนดเฉพาะนั้น .
ดังนั้นการตรวจสอบย้อนกลับนี้จึงครอบคลุมทั้งโครงการ
จัดลำดับความสำคัญ
| จัดลำดับความสำคัญ | นักเรียนที่ลงทะเบียน - ลำดับความสำคัญ 1 รักษาข้อมูลผู้ใช้-ลำดับความสำคัญ 1 ลงทะเบียนเรียนหลักสูตร-ลำดับความสำคัญ 1 ดูรายงานการ์ด-ลำดับความสำคัญ 1 |
ลงทะเบียน Student Priority 1 รักษาข้อมูลผู้ใช้-ลำดับความสำคัญ 2 ลงทะเบียนเรียนหลักสูตร-ลำดับความสำคัญ 1 ดูรายงานการ์ด-ลำดับความสำคัญ3 |
จากนั้นข้อกำหนดแต่ละข้อจะต้องได้รับการจัดลำดับความสำคัญ เพื่อให้ทีมมีแนวทางว่าข้อกำหนดใดที่สามารถนำไปปฏิบัติได้ก่อนและข้อกำหนดใดที่จะดำเนินการในภายหลังได้ ที่นี่ คุณจะเห็นลำดับความสำคัญที่ไม่ดี ได้แก่ การลงทะเบียนนักศึกษา การบำรุงรักษาข้อมูลผู้ใช้ และข้อกำหนดแต่ละข้อจะได้รับความสำคัญเป็น 1 ไม่สามารถมีลำดับความสำคัญเดียวกันได้ ดังนั้น จึงสามารถจัดลำดับความสำคัญของข้อกำหนดได้ ตัวอย่างของข้อกำหนดที่ดีในที่นี้คือ การลงทะเบียนนักศึกษาและลงทะเบียนเรียนจะได้รับความสำคัญสูงสุดเป็น 1 ในขณะที่การบำรุงรักษาข้อมูลผู้ใช้จะอยู่ในลำดับความสำคัญ 2 จากนั้นเราจะดูรายงานผลการเรียนในลำดับความสำคัญ 3
ทดสอบได้
| ทดสอบได้ | แต่ละหน้าของระบบจะโหลดในกรอบเวลาที่ยอมรับได้ | ลงทะเบียนนักศึกษาและลงทะเบียนหลักสูตรหน้าระบบจะโหลดภายใน 5 วินาที |
ข้อกำหนดแต่ละข้อควรทดสอบได้ ข้อกำหนดที่ไม่ดีคือ “แต่ละหน้าของระบบจะโหลดในกรอบเวลาที่ยอมรับได้” ขณะนี้มีปัญหาสองประการเกี่ยวกับข้อกำหนดนี้ ประการแรกคือแต่ละหน้าหมายความว่าสามารถมีได้หลายหน้า ซึ่งจะทำให้ความพยายามในการทดสอบลดลง ปัญหาอีกอย่างคือมันบอกว่าหน้าเว็บจะโหลดในกรอบเวลาที่ยอมรับได้ แล้วตอนนี้กรอบเวลาที่ยอมรับได้คือเท่าไร? เป็นที่ยอมรับของใคร ดังนั้นเราจึงต้องแปลงอาร์กิวเมนต์ที่ไม่สามารถทดสอบได้ให้เป็นอาร์กิวเมนต์ที่ทดสอบได้ ซึ่งบอกโดยเฉพาะเกี่ยวกับหน้าที่เรากำลังพูดถึง “หน้าลงทะเบียนนักเรียนและลงทะเบียนหลักสูตร” และกรอบเวลาที่ยอมรับได้ก็กำหนดไว้เช่นกัน ซึ่งก็คือ 5 วินาที
สรุป
ดังนั้นนี่คือวิธีที่เราต้องพิจารณาข้อกำหนดแต่ละข้อในระดับที่เหมาะสม ตัวอย่างเช่น หากเราจะสร้างซอฟต์แวร์โดยคำนึงถึงข้อกำหนดของระบบและการรวมระบบ เราต้องดูข้อกำหนดของระบบและการรวมระบบที่ระบุไว้ในข้อกำหนดของซอฟต์แวร์หรือเรื่องราวของผู้ใช้ และนำไปใช้กับคุณภาพข้อกำหนดแต่ละข้อ จากนั้นตรวจสอบว่าข้อกำหนดแต่ละข้อเป็นแบบแยกส่วน มีการระบุอย่างเฉพาะเจาะจง และสมบูรณ์หรือไม่ เป็นต้น