Object-Oriented Analysis and Design

1. Object-Oriented Analysis and Design ภาคการศึกษาที่ 2 / 2549 บทที่ 3 Introduction to UML

2. แนะนำ UML (Unified Modeling Language)

3. Modeling การสร้างแบบจำลอง (Modeling) เป็นวิธีการวิเคราะห์ และออกแบบ (Analysis and Design) วิธีการหนึ่งที่เน้นการสร้างแบบจำลอง เพื่อให้สามารถเข้าใจในปัญหาของระบบ ใช้เป็นเครื่องมือในการสื่อสาร แนวคิดในการพัฒนาระบบ กับบุคคลอื่นๆ Visual Modeling ใช้สัญลักษณ์รูปภาพในการสร้างแบบจำลอง

4. ความเป็นมาของภาษา UML จากความนิยมในการใช้แนวคิดเชิงวัตถุ (Object Orientation) ในการวิเคราะห์ออกแบบและพัฒนาระบบซอฟตแวรที่มีขนาดใหญและซับซอน ทําใหมีผูคิดคนวิธีการพัฒนาซอฟตแวรเชิงวัตถุ ขึ้นหลายวิธี แต่ละวิธีของการวิเคราะหออกแบบจะมีการกําหนดสัญลักษณรูปภาพ(Notation)ตางกัน รวมทั้งจุดเดนจุดดอยของแตละวิธีการก็แตกตางกัน ซึ่งยากที่จะตอบวิธีการใดดีที่สุด ผูออกแบบและพัฒนาระบบซอฟตแวร ที่มีประสบการณมักจะใชหลายวิธีการรวมกัน อันเปนที่มาของการรวมกันของวิธีการตางๆ ในเวลาต่อมา

5. ความเป็นมาของภาษา UML ชวงแรก เปนการวมกันระหวางวิธีการชื่อ Booch ของ Grady Booch และ OMT ของ James Rumbaugh เปนการพัฒนากระบวนการพัฒนาซอฟตแวรเชิงวัตถุที่มีเปาหมายใหเปนหนึ่งเดียวกัน (Unified Method) โดยนําเอาวิธีการของ Booch และOMT(Object Modeling Technique) มารวมกันแล้วปรับปรุงใหม ตอมา Ivar Jacobson ผูพัฒนากระบวนการ OOSE หรือ Objectory Process ไดเขารวมโครงการดังกลาวภายหลัง ซึ่งในครั้งนั้นเปนการสรางภาษาโมเดลขึ้นใหมเรียกวา ภาษายูเอ็มแอล (UML - Unified Modeling Language)

6. ความเป็นมาของภาษา UML เนื่องจากวิธีการพัฒนาซอฟตแวรเชิงวัตถุของทั้งสามมีชื่อเสียงและเป็นที่ยอมรับในชวงเวลานั้นอยู่แล้ว ภาษา UML ที่ถูกพัฒนาขึ้นมาใหมจึงกลายเปนที่นิยมใชกันอยางแพรหลาย ในป ค.ศ.1997 ภาษายูเอ็มแอล รุนที่ 1.1 ไดถูกเสนอใหกับหนวยงาน OMG (Object Management Group) กําหนดใหเปนภาษาโมเดลมาตรฐาน (Standard Modeling Language) จากนั้นภาษา UML ถูกพัฒนาตอโดย OMG ซึ่งในปจจุบันภาษา UML รุนที่เผยแพรออกสูสาธารณชนคือ ภาษา UML รุนที่ 2.0

7. ความเป็นมาของภาษา UML ปี 1998 พัฒา UML Version 1.2 ปี 1999 พัฒา UML Version 1.3 ปี 2000 พัฒา UML Version 1.4 ปี 2001 พัฒา UML Version 2.0 http://www.uml.org/

8. ภาษา UML ภาษา UML เปนภาษาที่มีรูปภาพมาตรฐาน (Standard Visual Modeling Language) และเปนภาษาสากลที่ใชในการวิเคราะห์ออกแบบและพัฒนาระบบซอฟตแวรเชิงวัตถุ ดังนั้น เอกสารการวิเคราะหและออกแบบที่ถูกสรางดวยภาษา UML จึงสามารถแลกเปลี่ยน และทําความเขาใจตรงกันไดระหวางผูรวมงานภายในกลุมผูพัฒนาระบบ

