1. วัตถุประสงค
เพื่อใหผูเรียนสามารถ
อธิบายความหมายของความตองการ
อธิบายความสําคัญของการกําหนดความตองการ
อธิบายประเภทของความตองการ
อธิบายกิจกรรมในกระบวนการกําหนดความตองการ
อธิบายเทคนิคในการรวบรวมความตองการ
หนวยที่ 3: การกําหนดความตองการ อธิบายการวิเคราะหความตองการ
(Requirements Determination) อธิบายสรางยูสเคสโมเดล
OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 1 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 2
การวิเคราะหและออกแบบระบบ
ซอฟตแวร
การพัฒนาระบบทีประสบความสําเร็จ
่
สรางระบบที่ตรงกับความตองการ
ภายในงบประมาณ
ภายในระยะเวลา
การวิเคราะหและออกแบบระบบทีมประสิทธิภาพ
่ ี
ชวยหลีกเลี่ยงความลมเหลว
วิเคราะห = การทําความเขาใจกับระบบที่จะสราง
การสรางแบบจําลอง (Modeling) ออกแบบ = กําหนดรูปแบบการสรางระบบ
OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 3 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 4
1

2. แบบจําลอง (Model) แบบจําลอง
การสรางแบบจําลอง คือกระบวนการสรางตัวแทน ประโยชนคือ
เพื่อแสดงโดเมนหรือซอฟตแวร แบบจําลองสรางไดงายและเร็ว
แบบจําลอง (model) แสดงภาพที่สมบูรณของ แบบจําลองสามารถใชในการจําลองสถานการณ เพื่อ
ระบบจากมุมมองดานหนึ่ง เรียนสิ่งที่มันกําลังแสดงอยูเพิ่มเติม
การพัฒนาระบบมักใชแบบจําลองหลายตัวเพื่อ แบบจําลองสามารถวิวัฒนไปพรอมกับการเรียนรูงานหรือ
ปญหา
แสดงภาพของระบบในมุมมองที่ตางๆ

เราสามารถเลือกรายละเอียดที่จะนําเสนอและไมนําเสนอ
ในแบบจําลอง
แบบจําลองสามารถแสดงสิ่งที่มีจริงและจินตนาการใน
ทุกดานได
OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 5 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 6
แผนภาพ (Diagram) แผนภาพ
แบบจําลองมักประกอบดวยเอกสารขอความและแผนภาพ กฎทีเปนมาตรฐานสําหรับการวาดแผนภาพมี
่
นักวิเคราะหและนักออกแบบใชแบบจําลองเชิงแผนภาพ ความสําคัญตอการเขาใจ
เพื่อ
สื่อสารความคิด UML (Unified Modeling Language) เปนภาษา
สรางความคิดหรือความเปนไปไดใหมๆ มาตรฐานในการสรางแผนภาพเพื่อการพัฒนาระบบ
ทดสอบความคิดหรือทํานาย เชิงวัตถุ
เพื่อทําความเขาใจโครงสรางและความสัมพันธ
แผนภาพ (diagram) แสดงสวนใดสวนหนึ่งของระบบ
แบบจําลองหนึ่ง
อาจใชแผนภาพหลายแบบในการนําเสนอ
มักใชหลายแผนภาพ
OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 7 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 8
2

3. แบบจําลองในการวิเคราะหและ
เทคนิคการสรางแบบจําลองที่ดี
ออกแบบ
เนนการนําเสนอที่ไมซบซอน
ั แบบจําลองยูสเคส (Use case model)
เนนความสอดคลองภายในชุดแผนภาพ แบบจําลองโครงสราง (structural model)
เนนความสมบูรณ แบบจําลองพฤติกรรม (dynamic and behavioral
เนนการนําเสนอแบบเปนลําดับชั้น model)
OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 9 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 10
ความตองการและขอกําหนด
เพื่อใหไดระบบที่ตรงตามความตองการ คือ
แกปญหาได
ตองทําความเขาใจกับปญหา
สภาพแวดลอมในการดําเนินธุรกิจ
เทคโนโลยีทใชได
ี่
เพื่อใหตัดสินใจเลือกกระทําทีเหมาะสมในการ
่
แกปญหา
การกําหนดความตองการ
OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 11 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 12
3

