Requirement Engineering

1.การจัดการโครงการ

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

2.วิธีปฏิบัติในการจัดการข้อกำหนด

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

3.การตรวจสอบข้อกำหนด

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

4.การกำหนดรายละเอียดของข้อกำหนด

• นำต้นแบบ SRS มาใช้
  
• ระบุที่มาของข้อกำหนด
  
• ใส่ชื่อให้ข้อกำหนดแต่ละข้อ
  
• บันทึกกฎทางธุรกิจ
  
• สร้าง Matrix ที่ติดตามข้อกำหนดได้
  

  
   

5.การหาข้อกำหนด

• ระบุกระบวนการพัฒนาข้อกำหนด
  
• เขียนวิสัยทัศน์และขอบเขตของโครงการ
  
• ระบุระดับของผู้ใช้และลักษณะเฉพาะ
  
• เลือกแชมป์ผลิตภัณฑ์ ของผู้ใช้แต่ละระดับ
  
• สร้างกลุ่มของผู้ใช้ประเภทต่าง ๆ
  
• ให้ตัวแทนของผู้ใช้ระบุ USE Case
  
• คงระยะ JAD (Joint Application Development)
  
• วิเคราะห์ขั้นตอนการทำงานของผู้ใช้
  
• กำหนดคุณลักษณะทางกายภาพและข้อกำหนดที่ไม่มีหน้าที่เฉพาะต่าง ๆ
  
• ตรวจสอบรายงานปัญหาอันเกิดจากระบบต่าง ๆ
  
• การนำข้อกำหนดจากโครงการอื่นกลับมาใช้ใหม่
  

6.การจัดการข้อกำหนด

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

7.การพัฒนาข้อกำหนด

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

8.ลักษณะเฉพาะของข้อความของข้อกำหนด

• ความสมบูรณ์
  
• ความถูกต้อง
  
• ความเป็นไปได้
  
• ความจำเป็น
  
• ลำดับความสำคัญ
  
• ความชัดเจน
  
• สามารถตรวจสอบได้
  

9.ความเสี่ยงจากกระบวนการของข้อกำหนดที่ไม่ดีพอ

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

 

10.ระดับของข้อกำหนด

มี 3 ระดับคือ

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

2. ข้อกำหนดของผู้ใช้ หมายถึง งานที่ผู้ใช้สามารถทำให้สำเร็จได้ด้วยซอฟต์แวร์ ซึ่งกล่าวถึงในกรณีที่ต้องนำมาใช้งาน หรือการอธิบายถึงสถานการณ์สมมติ (scenario)

3. ข้อกำหนดด้านฟังก์ชัน หมายถึง การทำงานของซอฟต์แวร์ที่ผู้พัฒนาสร้างไว้ในซอฟต์แวร์ เพื่อให้ผู้ใช้ทำงานได้สำเร็จ