บทนำ: ความแตกต่างระหว่าง “Simple Use Case” กับ “Professional Use Case”
ในบทความที่แล้ว เราดู Use Case Diagram แบบพื้นฐาน – วงกลมง่ายๆ และเส้นเชื่อม แต่ในโลก software engineering จริงๆ การออกแบบ use case ต้อง:
- ลึกลงไป – รายละเอียดทุกขั้นตอน
- ครอบคลุม – cover edge cases และ exceptions
- ชัดเจน – เพื่อให้ developer เข้าใจตรงกับ requirement
- วัดได้ – สามารถ test ได้
Use Case Engineering = ศิลปะและวิทยาศาสตร์ของการเขียน use cases ที่ มีประสิทธิภาพ, ครบถ้วน, และวัดได้
หลักการพื้นฐานของ Use Case Engineering
1. Actor ต้องชัดเจน: “ใครจริงๆ?”
Actor ไม่ใช่แค่ “คน” – อาจเป็น:
- Human Actor – ผู้ใช้จริง (Customer, Admin, Librarian)
- System Actor – ระบบอื่น (PaymentGateway, EmailService, ExternalAPI)
- Time Actor – เหตุการณ์ที่เกิดตามเวลา (Scheduler, Timer)
ตัวอย่างที่ 1: ระบุ Actors อย่างแม่นยำ
text❌ ไม่ชัดเจน:
- Actor: "User"
(User คือใครกันแน่? Admin? Customer? Vendor?)
✓ ชัดเจน:
- Actor: "Registered Customer"
(ผู้ซื้อที่ลงทะเบียนแล้ว)
- Actor: "Payment Gateway System"
(ระบบภายนอกที่ประมวลผลชำระเงิน)
- Actor: "System Clock"
(Event ที่เกิดตามเวลา เพื่อส่ง reminder)
2. Goal ต้องจากมุมมอง Actor
Goal คือ “ผลลัพธ์ที่ Actor ต้องการได้รับ” – ไม่ใช่สิ่งที่ระบบต้องทำ
text❌ ไม่ดี (มุมมองระบบ):
- Use Case: "Process Payment"
Goal: ระบบต้องเช็ค balance และ deduct amount
✓ ดี (มุมมอง Actor):
- Use Case: "Purchase Items"
Goal: Customer ต้องการซื้อสินค้า โดยชำระเงินสำเร็จ
ขั้นตอนการออกแบบ Use Case แบบเป็นระบบ
Step 1: Identify Actors and Goals
วิธีการ:
- ถามตัวเอง: “ใครจะใช้ระบบ?”
- ถามแต่ละ actor: “ตัวท่านต้องการอะไรจากระบบ?”
- ระบุ goals ทั้งหมด
ตัวอย่างที่ 2: E-Commerce System – Actors and Goals
text┌─────────────────────────────────────────────────┐
│ ACTORS AND GOALS ANALYSIS │
├─────────────────────────────────────────────────┤
│ │
│ Actor: Registered Customer │
│ Goals: │
│ 1. Browse and search for products │
│ 2. Add products to shopping cart │
│ 3. View cart and modify items │
│ 4. Proceed to checkout │
│ 5. Complete payment transaction │
│ 6. View order history │
│ 7. Track order status │
│ 8. Return/exchange products │
│ │
├─────────────────────────────────────────────────┤
│ Actor: System Administrator │
│ Goals: │
│ 1. Add new products to catalog │
│ 2. Update product information │
│ 3. Manage inventory levels │
│ 4. View sales reports │
│ 5. Manage customer accounts │
│ 6. Handle customer complaints │
│ 7. Configure system settings │
│ 8. Generate financial reports │
│ │
├─────────────────────────────────────────────────┤
│ Actor: Payment Gateway (System Actor) │
│ Goals: │
│ 1. Authorize payment transactions │
│ 2. Decline invalid transactions │
│ 3. Send transaction confirmation │
│ 4. Handle refunds │
│ │
├─────────────────────────────────────────────────┤
│ Actor: Email Service (System Actor) │
│ Goals: │
│ 1. Send order confirmation │
│ 2. Send shipping notification │
│ 3. Send delivery notification │
│ 4. Send promotional emails │
│ │
└─────────────────────────────────────────────────┘
Step 2: Write Detailed Use Case Specifications
ส่วนประกอบของ Use Case Specification:
text1. USE CASE ID & NAME
2. ACTOR(S)
3. PRECONDITION(S)
4. MAIN SUCCESS SCENARIO (Happy Path)
5. ALTERNATIVE FLOW(S)
6. EXCEPTION FLOW(S)
7. POSTCONDITION(S)
8. NON-FUNCTIONAL REQUIREMENTS
9. NOTES & ISSUES
ตัวอย่างที่ 3: Detailed Use Case – Online Purchase
text┌────────────────────────────────────────────────────┐
│ USE CASE: UC-004 - Complete Online Purchase │
├────────────────────────────────────────────────────┤
│ │
│ USE CASE ID: UC-004 │
│ USE CASE NAME: Complete Online Purchase │
│ │
├────────────────────────────────────────────────────┤
│ ACTOR(S): │
│ Primary: Registered Customer │
│ Secondary: Payment Gateway System │
│ Inventory System │
│ Email Service │
│ │
├────────────────────────────────────────────────────┤
│ PRECONDITION(S): │
│ 1. Customer is logged into the system │
│ 2. Customer has at least one item in cart │
│ 3. System is operational │
│ 4. Payment Gateway is available │
│ 5. Product stock is available │
│ │
├────────────────────────────────────────────────────┤
│ MAIN SUCCESS SCENARIO (Happy Path): │
│ │
│ 1. Customer selects "Proceed to Checkout" │
│ 2. System displays order summary │
│ - List of items in cart │
│ - Quantities and prices │
│ - Subtotal, taxes, shipping │
│ - Grand total │
│ │
│ 3. Customer reviews shipping address │
│ (Uses existing address or enters new) │
│ │
│ 4. System validates shipping address │
│ - Format check │
│ - Postal code validation │
│ - Service area check │
│ │
│ 5. Customer selects shipping method │
│ - Standard (3-5 days) │
│ - Express (1-2 days) │
│ - Overnight │
│ │
│ 6. System updates shipping cost │
│ - Recalculates total │
│ - Shows delivery date estimate │
│ │
│ 7. Customer selects payment method │
│ - Credit/Debit card │
│ - Digital wallet │
│ - Bank transfer │
│ │
│ 8. Customer enters payment information │
│ (Depending on selected method) │
│ │
│ 9. System validates payment details │
│ - Credit card format │
│ - Expiration date │
│ - CVV │
│ │
│ 10. System submits payment to Payment Gateway │
│ │
│ 11. Payment Gateway authorizes transaction │
│ - Validates with bank │
│ - Checks funds availability │
│ - Returns authorization code │
│ │
│ 12. System receives payment confirmation │
│ │
│ 13. System reserves inventory │
│ - Reduces stock levels │
│ - Locks items from other orders │
│ │
│ 14. System creates order record │
│ - Assigns order number │
│ - Records timestamp │
│ - Sets status to "Confirmed" │
│ │
│ 15. System sends confirmation email │
│ - Order details │
│ - Itemized receipt │
│ - Tracking information (when shipped) │
│ - Return policy information │
│ │
│ 16. System displays order confirmation page │
│ - Order number │
│ - Estimated delivery date │
│ - "Track Order" button │
│ - "Continue Shopping" button │
│ │
│ 17. Use case ends successfully │
│ │
├────────────────────────────────────────────────────┤
│ ALTERNATIVE FLOW(S): │
│ │
│ ALTERNATIVE 3A: Customer Uses New Address │
│ At Step 3: │
│ 3A.1 Customer selects "Enter New Address" │
│ 3A.2 System displays address form │
│ 3A.3 Customer enters address details │
│ 3A.4 System validates format │
│ 3A.5 Continue from Step 4 of main flow │
│ │
│ ALTERNATIVE 5A: Customer Uses Different │
│ Shipping Method │
│ At Step 5: │
│ 5A.1 Customer selects different shipping │
│ 5A.2 Continue from Step 6 of main flow │
│ (No additional steps needed) │
│ │
│ ALTERNATIVE 7A: Customer Uses Saved Payment │
│ At Step 7: │
│ 7A.1 Customer selects "Use Saved Card" │
│ 7A.2 System displays saved payment methods │
│ 7A.3 Customer selects one │
│ 7A.4 Skip to Step 10 (already validated) │
│ │
├────────────────────────────────────────────────────┤
│ EXCEPTION FLOW(S): │
│ │
│ EXCEPTION 4A: Address Validation Fails │
│ At Step 4: │
│ 4A.1 System detects invalid address │
│ 4A.2 System displays error message │
│ "Please enter a valid address" │
│ 4A.3 System highlights problematic fields │
│ 4A.4 Customer corrects address │
│ 4A.5 Return to Step 4 (Retry) │
│ │
│ EXCEPTION 9B: Invalid Payment Details │
│ At Step 9: │
│ 9B.1 System detects invalid payment info │
│ 9B.2 System displays error │
│ (e.g., "Invalid card number") │
│ 9B.3 Highlight incorrect field │
│ 9B.4 Customer re-enters information │
│ 9B.5 Return to Step 9 (Retry) │
│ 9B.6 Allow max 3 retry attempts │
│ (After 3 failures, terminate checkout) │
│ │
│ EXCEPTION 11C: Payment Authorization Fails │
│ At Step 11: │
│ 11C.1 Payment Gateway declines transaction │
│ 11C.2 System receives error code │
│ (Insufficient funds / Card expired / │
│ Fraud suspected / Other) │
│ 11C.3 System displays customer-friendly message: │
│ "Payment declined. Please verify your │
│ card details or try another payment │
│ method" │
│ 11C.4 System offers options: │
│ - Try different card │
│ - Try different payment method │
│ - Contact support │
│ 11C.5 If customer retries: Go back to Step 7 │
│ 11C.6 If customer contacts support: Terminate │
│ use case and note for support team │
│ │
│ EXCEPTION 13D: Inventory Not Available │
│ At Step 13: │
│ 13D.1 Another order claimed last items │
│ 13D.2 System cannot reserve all items │
│ 13D.3 System notifies customer: │
│ "Some items are no longer in stock" │
│ 13D.4 System offers options: │
│ - Remove out-of-stock items │
│ - Wait for restock notification │
│ - Cancel entire order │
│ 13D.5 Depending on choice: │
│ - If remove: Recalculate total, │
│ go back to Step 10 │
│ - If cancel: Rollback payment, │
│ terminate use case │
│ │
│ EXCEPTION 11E: Payment Gateway Timeout │
│ At Step 11: │
│ 11E.1 Payment Gateway doesn't respond │
│ within 30 seconds │
│ 11E.2 System displays message: │
│ "Payment service temporarily unavailable" │
│ 11E.3 System offers options: │
│ - Retry payment │
│ - Try later │
│ - Contact support │
│ 11E.4 Store partial data for retry │
│ │
├────────────────────────────────────────────────────┤
│ POSTCONDITION(S): │
│ Success: Order created, inventory reserved, │
│ payment processed, confirmation sent │
│ │
│ Failure: Order not created, payment not charged, │
│ customer notified, inventory unchanged │
│ │
├────────────────────────────────────────────────────┤
│ NON-FUNCTIONAL REQUIREMENTS: │
│ - Payment processing < 10 seconds │
│ - Email sent within 5 minutes │
│ - System availability: 99.9% │
│ - Payment data: encrypted (PCI-DSS compliant) │
│ - Support multiple payment methods │
│ - Support multiple currencies │
│ - Accessible to users with disabilities (WCAG) │
│ │
├────────────────────────────────────────────────────┤
│ NOTES & ISSUES: │
│ - Consider cart expiration (30 min timeout) │
│ - Handle race conditions (2+ users same item) │
│ - Integrate with tax calculation service │
│ - Consider fraud detection integration │
│ - Need to handle order modifications (within │
│ certain time window after placement) │
│ - Support for gift messages? │
│ - Subscription/recurring billing? │
│ │
└────────────────────────────────────────────────────┘
Step 3: Identify Alternative and Exception Flows
ความแตกต่าง:
| Alternative Flow | Exception Flow | |
|---|---|---|
| ธรรมชาติ | ผู้ใช้ทำอะไรแบบต่างไป | สิ่งผิดพลาดเกิดขึ้น |
| ตัวอย่าง | “Use saved card” | “Card declined” |
| ผลลัพธ์ | ยังสำเร็จได้ | ต้องจัดการ |
| ความถี่ | ค่อนข้างบ่อย | หาก lucky, rare |
ตัวอย่างที่ 4: Library System Use Case
text┌────────────────────────────────────────────────────┐
│ USE CASE: UC-002 - Borrow Book │
├────────────────────────────────────────────────────┤
│ │
│ ACTOR(S): │
│ Primary: Library Member │
│ Secondary: Librarian, Book System │
│ │
├────────────────────────────────────────────────────┤
│ PRECONDITION(S): │
│ 1. Member is registered and in good standing │
│ 2. Member has valid library card │
│ 3. Book is in stock │
│ 4. Member's account is not blocked │
│ │
├────────────────────────────────────────────────────┤
│ MAIN SUCCESS SCENARIO: │
│ │
│ 1. Member presents library card to Librarian │
│ 2. Member indicates which book(s) to borrow │
│ 3. Librarian scans library card │
│ 4. System retrieves member profile │
│ 5. Librarian scans each book's barcode │
│ 6. System checks: │
│ - Book availability │
│ - Member's borrow limit │
│ - Member's outstanding fines │
│ 7. System calculates due date │
│ (14 days from today, or member preference) │
│ 8. System records loan transaction │
│ 9. Librarian prints receipt │
│ 10. Member receives books and receipt │
│ │
├────────────────────────────────────────────────────┤
│ ALTERNATIVE 2A: Multiple Books │
│ At Step 2: │
│ 2A.1 Member provides list of multiple books │
│ 2A.2 Continue from Step 3, process all books │
│ (No additional complexity) │
│ │
│ ALTERNATIVE 6B: Member Is New │
│ At Step 4: │
│ 6B.1 System indicates "New Member" │
│ 6B.2 System sets first-time warning │
│ 6B.3 Continue normally │
│ (Librarian may explain policies verbally) │
│ │
├────────────────────────────────────────────────────┤
│ EXCEPTION 5C: Book Barcode Unreadable │
│ At Step 5: │
│ 5C.1 Scanner cannot read barcode │
│ 5C.2 Librarian manually enters ISBN/ID │
│ 5C.3 System locates book record │
│ 5C.4 Continue from Step 6 │
│ │
│ EXCEPTION 6D: Member Already at Borrow Limit │
│ At Step 6: │
│ 6D.1 System detects member has 5 books already │
│ (if limit is 5) │
│ 6D.2 System displays warning │
│ 6D.3 Librarian informs member │
│ 6D.4 Member options: │
│ - Return one book first, then retry │
│ - Request extension (if available) │
│ - Cancel borrow │
│ 6D.5 Terminate use case (if no return) │
│ 6D.6 If member returns a book: │
│ Return to Step 3 │
│ │
│ EXCEPTION 6E: Member Has Outstanding Fines │
│ At Step 6: │
│ 6E.1 System detects unpaid fine(s) │
│ 6E.2 System displays fine amount │
│ 6E.3 Librarian informs member │
│ 6E.4 Member options: │
│ - Pay fine first (via payment system) │
│ - Cancel borrow │
│ 6E.5 If member pays: │
│ Return to Step 3 after payment │
│ 6E.6 If member cancels: │
│ Terminate use case │
│ │
│ EXCEPTION 3F: Member Card Not Found │
│ At Step 3: │
│ 3F.1 System cannot find matching card │
│ 3F.2 Librarian tries again │
│ 3F.3 If still fails: │
│ - Librarian manually searches member │
│ - Using photo ID or name │
│ 3F.4 If member found: │
│ Return to Step 4 │
│ 3F.5 If member not found: │
│ "New member registration" process │
│ (Different use case) │
│ │
└────────────────────────────────────────────────────┘
Step 4: Define Non-Functional Requirements
ตัวอย่างที่ 5: NFRs ที่สำคัญ
text┌────────────────────────────────────────────────────┐
│ NON-FUNCTIONAL REQUIREMENTS (NFRs) │
├────────────────────────────────────────────────────┤
│ │
│ PERFORMANCE: │
│ - Book search must complete within 2 seconds │
│ - Barcode scan processing < 1 second │
│ - Receipt printing < 30 seconds │
│ │
│ AVAILABILITY: │
│ - System must be available 24/7 except │
│ scheduled maintenance (max 2 hours/month) │
│ - Planned maintenance: 2-4 AM │
│ │
│ RELIABILITY: │
│ - 99.9% uptime │
│ - Transaction must not be lost │
│ - System recovery time: < 30 minutes │
│ │
│ SECURITY: │
│ - Member card number encrypted (AES-256) │
│ - All transactions logged for audit │
│ - Staff access controlled by role │
│ - Password: min 8 chars, alphanumeric + special │
│ │
│ USABILITY: │
│ - All operations completable by novice user │
│ - Barcode scanner preferred over manual entry │
│ - Clear error messages in library's language │
│ - Receipt must be human-readable │
│ │
│ CAPACITY: │
│ - Support 100,000+ library members │
│ - Handle 1000+ transactions/day │
│ - Database: up to 50,000 books │
│ │
│ INTEROPERABILITY: │
│ - Work with standard barcode scanners │
│ - Compatible with Windows 7+, macOS 10.12+ │
│ - Support multiple printer models │
│ │
│ COMPLIANCE: │
│ - GDPR compliant (member privacy) │
│ - Accessibility: WCAG 2.1 AA │
│ - Legal: comply with local library laws │
│ │
│ MAINTAINABILITY: │
│ - Code documentation required │
│ - Unit tests: >= 80% coverage │
│ - Log rotation: daily, keep 30 days │
│ │
└────────────────────────────────────────────────────┘
Step 5: Create Use Case Relationships Map
ตัวอย่างที่ 6: Use Case Relationships
text┌──────────────────────────────────────────────────────┐
│ ONLINE SHOPPING SYSTEM - USE CASE RELATIONSHIPS │
├──────────────────────────────────────────────────────┤
│ │
│ UC-001: Browse Products │
│ └─ NO dependencies │
│ │
│ UC-002: Add to Cart │
│ └─ REQUIRES: UC-001 (already browsing) │
│ │
│ UC-003: View Cart │
│ └─ REQUIRES: UC-002 (cart has items) │
│ │
│ UC-004: Complete Purchase │
│ ├─ REQUIRES: UC-003 (view cart first) │
│ ├─ INCLUDES: UC-005 (payment processing) │
│ ├─ INCLUDES: UC-006 (shipping calculation) │
│ └─ EXTENDS: UC-007 (apply coupon) [optional] │
│ │
│ UC-005: Process Payment │
│ ├─ REQUIRES: UC-004 (part of purchase) │
│ └─ INTERACTS WITH: External Payment Gateway │
│ │
│ UC-006: Calculate Shipping │
│ ├─ REQUIRES: UC-004 (part of purchase) │
│ ├─ USES: Address validation service │
│ └─ USES: Shipping provider API │
│ │
│ UC-007: Apply Coupon Code │
│ ├─ EXTENDS: UC-004 (optional discount) │
│ ├─ USES: Coupon validation service │
│ └─ UPDATES: Order total │
│ │
│ UC-008: Track Order │
│ └─ REQUIRES: UC-004 (must have placed order) │
│ │
│ UC-009: Return Product │
│ ├─ REQUIRES: UC-004 (must have purchased) │
│ ├─ INCLUDES: UC-010 (process refund) │
│ └─ UPDATES: Inventory │
│ │
│ UC-010: Process Refund │
│ ├─ REQUIRES: UC-009 (part of return) │
│ └─ INTERACTS WITH: Payment Gateway │
│ │
│ UC-011: Manage Inventory (Admin) │
│ ├─ NO dependencies │
│ ├─ UPDATES: Product catalog │
│ └─ AFFECTS: UC-002 (product availability) │
│ │
└──────────────────────────────────────────────────────┘
Best Practices: Use Case Engineering
Checklist สำหรับ Use Case ที่ดี
text☐ SCOPE & BOUNDARIES:
☐ Use case is within system boundary
☐ Use case is not too small (atomic level)
☐ Use case is not too large (can complete in 5-15 min)
☐ ACTORS:
☐ Primary actor clearly identified
☐ Secondary actors listed
☐ System actors specified
☐ PRECONDITIONS:
☐ All prerequisites listed
☐ System state is clear
☐ User state is clear
☐ MAIN FLOW:
☐ Happy path (successful scenario) is clear
☐ Steps are sequential
☐ Each step is atomic
☐ Language is clear, simple
☐ ALTERNATIVE FLOWS:
☐ Different user choices covered
☐ Identified and numbered clearly
☐ Not too many (3-5 is typical)
☐ EXCEPTION FLOWS:
☐ Error scenarios identified
☐ Recovery mechanisms clear
☐ User is informed of issues
☐ Not too many (3-5 is typical)
☐ POSTCONDITIONS:
☐ Success postcondition defined
☐ Failure postcondition defined
☐ System state after use case is clear
☐ NON-FUNCTIONAL REQUIREMENTS:
☐ Performance requirements specified
☐ Security requirements specified
☐ Usability requirements specified
☐ Compliance requirements specified
☐ TRACEABILITY:
☐ Linked to requirements
☐ Linked to user stories
☐ Linked to other use cases
☐ Can be traced to test cases
Pitfalls ที่ต้องหลีกเลี่ยง
text❌ COMMON MISTAKES:
1. Use Case Too Vague:
❌ "Process order"
✓ "Customer completes purchase by selecting
shipping method, payment, and confirming order"
2. Missing Alternative Flows:
❌ Only happy path
✓ Include "User uses saved credit card"
"User enters new address", etc.
3. Missing Exception Handling:
❌ Assume everything works
✓ Include "Payment declined", "Inventory not available"
4. Wrong Level of Abstraction:
❌ Too low: "Click submit button"
✓ Right level: "Customer submits payment information"
5. Including Technology Details:
❌ "System opens database connection..."
✓ "System validates payment information"
6. Ambiguous Actor Roles:
❌ Actor: "User"
✓ Actor: "Logged-in Premium Customer"
7. Forgetting Non-Functional Requirements:
❌ No performance requirements
✓ "Payment processing must complete within 10 seconds"
8. Use Cases That Are Too Long:
❌ 30+ steps in main flow
✓ Break into multiple use cases
9. Lack of Connection to Requirements:
❌ Use cases created independently
✓ Each use case traces to business requirement
ตัวอย่างที่ 7: Complete Use Case Document
E-Learning Platform: Enroll in Course
text┌────────────────────────────────────────────────────┐
│ USE CASE SPECIFICATION │
├────────────────────────────────────────────────────┤
│ │
│ USE CASE ID: UC-E-005 │
│ USE CASE NAME: Enroll in Course │
│ VERSION: 1.0 │
│ LAST UPDATED: 2025-11-06 │
│ AUTHOR: Course Admin Team │
│ │
├────────────────────────────────────────────────────┤
│ BRIEF DESCRIPTION: │
│ A student searches for and enrolls in a course, │
│ potentially using a discount code, and gains │
│ access to course materials. │
│ │
├────────────────────────────────────────────────────┤
│ ACTOR(S): │
│ Primary: Student (logged-in user) │
│ Secondary: Payment System │
│ Notification Service │
│ Course Catalog System │
│ │
├────────────────────────────────────────────────────┤
│ STAKEHOLDERS & INTERESTS: │
│ - Student: Access course materials, learn │
│ - Instructor: Track enrollment, student progress │
│ - Administrator: Monitor course capacity │
│ - Finance: Track revenue from enrollments │
│ │
├────────────────────────────────────────────────────┤
│ TRIGGER: │
│ Student clicks "Enroll" button on course page │
│ │
├────────────────────────────────────────────────────┤
│ PRECONDITION(S): │
│ 1. Student is logged into the platform │
│ 2. Student has payment method on file │
│ 3. Course exists and is open for enrollment │
│ 4. Course has available seats (if limited) │
│ 5. Student hasn't already enrolled in course │
│ 6. Student meets course prerequisites (if any) │
│ 7. Payment system is operational │
│ │
├────────────────────────────────────────────────────┤
│ MAIN SUCCESS SCENARIO: │
│ │
│ 1. System displays course details │
│ - Name, description, instructor │
│ - Price, duration │
│ - Prerequisite courses │
│ - Start date │
│ │
│ 2. System verifies student prerequisites │
│ - Queries student's course history │
│ - Checks completion status │
│ │
│ 3. System shows enrollment options: │
│ - Full price │
│ - "Have a coupon?" option │
│ │
│ 4. Student confirms enrollment intent │
│ │
│ 5. System initiates payment process │
│ (Use existing saved method) │
│ │
│ 6. Payment System charges student │
│ - Processes payment │
│ - Returns transaction ID │
│ │
│ 7. System receives payment confirmation │
│ │
│ 8. System creates enrollment record │
│ - Links student to course │
│ - Sets start date │
│ - Records enrollment timestamp │
│ - Sets initial progress = 0% │
│ │
│ 9. System grants course access │
│ - Enables course materials │
│ - Adds to student's "My Courses" │
│ - Notifies instructor of enrollment │
│ │
│ 10. Notification Service sends email │
│ - Enrollment confirmation │
│ - Course access details │
│ - Getting started guide │
│ │
│ 11. System displays success page │
│ - Confirmation message │
│ - "Go to Course" button │
│ - "My Courses" link │
│ │
│ 12. Use case ends successfully │
│ │
├────────────────────────────────────────────────────┤
│ ALTERNATIVE FLOWS: │
│ │
│ ALT-3A: Student Uses Coupon Code │
│ At Step 3: │
│ 3A.1 Student selects "Have a coupon?" │
│ 3A.2 System displays coupon entry field │
│ 3A.3 Student enters coupon code │
│ 3A.4 System validates coupon: │
│ - Format valid │
│ - Not expired │
│ - Applicable to this course │
│ - Student hasn't used it before │
│ 3A.5 System calculates discount │
│ - Shows original price │
│ - Shows discount amount │
│ - Shows new total │
│ 3A.6 Student confirms enrollment │
│ 3A.7 Continue from Step 5 (with new total) │
│ │
│ ALT-5B: Student Uses Different Payment Method │
│ At Step 5: │
│ 5B.1 System offers payment options │
│ 5B.2 Student selects different method │
│ - Add new card │
│ - PayPal │
│ - Digital wallet │
│ 5B.3 Student enters payment details │
│ 5B.4 Continue from Step 6 │
│ │
│ ALT-4C: Enrollment with Installment Plan │
│ At Step 4: │
│ 4C.1 System offers payment plans: │
│ - Pay in full │
│ - 3 installments │
│ - 6 installments │
│ 4C.2 Student selects installment option │
│ 4C.3 System displays installment schedule │
│ 4C.4 Student confirms │
│ 4C.5 Continue from Step 5 │
│ │
├────────────────────────────────────────────────────┤
│ EXCEPTION FLOWS: │
│ │
│ EXC-2A: Student Missing Prerequisites │
│ At Step 2: │
│ 2A.1 System detects missing prerequisites │
│ 2A.2 System displays message: │
│ "You must complete X and Y first" │
│ 2A.3 System offers options: │
│ - Enroll in prerequisites first │
│ - Request instructor waiver │
│ 2A.4 Terminate use case or │
│ Redirect to waiver request process │
│ │
│ EXC-6B: Payment Declined │
│ At Step 6: │
│ 6B.1 Payment System declines transaction │
│ 6B.2 System displays error message: │
│ "Payment could not be processed" │
│ 6B.3 System offers options: │
│ - Retry with same method │
│ - Use different payment method │
│ - Contact support │
│ 6B.4 If retry: Return to Step 6 │
│ 6B.5 If different method: Go to ALT-5B │
│ 6B.6 If contact support: Terminate, │
│ create support ticket │
│ │
│ EXC-8C: Course at Capacity │
│ At Step 8: │
│ 8C.1 System detects course is full │
│ 8C.2 System displays message: │
│ "This course is at capacity" │
│ 8C.3 System offers waitlist option │
│ 8C.4 If accepted to waitlist: │
│ - Add student to waitlist │
│ - Send confirmation │
│ - Terminate use case │
│ 8C.5 If declined: │
│ - Suggest similar courses │
│ - Terminate use case │
│ │
│ EXC-5D: Payment System Timeout │
│ At Step 5: │
│ 5D.1 Payment System doesn't respond │
│ 5D.2 System displays message: │
│ "Payment service temporarily unavailable" │
│ 5D.3 System offers options: │
│ - Retry │
│ - Try later │
│ 5D.4 Store enrollment intent for later │
│ 5D.5 Send notification when available │
│ │
├────────────────────────────────────────────────────┤
│ POSTCONDITION(S): │
│ │
│ Success: │
│ - Enrollment record created │
│ - Payment processed │
│ - Student has access to course │
│ - Instructor notified │
│ - Confirmation email sent │
│ - Course appears in "My Courses" │
│ │
│ Failure: │
│ - Enrollment not created │
│ - Payment not charged │
│ - Student not enrolled │
│ - Support ticket created (if needed) │
│ │
├────────────────────────────────────────────────────┤
│ NON-FUNCTIONAL REQUIREMENTS: │
│ │
│ PERFORMANCE: │
│ - Coupon validation: < 2 seconds │
│ - Payment processing: < 10 seconds │
│ - Enrollment confirmation: < 1 second │
│ - Access granted: < 5 seconds │
│ │
│ AVAILABILITY: │
│ - 99.9% uptime during business hours │
│ - Graceful degradation if payment system down │
│ │
│ SECURITY: │
│ - Payment data: PCI-DSS compliant │
│ - Prevent duplicate enrollments │
│ - Audit log all transactions │
│ │
│ RELIABILITY: │
│ - No lost transactions │
│ - Retry logic for failed payments │
│ - Database consistency maintained │
│ │
│ USABILITY: │
│ - Clear pricing display │
│ - Simple coupon application │
│ - Clear error messages │
│ - Immediate access after payment │
│ │
│ COMPLIANCE: │
│ - GDPR compliant (payment data) │
│ - Refund policy clearly stated │
│ - Tax calculations correct │
│ │
├────────────────────────────────────────────────────┤
│ NOTES & ISSUES: │
│ │
│ - Consider auto-retry for failed payments │
│ - Implement fraud detection │
│ - Handle multi-currency payments │
│ - Consider group/team enrollments │
│ - Think about partial refunds │
│ - What if course is cancelled after enrollment? │
│ - What about transfer between students? │
│ - Need analytics on drop rates │
│ │
│ DEPENDENCIES: │
│ - Payment Gateway API │
│ - Notification Service │
│ - Course Catalog Service │
│ - Student Profile Service │
│ │
│ REFERENCES: │
│ - Business Requirement: BR-001-Enrollment │
│ - User Story: US-005-Student-Enrollment │
│ - Related Use Cases: UC-E-001, UC-E-002 │
│ │
└────────────────────────────────────────────────────┘
สรุป
การออกแบบ Use Case ตามหลัก Software Engineering ไม่ใช่แค่วาดวงกลมกับเส้น แต่เป็น:
- ระบบที่กระบบ – มี structure ชัดเจน
- ครอบคลุม – cover ทุกสถานการณ์ (happy path, alternatives, exceptions)
- ละเอียด – อธิบายทุกขั้นตอนแบบ step-by-step
- วัดได้ – สามารถทำ test cases จากนั้นได้
- เชื่อมต่อถึง requirement – trace ได้ว่ามาจากไหน
เมื่อใช้ Use Case Engineering อย่างถูกต้อง ทีมจะ:
- เข้าใจตรงกัน – developer, tester, business ต่างพูดภาษาเดียวกัน
- ลดปัญหา – หา edge cases ตั้งแต่ออกแบบ ก่อน code
- ทำ test ได้ดี – test cases มาจาก use case directly
- ดูแลรักษางาย – documentation ชัดเจน ให้คนใหม่เข้าใจได้เร็ว
Use Case ที่เขียนดีคือ สะพาน ที่เชื่อมระหว่าง ความต้องการทางธุรกิจ กับ ความต้องการของระบบ ให้ทุกฝ่ายทำงานไปในทิศทางเดียวกัน