4. กิจกรรมในการกําหนดความ
ขอมูลและผลลัพธ
ตองการ
การวิเคราะหโดเมน (domain analysis) ขอมูลเขา (input)
การกําหนดปญหา (defining the problem) เอกสารริเริ่มโครงการ (project initiation document)
ผลลัพธ (deliverables)
การรวบรวมความตองการ
เอกสารการวิเคราะหโดเมน (domain analysis
(requirements gathering) document)
การวิเคราะหความตองการ (requirements บทนิยามความตองการ (requirement definition)
analysis) ยูสเคสโมเดล (use case model)
การระบุความตองการ ตนแบบสวนติดตอผูใช (user interface prototype)
(requirements specification) แผนการดําเนินงานที่ปรับปรุง (refined work plan)
สถาปตยกรรมเบื้องตน (initial system architecture)
OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 13 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 14
การวิเคราะหโดเมน เอกสารการวิเคราะหโดเมน
กระบวนการเรียนรูเกี่ยวกับภูมหลังของระบบ
ิ บทนํา (Introduction)
อภิธานศัพท (Glossary)
เพื่อใหเขาใจปญหา และตัดสินใจไดดีในการ
ความรูทั่วไปเกี่ยวกับโดเมน (General knowledge about
วิเคราะหความตองการ และขั้นตอนอื่นๆ the domain)
โดเมน (domain) = แวดวงในการดําเนินงานหรือ ลูกคาและผูใช (Customer and user)
เทคโนโลยีทคาดวาจะใชซอฟตแวร
ี่ สภาพแวดลอม (The environment)
ประโยชน งานหรือระเบียบวิธีดําเนินงานในปจจุบัน (Task and
procedures currently performed)
การพัฒนาที่รวดเร็ว
ซอฟตแวรคูแขง (Competing software)
ระบบที่ดีขึ้น ความคลายคลึงระหวางโดเมนและองคกร (Similarities
สามารถคาดการณการขยายของระบบได across domains and organizations)
OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 15 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 16
4

5. การกําหนดปญหาและขอบเขต กําหนดปญหาและขอบเขต
กําหนดนิยามเบื้องตนของปญหาที่ตองแกไข
 นิยามของปญหา (problem statement)
ปญหา ถูกใชในการประเมินระบบ
ความยุงยาก นิยามที่ดีตองสั้นและกระชับ
โอกาส กําหนดปญหาที่แนชัดเพื่อชวยจํากัดขอบเขต
ทางแก คํานึงถึงเปาหมายระดับสูงของผูใช
การพัฒนาซอฟตแวร สะทอนปญหาที่แทจริง
ซื้อซอฟตแวร ขอบเขต (Scope)
แกไขโดยไมใชซอฟตแวร หนาที่รับผิดชอบของระบบ
งานหรือการกระทําที่มีผลตอการบรรลุเปาหมายของผูใช
OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 17 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 18
การรวบรวมความตองการ เทคนิคการรวบรวมความตองการ
(Requirement Gathering Techniques)
การรวบรวมขอมูลเกี่ยวกับลักษณะที่ตองการของ การสัมภาษณ (Interviewing)
ระบบจากบุคคลที่เกียวของ
่ การสังเกตการณ (Observation)
ประโยชน การศึกษาเอกสาร (Document sampling)
ไดขอมูลเพื่อใชในการวิเคราะหเพื่อกําหนดความ การใชสอบถาม (Questionnaires)
ตองการ Joint Application Development (JAD)
ชวยในการสรางการรองรับในการพัฒนาระบบในองคกร การระดมความคิด (Brain storming)
ความทาทาย การทําตนแบบ (Prototyping)
การเลือกบุคคลที่จะมีสวนรวม
การรวบรวมและการรวมขอมูล
OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 19 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 20
5

