1.4.1.2. Deliverables

✅ 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 Phase 1, the focus is on understanding the needs of the project by identifying who will be affected by it, known as stakeholders. You will conduct mock interviews to gather insights and create detailed persona profiles that summarize the stakeholders' interests. A stakeholder matrix, including a RACI (Responsible, Accountable, Consulted, Informed) chart, may also be used to clarify roles and responsibilities among stakeholders. The deliverables include a comprehensive list of stakeholders, notes from interviews, and a summary of their requirements.

Imagine you're organizing a school event. To plan effectively, you need input from students (participants), teachers (sponsors), and parents (supporters). By interviewing these groups, you create a clear picture of what each group wants, similar to how a Business Analyst identifies and documents stakeholder requirements.

✅ 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 Phase 2, you will document the gathered requirements to ensure clarity and direction. User stories are used to convey what the end-users need in a straightforward manner, formatted according to the INVEST principles (Independent, Negotiable, Valuable, Estimable, Small, Testable). Acceptance criteria are also created using the Gherkin syntax, establishing clear conditions for success. Requirements will be categorized into business, functional, and non-functional types, and a Requirement Traceability Matrix (RTM) will be created to track the relationship between requirements and deliverables.

Think of building a new playground. You don’t just say 'build a playground'; instead, you write user stories like 'As a child, I want swings so I can play.' This is similar to how a Business Analyst captures requirements. The acceptance criteria ensure that when the swings are built, they are safe and fun, much like in creating clear project requirements.

✅ 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)

Phase 3 involves visually modeling the system to illustrate how users will interact with it. A Use Case Diagram is drawn to represent the order placement process, showing different user interactions. An Activity Diagram outlines the customer workflow from browsing products to checking out. Low-fidelity wireframes or mockups will be created to provide a basic layout and design of the user interface, helping stakeholders visualize the system's functionalities.

Imagine planning a theme park. You'd first sketch a map (the Use Case Diagram) showing rides and attractions, then detail the flow of visitors (the Activity Diagram) going from one ride to another. Finally, you'd create rough drawings (wireframes) of what each attraction looks like. This is similar to how a BA models a system for clarity and understanding.

✅ 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)

In this optional phase, you develop test cases to ensure that the system meets its requirements and works as intended. Test cases are structured to verify specific functionalities, and they are mapped to the requirements listed in the RTM to maintain traceability. A defect log can also be created to document any issues identified during testing, providing a chance for continuous improvement.

Testing the system is like a dress rehearsal for a play. Just as actors practice to make sure everything runs smoothly, you write test cases to check that all parts of the online grocery ordering system work correctly. When a problem arises, like an actor forgetting their line, it’s noted down (defect log) so it can be fixed before the actual performance.

✅ 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 creating a concise presentation that summarizes your project. You will compile your findings into 6 to 8 slides, highlighting the business problem, proposed solutions, user stories, relevant diagrams, and future steps for the project. Presenting to your peers or a mentor allows for constructive feedback and learning opportunities. You may also choose to record a brief video walkthrough to enhance your presentation skills.

Presenting your project is like showcasing a science fair project. You prepare a poster (presentation) explaining your experiment (business problem), your findings (solution), and what you plan to do next. Sharing it with others helps you receive feedback and improve, just as a Business Analyst benefits from presenting their work to stakeholders.

--