1.4.3.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 the first phase, the focus is on gathering requirements. This involves identifying who the stakeholders are, such as customers and staff. Next, you would conduct mock interviews to understand these stakeholders' perspectives. Creating a stakeholder matrix helps clarify who is responsible for each task in the project. The expected deliverables from this phase include a list of stakeholders, notes from the interviews, and a summary of their requirements.

Imagine planning a party. First, you identify your guests (stakeholders) and what they might want. You could ask them what food they like (mock interviews) and take notes. Then, you organize this information to ensure everyone’s preferences are covered (stakeholder requirement summary).

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 the second phase, once you've gathered requirements, it’s time to document them. You write user stories that follow the INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable). Then, you establish acceptance criteria, which outline when a user story is considered complete. You categorize the requirements into business, functional, and non-functional to clarify what is needed. Finally, you create a Requirement Traceability Matrix to ensure all requirements are tracked.

Think of this phase as writing a recipe. The user stories are the list of ingredients and steps needed to make a dish. The acceptance criteria tell you what the final dish should look like to know if you're successful. Keeping track of which ingredients are mandatory (business vs functional vs non-functional) is like ensuring you have everything for the meal and documenting that you have all the essential elements.

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)

The third phase is about visualizing how the system will work. You create diagrams to illustrate how users interact with the system, such as a Use Case Diagram that details the steps a user takes to place an order. An Activity Diagram shows the workflow from browsing to checkout. Wireframes or mockups provide a visual representation of what the interface will look like, focusing on layout and functionality rather than design specifics.

This phase is like planning a new building. You start with blueprints (diagrams) showing how different rooms will be used (who can enter which room) and in what order (activity flow). Wireframes are like sketches of how the building will look from the outside and inside, giving an idea of the structure without focusing on colors or decorations just yet.

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 the optional test planning phase, you develop test cases that outline how to verify if the system meets the defined requirements. Each test case details the steps taken during the test and the expected outcome. Mapping these test cases back to the Requirement Traceability Matrix ensures all requirements are being tested. If any defects are found, they can be logged for further attention.

Consider this phase as a dress rehearsal for a play. You set up situations (test cases) to see if everything goes as planned (expected result). Just as a cast might discover something flawed in a scene, a business analyst documents these issues (defects) for corrections before the final 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 preparing a presentation to share your project findings and analyses. You would create a concise presentation that summarizes the business problem, the proposed solution, including user stories and relevant diagrams. It's essential to keep the presentation clear and engaging, allowing your audience to grasp the full scope of your project. You may also record a video walkthrough to further enhance your presentation.

Think of this phase like preparing for a big school project presentation. You gather all your findings into a succinct slide show (the deck) that tells a story — introducing the problem, your solution, and what happens next. Just like you would practice in front of friends or family to build confidence, presenting to peers or a mentor helps you refine your message and delivery.

Final Output Checklist

• Stakeholder Summary
• BRD or FRD
• 5+ User Stories with Acceptance Criteria
• RTM
• 2 Diagrams (Use Case + Activity)
• Wireframes
• Test Cases (Optional)
• Final Presentation

The final output checklist is a comprehensive list of all deliverables that should be completed by the end of the project. This includes a stakeholder summary, the Business Requirements Document (BRD) or Functional Requirements Document (FRD), user stories with acceptance criteria, a Requirement Traceability Matrix, diagrams, wireframes, and optional test cases, capped off with a final presentation.

Imagine a teacher giving you a checklist for an end-of-semester project. You need to ensure you have completed each component before submission — a summary of research (stakeholder summary), the detailed analysis (BRD/FRD), your main points (user stories), and visual aids (diagrams and wireframes). This checklist acts and ensures nothing is overlooked, much like double-checking your packing before a trip.

--