6. การสัมภาษณ การสัมภาษณ
ขั้นตอน การเลือกผูถูกสัมภาษณ
เลือกผูถูกสัมภาษณ ขึ้นกับขอมูลที่ตองการ
ควรเลือกจากหลายกลุม (ผูมีสวนรวมหลักทุกกลุม)
ออกแบบคําถามในการสัมภาษณ
การออกแบบคําถามในการสัมภาษณ
เตรียมพรอมสําหรับการสัมภาษณ ประเภทคําถาม
ดําเนินการสัมภาษณ คําถามปลายเปด (open-ended question)
คําถามปลายปด (closed-ended question)
ติดตามผลหลังการสัมภาษณ
คําถามสืบสวน (probing question)
รูปแบบการสัมภาษณ
มีโครงสราง กับไมมีโครงสราง
Top-down กับ Bottom-up
OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 21 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 22
การสัมภาษณ การสัมภาษณ
การออกแบบคําถามในการสัมภาษณ การเตรียมพรอมสําหรับการสัมภาษณ
คําถามที่ควรถาม วางแผน
รายละเอียดแบบเจาะจง กําหนดรายการคําถาม คาดเดาคําตอบ และการติดตาม
วิสัยทัศน ตรวจสอบความรูของผูถูกสัมภาษณ
ความคิดที่แตกตาง กําหนดความสําคัญกรณีเวลาไมพอ
การยอมรับขั้นต่ําสุด
เตรียมความพรอมของผูถูกสัมภาษณ
แหลงขอมูลอื่น
แจงนัดหมาย, เหตุผลในการสัมภาษณ และขอบเขตการ
ไดอะแกรมของการทํางาน สัมภาษณ
OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 23 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 24
6

7. การสัมภาษณ การสัมภาษณ
การดําเนินการสัมภาษณ การติดตามผลหลังการสัมภาษณ
สรางความนาเชื่อถือ สรางรายงานการสัมภาษณ (interview report)
บันทึกทุกขอมูล พิเคราะหหาชองวาง หรือขอสงสัย
ตรวจสอบนโยบายการใชสื่อบันทึก
ทําใหแนใจวาคุณเขาใจทุกประเด็น และทุกคําศัพท
แยกแยะขอเท็จจริงจากความคิดเห็น
ใหเวลาผูถูกสัมภาษณถาม
ขอบคุณผูถูกสัมภาษณถาม
จบภายในเวลา
OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 25 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 26
Joint Application Joint Application
Development (JAD) Development (JAD)
ทําใหทีมงาน ผูใช ผูบริหารไดทางานรวมกัน
ํ รูปแบบการจัด
ชวยลดโอกาสในการเกิดปญหาการขยายขอบเขต จัดใหในสถานที่ไกลจากการรบกวน
แบบแอบแฝงได 50% จัดที่นั่งเปนรูปตัวยู
หลีกเลี่ยงปญหาของเจาะจงเกินไปหรือคคลุมเครือ ใชกระดานไวทบอรด หรือแบบพลิกได
e-JAD
เกี่ยวของกับการระดมความคิด (brain storming)
บทบาทสําคัญ
ผูดําเนินรายการ (Facilitator)
ผูจดบันทึก (Scribe)
OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 27 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 28
7

8. Joint Application
หองประชุม JAD
Development (JAD)
ขั้นตอน
เลือกผูเขารวม
ออกแบบการประชุม
JPEG Figure 5-5 Goes Here กําหนดจํานวนวัน (5-10 วัน) และสถานที่
กําหนดตารางเวลา
กําหนดระเบียบวาระ
กําหนดคําถาม
เตรียมการ
แจงกําหนดการและวัตถุประสงค
OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 29 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 30
Joint Application
การใชแบบสอบถาม
Development (JAD)
ดําเนินการ เลือกผูมีสวนรวม
บทบาทของผูดําเนินรายการ ใชกลุมตัวอยางจากประชากร
รักษาการประชุมใหอยูในประเด็น ออกแบบแบบสอบถาม
ชวยในดานคําศัพททางเทคนิค
บันทึกขอมูลบนกระดาน เลือกคําถามอยางระมัดระวัง
วางตัวเปนกลาง บริหารการทําแบบสอบถาม
กระตุนการแสดงความคิดของผูเขารวม
 