9. ภาษา UML ภาษา UML มีคุณสมบัติที่สามารถนําเสนอและสนับสนุนหลักการเชิงวัตถุไดอยางครบถวนชัดเจน และไมผูกติดกับภาษาโปรแกรมภาษาใดภาษาหนึ่ง Model ที่ถูกสรางขึ้นจากภาษา UML สามารถถูกแปลงไปเปนระบบจริงที่ถูกสรางขึ้นดวยภาษาโปรแกรมเชิงวัตถุใดก็ได อีกทั้งภาษา UML เปนภาษาที่งายตอการทําความเขาใจ ผูที่ทําการศึกษาหรือนําไปใชงานไมจําเปนตองมีความรูอื่นใดนอกจากแนวคิดเชิงวัตถุ

10. ภาษา UML จากการที่ภาษา UMLเปนภาษาที่มีมาตรฐาน ผูออกแบบและพัฒนาจึงจําเปนตองศึกษาไวยากรณ(Syntax)หรือโครงสรางของภาษา UMLกอนนําไปใชงาน ภาษายูเอ็มแอลประกอบดวยองคประกอบพื้นฐาน 3 สวน คือ 1)หนวยโครงสรางพื้นฐาน (Basic Building Block) 2)กฎการใชงาน (Rules) 3)กลไกการทํางาน (Mechanism)

11. ภาษา UML 1)หนวยโครงสรางพื้นฐาน เป็นองคประกอบที่สําคัญและผูใช้ตองทําความเขาใจ ซึ่งประกอบดวยองคประกอบยอย 3 สวน คือ 1.1)สัญลักษณทั่วไป (Things) คือ สัญลักษณพื้นฐานที่ถูกใชงานในการสราง diagram ตางๆ ของภาษา UML ถือวาเปนรูปแบบที่เล็กที่สุดของModel สัญลักษณทั่วไปแบงไดออกเปน 4 หมวด คือ หมวดโครงสราง (Structural Things) หมวดพฤติกรรม (Behavioral Things) หมวดการจัดกลุม (Grouping Things) หมวดคําอธิบาย (Annotation Things)

12. ภาษา UML 1.2) ความสัมพันธ์ (Relationships) เปนสิ่งที่ใชแสดงความสัมพันธระหวางสัญลักษณทั่วไป มี 4 ชนิด คือ ความสัมพันธแบบขึ้นตอกัน (Dependency Relationship): คุณสมบัติของสิ่งหนึ่งขึ้นอยูกับคุณสมบัติของอีกสิ่งหนึ่ง ความสัมพันธแบบเกี่ยวของกัน (Association Relationship): สิ่งสองสิ่งที่มีความสัมพันธเชื่อมโยงกัน ความสัมพันธแบบทั่วไป(Generalization Relationship): คุณสมบัติของสิ่งหนึ่งเปนคุณสมบัติพื้นฐานของอีกสิ่งหนึ่ง ซึ่งอาจจะมีคุณสมบัติมากกวาคุณสมบัติพื้นฐานนั้น ความสัมพันธแบบตนแบบ (Realization Relationship): สิ่งหนึ่งถูกสรางใหมีคุณสมบัติของอีกสิ่งหนึ่ง

13. ภาษา UML 1.3) แผนภาพ (Diagrams) คือ แผนภาพที่เกิดจากแนวคิดที่วาสัญลักษณทั่วไป ใดๆก็ตาม ถามีคุณสมบัติบางประการที่สามารถจัดใหอยูใน กลุมเดียวกันได้ ก็จะใชแผนภาพมาจัดกลุมใหแกสัญลักษณ เหลานั้น

14. องคประกอบในภาษา UML

15. ภาษา UML นอกจากองคประกอบของภาษา UML แล้ว อีกสิ่งหนึ่งที่สำคัญคือ การเลือกใชงานdiagram สาเหตุที่ภาษา UML ตองมีแผนภาพที่หลากหลาย เนื่องจากใน ระบบที่มีขนาดใหญและมีความซับซอน ไม่สามารถใช้แผนภาพชนิดใดเพียงแผนภาพเดียว แล้วแสดงมุมมองได้ครบ ทั้งมุมมอง เชิงโครงสรางของระบบ (Static หรือ Structural View) และ เชิงพฤติกรรมของระบบ (Dynamic หรือ Behavioral View) ดังนั้นจําเปนตองมีการเลือกแผนภาพหนึ่งมาใชในมุมมองหนึ่ง และเลือกอีกแผนภาพหนึ่งมาใชในอีกมุมมองหนึ่ง

