Transcript PPT(Thai) - dusithost.dusit.ac.th

Chapter 9 : Requirments
Juthawut Chantharamalee
Curriculum of Computer Science
Faculty of Science and Technology, Suan Dusit University
Email: [email protected]
URL: http://dusithost.dusit.ac.th/~juthawut_cha/home.htm
Outline
1
ความหมายของวิศวกรรมความต้ องการ
2
กระบวนการวิศวกรรมความต้ องการ
3
การสกัดความต้ องการ
4
การวิเคราะห์ ความต้ องการ
5
การกาหนดความต้ องการ
6
การจัดการความต้ องการ
2
วิศวกรรมความต้องการ
• ข้ อมูลความต้องการ เป็ นวัตถุดบิ สาคัญในการออกแบบ
• หากสิ่ งทีน่ ามาใช้ ในการออกแบบเป็ นสิ่ งที่ผดิ พลาด ย่อมส่ งผลให้ การออกแบบผิดพลาด
ไปด้ วย
•
ปัญหาทีเ่ กิดขึน้ กับซอฟต์ แวร์ ส่วนใหญ่
– มีผลมาจากการออกแบบที่ดอ้ ยคุณภาพ
– การกาหนดความต้องการไม่ถกู ต้อง
• ในอุตสาหกรรมการผลิตซอฟต์ แวร์ นาหลักวิชาวิศวกรรมมาใช้ ในการวิเคราะห์ความ
ต้ องการ เรียกว่ า “วิศวกรรมความต้ องการ (Requirement Engineering)
– มีวตั ถุประสงค์เพื่อให้วิศวกรซอฟต์แวร์มีความเข้าใจและเข้าถึงความต้องการ
ของผูใ้ ช้ได้อย่างแท้จริ ง
3
วิศวกรรมความต้องการ
• การจัดทาข้ อกาหนดความต้ องการ ต้ องมีคุณสมบัตสิ าคัญ คือ
ความสามารถตรวจสอบ พิสูจน์ และวิเคราะห์ คุณภาพได้
• การจัดทาข้ อกาหนดความต้ องการเป็ นเครื่องบ่ งชี้ว่าความต้ องการที่
กาหนดขึน้ จะต้ องชัดเจน ไม่ คลุมเครือ
• ต้ องมีกระบวนการบางอย่ าง เพือ่ ทาให้ วศิ วกรซอฟต์ แวร์ สามารถ
กาหนดความต้ องการได้ อย่ างถูกต้ องและตรงกับความต้ องการที่
แท้ จริง
• กระบวนการดังกล่ าว คือ วิศวกรรมความต้ องการ
4
วิศวกรรมความต้องการ
•
วิศวกรรมความต้ องการ (Requirement Engineering)
– กระบวนการที่จะทาให้วิศวกรรมซอฟต์แวร์ เข้าใจและเข้าถึงความ
ต้องการของลูกค้าได้อย่างแท้จริ ง ด้วยการสกัดความต้องการ ตรวจสอบ
และนิยามความต้องการ เพื่อนาไปสร้างเป็ นข้อกาหนดความต้องการด้าน
ระบบหรื อซอฟต์แวร์ ที่จะใช้เป็ นจุดเริ่ มต้นในการพัฒนาระบบใน
ขั้นตอนต่อไป [Jawadekar, 2004]
– นอกจากนี้ วิศวกรรมความต้องการยังรวมไปถึงกระบวนการควบคุมการ
เปลี่ยนแปลงของความต้องการที่จะเกิดขึ้นด้วย เรี ยกว่า “การจัดการความ
ต้องการ (Requirement Management)”
– ดังนั้น การวิศวกรรมความต้องการจึงช่วยให้ซอฟต์แวร์ที่ผลิตออกมา
สามารถแก้ปัญหาหรื อช่วยสนับสนุนการทางานของลูกค้าได้อย่างถูกต้อง
ตรงตามความต้องการที่แท้จริ ง
5
วิศวกรรมความต้องการ
• เป้าหมายของวิศวกรรมความต้ องการ ก็คอื การสร้ าง
และบารุงเอกสารข้ อกาหนดความต้ องการ ทั้งทางด้ าน
ระบบและด้ านซอฟต์ แวร์ ให้ เป็ นเอกสารทีม่ คี ุณภาพ
ทีส่ ุ ด
6
วิศวกรรมความต้องการ
• กิจกรรมของวิศวกรรมความต้ องการ จะรวมอยู่ในระยะการวิเคราะห์
ความต้ องการของกระบวนการผลิตซอฟต์ แวร์
• เป็ นกิจกรรมที่ต้องดาเนินการอย่ างเป็ นลาดับขั้นตอน มีกระบวนการและ
ทีมงานเฉพาะ
• กระบวนการวิศวกรรมความต้ องการ จะมีลกั ษณะการทาซ้าในแต่ ละ
ระยะของการผลิตซอฟต์ แวร์ เพือ่ ให้ เป็ นเอกสารความต้ องการทีม่ ี
ประสิ ทธิภาพปัจจุบัน
• แบบจาลองของกระบวนการวิศวกรรมความต้ องการมีหลายรูปแบบ
ไม่ ว่าจะเป็ น Waterfall หรือ Spiral ตามการประยุกต์ ใช้ ของแต่ ละ
องค์ กร จึงทาให้ ข้นั ตอนของกระบวนการมีจานวนแตกต่ างกัน
7
Engineering Requirement Process
ความต้ องการประเภทต่ างๆ
Requirement Elicitation
แบบจาลองความต้ องการ
Requirement Analysis
ข้ อกาหนดความต้ องการ
Requirement Specification
เอกสารข้ อกาหนดความต้ องการ
Requirement Validation
8
กระบวนการวิศวกรรมความต้องการ
• กระบวนการที่จะเข้ าถึงความต้ องการที่แท้ จริง
– สกัดความต้องการ
– วิเคราะห์ความต้องการ
– กาหนดหรื อนิยามความต้องการ
– ตรวจสอบความต้องการ
– จัดการความต้องการ
• เป้าหมายคือของ Engineering Requirement
– การสร้างและบารุ งเอกสารข้อกาหนดความต้องการทั้งด้านระบบและ
ด้านซอฟท์แวร์ให้เป็ นเอกสารที่มีคุณภาพ
9
Engineering Requirement Process
• สกัดความต้ องการ (Requirement Elicitation)
– รวบรวมความต้องการและเข้าใจปัญหาของระบบงาน
– ความจาเป็ นของการนาซอฟท์แวร์มาใช้งาน
– ความต้องการจากกลุ่มผูใ้ ช้
• วิเคราะห์ ความต้ องการ(Requirement Analysis)
– ศึกษาและประเมินความต้องการที่รวบรวมได้
– จัดลาดับความสาคัญของความต้องการ
– สร้างแบบจาลองระดับแนวคิด (Conceptual Model)
– ประชุมและนาเสนอ
10
Engineering Requirement Process
• กาหนดความต้ องการ(Requirement Specification)
– นิยามความต้องการของระบบ
– กาหนดความต้องการด้านระบบ
– แจกแจงในรู ปแบบเอกสาร
• ตรวจสอบความต้ องการ (Requirement Validation)
– ทบทวนเอกสารทั้งหมด
– ตรวจสอบความสมบูรณ์
– ตรงตามเป้ าหมายของการพัฒนาซอฟท์แวร์
11
Requirement
Specification
System Requirements
Specification and
modeling
System
Requirements
Elicitation
User Requirements
Specification
Business Requirements
Specification
User
Requirements
Elicitation
Feasibility
Study
Prototyping
Requirement
Elicitation
Reviews
System Requirements Document
Requirement
Validation
12
การสกัดความต้องการ
• การสกัดความต้ องการ (Requirement Elicitation)
– เป็ นขั้นตอนในการเก็บรวบรวมข้ อเท็จจริง เพือ่ ทาความเข้ าใจกับปัญหา
ที่เกิดขึน้ และบทบาทของซอฟต์ แวร์ ในการทาหน้ าทีแ่ ก้ปัญหา
– วิศวกรซอฟต์ แวร์ จะต้ องสามารถเข้ าใจถึงเป้าหมายและวัตถุประสงค์
ของลูกค้ าได้ เป็ นอย่ างดี
– ค้ นหาความต้ องการจากบุคคลทีเ่ กีย่ วข้ องแต่ ละกลุ่มด้ วยเทคนิคต่ าง ๆ
เช่ น การสั มภาษณ์ การออกแบบสอบถาม
– ทักษะพืน้ ฐานที่วิศวกรซอฟต์ แวร์ ต้องมีในขั้นตอนนี้ คือ “การ
ติดต่ อสื่ อสารหรือการประสานงาน (Communication)”
13
การสกัดความต้องการ
• การค้ นหาความต้ องการทีแ่ ท้ จริงเป็ นเรื่องยาก
1. ความต้ องการของผู้ใช้ ค่อนข้ างคลุมเครือ ไม่ ชัดเจน มีลกั ษณะเป็ น
นามธรรม และมีความเป็ นไปได้ น้อย
2. วิศวกรซอฟต์ แวร์ ต้องทาความเข้ าใจกับคาศัพท์ ของผู้ใช้ ทีใ่ ช้ บอกความ
ต้ องการ
3. ผู้ใช้ แต่ ละคนมีความต้ องการแตกต่ างกัน
4. สายบังคับบัญชาขององค์กรลูกค้ า อาจส่ งผลกระทบต่ อความต้ องการที่
รวบรวมมาได้
5. สภาพแวดล้อมทางธุรกิจและสภาพเศรษฐกิจมีผลต่ อการเปลีย่ นแปลง
14
ความต้ องการ
เทคนิคการเก็บรวบรวมความต้องการ
เทคนิคทีใ่ ช้
1. การสั มภาษณ์ (Interview) นิยมใช้ มากทีส่ ุ ด
2. การแสดงลาดับเหตุการณ์ (Scenario) เตรียมคาถามตามลาดับงานของ
ผู้ใช้
3. สร้ างต้ นแบบ (Prototype) เช่ น ออกแบบจอภาพบนกระดาษ เพือ่ ทดสอบ
การยอมรับความต้ องการในเบือ้ งต้ น
4. การประชุ ม (Meeting) เป็ นการเรียกกลุ่มบุคคลทีเ่ กีย่ วข้ องมาประชุ ม เพือ่
ขอความคิดเห็นและความต้ องการ
5. การสั งเกต (Observation) โดยตรวจสอบสภาพแวดล้อมการทางานของ
ผู้ใช้ เป็ นวิธีทดี่ ีแต่ ค่าใช้ จ่ายสู ง
15
กลยุทธ์ ทนี่ ิยมใช้ ในการวิเคราะห์ ความต้ องการ
1. Asking
• Ask
• Interview
• Brainstorming
• Questionnaire
16
กลยุทธ์ ทนี่ ิยมใช้ ในการวิเคราะห์ ความต้ องการ
2. Derivation from Existing System
* พิจารณาจากระบบงานเดิม
17
กลยุทธ์ ทนี่ ิยมใช้ ในการวิเคราะห์ ความต้ องการ
3. Process Analysis หรือ
Decision Analysis
• Simulation
18
กลยุทธ์ ทนี่ ิยมใช้ ในการวิเคราะห์ ความต้ องการ
4. Prototyping
• ผู้ใช้ ไม่ ทราบความต้ องการทีแ่ น่ นอน
19
Asking
• Context - free Questions
เป็ นคาถามประเภทที่ต้องการภาพรวม
ของระบบ
20
Asking
• Context - free Questions เช่ น
* ใครต้ องการระบบงานนี้ ?
* ใครใช้ ระบบงานนี้ ?
* ผลประโยชน์ ที่จะได้ รับจากระบบ
งานใหม่ นีค้ อื อะไร ?
* มีข้อมูลแหล่งอืน่ ทีต่ ้ องใช้ อกี หรือไม่ ?
21
Asking
• Context - free Questions (ต่ อ)
* ลักษณะของ output ที่คาดหวังจาก
ระบบงานที่เสร็จแล้ วเป็ นอย่ างไร ?
* มีปัญหาอะไรบ้ างที่ระบบงานนีค้ วรพิจารณา ?
* ระบบงานนีม้ ีสิ่งแวดล้ อมการทางานอะไรบ้ าง ?
* มีกฎหรือประสิ ทธิภาพพิเศษที่ต้องคานึงถึง
หรือไม่ ?
22
Asking
• Meta - question
* คุณเป็ น “ตัวจริง” ใช่ หรือไม่ ที่จะเป็ นคนตอบ
คาถาม ?
* คาถามที่ถามทั้งหมดนีเ้ กีย่ วข้ องกับระบบงาน
หรือไม่ ?
23
Asking
• Meta - question
* ผมถามคุณมากไปหรือเปล่า ?
* มีคนอืน่ อีกหรือไม่ ทจี่ ะให้ ข้อมูลได้ อกี ?
* มีอะไรบ้ างทีผ่ มยังไม่ ได้ ถามคุณ ?
24
Asking
What
information produced ?
information provide ?
performance required
?
interface defined ?
constraints apply
?
25
Asking
What How
26
Interview
1. กาหนดบุคคลที่จะไปสัมภาษณ์
(Detemine who to Interview)
* หาได้จากโครงสร้างขององค์กร (Organization Chart)
* ควรเป็ น Informal Organization Chart
27
Interview
2. กาหนดวัตถุประสงค์
(Establish Objective for the Interview)
* มีหน้าที่อะไรบ้าง
* หน่วยงานนี้มีความต้องการอะไรบ้าง
* อยากให้ช่วยเหลือหรื อปรับปรุ งอะไร
* มีข้นั ตอนการทางานอะไรบ้าง
28
Interview
3.เตรี ยมการสัมภาษณ์ (Prepare for the Interview)
* คาถาม
ปลายเปิ ด
ปลาย
ปิ ด
29
Interview
4. ทาการสัมภาษณ์ (Conduct the Interview)
ห้าม !
* กล้องวิดีโอ
* เทป
30
Interview
5. ทาเอกสารหลังการสัมภาษณ์
(Document the Interview)
* สรุ ปผลการสัมภาษณ์
31
User Requirements
need
need to have
want
nice to have
32
User Requirements
“ I know you believe you understand what you
think I said , but I am not sure you realize
that what you heard is not what I meant..”
33
การวิเคราะห์ความต้องการ
การวิเคราะห์ ความต้ องการ (Requirement Analysis)
- การนาข้ อมูลความต้ องการทีร่ วบรวมได้ มาวิเคราะห์ หรือประเมิน
เพือ่ จาแนกกลุ่มของความต้ องการ
- จัดลาดับความสาคัญ ดูความสอดคล้อง ขจัดความขัดแย้ ง
- สร้ างแบบจาลอง ออกแบบสถาปัตยกรรมของซอฟต์ แวร์
- นาไปทดสอบการยอมรับจากลูกค้ า
- เมื่อลูกค้ ายอมรับในข้ อกาหนดความต้ องการ คือ เอกสารความ
ต้ องการทั้งหมด (ฉบับร่ าง)
34
การวิเคราะห์ความต้องการ
การวิเคราะห์ ความต้ องการ มีวตั ถุประสงค์ ดังนี้
- เพือ่ ตรวจหาและแก้ ไขความขัดแย้ งระหว่ างความต้ องการใน
แต่ ละรายการ
- เพือ่ ค้ นหาขอบเขตของซอฟต์ แวร์ และการทางานกับ
สภาพแวดล้ อมนอกระบบ
- เพือ่ ศึกษาความต้ องการด้ านระบบอย่ างละเอียด เพือ่ ใช้ ในการ
กาหนดความต้ องการด้ านซอฟต์ แวร์
35
การวิเคราะห์ความต้องการ
การวิเคราะห์ ความต้ องการ มีกจิ กรรมย่ อย ดังรู ป
แบ่ งกลุ่มความต้ องการ
(Requirement
Classification)
สร้ างแบบจาลอง
ความต้ องการ
(Conceptual Modeling)
เจรจาต่ อรองความต้ องการ
(Requirement Negotiation)
ออกแบบสถาปัตยกรรมและ
จัดสรรความต้ องการ
(Architectural Design and
Requirement Allocation)
36
การแบ่งกลุ่มความต้องการ (Requirement Classification)
1. แบ่ งเป็ นความต้ องการที่เป็ นหน้ าทีห่ ลัก (Functional Requirement) และ
ไม่ ใช่ หน้ าทีห่ ลัก (Non-Functional Requirement)
2. แบ่ งความต้ องการทีเ่ กีย่ วกับผลิตภัณฑ์ (Product) และกระบวนการ
(Process)
3. แบ่ งกลุ่มตามขอบเขตของความต้ องการ
- จาเป็ น (Mandatory)
- ปรารถนาสู ง (Highly Desirable)
- ปานกลาง (Desirable)
- ละเว้ นได้ (Optional)
37
การแบ่งกลุ่มความต้องการ (Requirement Classification)
4. แบ่ งกลุ่มตามขอบเขตของความต้ องการ โดยต้ องให้ ความสาคัญต่ อความ
ต้ องการทีม่ ีขอบเขตกว้ าง
5. แบ่ งกลุ่มตามการเปลีย่ นแปลงของความต้ องการ
- ความต้ องการที่เปลีย่ นแปลงได้ (Volatility)
- ความต้ องการทีไ่ ม่ สามารถเปลีย่ นแปลงได้ (Stability)
38
การสร้ างแบบจาลองความต้ องการ (Requirement Modeling)
- แบบจาลองความต้ องการ (Requirement Model) หรือแบบจาลอง
แนวคิด (Conceptual Model)
- เพือ่ จาลองความต้ องการทีร่ วบรวมมา ทาให้ ผู้ทเี่ กีย่ วข้ องเห็นภาพของ
ความต้ องการ
- เข้ าใจความต้ องการได้ ตรงกัน
- ชี้ถึงจุดผิดพลาดของความต้ องการได้ ง่าย
- แก้ไขได้ ทันทีก่อนนาไปออกแบบจาลองความต้ องการ
- ถือเป็ นกุญแจสาคัญสาหรับการวิเคราะห์ ความต้ องการและออกแบบ
ระบบ
39
การสร้ างแบบจาลองความต้ องการ (Requirement Modeling)
- ชนิดและวิธีการสร้ างแบบจาลองจะแตกต่ างกัน ตามแนวทางของการ
วิเคราะห์ ระบบ
- เชิงโครงสร้ าง (SSAD) จะใช้ DFD และ ERD เป็ นแบบจาลอง
กระบวนการ การไหลของข้ อมูลและโครงสร้ างข้ อมูล
- เชิงวัตถุ (OOSAD)
- Use case เพือ่ ให้ เห็นหน้ าทีก่ ารทางานของซอฟต์ แวร์
- Class/Object Diagram แสดงให้ เห็นข้ อมูลและพฤติกรรมของระบบ
40
การสร้ างแบบจาลองความต้ องการ (Requirement Modeling)
ปัจจัยทีส่ ่ งผลกระทบต่ อการเลือกใช้ แบบจาลอง ดังนี้
1. ธรรมชาติของปัญหา เช่ น ความต้ องการการทางานแบบเวลาจริง
(Real-time) จะต้ องใช้ แบบจาลองในลักษณะ Control Flow และ State Model
2. ความชานาญของวิศวกรซอฟต์ แวร์
3. ความต้ องการด้ านกระบวนของลูกค้า
4. ระเบียบวิธีปฏิบัติและเครื่องมือที่เลือกใช้ อาจไม่ ได้ การยอมรับจากลูกค้ า
41
การสร้ างแบบจาลองความต้ องการ (Requirement Modeling)
ข้ อดีของการสร้ างแบบจาลองของระบบ
- ทีมงานทราบถึงภาพรวมของระบบ
- ทราบถึงการโต้ ตอบกับสภาพแวดล้อมอืน่ นอกระบบ
- ประโยชน์ ในการออกแบบการทางานของซอฟต์ แวร์
สิ่ งสาคัญในการสร้ างแบบจาลอง คือ
- ระเบียบวิธีปฏิบัติทใี่ ช้ สร้ างแบบจาลอง
- UML (Unified Modeling Language)
- Formal Modeling
42
การออกแบบสถาปัตยกรรมและการจัดสรรความต้องการ
(Architectural Design and Requirement Allocation)
• ความซับซ้ อนของกระบวนการวิศวกรรมซอฟต์ แวร์ ทาให้ ต้องมีการ
ออกแบบสถาปัตยกรรมของซอฟต์ แวร์
• เพือ่ แสดงคอมโพเน้ นท์ หรือส่ วนประกอบของซอฟต์ แวร์ ที่เข้ ามาสนับสนุน
และรองรับความต้ องการส่ วนใดของผู้ใช้
• การจัดสรรความต้ องการ (Requirement Allocation) เข้ ากับองค์ ประกอบแต่
ละส่ วนของซอฟต์ แวร์
43
การออกแบบสถาปัตยกรรมและการจัดสรรความต้องการ
(Architectural Design and Requirement Allocation)
•การจัดสรรความต้ องการมีความสาคัญ
– ช่ วยให้ ทมี งานนาแต่ ละส่ วนทีจ่ ดั สรรแล้ วไปวิเคราะห์ ในระดับ
รายละเอียดเพิม่ เติมต่ อไป
– ในโครงการขนาดใหญ่ การจัดสรรความต้ องการทาให้ เกิดการ
วิเคราะห์ ระบบย่ อยรอบใหม่
44
การออกแบบสถาปัตยกรรมและการจัดสรรความต้องการ
(Architectural Design and Requirement Allocation)
•ตัวอย่าง
- ความต้ องการให้ พฒ
ั นาประสิ ทธิภาพของ
ระบบห้ ามล้อ (Brake System) ของรถยนต์
ความต้ องการคือ
- ระยะหยุด
- แรงดันของเบรก
- การขับขี่ในสภาพทีไ่ ม่ ปลอดภัย - ความนุ่มนวลในการทางาน
ความต้ องการจะถูกจัดสรรให้ กบั ฮาร์ ดแวร์ ของระบบเบรก และระบบป้ องกันล้ อตาย
(Anti-Lock Breaking System) และทาให้ มีการกาหนดความต้ องการในด้ านอืน่ ๆ เช่ น
ความต้ องการด้ านประสิ ทธิภาพของ ABS
45
การเจรจาต่อรองความต้องการ (Requirement Negotiation)
•การเจรจาต่ อรองความต้ องการ หรือเรียกว่ า การแก้ไขข้ อขัดแย้ งระหว่าง
ความต้ องการ (Conflict Resolution)
•จะเกิดขึน้ เมื่อมีการนาเสนอแบบจาลองความต้ องการต่ อลูกค้ า เพือ่ รับทราบ
และยอมรับ
•จะเกิดขึน้ เมื่อลูกค้ าพบข้ อผิดพลาด หรือไม่ พอใจในข้ อกาหนดความต้ องการ
หรืออาจมีการเปลีย่ นแปลง
46
การเจรจาต่อรองความต้องการ (Requirement Negotiation)
•ลักษณะความขัดแย้ งหรือความไม่ สอดคล้อง
– ความขัดแย้ งระหว่ างผู้มีส่วนได้ ส่วนเสี ยทีม่ ีความเห็นไม่ ตรงกัน
– ความขัดแย้ งระหว่ างความต้ องการกับทรัพยากรทีม่ อี ยู่
– ความขัดแย้ งระหว่ างข้ อกาหนดความต้ องการที่เป็ นหน้ าที่หลักกับที่
ไม่ ใช่ หน้ าที่หลัก
•ความสาคัญในการแก้ ไขความขัดแย้ ง
– ไม่ รีบแก้ไข หรือละเลยจะส่ งผลย้ อนหลัง
– กลายเป็ นวัตถุดิบทีไ่ ม่ มีคุณภาพทีจ่ ะนาไปสู่ การออกแบบ
47
การวิเคราะห์ความต้องการ
• เมื่อผ่ านขั้นตอนการวิเคราะห์ ความต้ องการ รายการความต้ องการ
ต้ องมีลกั ษณะ ดังนี้
– มีความถูกต้ อง (Validity)
– สอดคล้ อง (Consistency)
– เป็ นไปได้ (Feasibility)
– พร้ อมนาไปจัดทาข้ อกาหนดความต้ องการในเอกสาร
48
การกาหนดความต้องการ
• การกาหนดความต้ องการ หรือ ข้ อกาหนดความต้ องการ (Requirement
Specification)
• ข้ อกาหนดความต้ องการสาหรับวิศวกรรม คือ การกาหนดค่ าทางตัวเลข
หรือกาหนดข้ อจากัดต่ อเป้าหมายในการออกแบบผลิตภัณฑ์
• แต่ ข้อกาหนดความต้ องการสาหรับซอฟต์ แวร์ ค่ าที่เป็ นตัวเลขที่จะนามาใช้
เป็ นข้ อความในการออกแบบซอฟต์ แวร์ มนี ้ อยมาก
• ความต้ องการส่ วนใหญ่ ของซอฟต์ แวร์ จะบ่ งบอกถึงคุณลักษณะของ
ซอฟต์ แวร์ มากกว่ า
49
การกาหนดความต้องการ
• ข้ อกาหนดความต้ องการด้ านซอฟต์ แวร์ (Software Requirement
Specification) หมายถึง การสร้ างเอกสารความต้ องการ แสดงรายละเอียด
ทางด้ านซอฟต์ แวร์ ทีส่ ามารถตรวจสอบ ประเมินค่ า และยอมรับได้
• ระบบทีม่ ีความซับซ้ อนสู ง เอกสารข้ อกาหนดความต้ องการของระบบ
จะต้ องประกอบด้ วย (นอกเหนือจากคอมโพเน้ นท์ ของซอฟต์ แวร์ )
– การนิยามระบบ (System Definition)
– ความต้ องการด้ านระบบ (System Requirement)
– ความต้ องการด้ านซอฟต์ แวร์ (Software Requirement)
50
การจัดทาข้อกาหนด (Specification)
เอกสารทีเ่ กีย่ วข้ อง
1. เอกสารนิยามระบบ เป็ นเอกสารทีถ่ ูกจัดทาขึน้ จากมุมมอง
ของผู้ใช้ โดยแสดงถึงรายการความต้ องการด้ านระบบ
2. เอกสารข้ อกาหนดความต้ องการด้ านระบบ ดาเนินงานโดย
วิศวกรระบบ มักถูกจัดทาก่ อนข้ อ 3
3. เอกสารข้ อกาหนดความต้ องการด้ านซอฟต์ แวร์ ระบุถงึ
หน้ าที่ของซอฟต์ แวร์ ซึ่งเป็ นข้ อตกลงขั้นพืน้ ฐานของ
ทีมงานกับผู้ใช้
51
เอกสารข้อกาหนดด้านซอฟต์แวร์
เอกสารนิยามระบบ (System Definition Document)
•หรือ เอกสารความต้ องการของผู้ใช้ (User Requirement Document)
•เป็ นเอกสารบันทึกความต้ องการด้ านระบบของผู้ใช้
•เป็ นการกาหนดความต้ องการในระดับสู งจากมุมมองของผู้ใช้
•ผู้ทอี่ ่านเอกสาร คือ กลุ่มของของผู้ใช้ หรือลูกค้า (และฝ่ ายการตลาด)
•เอกสารต้ องเขียนด้ วยภาษาทีเ่ ข้ าใจง่ าย หรือคาศัพท์ ทลี่ ูกค้ าใช้ ในงานธุรกิจ
52
เอกสารข้อกาหนดด้านซอฟต์แวร์
รายละเอียดของเอกสารนิยามระบบ
– รายการความต้ องการด้ านระบบตามหลักการและเหตุผลหรือทีม่ าของ
ระบบ และต้ องสอดคล้องกับวัตถุประสงค์ ของระบบ
– รายละเอียดของสภาพแวดล้อมภายนอกระบบ
– ข้ อจากัด ข้ อสมมติฐาน ความต้ องการทีไ่ ม่ ใช่ หน้ าทีห่ ลักของระบบ
– แบบจาลองความต้ องการในระดับสู ง (Context System)
– แผนภาพลาดับเหตุการณ์ (Scenario) หรือเอ็นติตี้ (Entity)
– ข้ อมูลและลาดับขั้นตอนการทางาน
53
เอกสารข้อกาหนดด้านซอฟต์แวร์
เอกสารข้ อกาหนดความต้ องการด้ านระบบ (System Requirement
Specification)
– นักพัฒนาระบบ จะแยกรายละเอียดความต้ องการค้ านระบบออกจาก
รายละเอียดความต้ องการด้ านซอฟต์ แวร์
– เอกสารข้ อกาหนดความต้ องการด้ านระบบ จะถูกกาหนดขึน้ มาก่ อน
เพือ่ นาไปกาหนดความต้ องการด้ านซอฟต์ แวร์
– การจัดทาเอกสารข้ อกาหนดความต้ องการด้ านระบบ เป็ นการ
ดาเนินงานของวิศวกรรมระบบ
54
เอกสารข้อกาหนดด้านซอฟต์แวร์
เอกสารข้ อกาหนดความต้ องการด้ านซอฟต์ แวร์ (Software
Requirement Specification)
– เอกสารทีร่ ะบุถึงหน้ าทีข่ องซอฟต์ แวร์
– ช่ วยให้ ทีมพัฒนาทราบว่ าต้ องพัฒนาอะไร
– เอกสารข้ อกาหนดความต้ องการด้ านซอฟต์ แวร์ หรือ SRS
เปรียบเสมือนข้ อตกลงพืน้ ฐานระหว่ างลูกค้ ากับบริษัทผู้ผลิต
– เอกสารนิยามซอฟต์ แวร์ จะเป็ นบทนาก่อนเข้ าสู่ ความต้ องการด้ าน
ซอฟต์ แวร์
55
เอกสารข้อกาหนดด้านซอฟต์แวร์
• เอกสารข้ อกาหนดความต้ องการต้ องผ่ านการประเมินความ
ต้ องการ ก่ อนนาไปใช้ เป็ นวัตถุดบิ ในการออกแบบ
• เพือ่ ให้ ความต้ องการทีร่ ะบุในเอกสารมีลกั ษณะทีจ่ ะนาไปประเมิน
ราคา ความเสี่ ยงและจัดตารางงาน
• เมื่อข้ อมูลความต้ องการผ่ านการประเมินแล้ ว สามารถนาไปใช้ ใน
การวางแผนการวัดผลิตผลในการผลิตซอฟต์ แวร์
56
ตัวอย่างเอกสาร SRS (IEEE830,1993 [Jawadekar, 2005]
Chapter/Section
Topic
1
Introduction
1.1
บทคัดย่อ
1.2
วัตถุประสงค์ ของเอกสาร
1.3
โครงสร้ างของเอกสาร
1.4
คาศัพท์ ทใี่ ช้
1.5
คาศัพท์ ทใี่ ช้ เฉพาะในเอกสารนี้
1.6
อืน่ ๆ ทีต่ ้ องการอ้ างอิงถึง
57
ตัวอย่างเอกสาร SRS (IEEE830,1993 [Jawadekar, 2005]
Chapter/Section
Topic
2
System Description
2.1
ภาพรวมของระบบปัจจุบัน
2.2
ปัญหาทีพ่ บในระบบปัจจุบัน
2.3
เป้ าหมายของระบบทีพ่ งึ ประสงค์
2.4
ภาพรวมของระบบที่พงึ ประสงค์
2.5
คุณลักษณะของผู้ใช้ ระบบ
2.6
ข้ อสมมติฐาน
58
ตัวอย่างเอกสาร SRS (IEEE830,1993 [Jawadekar, 2005]
Chapter/Section
Topic
3
Functional Requirements
3.1
ฟังก์ชันหลักของระบบทั้งหมด
3.2
ฟังก์ชัน/โมดูล-1
3.2.1
3.2.2
รายละเอียดของฟังก์ชัน (สร้ างแบบจาลองประกอบ ถ้ า
จาเป็ น)
การบรรลุเป้ าหมายทีต่ ้ องการ
3.2.3
ตัวอย่างความต้ องการ
59
ตัวอย่างเอกสาร SRS (IEEE830,1993 [Jawadekar, 2005]
Chapter/Section
Topic
3.3
ฟังก์ชัน/โมดูล-2
3.3.1
รายละเอียดของฟังก์ชัน (สร้ างแบบจาลองประกอบ ถ้ า
จาเป็ น)
3.3.2
การบรรลุเป้ าหมายทีต่ ้ องการ
3.3.3
ตัวอย่างความต้ องการ
3.4
ฟังก์ชัน/โมดูล-3
3.4.1
...
3.4.2
...
...
...
60
ตัวอย่างเอกสาร SRS
(IEEE830,1993 [Jawadekar, 2005]
Chapter/Section
4
4.1
4.2
4.3
4.4
4.5
4.6
4.7
Topic
Non-Functional Requirements
ประสิ ทธิภาพ
ความได้ ผลของเครื่องมืออรรถประโยชน์
ระบบรักษาความปลอดภัยของระบบ
ความปลอดภัยในการใช้ งาน
สมรรถภาพ
ส่ วนประสานกับผู้ใช้
ใช้ งานได้ ดี
61
ตัวอย่างเอกสาร SRS
(IEEE830,1993 [Jawadekar, 2005]
Chapter/Section
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
Topic
ความน่ าเชื่อถือ
ความถูกต้ องแม่ นยา
การนาไปใช้ ได้ อกี
ง่ ายต่ อการใช้ งาน
ความสามารถทางานร่ วมกันได้
ความสามารถเข้ ากันได้ กบั ระบบอืน่
มีการกาหนดระดับความเป็ นส่ วนตัว
สามารถดูแลระบบได้ ง่าย
62
ตัวอย่างเอกสาร SRS (IEEE830,1993 [Jawadekar, 2005]
Chapter/Section
4.16
4.17
4.18
5
6
6.1
6.2
6.3
Topic
การขยายระบบในอนาคต
ความสามารถในการดูแลรักษา
ความสามารถในการทดสอบ
Design Constraint
Project Requirement (Optional)
การประมาณการขนาดของซอฟต์ แวร์
การประมาณแรงงานการผลิตซอฟต์ แวร์
การประมาณการต้ นทุน
63
ตัวอย่างเอกสาร SRS (IEEE830,1993 [Jawadekar, 2005]
Chapter/Section
Topic
6.4
ตารางการทางาน
6.5
Platform ทีใ่ ช้ ในการพัฒนา
6.6
เงือ่ นไขทีใ่ ช้ ในการยอมรับ
Appendices
A
ประเด็นทีอ่ ยู่ในระหว่ างศึกษา (Pending Issues)
B
อภิธานศัพท์ (Glossary)
C
ดัชนี (Index)
64
การตรวจสอบความต้องการ
• การตรวจสอบความต้ องการ คือ ขั้นตอนสุ ดท้ ายก่ อนนาไปสู่ การ
ออกแบบ
• เป็ นการวิเคราะห์ และตรวจหาข้ อผิดพลาดหรือปัญหาที่อาจเกิดขึน้
จากการทับซ้ อนความต้ องการ
• มีความสาคัญ เพราะเมื่อเกิดปัญหาจะทาให้ เกิดข้ อผิดพลาดของ
ซอฟต์ แวร์ ส่ งผลต่ องบประมาณ
65
การตรวจสอบความต้องการ
การตรวจสอบเอกสารข้ อกาหนดความต้ องการ ควร
ตรวจสอบตามลักษณะดังนี้
1. มีความเที่ยงตรง (Validity)
2. มีความสอดคล้ อง (Consistency)
3. มีความครบถ้ วนสมบูรณ์ (Completeness)
4. มีความเป็ นไปได้ (Feasibility)
5. สามารถพิสูจน์ ได้ (Verifiability)
66
การตรวจสอบความต้องการ
1. มีความเทีย่ งตรง (Validity)
- การกาหนดความต้ องการจะตอบสนองความต้ องการของ
ผู้ใช้ ทุก ๆ กลุ่มอย่ างเท่ าเทียม
- ความต้ องการควรเกิดจากความต้ องการของผู้ใช่ อย่ าง
ทัว่ ถึงและยุตธิ รรม
2. มีความสอดคล้ อง (Consistency)
- ความต้ องการในเอกสารจะต้ องไม่ ขดั แย้ งกัน
67
การตรวจสอบความต้องการ
3. มีความครบถ้ วนสมบูรณ์ (Completeness)
- เอกสารต้ องระบุรายละเอียดฟังก์ ชันและบริการครบถ้ วน
4. มีความเป็ นไปได้ (Feasibility)
- เพือ่ ให้ มั่นใจว่ าความต้ องการทีร่ ะบุในเอกสารสามารถพัฒนาระบบได้ จริง
- เทคโนโลยี งบประมาณ และระยะเวลาในการพัฒนา
5. สามารถพิสูจน์ ได้ (Verifiability)
- ความต้ องการจะต้ องพิสูจน์ เพือ่ หาความจริงได้
- สามารถทดสอบ ทดลอง ให้ เห็นถึงการทางานจริงของระบบ
68
เทคนิคในการตรวจสอบความต้องการ
เทคนิคการตรวจสอบ
1. การทบทวนความต้ องการ (requirment review)
– โดยมีการตรวจสอบเอกสารอย่างละเอียด เพื่อหาข้อผิดพลาดตามลักษณะ
ต่างๆ
– การทบทวนความต้องการอาจเป็ นแบบทางการหรื อไม่เป็ นทางการก็ได้
ขึ้นอยูก่ บั องค์กร
– การทบทวนแบบไม่เป็ นทางการ (Informal Review) ทีมทบทวนจะนา
เอกสารความต้องการมาพิจารณาหาข้อผิดพลาดร่ วมกับผูม้ ีส่วนได้ส่วน
เสี ยและผูร้ ับเหมาช่วง
– การทบทวนแบบเป็ นทางการ (Formal Review) ทีมทบทวนจะต้อง
พิจารณาความต้องการร่ วมกับผูใ้ ช้ทีละรายการ
69
เทคนิคในการตรวจสอบความต้องการ
เทคนิคการตรวจสอบ
1. การทบทวนความต้ องการ (requirment review)
– ตรวจสอบตามลักษณะต่อไปนี้
• สามารถพิสูจน์ ได้ (Verification) ความต้องการนั้นต้องสามารถพิสูจน์
การทางานหรื อทดลองได้
• สามารถเข้ าใจได้ (Comprehensibility) ผูใ้ ช้สามารถเข้าใจในความ
ต้องการนั้นหรื อไม่
• สามารถยอนกลับไปตรวจสอบได้ (Traceability) สามารถย้อนกลับไป
ตรวจสอบแหล่งที่มาของความต้องการ เมื่อต้องมีการเปลี่ยนแปลง
• สามารถดัดแปลงได้ (Adaptability) ความต้องการจะต้องสามารถ
ดัดแปลงได้โดยไม่ส่งผลกระทบต่อระบบ
70
เทคนิคในการตรวจสอบความต้องการ
เทคนิคการตรวจสอบ
2. การจัดทาต้ นแบบ (prototyping)
- เป็ นการสร้ างต้ นแบบของระบบ (Executable Model)
- เพือ่ สาธิตให้ ลูกค้ าหรือผู้ใช้ ระบบดู หรือทดลองใช้ ด้วยตนเอง
- ตรวจสอบว่ าตรงตามความต้ องการของลูกค้ าหรือไม่
- เป็ นวิธีที่ช่วยรวบรวมความต้ องการที่เกิดขึน้ ใหม่
- เป็ นเทคนิคที่ดีในการตรวจสอบความต้ องการ มีความชัดเจน
- การสร้ างต้ นแบบต้ องใช้ เงินทุนสู ง แต่ ได้ ผลลัพธ์ ทดี่ ี
- เป็ นเทคนิคทีด่ ีทสี่ ุ ดอย่ างหนึ่ง เหมาะแก่การลงทุน
71
เทคนิคในการตรวจสอบความต้องการ
เทคนิคการตรวจสอบ
3. การสร้ างแบบทดสอบ (Test-Case Generation)
- โดยนาแบบทดสอบนั้นไปออกแบบหรือพัฒนาระบบขึน้ ใช้
- ถ้ าทาได้ ยาก ควรพิจารณาความต้ องการนั้นใหม่
- มักใช้ กบั การพัฒนาซอฟต์ แวร์ แบบ Extreme Programming
72
การตรวจสอบความต้องการ
ข้ อแนะนาสาหรับการตรวจสอบความต้ องการ
- ทีมงานตรวจสอบความต้ องการ ควรเป็ นทีมงานอืน่ ที่ไม่ ใช่ ทีมพัฒนา
- หากพบข้ อผิดพลาดควรแก้ไขให้ ถูกต้ องและจัดทาเอกสารพร้ อมกับ
เสนอวิธีแก้ไขปัญหา
- ทุกครั้งทีม่ ีการแก้ไขข้ อมูลความต้ องการ ต้ องมั่นใจว่ ามีความสอดคล้อง
และถูกต้ องเสมอ
- ควรระบุเทคนิคหรือวิธีการทีใ่ ช้ ในการตรวจสอบความต้ องการไว้ ใน
สั ญญา
73
การจัดการความต้องการ (Requirement Management)
• การจัดการความต้ องการ (Requirement Management)
- คือ กระบวนการทาความเข้ าใจและควบคุมความเปลีย่ นแปลงของ
ความต้ องการของระบบ [Sommerville, 2007]
- สามารถเริ่มดาเนินการได้ ทันทีทจี่ ัดทาเอกสารข้ อกาหนดความ
ต้ องการฉบับร่ างเสร็จ
- การวางแผนการจัดการความต้ องการ ควรเริ่มตั้งแต่ ข้นั ตอนการสกัด
ความต้ องการ
74
งานย่อยของงานวิศวกรรมความต้องการ
• การจัดการความต้ องการ (Requirement Management)
ความต้ องการในระบบมักเปลีย่ นแปลงไปตลอดช่ วงชีวติ ของ
ระบบ การจัดการความต้ องการเป็ นชุดของกิจกรรมทีช่ ่ วยให้
ทีมงานกาหนดกลไกในการควบคุมและติดตามความสาเร็จและ
การเปลีย่ นแปลงความต้ องการ ณ เวลาใดเวลาหนึ่งขณะที่
โครงการดาเนินไป
75
การจัดการความต้องการ (Requirement Management)
สาเหตุของการเปลีย่ นแปลงความต้ องการ
1. มีผู้ใช้ หลายกลุ่มซึ่งมีความต้ องการต่ างกัน จึงมีความขัดแย้ งกัน
จาเป็ นต้ องมีการปรับสมดุลความต้ องการใหม่
2. เกิดความขัดแย้ งระหว่ างผู้ใช้ ทจี่ ่ ายเงินลงทุน กับผู้ใช้ ทเี่ ป็ นผู้ใช้ ระบบ
โดยตรง
3. มีการเปลีย่ นสภาพแวดล้อมทางธุรกิจและเทคโนโลยีภายหลังมีการ
ติดตั้งใช้ ระบบงาน
76
การจัดการความต้องการ (Requirement Management)
• กระบวนการ
1. จาแนกความต้ องการทีเ่ ปลีย่ นแปลงและความต้ องการที่ไม่ เปลีย่ นแปลง
2. วางแผนการจัดการความต้ องการ โดยระบุความเป็ นเอกลักษณ์ ให้ กบั ทุก
ความต้ องการ กาหนดกิจกรรมการประเมินผล กาหนดความสั มพันธ์ ของ
ความต้ องการแต่ ละรายการและใช้ Case Tool เข้ าช่ วยจัดการความต้ องการ
3. จัดการกับการเปลีย่ นแปลงความต้ องการ เพือ่ ให้ การเปลีย่ นแปลง
ทั้งหมดที่เกิดขึน้ มีความสอดคล้องกัน โดยอาศัยหลักการจัดการโครงแบบ
ของระบบ
77
ความต้องการที่เปลี่ยนแปลงและไม่เปลี่ยนแปลง
• วิวฒ
ั นาการของความต้ องการ แบ่ งความต้ องการออกเป็ น 2 ประเภท
1. ความต้ องการที่ไม่ เปลีย่ นแปลง (Enduring Requirement)
- เป็ นความต้องการแบบคงที่ ไม่เปลี่ยนแปลงได้ง่าย
- เป็ นความต้องการที่เกิดจากการทางานหลักของธุรกิจในแต่ละวัน
2. ความต้องการที่เปลี่ยนแปลง (Volatile Requirement)
- เป็ นความต้องการที่มีการเปลี่ยนแปลงอยูเ่ สมอในระหว่างการพัฒนา
ระบบหรื อหลังจากการติดตั้งระบบเพื่อใช้งานไปแล้ว
78
การวางแผนการจัดการความต้องการ
• การจัดการความต้ องการเป็ นกระบวนการทีต่ ้ องใช้ งบประมาณค่ อนข้ างสู ง
• การวางแผนก่ อนเริ่มดาเนินงาน ตามกิจกรรมต่ อไปนี้
– จาแนกความต้ องการ (Requirement Identification) ทีมงานต้ องทาการระบุความเป็ น
เอกลักษณ์ ให้ กบั ทุกความต้ องการ เพือ่ ไม่ ให้ ความต้ องการซ้าซ้ อนกัน และเพือ่ การอ้ างอิง
– กระบวนการจัดการการเปลีย่ นแปลง (Change Management Process) ทีมงานต้ องกาหนด
กิจกรรมในการประเมินผลกระทบและต้ นทุนทีเ่ กิดจากการเปลีย่ นแปลง
– นโยบายการสื บหา (Traceability Policy) เป็ นการกาหนดความสั มพันธ์ ระหว่ างความต้ องการ
แต่ ละรายการ และเก็บบันทึก เพือ่ ประโยชน์ ในการบารุ งรักษา
– CASE Tool ทีมงานต้ องสรรหาเครื่องมือเข้ ามาสนับสนุนกระบวนการจัดการความต้ องการ
เครื่องมือจะช่ วยให้ จัดการข้ อมูลได้ ง่ายขึน้
79
การจัดการความต้องการ
• การจัดการความต้ องการ จะพิจารณาในเรื่องของความสั มพันธ์ ระหว่ าง
ความต้ องการกับการออกแบบระบบ
• เมื่อเกิดการเปลีย่ นแปลง จะต้ องทาการออกแบบหรือแก้ไขในส่ วนนั้นใหม่
• การเปลีย่ นแปลงความต้ องการย่ อมส่ งผลกระทบต่ อส่ วนอืน่ ทีส่ ั มพันธ์ กนั
• การสื บหาส่ วนที่ได้ รับผลกระทบหรือแหล่งทีม่ าของความต้ องการจึงมี
ความจาเป็ น
80
การจัดการความต้องการ
• การสื บหา แบ่ งออกเป็ น 3 ชนิด ดังนี้
– 1. การสื บหาแหล่งที่มา (Source Traceability) เป็ นการสื บหาแหล่งที่มาของการ
เปลีย่ นแปลง เพือ่ สอบถามถึงเหตุและช่ วงเวลาการนาเสนอให้ เปลีย่ น
– 2. การสื บหาความต้ องการ (Requirement Traceability) เป็ นการสื บหาจานวน
ความต้ องการที่ได้ รับผลกระทบจากการเปลีย่ นแปลง
– 3. การสื บหาในส่ วนการออกแบบ (Design Traceability) เป็ นการสื บหาส่ วนการ
ออกแบบจากความต้ องการทีเ่ ปลีย่ นแปลง เพือ่ ทาการแก้ ไขให้ ถูกต้ อง
81
การจัดการความต้องการ
• การจัดการความต้องการต้องให้ความสาคัญกับรายละเอียดต่าง ๆ ของความต้องการ
• ระบบขนาดใหญ่ ย่อมต้องมีความต้องการจานวนมาก ส่ งผลให้การจัดการมีความ
ยุง่ ยากและต้องใช้เวลานาน
• จาเป็ นต้องนาเครื่ องมือเข้ามาช่วยสนับสนุนกระบวนการจัดการความต้องการ
• วิศวกรรมซอฟต์แวร์มี CASE Tool ที่สนับสนุนงานสาคัญของกระบวนการ
– แหล่งจัดเก็บความต้องการ (Requirement Storage)
– การจัดการกับการเปลี่ยนแปลง (Change Management)
– การจัดการความสามารถสื บหาได้ (Traceability Management)
82
การจัดการกับการเปลี่ยนแปลงความต้องการ
• เมื่ อ มี ก ารเปลี่ ยนแปลงความต้อ งการ ที มงานหรื อ องค์ก รต้องมี กระบวนการ
จัดการกับการเปลี่ยนแปลง (Requirement Change Management)
• เพื่อให้การเปลี่ยนแปลงที่เกิดขึ้นมีความสอดคล้องกับส่ วนอื่นที่สัมพันธ์กนั และ
อยูภ่ ายใต้การควบคุมอย่างเป็ นทางการ
• กระบวนการจัดการการเปลี่ยนแปลงจะเกี่ยวข้องกับการวิเคราะห์ถึงความคุม้ ค่า
เมื่อต้องเปลี่ยนแปลง
83
สรุป
ทาไมต้ องวิเคราะห์ ความต้ องการ
1.เพื่อเก็บข้อมูล/ข้อเท็จจริ ง (Collect Data/Fact)
2.วิเคราะห์ขอ้ เท็จจริ ง (Analysis Facts)
3.ตัดสิ นใจ (Make a Decision)
84
สรุป
Get the Fact
Analysis the Facts
Make a Decision
85
สรุป
การวิเคราะห์ ความต้ องการของผู้ใช้
มีสิ่งที่ตอ้ งคานึงดังนี้
Scope
problem
bounded
86
สรุ ป
• การจัดทาข้ อกาหนดความต้ องการ ต้ องชัดเจนไม่ คลุมเครือ
• ข้ อกาหนดความต้ องการต้ องสามารถตรวจสอบ พิสูจน์ และวิเคราะห์
คุณภาพได้
• วิศ วกรรมความต้ อ งการ (Requirement
Engineering) หมายถึ ง
กระบวนการที่จะทาให้ วิศวกรซอฟต์ แวร์ เข้ าใจและเข้ าถึงความต้ องการ
ของลูกค้ าได้ อย่ างแท้ จริง
• ด้ วยขั้นตอน การสกัดความต้ องการ ตรวจสอบ และนิยามความต้ องการ
87
สรุ ป
กระบวนการวิศวกรรมความต้ องการ ประกอบด้ วยกิจกรรมย่อมดังนี้
1. การสกัดความต้ องการ (Requirement Elicitation) คือ การรวบรวมหรื อค้นหา
ความต้องการ
2. การวิเคราะห์ ความต้ อง (Requirement Analysis) คือ ขั้นตอนในการประเมิน
ความต้องการที่รวบรวมได้ เพื่อจัดกลุ่มความต้องการ จัดลาดับความสาคัญของ
ความต้องการ แก้ไขความขัดแย้งของความต้องการ สร้างเป็ นแบบจาลองความ
ต้องการในระดับความคิด
3. การกาหนดความต้ องการ (Requirement Specification) คือ การสร้างเอกสาร
ความต้องการเพื่อแสดงรายละเอียดทางด้านซอฟต์แวร์ ที่สามารถตรวจสอบ
ประเมินค่า และยอมรับได้
88
สรุ ป
กระบวนการวิศวกรรมความต้ องการ ประกอบด้ วยกิจกรรมย่ อมดังนี้
4. การตรวจสอบความต้ องการ (Requirement Validation) คือการ
ทบทวนและตรวจสอบข้ อกาหนดความต้ องการในเอกสารทั้งหมด เพือ่ ให้
เกิดความเที่ยงตรง สอดคล้อง ครบถ้ วน มีความเป็ นไปได้ และสามารถ
พิสูจน์ ได้ ตามเป้าหมายของกระบวนการวิศวกรรมซอฟต์ แวร์
การวิศวกรรมความต้ องการ ยังรวมถึง กระบวนการจัดการความต้ องการ
(Requirement Management) เป็ นกระบวนการทาความเข้ าใจและควบคุม
การเปลีย่ นแปลงความต้ องการของระบบ
89
Chapter 9 : The End (Any Question?)