ลดการมีอํานาจเหนือ วางแผนและดําเนินการเพื่อใหอัตราการตอบสนองสูง
แกขอขัดแยง
 ติดตามผลการทําแบบสอบถาม
ติดตามผล สรางรายงานผลการสํารวจ
ทํารายงานการประชุม
สงผลไปยังผูมีสวนรวม
OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 31 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 32
8

9. การวิเคราะหเอกสาร การสังเกตการณ
ใหขอมูลเกี่ยวกับระบบปจจุบัน (“as-is” system) ผูใชหรือลูกคาอาจจะไมไดจําทุกสิงที่ตนทํา
่
ประเภทของเอกสาร ตรวจสอบความถูกตองของขอมูลที่ไดมาดวยวิธีอื่น
แบบฟอรม ทําตัวเปนเหมือนเงาเฝาดูการปฏิบติงานและจดบันทึก
ั
รายงาน พฤติกรรมเปลี่ยนเมื่อถูกจองมอง
คูมือนโยบาย อยาละเลยกิจกรรมที่ทําเปนชวงเวลา
รายสัปดาห รายเดือน รายป
คูมือผูใช
มองหาขอมูลที่ผูใชเพิ่มในแบบฟอรม
มองหาองคประกอบที่ไมไดใชในแบบฟอรม
OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 33 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 34
ความตองการของผูใช (User

การทําตนแบบ
Requirements)
ตนแบบ (prototype) คือโปรแกรมที่สรางอยางรวดเร็ว และ ความตองการทีมาจากระบบปจจุบัน (Current
่
มีสวนเล็กๆ ของฟงกชันที่คาดวาจะมีในระบบสมบูรณ system)
เพื่อใชในการรวบรวมผลตอบกลับเกี่ยวกับความคิด
ความตองการใหม (New requirement)
รูปแบบงายสุดของตนแบบคือ ตนแบบบนกระดาษ (paper
prototype) ของสวนติดตอผูใช (user interface)
เหมาะกับการพัฒนาแบบขนาน
อาจสรางตนแบบจําลอง (mock-up)
ตนแบบดานอื่น – อัลกอริทึม หรือฐานขอมูล
เพื่อทดสอบและตรวจสอบความคิดที่มี และสรางความคิด
ใหม
OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 35 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 36
9

10. ความตองการทีมาจากระบบ
่ ความตองการทีมาจากระบบ
่
ปจจุบัน (Current system) ปจจุบัน (Current system)
สวนใหมของระบบปจจุบันตอบสนองความตองการของผูที่ ระบบปจจุบนอาจมีจุดออนหรือขอผิดพลาดที่ควรกันไมให
ั
ใช ผานการปรับปรุง และผูใชคุนเคยกับระบบ ในเกิดขึ้นในระบบใหม
ชวยใหเขาใจการสภาพทั่วไปขององคการ
บางสวนของระบบปจจุบันไมสอดคลองกับความตองการ
บางสวนของระบบปจจุบันอาจถูกคงไว
แลว และมีบางดานที่ระบบไมรองรับ
ตองทําความเขาใจการทํางานของบุคคลในปจจุบันเพื่อ
นักวิเคราะหจึงตองทําความเขาใจระบบปจจุบัน เพราะ อธิบายลักษณะของผูใชของระบบใหม
หนาที่บางอยางในระบบปจจุบันตองคงในระบบใหม เพื่อรวบรวมขอมูลพื้นฐานเพื่อใชในการกําหนดและวัด
ประสิทธิภาพของระบบใหม
ขอมูลในระบบปจจุบันมีคาและตองนําไปใชในระบบใหม
ความเปลี่ยนแปลงภายในและภายนอกองคกรกอใหเกิด
เอกสารตางๆของในระบบปจจุบันอาจมีรายละเอียด ความตองการใหม นําไปสูการพัฒนาระบบใหมเพื่อ
เกี่ยวกับอัลริทึมที่จําเปนในระบบใหม ตอบสนองความตองการนี้
OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 37 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 38
สรางขอกําหนดความตองการ ความตองการ (Requirements)
เขียนชุดคําสั่งที่แนนอนเพื่อกําหนดวาซอฟตแวร เปาหมายของการกําหนดความตองการ คือสรางขอกําหนด
ความตองการ (Requirements specification)
ตองทําอะไร
ความตองการ คือ ถอยแถลงที่อธิบายในมุมของสิ่งที่ระบบ
อธิบายการแสดงพฤติกรรมของระบบ ตองทํา หรือบอกวาอะไรคือสิ่งที่ระบบตองทํา หรือขอบังคับ
แตไมระบุการออกแบบหรือการสราง ในการพัฒนาระบบ
ตองมีสวนรวมในการแกปญหาของลูกคา
เปนขอตกลงที่ผานการตอรองระหวางผูมีสวนรวม
ปญหาในการกําหนดความตองการ
มีคําอธิบายทีไมชดเจน
่ ั
การกําหนดความตองการใหสมบูรณ
การกําหนดใหมีเฉพาะความสามารถจําเปน
OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 39 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 40
10