16. ภาษา UML เพื่อใหไดแผนภาพที่สามารถเสนอมุมมองไดอยางครบถวน จําเปนตองใชหลายแผนภาพ โดยตองเขาใจจุดประสงคของแตละแผนภาพ และเลือกใชแผนภาพใหตรงกับมุมมองที่ตองการ

17. ภาษา UML View ตามแนวทางของ UML นี้จะแยกออกเป็น 2 ลักษณะหลัก คือ 1. Static Views (Structural Views) มุมมองของระบบที่ไม่มีการเคลื่อนไหวหรือคงที่ ไม่ได้มองถึงการเปลี่ยนสภาวะหรือสถานะขององค์ประกอบที่อยู่ภายในระบบ เช่น Class Diagram 2. Dynamic Views (Behavioral Views) มุมมองของระบบที่มีการเคลื่อนไหว,เปลี่ยนแปลง สภาวะหรือสถานะขององค์ประกอบที่อยู่ภายในระบบ เช่น Sequence Diagram

18. Diagram ใน UML Diagram(แผนภาพ) ใน UML จำแนกตาม มุมมองเชิงโครงสร้าง และ มุมมองเชิงพฤติกรรมของระบบ

19. Class Diagram • ใช้เพื่อแสดงโครงสร้างของระบบซึ่งประกอบด้วย • Class และรายละเอียดภายใน Class • ความสัมพันธ์ในเชิง Abstraction ระหว่าง Class เช่น • Aggregation , Generalization , Association

20. Object Diagram คล้ายกับ Class Diagram

21. Component Diagram ใช้เพื่อแสดงโครงสร้างทางกายภาพของSoftwareซึ่งประกอบด้วยส่วนประกอบต่างๆ ที่เรียกว่า Components (ชิ้นส่วนทาง software)

22. Deployment Diagram ใช้เพื่อแสดงโครงสร้างทางHardwareของระบบ ซึ่งมักใช้ร่วมกับ Component Diagram

23. Use Case Diagram ใช้เพื่ออธิบายฟังก์ชันของระบบในมุมมองของกลุ่มผู้ใช้ระบบ

24. Sequence Diagram Time ใช้เพื่อแสดงปฎิสัมพันธ์(Interaction)ระหว่าง Objectsโดยเฉพาะการส่ง Message ระหว่าง Objects ตามลำดับของเวลา

25. Collaboration Diagram ใช้เพื่อแสดงปฎิสัมพันธ์(Interaction)ระหว่าง Objectsคล้ายกับ Sequence Diagram แต่ต่างกันที่ Collaboration Diagram จะไม่แสดงลำดับการส่ง Message อย่างชัดเจน แต่จะเน้นที่ การแสดงความสัมพันธ์ระหว่าง Objects ตามลักษณะการทำงาน (ปกติจะเลือกใช้ Diagram ใด Diagram หนึ่ง)

26. Statechart Diagram ใช้เพื่อแสดงสถานะ (State) ของแต่ละ Object รวมทั้งเหตุการณ์(Events)ต่าง ๆ ที่ทำให้สถานะของ Object เปลี่ยนไป โดยจะให้ความสนใจว่า ณ เวลาต่าง ๆ Object นั้นมีสถานะเป็นแบบใด

27. Activity Diagram ใช้เพื่อแสดงลำดับการดำเนินกิจกรรม(Activity) จากกิจกรรมหนึ่งไปยังอีกกิจกรรมหนึ่งภายในระบบ ที่เกิดจากการทำงานของObjects (ในลักษณะ Flowchart) สัญลักษณ์จะคล้ายกับ Statechart Diagram แต่จะไม่สนใจในเรื่องสถานะ

28. Diagram ใน UML ปัจจุบัน Diagram ในภาษา UML สามารถแบ่งออกได้เป็น9 diagrams โดยแต่ละ diagram เปรียบเสมือนมุมมองในด้านต่างๆของระบบที่ผู้วิเคราะห์และออกแบบกำลังจะพัฒนา โดยในแต่ละ diagram ที่แสดงมุมมองต่างๆ ประกอบด้วยสัญลักษณ์ที่ใช้สื่อความหมายเฉพาะภายใน diagram นั้น

