- กระบวนการสร้างสิ่งที่ลูกค้าต้องการจากระบบ
- ข้อจำกัดในการดำเนินงานและการพัฒนา
- ความต้องการของระบบคืออะไร?
- คำอธิบายสิ่งที่ระบบให้บริการ
- ข้อจำกัด (ที่เกิดขึ้นในระหว่างกระบวนการทำ requirement)
- เป็นได้กว้างมาก
- ตั้งแต่คำจำกัดความนามธรรมระดับสูงของบริการ
- ข้อจำกัดของระบบ
- ข้อกำหนดทางคณิตศาสตร์แบบละเอียด
- ข้อกำหนดมีหน้าที่หลักสองอย่าง ()
- เป็นพื้นฐานสำหรับการเสนอราคา (สัญญาประมูลโครงการ) - ต้องเปิดกว้างสำหรับการตีความในภายหลัง
- เป็นพื้นฐานสำหรับการทำสัญญา (ตรวจสอบตอนส่งมอบงาน) - ต้องเขียนไว้อย่างละเอียด
- อาจต้องทำทั้งสองอย่างควบคู่กัน
- ถ้าบริษัทประสงค์จะทำสัญญาโครงการพัฒนาซอฟต์แวร์ขนาดใหญ่
- ต้องกำหนด requirement ของตนในรูปแบบนามธรรมอย่างพอเพียง
- ไม่ต้องกำหนดวิธีการที่ตายตัวไว้ล่วงหน้า
- ต้องมีการเขียน requirement ให้ผู้รับเหมาหลายรายสามารถร่วมประมูลได้
- มีรายละเอียดพอเพียงที่จะสามารถเสนอราคาเพื่อทำสัญญา
- ผู้รับเหมาสามารถเสนอวิธีที่แตกต่างกัน เพื่อตอบสนองต่อ requirement
- เมื่อชนะการประมูล ผู้รับเหมาต้องเขียนคำนิยามของระบบสำหรับลูกค้าในรายละเอียด เพื่อให้ลูกค้าเข้าใจและสามารถตรวจสอบว่าซอฟต์แวร์จะทำงานอย่างไร
- เอกสารทั้งสองนี้ เรียกว่าเอกสารข้อกำหนดสำหรับระบบ (requirements document for the system)
- ความต้องการของผู้ใช้
- การบรรยายโดยใช้ภาษาธรรมชาติ รวมทั้งแผนผังของบริการที่ระบบให้และข้อจำกัดในการดำเนินงาน
- เขียนขึ้นสำหรับลูกค้า
- ความต้องการของระบบ
- เอกสารที่มีโครงสร้างที่ชัดเจน แสดงคำอธิบายโดยละเอียด
- เกี่ยวกับฟังก์ชันที่ซอฟต์แวร์ให้บริการ
- เกี่ยวกับข้อจำกัดในการดำเนินงานของระบบและสิ่งที่จำเป็นต้องนำมาใช้
- เขียนขึ้นเพื่อเป็นส่วนหนึ่งของสัญญาระหว่างลูกค้ากับผู้รับเหมา
- User requirements
- Client managers
- System end-user
- Client Engineers
- Contractor manager
- System architects
- System requirements
- System end-users
- Client Engineers
- System architects
- Software developers
- บุคคลหรือองค์กรใด ๆ ที่ได้รับผลกระทบจากระบบด้วยวิธีใดก็ตามรวมทั้งผู้ที่มีส่วนได้เสียตามกฎหมาย
- ประเภทผู้มีส่วนได้ส่วนเสีย
- ผู้ใช้ (End users)
- ผู้จัดการระบบ (System managers)
- เจ้าของระบบ (System owners)
- ผู้มีส่วนได้เสียภายนอก (External stakeholders)