11. ความตองการเชิงฟงกชัน ความตองการแบไมเปนฟงกชัน
(Functional Requirements) (Non-functional Requirements)
คุณสมบัติเชิงพฤติกรมที่ระบบตองมี
อธิบายสิ่งที่ระบบตองทําได หรือบริการที่ระบบ
แบงเปน
สามารถใหกบผูใชได
ั สภาพแวดลอมในการทํางาน (operational)
แบงเปน แพลตฟอรม
เทคโนโลยีที่ใช
การนําเขาขอมูล (input) ดานประสิทธิภาพ (performance) หรือ คุณภาพ (Quality)
การแสดงผล (output) ความเร็วในการ
ความสามารถในการรองรับ
การจัดเก็บขอมูล การใชทรัพยากร
การคํานวณและประมวลผล ความนาเชื่อถือ
การใชประโยชน
การกํากับเวลาและการประสานเวลา การพื้นตัวจากความขัดของ
การบํารุงรักษาและขยาย
การใชงานซ้ํา
OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 41 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 42
ความตองการแบไมเปนฟงกชัน
เทคนิคการวิเคราะหความตองการ
(Non-functional Requirements)
การรักษาความปลอดภัย (security) Business process automation
Problem analysis
วัฒนธรรมหรือนโยบาย (cultural and political) Root cause analysis
วัฒนธรรม
Business process improvement
นโยบาย Duration analysis
กฎหมาย หรือระเบียบ Activity-base costing
กระบวนการ (process) Information benchmarking
กระบวนการพัฒนา Business process reengineering
ตนทุนและกําหนดสง Outcome analysis
Technology analysis
Activity elimination
การวิเคราะห Use Case
OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 43 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 44
11

12. ยูสเคส (Use Case) ยูสเคสโมเดล
ยูสเคสคือชนิดของความสามารถของระบบจาก ยูสเคสโมเดล
มุมมองของผูใช  แสดงกลุมของยูสเคส
แสดงลักษณะเฉพาะของพฤติกรรมของระบบทั้งหมด และ
ยูสเคสคือลําดับการกระทําที่แอคเตอรกระทําเพื่อ แอคเตอรภายนอก
ทํางานหนึ่งใหสําเร็จ Use case model ประกอบดวย รายการยูสเคส และ
ยูสเคส ใชเพือบันทึกขอบเขตของระบบ และความ
่ อาจมีคําอธิบายยูสเคส (Use case description) หรือ
เขาใจของผูพัฒนาวาอะไรคือสิ่งที่ผูใชตองการ
 แผนภาพ (UML use case diagram)