29. Diagram ใน UML นอกจากความรู้พื้นฐานที่เกี่ยวข้องกับองค์ประกอบและdiagramของภาษา UML แล้ว สิ่งที่ทำให้การใช้งานภาษา UMLเป็นไปอย่างประสบผลสำเร็จอีกอย่างก็คือ ผู้ออกแบบและพัฒนาจำเป็นต้องเรียนรู้กระบวนการในการเลือกใช้ diagram ตามความเหมาะสม ในขั้นตอนกระบวนการพัฒนาซอฟต์แวร์เชิงวัตถุ จะใช้แผนภาพของภาษา UML เพื่อสร้างโมเดลระบบอย่างเป็นขั้นตอนสอดคล้องกับกระบวนการพัฒนาซอฟต์แวร์

30. Diagram ใน UML ในการพัฒนาระบบโดยทั่วไป ผู้พัฒนาไม่จำเป็นต้องสร้างแผนภาพให้ครบทุกแผนภาพเสมอไป ผู้พัฒนาสามารถปรับเปลี่ยนการใช้งานแผนภาพได้ตามความเหมาะสม

31. Object 1. เฟสการวิเคราะห์ความต้องการ(Requirement Analysis) วัตถุประสงค์ของเฟสแรกนี้ คือ การทำความเข้าใจกับขอบเขตของปัญหา (Problem Domain) การกำหนดขอบเขตของการพัฒนาและฟังก์ชันการทำงานต่างๆของระบบที่พัฒนา สิ่งที่ผู้พัฒนาต้องทำในขั้นตอนนี้ คือ การนำเอาความต้องการแบบ Functionality (Functional Requirements) ซึ่งบ่งบอกถึงความสามารถที่ผู้ใช้สามารถเรียกใช้จากระบบ มาแปลงเป็น Model ความต้องการของผู้ใช้งาน ซึ่งจะใช้Use Case Diagram

32. Object 1. เฟสการวิเคราะห์ความต้องการ(Requirement Analysis) ที่ขาดไม่ได้ใน Use Case คือ คำบรรยาย Use Case(Use Case Description) ซึ่งเป็นรายละเอียดของแต่ละ Function ว่าเริ่มต้นอย่างไร มีการดำเนินเหตุการณ์เกิดขึ้นอย่างไรและสิ้นสุดลงอย่างไร เรียกรวมๆว่า ลำดับการเกิดเหตุการณ์ (Flow of Event) รวมถึงเหตุการณ์ยกเว้น (Exception Flow of Event) ที่อาจเกิดขึ้นระหว่างการปฏิบัติฟังก์ชันดังกล่าวของระบบ ก็ต้องถูกบันทึกด้วยเช่นกัน

33. Object 2. เฟสการวิเคราะห์ระบบ(Domain Analysis) ในเฟสที่สองนี้เป็นการบรรยายถึงโครงสร้างและพฤติกรรมของระบบที่กำลังพัฒนา ซึ่งกิจกรรมสำคัญต่างๆที่ผู้พัฒนาต้องกระทำในเฟสนี้ ได้แก่ 2.1) การสร้าง Class Diagramเพื่อศึกษาโครงสร้าง (Structure) หรือส่วนที่เป็นโครงสร้างของระบบ โดยการ

34. Object 2. เฟสการวิเคราะห์ระบบ(Domain Analysis) 2.1.1หา Class ทั้งหมดในระบบโดยใช้เทคนิคHeuristic Mappingคือ ให้คำนามที่พบในคำบรรยาย Use case (เฟสแรก) แปลงเป็น Class คำกิริยา จะถูกแปลงเป็นOperationและ คำวิเศษณ์ จะถูกแปลงเป็น Attribute ซึ่งคำนามทุกคำอาจไม่ถูกแปลงเป็น Class เสมอไป เช่น คำนามบางคำเขียนต่างกันแต่หมายถึงสิ่งเดียวกัน ซึ่งขั้นตอนนี้ ประสบการณ์ถือเป็นสิ่งสำคัญที่ช่วยให้ผู้พัฒนาค้นพบคลาสเป้าหมาย และรายละเอียดของคลาสได้อย่างถูกต้อง

