- Table of contents
- User Stories and Use Cases
User Stories and Use Cases¶
Resources¶
- Use Cases & User Stories templates are available here - Templates and Forms
- Grading rubric available on the Tasks and Due Dates page
Important Note: The "User" in User Stories and Use Cases can be a person or other system that interacts with the device in question.¶
Engineering Definition¶
User Stories and Use Cases are two essential techniques for gathering and documenting project requirements.
| User Stories | Use Cases | |
|---|---|---|
| Definition | A short, simple description of a feature told from the perspective of the user. | A detailed description of the interactions between a user and the system. |
| Purpose | Capture user needs and expectations in a simple format. | Describe step-by-step functional behavior of a system in different scenarios. |
| Scope | Narrow; generally one feature or need | Broader; can describe multiple scenarios and alternative paths |
| Format | One-liner with goal and reason | Structured narrative with flows and exceptions |
| Focus | What the user wants | How the system behaves, includes how the system and user interact |
User Stories (Format and Examples)¶
Format: As a <type of user>, I want <a goal> so that <reason>.
Example 1: E-commerce Platform
User Story: As a shopper , I want to filter products by price range so that I can quickly find items within my budget.
Discovery Questions:
1. What is the default price range shown to the user (e.g., full range, popular range)?
2. Should the price filter use a slider, input fields, preset ranges, or a combination?
3. When should the filter apply — instantly as the user changes it, or only after clicking a “Filter” button?
4. What is the minimum and maximum price allowed in the filter?
5. What should happen if no products match the selected price range?
6. Should the filter be reset after the user performs a new search?
Acceptance Criteria:
Example 2: Flight Booking System1. The filter shows the full product price range by default (e.g., $0 to $1000).
2. The interface includes a slider for intuitive adjustments and input fields for precise values. Optional preset ranges (e.g., “Under $50”, “$50–$100”, etc.) are provided for quick filtering.
3. Filtering is triggered only after the user clicks the “Filter” button. A “Clear” to remove applied filters.
4. Users can input any price within a system-defined boundary (e.g., $0 to $10,000).
5. The system pops up a warning message.
6. The price filter persists when a user enters a new search term.
User Story: As a traveler, I want to receive email confirmation after booking so that I have a record of my flight details.
| No. | Discovery Question | Acceptance Criteria |
|---|---|---|
| 1 | What information should be included in the confirmation email? | Email must include traveler’s name, booking reference, flight details (numbers, airports, times), seat info, price paid, and support contact. |
| 2 | When should the confirmation email be sent—immediately after booking or with a delay? | Email is sent within 1 minute of successful booking. |
| 3 | What happens if the user enters an invalid or unreachable email address? | Email format is validated before submission. Failed deliveries are logged. |
| 4 | Should users receive a copy of the confirmation on other channels (e.g., SMS, app)? | Optional SMS or in-app notifications may be sent (if enabled), but email is always the primary and mandatory confirmation channel. |
| 5 | Should users be able to resend or retrieve their confirmation email later? | Users can log in and resend the email from booking history, available up to 1 year after the booking date. |
User Story: As a engineer, I want to view real-time data from the sensors on a dashboard so that I can monitor and react quickly to issues.
| No. | Discovery Question | Acceptance Criteria |
|---|---|---|
| 1 | What types of sensor data need to be displayed on the dashboard? | List of data that are needed to be displayed on the Dashboard (e.g., temperature, pressure, flow) |
| 2 | How frequently should the dashboard update with new sensor data? | Information in dashboard updated every 30 seconds automatically |
| 3 | What visualizations or formats should be used to present the data? | Line graphs for sensor data, pie chart for consolidated information - color coded with details. |
| 4 | Should the dashboard provide alerts or notifications for abnormal readings? | Alerts are triggered in real-time when sensor values cross predefined thresholds. - with visible or audible notifications. |
| 5 | What happens if sensor data is temporarily unavailable or delayed? | The dashboard indicates data alert message with 3 mins of no data from the sensor and also last known value with time stamp. |
Detailed User Stories example for Passive Cooling Device for Medical Supplies: export:/Examples/Detailed User Stories Example for Passive Cooling Device for medical supplies.pdf
Additional Examples for User Stories
Example 4: Bottleneck Detection
As a production supervisor, I want the system to automatically identify process bottlenecks from the data so that I can address delays and improve throughput.
Example 5: Historical Data Analysis
As a production supervisor, I want to analyze production data over the past month so that I can identify trends that lead to equipment failure.
Example 6: Alert Notification
As an engineer, I want to receive alerts when the system operates outside of standard parameters so that I can respond before breakdowns occur.
Use Cases (Format and examples)¶
Format:
1. Title: Name of the use case
2. Primary User: Who (or what) is using the system
3. Goal: What the primary user wants to achieve
4. Preconditions: What must be true before the use case starts
5. Main Success Scenario (Flow): Step-by-step of what happens
6. Extensions / Alternate flows: What happens if something goes wrong
Use Case 1: Monitor Real-time Production Data
• Title: Monitor Real-time Production Data
• Primary User: Process Engineer
• Goal: To view real-time metrics of each manufacturing stage
• Preconditions: Software can acquire data from the sensors / data sources.
• Main Success Scenario (Flow):1.Engineer logs into the system
2.System fetches current data from the sensors / data sources
3.Engineer sees a dashboard of live performance metrics and graphs
4.Data is updated every 10 seconds• Extensions / Alternate flows: If a data source is offline, system shows a warning.
Use Case 2: Identify Bottlenecks in Production
• Title: Identify Bottlenecks in Production
• Primary User: Production Supervisor
• Goal: To detect stages in the process that limit overall throughput
• Preconditions: Historical and real-time data from each station is available
• Main Success Scenario (Flow):1. Manager selects a production line and time range
2. System analyzes cycle times, buffer levels, and queue durations
3. System highlights the station(s) with the highest delay and lowest efficiency
4. Bottlenecks are shown visually with color-coded charts• Extensions / Alternate flows: Provide options to detailed information on the stations with bottlenecks.
Submission¶
Use Case and User Stories documents should be committed to the Repository - /working/Engineering Analysis