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