บทที่ 6 วิศวกรรมความต้องการ
6.1 ความหมายของวิศวกรรมความต้องการ
วิศวกรรมความต้องการ (Requirement Engineering) หมายถึง กระบวนการที่จะทำให้วิศวกรซอฟต์แวร์เข้าใจและเข้าถึงความต้องการของลูกค้าอย่างแท้จริง ด้วยการสกัดความต้องการ ตรวจสอบ และนิยามความต้องการ เพื่อนำไปสร้างเป็นข้อกำหนดความต้องการด้านระบบหรือซอฟต์แวร์ ซึ่งเป็นจุดเริ่มต้นในการพัฒนาระบบในขั้นตอนต่อไป
เป้าหมายของการวิศวกรรมความต้องการ ก็คือ การสร้างและบำรุงรักษาเอกสารข้อกำหนดความต้องการ ทั้งทางด้านระบบ และด้านซอฟต์แวร์ให้เป็นเอกสารที่มีคุณภาพที่สุด
6.2 กระบวนการวิศวกรรมความต้องการ
กิจกรรมของวิศวกรรมความต้องการ จะรวมอยู่ในระยะการวิเคราะห์ความต้องการของกระบวนการผลิตซอฟต์แวร์และเป็นกิจกรรมที่ต้องดำเนินการอย่างเป็นขั้นตอน มีกระบวนการและทีมงานเฉพาะ ประกอบไปด้วยขั้นตอนดังนี้
ขั้นตอนที่ 1 สกัดความต้องการ (Requirement Elicitation)
การสกัดความต้องการก็คือ การรวบรวมหรือค้นหาความต้องการ เป็นขั้นตอนของการทำความเข้าใจกับปัญหาที่เกิดขึ้นที่ต้องการแก้ไขด้วยซอฟต์แวร์ โดยเก็บรวบรวมด้วยเทคนิคต่างๆ
ขั้นตอนที่ 2 วิเคราะห์ความต้องการ (Requirement Analysis)
เป็นขั้นตอนในการประเมินความต้องการที่รวบรวมมาได้ เพื่อจัดกลุ่มความต้องการ จัดลำดับความสำคัญของความต้องการ แก้ไขความขัดแย้งระหว่างความต้องการ เพื่อให้เกิดความสอดคล้องกัน จากนั้นสร้างแบบจำลองความต้องการในระดับแนวคิด นำเสนอให้ผู้ที่เกี่ยวข้องเพื่อพิจารณายอมรับ หรือแก้ไข
ขั้นตอนที่ 3 กำหนดความต้องการ (Requirement Specification)
เมื่อได้แบบจำลองที่ได้รับการยอมรับแล้ว จะจัดทำเป็นเอกสารข้อกำหนดความต้องการ โดยเริ่มจากการนิยามความต้องการของระบบ แล้วจัดทำเป็นข้อกำหนดความต้องการด้านระบบ เพื่อนำมาแจกจ่ายเป็นข้อกำหนด ความต้องการด้านซอฟต์แวร์ เอกสารทั้งหมดต้องสามารถตรวจสอบคุณภาพได้
ขั้นตอนที่ 4 ตรวจสอบความต้องการ (Requirement Validation)
เป็นการทบทวนและตรวจสอบข้อกำหนดความต้องการในเอกสารทั้งหมด เพื่อให้เกิดความเที่ยงตรง สอดคล้อง ครบถ้วนสมบูรณ์ มีความเป็นไปได้ และสามารถพิสูจน์ได้ตามเป้าหมายของกระบวนการ วิศวกรรมซอฟต์แวร์ จากนั้นจะนำไปทดสอบเพื่อให้เกิดการยอมรับจากบุคคลทุกฝ่ายที่เกี่ยวข้อง
แสดงกระบวนการวิศวกรรมความต้องการ (แบบ Spiral Somerville)
6.3 การสกัดความต้องการ
การสกัดความต้องการ (Requirement Elicitation) เป็นขั้นตอนในการเก็บรวบรวมข้อเท็จจริง เพื่อทำความเข้าใจกับปัญหาที่เกิดขึ้น และบทบาทของซอฟต์แวร์ในการทำหน้าที่แก้ปัญหาดังกล่าวนั้น ในขั้นตอนนี้วิศวกรซอฟต์แวร์จะสามารถเข้าถึงเป้าหมายและวัตถุประสงค์ของลูกค้าเป็นอย่างดี
เทคนิคการเก็บรวบรวมความต้องการ
1. การสัมภาษณ์ (Interview) เป็นวิธีที่นิยมใช้มากที่สุดวิธีหนึ่ง
2. การแสดงลำดับเหตุการณ์ (Scenario) เป็นการเตรียมคำถามตามลำดับงานของผู้ใช้ ในแต่ละงานจะมีการตั้งคำถาม
3. ต้นแบบ (Prototype) เป็นเทคนิคที่ทำให้ผู้ใช้เข้าใจสถานการณ์และคำถามได้ง่ายเช่นกัน
4. การประชุม (Facilitated Meeting) เป็นการเรียกกลุ่มบุคคลที่เกี่ยวข้องเข้าร่วมประชุมเพื่อขอความคิด และความต้องการ เพื่อให้เกิดความเข้าใจในความต้องการอย่างถ่องแท้มากกว่าการทำงานเพียงลำพัง
5. การสังเกต (Observation) ใช้ตรวจสอบสภาพแวดล้อมการทำงานของผู้ใช้ซอฟต์แวร์ในระบบเดิม เพื่อพบกับปัญหาและวิธีการแก้ไขของผู้ใช้ที่เกี่ยวข้องอย่างแท้จริง
6.4 การวิเคราะห์ความต้องการ
การวิเคราะห์ความต้องการ (Requirement Analysis) เป็นการนำข้อมูลความต้องการที่รวบรวมได้มาวิเคราะห์ ประเมินเพื่อจำแนกกลุ่มความต้องการ จากนั้นนำมาจัดลำดับความสำคัญ ดูความสอดคล้อง ขจัดความขัดแย้ง นำไปสร้างเป็นแบบจำลอง และออกแบบสถาปัตยกรรมซอฟต์แวร์เบื้องต้น เพื่อนำไปทดสอบการยอมรับกับลูกค้า เมื่อลูกค้ายอมรับจะได้เอกสารความต้องการทั้งหมด (ฉบับร่าง)
การวิเคราะห์ความต้องการมีกิจกรรมย่อยดังนี้
แสดงกิจกรรมย่อยของการวิเคราะห์ความต้องการ
6.4.1 การแบ่งกลุ่มความต้องการ (Requirement Classification)
1. ความต้องการที่เป็นหน้าที่หลัก (Functional Requirement) และไม่ใช่หน้าที่หลัก Non-Functional Requirement)
2. แบ่งความต้องการที่เกี่ยวข้องกับผลิตภัณฑ์ และกระบวนการ
3. แบ่งกลุ่มตามลำดับความสำคัญของความต้องการ (จำเป็น (Mandatory) ปรารถนาสูง (Highly Desirable) ปานกลาง (Desirable) และละเว้นได้ (Optional))
4. แบ่งกลุ่มตามขอบเขตความต้องการ โดยให้ความสำคัญต่อความต้องการที่มีขอบเขตกว้าง ซึ่งส่งผลกระทบต่อการพัฒนาซอฟต์แวร์
5. แบ่งกลุ่มตามความต้องการเปลี่ยนแปลงของความต้องการ ได้แก่ ความต้องการที่เปลี่ยนแปลงได้ (Volatility) และความต้องการที่ไม่สามารถเปลี่ยนแปลงได้ (Stability)
6.4.2 การสร้างแบบจำลองของความต้องการ (Requirement Modeling)
แบบจะลองความต้องการ (Requirement Model) หรือ แบบจำลองแนวคิด (Conceptual Model) ใช้เพื่อจำลองความต้องการที่รวบรวมมาได้ ทำให้ผู้ใช้และบุคคลอื่นๆ ที่เกี่ยวข้องเห็นภาพรวมของความต้องการ เข้าใจความต้องการได้ตรงกับทีมงาน
ชนิดและแบบจำลองจะแตกต่างกันออกไปตามแนวทางของการวิเคราะห์ เช่น แนวทางเชิงโครงสร้าง (SSAD ) จะใช้ DFD และ ERD ซึ่งเป็นแบบจำลองกระบวนการ ส่วนแนวทางเชิงวัตถุ (OOSAD) จะใช้แบบจำลอง Use Case เพื่อให้เห็นหน้าที่การทำงานของซอฟต์แวร์
เพื่อประโยชน์ในการออกแบบการทำงานของซอฟต์แวร์ สิ่งสำคัญต่อการสร้างแบบจำลองคือ ระเบียบวิธีปฏิบัติที่ใช้สร้างแบบจำลอง ซึ่งปัจจุบันนิยมใช้ระเบียบวิธีตามภาษาการสร้างต้นแบบจำลองที่เรียกว่า UML (Unified Modeling Language) และ Formal Modeling ที่ใช้สมาการทางคณิตศาสตร์เข้ามาอธิบาย
IEEE ได้กำหนดสัญลักษณ์ที่เป็นประโยชน์ในการสร้างแบบจำลองหลายชนิด เช่น IEEE 1320.1, IDEF0 (ใช้สร้างแบบจำลองเชิงฟังก์ชัน) และ IEEE 1320.2, IDEF1X97 (เพื่อสร้างแบบจำลองข้อมูลเป็นต้น)
6.4.3 การออกแบบสถาปัตยกรรมและการจัดสรรความต้องการ (Architectural Design and Requirement Allocation)
ด้วยความซับซ้อนของกระบวนการวิศวกรรมซอฟต์แวร์ทำให้บางครั้ง วิศวกรซอฟต์แวร์ต้องดำเนินการออกแบบ สถาปัตยกรรมของซอฟต์แวร์ (Architectural Design) ในขั้นตอนนี้ด้วย เนื่องจากต้องการแสดงให้ผู้ใช้ หรือลูกค้าเห็นได้ชัดเจนว่าคอมโพเน้นท์หรือส่วนประกอบใดของซอฟต์แวร์ ที่เข้ามาสนับสนุนและรองรับความต้องการส่วนใหญ่ของผู้ใช้ นับว่าเป็น ?การจัดสรรความต้องการ (Requirement Allocation?) เข้ากับองค์ประกอบแต่ละส่วนของซอฟต์แวร์
6.4.4 การเจรจาต่อรองความต้องการ (Requirement Negotiation)
การเจรจาต่อรองความต้องการเรียกอีกอย่างหนึ่งว่า ?การแก้ไขความขัดแย้งระหว่างความต้องการ (Confict Resolution)? เกิดขึ้นเมื่อการนำเสนอแบบจำลองความต้องการต่อลูกค้าเพื่อรับทราบละยอมรับ หากลูกค้าพบข้อผิดพลาดในข้อกำหนดความต้องการ หรือไม่พอใจในข้อกำหนดความต้องการ หรืออาจต้องการเปลี่ยนแปลง จะเกิดการเจรจาต่อรองความต้องการขึ้น
เมื่อผ่านขั้นตอนการวิเคราะห์ความต้องการแล้ว รายการความต้องการต่างๆ ที่ร่างไว้จะมีความถูกต้อง (Validity) สอดคล้อง (Consistence) และความเป็นไปได้ (Feasibility) มากขึ้น พร้อมที่จะนำไปจัดทำข้อกำหนดความต้องการในเอกสารต่อไป
6.5 การกำหนดความต้องการ
ข้อกำหนดความต้องการด้านซอฟต์แวร์ส่วนใหญ่จะบ่งบอกถึงคุณลักษณะของซอฟต์แวร์ ซึ่งหมายถึง การสร้างเอกสารความต้องการแสดงรายละเอียดทางด้านซอฟต์แวร์ ที่สามารถตรวจสอบ ประเมินค่า และยอมรับได้ โดยเฉพาะอย่างยิ่งในระบบที่มีความซับซ้อนสูง โดยจะต้องประกอบด้วยรายละเอียดอื่นที่ไม่ใช่คอมโพเน้นท์ซอฟต์แวร์เพียงอย่างเดียว ได้แก่ การนิยามระบบ (System Definition) ความต้องการด้านระบบ (System Requirement) และความต้องการด้านซอฟต์แวร์ (Software Requirement)
เอกสารนิยามระบบ (System Definition Document)
เป็นบันทึกความต้องการด้านระบบของผู้ใช้ เป็นการกำหนดมุมมองในระดับสูงจากมุมมองของผู้ใช้
เอกสารข้อกำหนดความต้องการด้านระบบ (System Requirement Specification)
เอกสารความต้องการด้านระบบจะถูกกำหนดขึ้นมาก่อนเพื่อนำไปกำหนดความต้องการด้านซอฟต์แวร์ภายหลัง
เอกสารข้อกำหนดความต้องการด้านซอฟต์แวร์ (Software Requirement Specification SRS)
เอกสารข้อกำหนดทางด้านซอฟต์แวร์หรือ SRS เปรียบเสมือนข้อตกลงพื้นฐานระหว่างลูกค้ากับผู้ผลิต เพื่อให้เข้าใจตรงกันว่าสิ่งใดที่ซอฟต์แวร์ต้องทำ และสิ่งใดที่เป็นเงื่อนไขหรือข้อห้าม
6.6 การตรวจสอบความต้องการ
เมื่อจัดทำเอกสารข้อกำหนดความต้องการ ขั้นตอนสุดท้ายก่อนนำไปสู่การออกแบบคือการตรวจสอบความต้องการอีกครั้ง เป็นการวิเคราะห์และตรวจสอบข้อผิดพลาดหรือปัญหาที่อาจเกิดขึ้นจากความทับซ้อนของความต้องการ ซึ่งควรจรวจสอบตามลักษณะดังนี้
1. ความเที่ยงตรง (Validity) จะต้องตรวจสอบความต้องการของผู้ใช้ทุกๆ กลุ่มอย่างเท่าเทียมกัน
2. ความสอดคล้อง (Consistency) ความต้องการในเอกสารจะต้องไม่ทับซ้อนกัน ไม่ขัดแย้งกัน
3. ความครบถ้วนสมบูรณ์ (Completeness) ต้องระบุรายละเอียดฟังก์ชันและบริการครบถ้วน ครอบคลุมความต้องการของผู้ใช่
4. ความเป็นไปได้ (Feasibility) ตรวจสอบความต้องการด้วยองค์ความรู้เกี่ยวกับเทคโนโลยีที่องค์กรมีอยู่เพื่อให้มั่นใจว่าสามารถนำความต้องการที่ระบุในเอกสารไปพัฒนาระบบได้จริง
5. สามารถพิสูจน์ได้ (Verifiability) ความต้องการนั้นจำต้องสามารถพิสูจน์เพื่อหาความจริงได้ คือต้องทดสอบและทดลองให้ลูกค้าเห็นถึงการทำงานจรองของระบบที่จะตอบสนองต่อความต้องการที่ระบุในเอกสารได้
เทคนิคในการตรวจสอบความต้องการ
1. การทบทวนความต้องการ (Requirement Review) เป็นการตรวจสอบเอกสารความต้องการอย่างละเอียด เพื่อตรวจหาความต้องการ หรือข้อสมมติฐานที่ผิดพลาด หรือถูกละเลย ไม่ชัดเจน ไม่ตรงตามมาตรฐานที่กำหนด โดยตรวจสอบตามลักษณะต่อไปนี้
- สามารถพิสูจน์ได้ (Verification)
- สามารถเข้าใจได้ (Comprehensibility)
- สามารถย้อนกลับไปตรวจสิบได้ (Traceability)
- สามารถดัดแปลงได้ (Adaptability)
2. การจัดทำต้นแบบ (Prototyping) เป็นการสร้างต้นแบบของระบบ ขั้นมาเพื่อสาธิตให้ลูกค้าหรือผู้ใช้ระบบดู หรือทดลองใช้ด้วยตนเอง ก็จะทราบว่าตรงตามความต้องการหรือไม่
3. การสร้างแบบทดสอบ (Test-Case Generation) ความต้องการที่ดีจะต้องสามารถทดสอบได้ ถ้าหาดจัดทำแบบทดสอบยางก็แสดงว่าระบบที่จะนำไปพัฒนานั้นยากด้วย
6.7 การจัดการความต้องการ
การจัดการความต้องการ ( Requirement Management) คือ กระบวนการทำความเข้าใจและควบคุมการเปลี่ยนแปลงความต้องการที่อาจจะเกิดขึ้นได้ตลอดเวลา ทั้งในช่วงการพัฒนาและระหว่างการใช้งาน
การเปลี่ยนแปลงความต้องการอาจเกิดได้จากหลายสาเหตุ ดังนี้
1. สาเหตุจากมีผู้ใช้หลายกลุ่ม
2. สาเหตุจากเงินทุน ข้อจำกัดด้านค่าใช้จ่าย
3. สาเหตุจากสภาพแวดล้อมและเทคโนโลยีเปลี่ยนแปลง
6.7.1 ความต้องการที่เปลี่ยนแปลงและไม่เปลี่ยนแปลง
1. ความต้องการที่ไม่เปลี่ยนแปลง (Enduring Requirement) เป็นความต้องการแบบคงที่ไม่เปลี่ยนแปลงได้ง่าย เป็นความต้องการจากการทำงานหลักของธุรกิจในแต่ละวัน
2. ความต้องการที่เปลี่ยนแปลง (Volatile Requirement) เป็นความต้องการที่มีการเปลี่ยนแปลงอยู่เสมอ ในระหว่างการพัฒนาหรือติดตั้งระบบเพื่อใช้งานไปแล้ว
6.7.2 การวางแผนการจัดการความต้องการ
เนื่องจากการจัดการความต้องการเป็นกระบวนการที่ต้องใช้งบประมาณค่อนข้างสูง ดังนั้น จึงต้องมีการวางแผนก่อนเริ่มดำเนินงาน ตามกิจกรรมต่อไปนี้
1.จำแนกความต้องการ (Requirement Identification) ทีมงานต้องทำการระบุความเป็นเอกลักษณ์ให้กับทุกความต้องการเพื่อไม่ให้ความต้องการซ้ำซ้อนกัน และเพื่อการอ้างอิงถึง
2.กระบวนการจัดการความเปลี่ยนแปลง (Change Management Process) ทีมงานจะต้องกำหนดกิจกรรมในการประเมินผลกระทบและต้นทุนที่เกิดจากการเปลี่ยนแปลง
3.นโยบายการสืบหา (Traceability Policy) เป็นการกำหนดความสัมพันธ์ระหว่างความต้องการแต่ละรายการ และระหว่างความต้องการกับการออกแบบระบบ แล้วเก็บบันทึกไว้เพื่อประโยชน์ในการบำรุงรักษาต่อไป
4. CASE Tool ทีมงานต้องสรรหาเครื่องมือเข้ามาสนับสนุนกระบวนการจัดการความต้องการแต่ละรายการ เนื่องจากเป็นกระบวนการที่ต้องเกี่ยวข้องกับข้อมูลจำนวนมาก เครื่องมือเหล่านี้จะช่วยจัดการข้อมูลได้ง่ายขึ้น
การสืบหาส่วนที่ได้รับผลกระทบกระเทือนหรือแหล่งที่มาของความต้องการจึงมีความจำเป็น โดยสามารถสืบหาได้จากรายละเอียดในเอกสารข้อกำหนดความต้องการ สามารถแบ่งได้ 3 ชนิด
1. การสืบหาแหล่งที่มา (Source Traceability) เป็นการสืบหาแหล่งที่มาของการเปลี่ยนแปลง เพื่อสอบถามถึงเหตุผลและช่วงเวลาในการเสนอให้เปลี่ยน เพื่อนำเข้าสู่ที่ประชุม
2. การสืบหาความต้องการ (Requirement Traceability) เป็นการสืบหาจำนวนความต้องการที่ได้รับผลกระทบจากการเปลี่ยนแปลง เพื่อขยายผลไปยังการสืบหาความต้องการเมื่อเปลี่ยนแปลงไป
3. การสืบหาในส่วนการออกแบบ (Design Traceability) เป็นการสืบหาส่วนการออกแบบจากความต้องการที่อาจมีการเปลี่ยนแปลงไป เพื่อทำการแก้ไขให้ถูกต้อง
6.7.3 การจัดการกับการเปลี่ยนแปลงความต้องการ
เมื่อมีการยื่นข้อเสนอให้มีการเปลี่ยนแปลงความต้องการเกิดขึ้น ต้องวิเคราะห์ถึงความคุ้มค่าเมื่อต้องเปลี่ยนแปลงตามข้อเสนอหากมีความคุ้มค่าจะอนุมัติให้ดำเนินการเปลี่ยนแปลงได้ แต่หากพบว่าไม่ได้รับผลตอบแทนที่คุ้มค่าก็จะยกเลิกข้อเสนอนั้นไป
ไม่มีความคิดเห็น:
แสดงความคิดเห็น