1.4.2.1. Tasks

Phase 1: Elicit Requirements

Tasks:

• Identify stakeholders (e.g., customers, store staff, delivery team, admin)
• Conduct 2–3 mock interviews or prepare stakeholder personas
• Create a stakeholder matrix (with RACI if possible)

Deliverables:

• Stakeholder List & Roles
• Interview Notes / Persona Profiles
• Stakeholder Requirement Summary

In this first phase, students will learn how to elicit requirements from various stakeholders involved in the project. Identifying stakeholders means recognizing who will be affected by the project or who has an interest in its outcome. Mock interviews help simulate real conversations to gather insights, while a stakeholder matrix helps to clarify roles and responsibilities. The deliverables in this phase include a list of stakeholders, notes from the interviews, and a summary of their requirements.

Imagine planning a community event and needing input from various groups: vendors (store staff), volunteers (admin), attendees (customers), and delivery services (delivery team). Just like gathering their opinions helps shape the event, eliciting requirements gives a clear understanding of the needs for the grocery ordering system.

Phase 2: Document Requirements

Tasks:

• Write 5–8 user stories using INVEST format
• Define acceptance criteria using Gherkin (Given–When–Then)
• Categorize requirements: business, functional, non-functional
• Create a Requirement Traceability Matrix (RTM)

Deliverables:

• User Stories Document
• Acceptance Criteria Sheet
• BRD or FRD (can be simplified)
• RTM in Excel or Table format

In this phase, students learn to document requirements effectively. User stories describe features from an end-user perspective and follow the INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable). Acceptance criteria set the conditions that must be met for a feature to be considered complete. Categorizing requirements into business, functional, and non-functional ensures clarity in what needs to be built. Finally, the Requirement Traceability Matrix (RTM) links requirements to their sources, making it easier to track them throughout the project.

Creating user stories is like writing recipe instructions: each step (or story) needs to be clear and easy to follow. Think of acceptance criteria as the ‘taste test’ — the dish has to meet certain standards before it can be served. By organizing the ingredients (requirements) in categories, you ensure that no important flavor is left out!

Phase 3: Model the System

Tasks:

• Draw Use Case Diagram for order placement
• Draw Activity Diagram for customer flow (browse → checkout)
• Create Wireframes or Mockups (use Draw.io, Balsamiq, or Figma)

Deliverables:

• Use Case Diagram
• Activity Diagram
• Low-fidelity Wireframes (for 2–3 key screens)

Modeling the system involves creating visual representations of how the system will function. The use case diagram outlines interactions between users (actors) and the system for specific tasks, such as placing an order. The activity diagram captures the flow of actions a customer takes while navigating the system, from browsing to checkout. Wireframes are basic designs of screens showing the layout of elements, allowing stakeholders to visualize the final product before development starts.

Think of modeling a system like designing a theme park. The use case diagram is like a map showing where people can enter certain rides (interactions), the activity diagram illustrates the path they take from one ride to another, and wireframes are initial sketches of how the park will look, giving a sense of layout before the attractions are built.

Phase 4: Test Planning (Optional)

Tasks:

• Write 3–5 test cases
• Map them to requirements in RTM
• Identify a sample defect (if any) from testing

Deliverables:

• Test Case Table (ID, Steps, Expected Result)
• Defect Log (Optional, for extra challenge)

Test planning focuses on ensuring that the system works as intended. Writing test cases involves outlining steps to verify that each requirement performs correctly. Mapping these cases back to the RTM ensures that all requirements are covered by tests. Identifying defects highlights any issues found during testing, leading to necessary corrections. The deliverables include a table listing the test cases and, optionally, a defect log that details any issues discovered.

Testing can be compared to quality checking in a kitchen. When a chef creates a new dish, they might write down the steps for others to replicate (test cases). They also need to check if the dish meets customer expectations (mapping to requirements), and if any flavors are off, they note them down to fix them before serving.

Phase 5: Presentation & Review

Tasks:

• Create a summary presentation (6–8 slides max)
• Include business problem, solution scope, user stories, diagrams, and next steps
• Present your project to peers or mentor (live or recorded)

Deliverables:

• Slide Deck (PDF or PPT)
• Optionally, record a 5-minute video walkthrough

The final phase involves compiling all work into a clear presentation. The presentation should summarize the business problem, outline the proposed solution, detail user stories, and display diagrams created during the project. This step emphasizes the importance of communication skills in conveying project findings effectively, either in a live setting or through a recorded format. The deliverables include a slide deck, with an option for a video walkthrough to elaborate on the project.

Think of this presentation as the grand unveiling of a new product. Just as a company might launch a new gadget by highlighting its features and benefits to an audience, you need to showcase your project and explain how it addresses the predetermined business problem. Engaging your audience helps them understand the value you've created.

--