1.4.5.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 and gathering the needs of those involved in the project. This starts with identifying who the stakeholders are, such as customers who will use the system, store staff who will manage the products, delivery teams responsible for fulfilling orders, and administrators overseeing the system. Next, it's important to engage with stakeholders either through mock interviews or by creating detailed profiles that represent different stakeholder types. Finally, a stakeholder matrix can be created to clarify the roles and responsibilities of each stakeholder, ideally using a RACI chart, which outlines who is Responsible, Accountable, Consulted, and Informed in the project process. The deliverables for this phase include a comprehensive list of stakeholders along with their roles, notes from interviews or profiles developed, and a summary of the stakeholders' requirements.

Imagine you are planning a birthday party. First, you need to identify your stakeholders: the birthday person, guests, the catering service, and possibly a party planner. You would then ask them about their preferences and needs (mock interviews), create a list that specifies who will do what (like who brings the cake, who sets up the decorations), and summarize these requirements to ensure everyone is on the same page.

✅ 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, the goal is to clearly document the gathered requirements. This begins with creating user stories, which are short descriptions outlining how a user will interact with the system, structured in a way that they are Independent, Negotiable, Valuable, Estimable, Small, and Testable (the INVEST criteria). Next, acceptance criteria must be defined to specify when a user story is considered complete, often using a format called Gherkin, which follows a 'Given-When-Then' structure. Requirements are then categorized into three types: business (high-level needs), functional (specific functionalities), and non-functional (system attributes like performance). The Requirement Traceability Matrix (RTM) is created to track these requirements throughout the project. The deliverables include a document of user stories, a sheet outlining acceptance criteria, potentially a Business Requirement Document (BRD) or Functional Requirement Document (FRD), and the RTM.

Think of this phase like building a house. Writing user stories is akin to creating a blueprint where you specify what types of rooms you want (user stories). Defining acceptance criteria is like specifying that the kitchen must have at least two windows and a fridge (criteria that must be met). You then categorize tasks (building walls, plumbing) into broader categories (structural work, finishing touches) and maintain a checklist (RTM) to track what needs to be completed and verified.

✅ 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 creating visual models to represent how the system will function. The Use Case Diagram illustrates the interaction between users (actors) and the system, focusing on a specific process like placing an order. The Activity Diagram shows the pathway a customer takes when browsing the site to checking out, capturing important user flows. Wireframes or mockups are also created to visualize the layout of key screens in the system. This modeling helps clarify the system’s design and usability before development starts. The deliverables include the Use Case Diagram, Activity Diagram, and initial low-fidelity wireframes for crucial screens.

Imagine you are designing a new app for ordering food online. The Use Case Diagram would show how a customer interacts with your app to place a meal order. The Activity Diagram illustrates the steps they take from choosing a dish to confirming the order. Creating wireframes would be like sketching out the layout of the app on paper, showing where each button and feature will be located without getting into the final design details, so everyone can understand what to expect.

✅ 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 Phase 4, although it's optional, testing strategies can be developed to ensure that the system functions as intended. This involves writing test cases, which are detailed instructions on how to test specific functionalities of the system. Each test case is mapped back to requirements in the RTM to ensure coverage. Moreover, if any issues are found during testing, they should be logged in a Defect Log for tracking. The deliverables for this phase include a table of test cases that specify what to do and what the expected outcomes are, and optionally a log of any defects encountered.

Think of throwing a big event, like a wedding. Before the event, you would create a checklist of things to test, such as whether the music system works and if the catering is on time. This checklist is your test cases. If you find any problems, like the cake cutter being missing, you’d track that problem in a log to make sure it gets resolved before the big day.

✅ 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 is about summarizing and sharing the project's findings and proposed solution. A concise presentation of 6–8 slides should be prepared, which includes an overview of the business problem, solution scope, key user stories, diagrams, and the next steps in the process. After preparing the slides, the project can be presented live to peers or mentors or recorded for their review. The deliverables for this phase are the slide deck, which can be submitted as a PDF or PowerPoint file, and optionally, a short video walkthrough to provide a more dynamic view of the project.

Imagine presenting a school project. You would prepare a few slides summarizing your research, your project’s objective, and any interesting visuals or diagrams you created. After rehearsing, you would present your work to the class or record a video explanation to make it easier for others to understand your findings.

✅ 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 serves as a compilation of critical items that should be produced throughout the project process. It includes a summary of stakeholders to keep track of who is involved, a BRD or FRD to document the business and functional requirements, and a minimum of five user stories complete with acceptance criteria to validate the requirements. The RTM, diagrams (both Use Case and Activity), wireframes, and optional test cases should also be included as part of the deliverables. Finally, the checklist confirms that a final presentation summarizing the entire project has been created.

Consider this checklist similar to a packing list for a road trip. Before you leave, you ensure you have all essentials like snacks, drinks, a map, and entertainment. This checklist ensures you’re fully prepared for the journey, just like the output checklist ensures that you have all necessary documentation and materials to complete your business analysis project.

--