35. Object 2. เฟสการวิเคราะห์ระบบ(Domain Analysis) 2.1.2ค้นหาความสัมพันธ์ (Relationships) ระหว่างคลาส อันได้แก่ การขึ้นต่อกัน (Dependency), การถ่ายทอดคุณสมบัติ (Inheritance), ความสัมพันธ์แบบเชื่อมโยง(Association) ทั้งแบบ สัมพันธ์แบบองค์ประกอบร่วม (Composition) และ สัมพันธ์แบบมีส่วนร่วม (Aggregation) ด้วยเช่นกัน

36. Object 2. เฟสการวิเคราะห์ระบบ(Domain Analysis) 2.2)การสร้าง Sequence Diagram เพื่อศึกษาพฤติกรรม (Behavior) หรือส่วนที่มีความเป็นพลวัต( Dynamic) ของระบบ โดยการสร้าง Sequence Diagramสำหรับแต่ละ Use caseใน Use Case Diagram จากเฟสแรก นอกจากนี้การสร้าง Sequence Diagramยังช่วยให้พบ Operation เพิ่มเติมด้วย

37. Object 2. เฟสการวิเคราะห์ระบบ(Domain Analysis) วิธีการพัฒนาซอฟต์แวร์เชิงวัตถุ เป็นไปในลักษณะของการวนรอบทำซ้ำและทำเพิ่ม (Interative and Incremental) ขึ้นเรื่อยๆจนสมบูรณ์ ซึ่งลักษณะดังกล่าวเริ่มปรากฏในเฟสนี้ คือ แทนที่ต้องทำการวิเคราะห์ ทุก Use Case จาก Use Case Diagramในครั้งเดียว ซึ่งหากเป็นระบบที่ซับซ้อนและมีขนาดใหญ่ก็อาจประกอบไปด้วย Use Case นับร้อย

38. Object 2. เฟสการวิเคราะห์ระบบ(Domain Analysis) ดังนั้นในเฟสนี้ ผู้พัฒนาสามารถเลือกเพียงหนึ่ง Use Case มาทำการวิเคราะห์ หา Classes และ Relations รวมถึงลักษณะ Dynamic ของระบบ และเมื่อวงจรการพัฒนากลับมาที่เฟสนี้อีกครั้ง ก็เป็นการวิเคราะห์ออกแบบ Use Case ถัดๆไปนั่นเอง

39. Object 2. เฟสการวิเคราะห์ระบบ(Domain Analysis) กล่าวโดยสรุป ในเฟสของการวิเคราะห์เป็นการ Model ปัญหา ซึ่งผลที่ได้ในเฟสนี้คือ เอกสารที่บันทึก Model การวิเคราะห์ระบบ (Analysis Model Document) อันประกอบไปด้วย Class Diagram, Sequence Diagram นอกจากนี้อาจมีการใช้สัญลักษณ์ Package หรือ Diagram อื่นๆ เช่น Collaboration Diagram , State Transition Diagram, Activity Diagram มาช่วยในการสร้างโมเดลด้วยเช่นกัน

40. Object 3. เฟสการออกแบบ(Design) ในเฟสการออกแบบระบบ ผู้พัฒนาจะทำการกำหนดรายละเอียดเชิงเทคนิคของระบบให้พร้อม เพื่อนำไป Implement จริงในเฟสถัดไป อาจกล่าวได้ว่า เฟสนี้เป็นเฟสการค้นหาวิธีการแก้ปัญหา(How) ภายหลังจากการทำความเข้าใจปัญหา (What ในเฟสก่อนหน้า) สิ่งที่ต้องเตรียมสำหรับใช้ในเฟสนี้ คือ Model การวิเคราะห์จากเฟสที่สอง ซึ่งอาจรวมถึงความต้องการแบบ Nonfunctionalก็จะถูกนำมาพิจารณาในการออกแบบเฟสนี้ด้วยเช่นกัน

41. Object 3. เฟสการออกแบบ(Design) กิจกรรมในการเฟสการออกแบบระบบมีดังต่อไปนี้ 3.1)การเพิ่มเติมClass หรือ Package ลงไปภายในModel การวิเคราะห์ระบบ (เฟสที่สอง) เช่น การเพิ่มแพ็กเกจที่เกี่ยวข้องกับฐานข้อมูล การติดต่อสื่อสาร โดย Package หรือ Class เหล่านี้จะทำงานร่วมกันกับ Package เดิมที่มีอยู่ในModel การวิเคราะห์ระบบ นอกจากนี้ยังรวมถึงการแก้ไขปรับปรุงเพิ่มเติม Attribute หรือ Operation ของ Class ต่างๆในModel การวิเคราะห์ระบบด้วยเช่นกัน

