Learn
Games

1.4.1.1 - Tasks

Interactive Audio Lesson

Listen to a student-teacher conversation explaining the topic in a relatable way.

Elicit Requirements

Unlock Audio Lesson

Signup and Enroll to the course for listening the Audio Lesson

Teacher
Teacher

Today we'll delve into the first phase of our mini-project: Eliciting Requirements. This involves identifying key stakeholders for our grocery project. Can anyone recall who those stakeholders might be?

Student 1
Student 1

Are customers considered stakeholders?

Teacher
Teacher

Absolutely! Customers are primary stakeholders because they will use the system. Who else might we consider?

Student 2
Student 2

What about store staff and delivery teams?

Teacher
Teacher

Exactly! We've got customers, staff, delivery teams, and admin. Now, let's discuss how we can gather their requirements. What methods can we use?

Student 3
Student 3

I think we could conduct interviews or create stakeholder personas.

Teacher
Teacher

That’s a great point! Mock interviews and creating personas will help us understand their needs better. Let’s remember this with the acronym RACI — Responsible, Accountable, Consulted, Informed — for stakeholder roles. Who wants to explain RACI?

Student 4
Student 4

RACI categorizes who is responsible for tasks, who cares about the outcome, who should be consulted, and who needs to be informed, right?

Teacher
Teacher

Well done! Understanding stakeholder responsibilities is crucial. Now, let’s summarize this session. We learned about identifying key stakeholders, methods to gather requirements, and the RACI framework.

Document Requirements

Unlock Audio Lesson

Signup and Enroll to the course for listening the Audio Lesson

Teacher
Teacher

We have our requirements outlined. Moving on to documenting these, what format do we use for our user stories?

Student 1
Student 1

We can use the INVEST criteria!

Teacher
Teacher

Correct! INVEST stands for Independent, Negotiable, Valuable, Estimable, Small, and Testable. We want our user stories to meet these criteria. Can someone share an example of a user story in this format?

Student 2
Student 2

As a customer, I want to add items to my cart so that I can make a purchase.

Teacher
Teacher

Great example! Now, documenting acceptance criteria is also vital. Who remembers what the Gherkin format looks like for acceptance criteria?

Student 3
Student 3

It’s in the format of Given, When, Then!

Teacher
Teacher

Exactly! This format helps clarify conditions. Let’s summarize what we covered: we discussed the importance of user stories, the INVEST format, and Gherkin for acceptance criteria. Understanding requirements documentation is key in BA work.

Model the System

Unlock Audio Lesson

Signup and Enroll to the course for listening the Audio Lesson

Teacher
Teacher

Let’s explore system modeling. Why do you think creating diagrams like use case diagrams is essential?

Student 4
Student 4

It helps visualize how users will interact with the system!

Teacher
Teacher

Exactly! Use case diagrams identify different user interactions. What other diagrams can we create?

Student 1
Student 1

We could also create activity diagrams to show flow!

Teacher
Teacher

Right! Activity diagrams are excellent for visualizing processes like checkout. Now, how about wireframes? Why do we create them?

Student 2
Student 2

Wireframes help us visualize the layout of the user interfaces.

Teacher
Teacher

Exactly! Remember, low-fidelity wireframes can convey basic ideas. Let's recap today: we covered use cases, activity diagrams, and wireframes, all of which aid in better understanding user interactions.

Introduction & Overview

Read a summary of the section's main ideas. Choose from Basic, Medium, or Detailed.

Quick Overview

This section details the various tasks involved in preparing a mini-project related to an online grocery ordering system.

Standard

The section outlines a comprehensive plan for completing a mini-project as a Business Analyst, including requirements elicitation, documentation, system modeling, testing, and presentation. Each phase has specific tasks and corresponding deliverables to create a structured analysis process.

Detailed

This section focuses on the preparations and tasks required to conduct a mini-project in the context of a Business Analyst assignment. The mini-project is centered around developing an Online Grocery Ordering System, and it is divided into several key phases: Elicit Requirements, Document Requirements, Model the System, Test Planning, and Presentation & Review. Each phase includes specific tasks for students to engage with, from identifying stakeholders and conducting interviews to creating user stories, diagrams, and a final presentation summarizing their findings. This structured approach leverages techniques learned throughout the course and aims to simulate a real-world BA project. The deliverables for each phase are clearly defined, emphasizing a practical application of business analysis skills.

Audio Book

Dive deep into the subject with an immersive audiobook experience.

Phase 1: Elicit Requirements

Unlock Audio Book

Signup and Enroll to the course for listening the Audio Book

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

Detailed Explanation

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.

Examples & Analogies

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

Unlock Audio Book

Signup and Enroll to the course for listening the Audio Book

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

Detailed Explanation

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.

Examples & Analogies

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

Unlock Audio Book

Signup and Enroll to the course for listening the Audio Book

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)

Detailed Explanation

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.

Examples & Analogies

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)

Unlock Audio Book

Signup and Enroll to the course for listening the Audio Book

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)

Detailed Explanation

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.

Examples & Analogies

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

Unlock Audio Book

Signup and Enroll to the course for listening the Audio Book

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

Detailed Explanation

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.

Examples & Analogies

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.

Definitions & Key Concepts

Learn essential terms and foundational ideas that form the basis of the topic.

Key Concepts

  • Requirements Elicitation: The process of gathering information to specify what a system should do.

  • User Stories: A way to document requirements focusing on user needs.

  • Acceptance Criteria: Conditions that a product must satisfy to be accepted.

  • Use Case Diagram: Visual representation showing how users interact with the system.

  • Wireframes: Basic layouts representing key elements of an interface.

Examples & Real-Life Applications

See how the concepts apply in real-world scenarios to understand their practical implications.

Examples

  • A user story for the project: 'As a customer, I want to view available products, so that I can make informed purchase decisions.'

  • An acceptance criterion example using Gherkin: 'Given I am a registered user, When I add an item to the cart, Then it should appear in my shopping cart.'

Memory Aids

Use mnemonics, acronyms, or visual cues to help remember key information more easily.

🎵 Rhymes Time

  • To elicit needs and stakeholder pleas, gather insights with great ease!

📖 Fascinating Stories

  • Imagine a customer who can't find cake; a story of needs they will share for your sake!

🧠 Other Memory Gems

  • For INVEST, remember: I Need Valuables, Every Small Task.

🎯 Super Acronyms

RACI

  • Responsible and Accountable
  • Who's Consulted? Who's Informed?

Flash Cards

Review key concepts with flashcards.

Glossary of Terms

Review the Definitions for terms.

  • Term: Stakeholder

    Definition:

    Individuals or groups who have an interest in the project or are affected by it.

  • Term: User Stories

    Definition:

    Short descriptions of a feature from the perspective of the end user.

  • Term: Gherkin

    Definition:

    A language used for writing acceptance criteria in a structured format (Given-When-Then).

  • Term: RACI

    Definition:

    A responsibility assignment matrix for clarifying roles within a project.

  • Term: Use Case Diagram

    Definition:

    A visual representation of interactions between users and a system.