แสดงวิธีการใชระบบ โดยใชบางสวนของ
ความสามารถของระบบ
OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 45 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 46
ตัวอยางอธิบายยูสเคสในรูป
องคประกอบคําอธิบายยูสเคส
แบบอยางงาย
ชื่อ ยูสเคส: เปดไฟล
แอ็คเตอร ขั้นตอน:
เปาหมาย การกระทําของแอ็คเตอร การตอบสนองของระบบ
เงื่อนไขกอนทํา (pre-condition) 1. เลือกคําสั่ง ‘เปด’ 2. แสดงหนาตาง ‘เปดไฟล’
สรุปหรือคําอธิบายยูสเคสแบบยอ 3. ระบุชื่อไฟล
ยูสเคสทีเกียวของ
่ ่ 4. ยืนยันการเลือก 5. เอาหนาตางไดอะล็อกออกจาก
ขั้นตอน หนาจอ
เงื่อนไขหลังทํา (post-condition)
OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 47 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 48
12

13. สัญลักษณสําคัญในแผนภาพ
แผนภาพยูสเคส
ยูสเคส
แอ็คเตอร (actor)
แผนภาพยูสเคส (Use case diagram) ใชแสดงงานที่
แสดงบทบาทของผูใช
ระบบจะสามารถทําได และผูใชที่ติดตอกับระบบใช
ความสามารถนี้ มีชื่อบทบาทอยูดานลาง
 
บทบาท
อยูนอกขอบเขตของระบบ
ยูสเคส (use case)
ยูสเคส งานของระบบ
อยูภายในขอบเขตของระบบ
หัวเรื่อง/ขอบเขตระบบ (subject/system boundary)
หัวเรื่อง ระบุชื่อของระบบภายใน หรือดานบน
แสดงขอบเขตในการพิจารณา
OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 49 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 50
สัญลักษณสําคัญในแผนภาพ สัญลักษณสําคัญในแผนภาพ
ยูสเคส ยูสเคส
ความสัมพันธ (association) ความสัมพันธแบบ generalization
เชื่อมโยงแอ็คเตอรกับยูสเคส เชื่อมโยงระหวางแอ็คเตอร หรือระหวางยูสเคส
ความสัมพันธแบบ include
<<include>>
เชื่อมโยงระหวางยูสเคส
แสดงการใชยูสเคส
ชี้ไปยังคลาสที่ถก include
ู
ความสัมพันธแบบ extend
<<extend>> เชื่อมโยงระหวางยูสเคส
แสดงการขยายยูสเคส
ชี้ไปยังคลาสที่ถกขยาย
ู
OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 51 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 52
13

15. พิจารณาหาแอคเตอร พิจารณาหายูสเคส
ฮารดแวรหรือระบบภายนอกใดที่ใชระบบนี้ในการ 1. สําหรับแตละแอคเตอร หางานหรือหนาที่ที่แอคเตอร ควร
ทํางาน? สามารถทําได หรือที่ระบบตองการใหแอคเตอรทํา ยูสเคส
ควรสื่อถึงการดําเนินของเหตุการณที่นําไปสูเปาหมายที่
แอพพลิเคชั่นนี้แกปญหาใด (เพื่อใคร)? ชัดเจน
ผูใชใชระบบอยางไร (ยูสเคส)? ผูใชทําอะไรกับระบบ? 2. ตั้งชื่อยูสเคส
ชื่อยูสเคสควรอธิบายหนาที่ของยูสเคส
ชื่อยูสเคสควรสื่อวาอะไรจะเกิดขึ้นเมื่อยูสเคสถูกกระทํา
ควรอยูในรูป กริยา หรือ กริยา + นาม
ชื่อควรสือความหมาย และตรงกัน
่
3. อธิบายยูสเคสพอสังเขป (คําอธิบายยูสเคสแบบยอ) โดยใช
คําศัพทที่ผูใชคุนเคย
OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 57 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 58
เขียนคําอธิบายยูสเคส เขียนคําอธิบายยูสเคส
เขียนรายละเอียดใหสมบูรณตามรูปแบบคําอธิบาย เขียนรายละเอียดใหสมบูรณตามรูปแบบคําอธิบาย
ยูสเคส ยูสเคส
เขียนลําดับขันตอนการทํางาน โดยเขียนเปนขอๆ
้ เขียนลําดับขันตอนการทํางาน โดยเขียนเปนขอๆ
้
แบงเปน แบงเปน
Basic course (ลําดับเหตุการณหลัก) หรือ Normal flow Basic course (ลําดับเหตุการณหลัก) หรือ Normal flow
(การดําเนินเหตุการณปกติ) (การดําเนินเหตุการณปกติ)
Subflow (ลําดับเหตุการณยอย)
 Subflow (ลําดับเหตุการณยอย)

