1.4.1.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 the first phase, the primary goal is to elicit or gather the requirements from various stakeholders involved in the business project. This involves identifying key stakeholders such as customers who will use the online grocery ordering system, store staff who will manage the orders, the delivery team responsible for home deliveries, and administrators overseeing the system.

Next, the task includes conducting mock interviews with these stakeholders to understand their needs better. Alternatively, if mock interviews aren't possible, creating personas (fictional characters representing users or stakeholders) can help conceptualize their needs.

Finally, the creation of a stakeholder matrix, which might include the RACI (Responsible, Accountable, Consulted, Informed) framework, will visually outline the roles and responsibilities of each stakeholder in relation to the project, ensuring clarity in who does what.

Imagine planning a big family vacation. You need to identify who will be going (stakeholders), like your parents, siblings, and relatives. You could sit down with them (mock interviews) to discuss where everyone wants to go, what activities they prefer, and how much they are willing to spend. After gathering this information, you create a list showing who prefers what, ensuring each person’s preferences are accounted for (stakeholder matrix). This way, everyone’s expectations are clear, just like in a project, where clear roles minimize misunderstandings.

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 focus shifts to documenting the requirements gathered from stakeholders. This starts with writing user stories, which are short descriptions of a software feature from an end-user perspective. The INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable) help ensure these stories are effective.

Next, each user story requires clear acceptance criteria, which define conditions that must be met for the story to be considered complete. The Gherkin format provides a structured way to write these criteria using the 'Given-When-Then' format—helping outline initial context, action, and expected outcome clearly.

Also, it's essential to categorize requirements into business requirements (what the business needs), functional requirements (what the system must do), and non-functional requirements (system attributes like performance). Lastly, a Requirement Traceability Matrix (RTM) is created to track all requirements throughout the project lifecycle, ensuring nothing gets overlooked.

Think of writing a recipe. Each user story is like a recipe step, for example: 'As a customer, I want to add products to my cart so that I can purchase them later.' Here, the acceptance criteria are like the specifics for each step, such as 'Given I am logged in, When I select an item, Then it should appear in my cart.' Categorizing requirements is akin to organizing your grocery list: what meals you want to make (business need), ingredients required (functional), and preferred brands or quality (non-functional). Finally, an RTM is like keeping a checklist of ingredients confirming that you've bought everything you need before starting the cooking process.

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)

In Phase 3, the task involves modeling the system to visually represent how the online grocery ordering system will function. This begins with creating a Use Case Diagram, which illustrates the various interactions between users (actors) and the system. For instance, a use case might depict how a customer places an order.

Next, an Activity Diagram outlines the various steps a customer takes from browsing products to completing a checkout, providing a visual workflow that is easy to understand.

Finally, creating wireframes or mockups of key screens gives a blueprint of the user interface design, helping stakeholders visualize how the system will appear and function. Tools like Draw.io or Figma can assist in creating these visuals effectively.

Consider designing a new amusement park ride. The Use Case Diagram is like a layout showing where guests will enter, the path they will take, and how they will exit the ride (interactions). The Activity Diagram represents the flow of guests from waiting in line, boarding, enjoying the ride, and disembarking, which helps identify each step of their experience. Finally, the wireframes are concept sketches of the ride and nearby areas, allowing designers, engineers, and stakeholders to visualize what the ride will look like before any actual building starts.

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)

Phase 4 is focused on optional test planning, crucial for ensuring that the system is functioning as intended before going live. The tasks in this phase include writing 3 to 5 test cases, which outline specific scenarios to verify if the system behaves correctly under various conditions. Each test case should have a unique ID and include the steps to execute, along with the expected results for validation.

These test cases should then be mapped to requirements in the Requirement Traceability Matrix (RTM) to ensure comprehensive coverage of all requirements during testing. Identifying sample defects during testing helps preempt issues in the live system, making it essential for a smooth user experience.

Imagine you're testing a new restaurant recipe before it is served to customers. Each test case is a specific scenario: 'What happens if you double the spice?' You write steps on how to alter the recipe and then assess whether it still tastes good (expected result). Mapping these scenarios to the original recipe ensures you're testing all parts. Similarly, if you notice too much salt, you document this issue (defect log) to avoid serving it to diners later.

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

In the final phase, the task shifts to summarizing the project and sharing findings with peers or mentors. This begins with creating a succinct presentation of 6 to 8 slides, ensuring that there's a clear focus on the business problem identified, the scope of solutions proposed, user stories generated, and the diagrams created in previous phases.

This presentation serves as a formal review of the work and is vital to demonstrating the deliverables generated throughout the project lifecycle. Presenting effectively can be done live or recorded, which allows for flexibility in sharing information with diverse audiences.

Think of this last phase as preparing for a school science fair. You compile a poster (presentation slides) that summarizes your project—what problem you were trying to solve, your experiment steps (solution scope), and results (diagrams and user stories). Lastly, you would present your findings in person or via a video to share your hard work and insights with other students and judges, making sure your project is clear and engaging.

--