1. System Actors (The “Who”)
-
Primary Actor (User): [e.g., Customer, End-User, Patient] – Initiates the main workflows.
-
Secondary Actor (Admin/Support): [e.g., Manager, System Admin] – Maintains the system and handles edge cases.
-
External Systems: [e.g., Payment Gateway, SMS API] – Third-party services the system interacts with.
2. High-Level Use Case Diagram (Overview)
The system revolves around the following core functional areas:
-
UC-01: [e.g., User Registration / Login]
-
UC-02: [e.g., Perform Main Action – Buy/Book/Create]
-
UC-03: [e.g., Manage Account Settings]
-
UC-04: [e.g., Admin Dashboard / Reporting]
3. Detailed Use Case Specification (The Core Flow)
Here is the deep-dive into the most critical function of the project.
| Element | Description |
|---|---|
| Use Case ID | UC-02 |
| Use Case Name | [e.g., Submit an Order / Create a Task / Transfer Funds] |
| Primary Actor | [End-User Name] |
| Secondary Actors | [Payment Gateway / Database / 3rd Party API] |
| Trigger | The user clicks the “[Main Action]” button. |
| Preconditions | 1. User is authenticated (Logged in). 2. User has sufficient balance/permissions. |
| Postconditions (Success) | 1. Action is saved to the database. 2. Confirmation receipt/email is generated. |
| Basic Flow (Happy Path) | 1. User selects required options (e.g., cart items, dates). 2. User reviews the summary. 3. User confirms the action. 4. System validates the request. 5. System processes payment/action via external API. 6. System displays a “Success” page with a reference number. |
| Alternative/Exception Flows | Alt-1: Insufficient balance → System prompts user to add funds. Alt-2: API timeout → System shows “Service unavailable, try again”. Alt-3: Missing required field → System highlights the missing input in red. |
Concrete Example: “Smart Parking Management System”
Using the template above, here is what the project description looks like for an IoT-based mobile app that lets drivers find and book parking spots.
Project Name: ParkSmart
Objective: To build a mobile app that allows Drivers to find, reserve, and pay for vacant parking spots in real-time, while allowing Administrators to monitor occupancy rates and adjust pricing.
1. System Actors
-
Primary Actor: Registered Driver (uses the mobile app).
-
Secondary Actor: Parking Administrator (uses the web dashboard).
-
External System: IoT Ground Sensors (send occupancy data) & Payment Gateway (Stripe/PayPal).
2. High-Level Use Cases
-
UC-01: View real-time parking map.
-
UC-02: Reserve a parking spot.
-
UC-03: Extend parking session remotely.
-
UC-04: Process automated payment.
-
UC-05: Admin – Generate revenue reports.
3. Detailed Use Case Specification (Core Feature: Reserve Spot)
| Element | Description |
|---|---|
| Use Case ID | UC-02 |
| Use Case Name | Reserve a Parking Spot |
| Primary Actor | Registered Driver |
| Secondary Actors | IoT Sensor System, Payment Gateway |
| Trigger | Driver clicks on an available “Green” spot on the interactive map. |
| Preconditions | 1. Driver is logged in. 2. Driver has a valid payment method linked. 3. The selected spot is marked as ‘Vacant’ by the IoT sensor. |
| Postconditions (Success) | 1. The spot is marked as ‘Reserved’ in the database. 2. The IoT sensor updates to a blinking ‘Reserved’ light. 3. Driver receives a push notification with a 15-minute grace period timer. |
| Basic Flow (Happy Path) | 1. Driver selects a spot on the map. 2. System displays the price per hour for that specific zone. 3. Driver selects a duration (e.g., 2 hours). 4. Driver taps “Reserve Now”. 5. System calculates the total cost. 6. System processes the payment via the Gateway and holds the funds. 7. System sends a digital receipt and unlocks the spot’s barrier (if applicable). |
| Alternative/Exception Flows | Alt-1: Spot gets taken mid-selection → System refreshes the map and notifies the driver: “Spot just taken, showing nearest alternative.” Alt-2: Payment declines → System cancels the hold on the spot and prompts the driver to update their payment method. Alt-3: Driver arrives late (exceeds 15-min grace) → System cancels the reservation, issues a full refund, and releases the spot back to ‘Vacant’. |
4. Additional Use Case Summaries
-
UC-03 (Extend Session): The driver can extend their booking directly from the app without walking back to the meter. The system validates if the new end-time overlaps with another booking and charges the pro-rated difference.
-
UC-05 (Admin Reports): The Admin logs into the dashboard to view heatmaps of busy zones. This use case allows filtering by date/hour to adjust dynamic pricing for high-demand events.
How to use this:
If your project is not a parking app, just swap out the nouns. Replace “Driver” with “Customer,” “Reserve a Spot” with “Place an Order,” and “IoT Sensor” with “Inventory Database.” This structure perfectly serves as both a project description and a functional requirement document for your development team.