42. Object 3. เฟสการออกแบบ(Design) 3.2)จัดหา Class Library หรือ Component จากที่อื่นเพื่อนำมา ใช้อีกครั้ง เพื่อช่วยลดเวลาในการพัฒนาระบบ (Reuse of Class Libraries) 3.3)กำหนดรายละเอียดส่วนติดต่อกับผู้ใช้ของระบบ (User Interface Design) 3.4)หาวิธีจัดการกับข้อผิดพลาดที่อาจจะเกิดขึ้นในการใช้ งานระบบ (Exception Handling)

43. Object 3. เฟสการออกแบบ(Design) 3.5)ออกแบบสถาปัตยกรรมระบบ (System Architecture Design) เพื่อทำการพิจารณาที่อยู่ หรือตำแหน่งการติดตั้งของ Component หรือ Package ต่างๆ พิจารณาว่า Class ใดควรอยู่ ใน Component หรือไฟล์ใดควรติดตั้งไว้ที่ระบบคอมพิวเตอร์ ส่วนใด นั่นคือการสร้างComponent Diagramและ Deployment Diagram สำหรับรูปแบบของสถาปัตยกรรมที่ใช้กันโดยทั่วไป คือ สถาปัตยกรรมแบบกระจาย (Distributed System) ซึ่งได้แก่ 2-เทียร์ (2-Tier), 3-เทียร์ (3- Tier) และ มัลติเทียร์(Multi-Tier System)

44. Object 3. เฟสการออกแบบ(Design) 3.6) ออกแบบส่วนที่เป็น Nonfunctional Requirement เช่น กลุ่มของผู้ใช้งานมีความต้องการใช้งานระบบใหม่ร่วมกับฐานข้อมูลหรือระบบเดิมที่มีอยู่ (Legacy System Integration) 3.7)นอกจากนี้ การออกแบบยังรวมถึงการตัดสินใจเลือกใช้เทคโนโลยีต่างๆที่มีอยู่ให้เหมาะสมกับความต้องการและงบประมาณของผู้ใช้งานด้วยเช่นกัน

45. Object 3. เฟสการออกแบบ(Design) กล่าวโดยสรุป UML Diagram ที่ถูกสร้างในเฟสนี้ได้แก่ Component Diagramและ Deployment Diagram ในส่วนของ Class DiagramและSequence Diagramจะถูกเพิ่มรายละเอียดเชิงเทคนิค เรียกผลลัพธ์รวมของเฟสนี้ว่าModel การออกแบบระบบ (Design Model) ซึ่งประกอบไปด้วย Diagram ต่างๆข้างต้น รวมถึงข้อกำหนด ด้านอื่นๆ ซึ่งระบุถึงรายละเอียดของความต้องการแบบ Nonfunctional เทคนิควิธีการแก้ปัญหา และเอกสารการออกแบบ (UML Design Document) นี้จะถูกส่งต่อไปให้โปรแกรมเมอร์เพื่อนำไปพัฒนาในเฟสถัดไป

46. Object 4. เฟสการสร้างโปรแกรมระบบ(Construction) วัตถุประสงค์หลักของเฟสนี้ คือ การแปลงผลที่ได้จากเฟส การออกแบบไปเป็น Code กล่าวคือ นักวิเคราะห์ออกแบบระบบจะต้องทำการสร้าง Model ระบบที่สมบูรณ์อันเป็นข้อมูลสำคัญสำหรับโปรแกรมเมอร์

47. Object 5.เฟสการทดสอบระบบ(Testing) ในเฟสนี้ ผู้พัฒนาจะต้องทำการค้นหาข้อผิดพลาด (Error) ภายในระบบที่กำลังพัฒนา ซึ่ง โดยปกติการทดสอบระบบจะอ้างอิงผลการวิเคราะห์ความต้องการผู้ใช้งานระบบ(เฟสแรก)เป็นหลัก ว่าเป็นไปตามความต้องการของผู้ใช้งานจริงอย่างครบถ้วนหรือไม่ ทั้งด้านความต้องการแบบ Functional และ Nonfunctional