Alternative course (ลําดับเหตุการณทางเลือก) หรือ Alternative course (ลําดับเหตุการณทางเลือก) หรือ
Exceptional flow/alternative flow (การดําเนินเหตุการณ Exceptional flow/alternative flow (การดําเนินเหตุการณ
กรณีแตกตาง) กรณีแตกตาง)
OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 59 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 60
15

16. การหา Exceptional flow เขียนคําอธิบายยูสเคส
พิจารณาการกระทําที่ถูกเลือกปฏิบัติ แทนการ ระบุความสัมพันธระหวางยูสเคส
กระทําตามขันตอนใน Normal flow
้ <<include>>
พิจารณาพฤติกรรมทีเกิดขึ้น ในกรณีเกิดสถาวะไม
่ ยูสเคสที่เปนขั้นตอนหนึ่งของหลายยูสเคส
ปกติ (อาจเกิดจากความผิดพลาดของผูใช ความ <<extend>>
ผิดปกติของเครื่อง หรือสภาพแวดลอมอื่นๆ ) ยูสเคสหนึ่งอาจแทรกเขาไปในอีกยูสเคสหนึ่ง
Generalization
ระหวางแอ็บสแตร็กยูสเคส และคอนครีตยูสเคส
OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 61 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 62
การหาความสัมพันธแบบ
การหาความสัมพันธระหวางยูสเคส
extend
1. ความสัมพันธแบบ include 1. พิจารณาแยก Excetional flow ออกมาเปนยูสเคส
พิจารณาการกระทําที่ซ้ํากันในหลายๆ ยูสเคส แลวกําหนดใหยูสเคสใหม extend ยูสเคสเดิม
แยกการกระทํานั้นออกมาเปนยูสเคส แลวกําหนดให 2. พิจารณาสภาวะทีอาจแทรกเขาไปในยูสเคส หรือ
่
ยูสเคสเดิม include ยูสเคสใหม หยุดการทํางานของยูสเคส
2. ความสัมพันธแบบ extend 3. ปรับปรุงยูสเคสไดอะแกรม และคําอธิบายยูสเคส
แยก exceptional flow ที่ซับซอน หรือสําคัญเปน
ยูสเคสใหม
3. ความสัมพันธแบบ generalization
พิจารณาการ inheritance ของยูสเคสและแอคเตอร
OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 63 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 64
16

17. ขอแนะนําในการสรางแบบจําลอง ขอดีของการใชยูสเคสในการ
ยูสเคส พัฒนาซอฟตแวร
1.ใสใจกับยูสเคสที่ไมซบซอนและที่เปนปกติกอน
ั  ชวยในการกําหนดขอบเขต
2.สําหรับทุกขันในยูสเคสใหถามคําถามนี้
้ มักใชในการวางแผนการพัฒนา
มีอะไรผิดพลาดเกิดขึ้นในขั้นนี้ไดบาง? ใชพัฒนาและตรวจสอบความตองการ
ขั้นตอนนี้สามารถทํางานแตกตางไปไดอยางไรบาง? ใชเปนพื้นฐานในการกําหนดกรณีทดสอบ
3.หายูสเคสรวมออกมาจากลําดับเหตุการณรวมและ
 ใชในการวางโครงสรางคูมือผูใช

การใชงานทีเกี่ยวของ และถามีการเพิมยูสเคสใหมที่
่ ่
เฉพาะขึ้นพยายามใชประโยชนจากความสัมพันธ
แบบเอ็กซเทนด (extend)
OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 65 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 66
17