1.4.1.2 - Deliverables
Enroll to start learning
Youβve not yet enrolled in this course. Please enroll for free to listen to audio lessons, classroom podcasts and take practice test.
Interactive Audio Lesson
Listen to a student-teacher conversation explaining the topic in a relatable way.
Eliciting Requirements
π Unlock Audio Lesson
Sign up and enroll to listen to this audio lesson
Welcome, everyone! Today we start with the first phase of our project, which is eliciting requirements. Can anyone tell me why identifying stakeholders is crucial?
I think itβs because stakeholders provide us with the necessary input to understand what they need?
Absolutely! Remember, the acronym RACI helps us clarify roles. Who can break down what RACI stands for?
RACI stands for Responsible, Accountable, Consulted, and Informed!
Great! So, how do we gather this information from the stakeholders?
We can conduct mock interviews!
Yes, and from those interviews, weβll create stakeholder personas and a stakeholder requirement summary. Can anyone summarize what our deliverables will be for this phase?
We need a stakeholder list, interview notes, and the requirement summary.
Exactly! Letβs conclude this session by saying that clear elicitation lays the foundation for the rest of our analysis work.
Documenting Requirements
π Unlock Audio Lesson
Sign up and enroll to listen to this audio lesson
Now, let's explore the second phase: documenting our requirements. What are user stories and why are they important?
User stories describe features from the end-user perspective, right?
Exactly! They help keep the focus on user needs. Can someone explain the INVEST criteria for writing good user stories?
INVEST stands for Independent, Negotiable, Valuable, Estimable, Small, and Testable.
Well done! And what about acceptance criteria? Who can illustrate the Gherkin format for us?
The Gherkin format uses βGivenβ, βWhenβ, βThenβ to define the conditions under which the user story is considered done!
Perfect! Now, remember, our goal is to create a User Stories Document that provides clarity for the development team. Whatβs the significance of the Requirement Traceability Matrix?
It links requirements to their corresponding user stories and helps in tracking progress.
Great insights! The documentation phase sets clear expectations and guides our development efforts effectively.
Modeling the System
π Unlock Audio Lesson
Sign up and enroll to listen to this audio lesson
In phase three, modeling is key! What visual tools do we have at our disposal to represent our system requirements?
Use Case Diagrams and Activity Diagrams!
Absolutely! Use Case Diagrams illustrate who interacts with the system and the functionalities. Can someone outline a simple use case for our grocery ordering system?
A user can browse items, add them to their cart, and place an order.
Exactly! Now, how about Activity Diagrams? Whatβs their role?
They show the flow of processes, like how a customer would transition from browsing to checkout.
Exactly! Finally, letβs not forget wireframes. How do they help us visualize the user interface?
Wireframes give a low-fidelity representation of the key screens so we can plan the layout and functionality.
Brilliant! Visual modeling helps everyone involved to understand the system deeply.
Test Planning
π Unlock Audio Lesson
Sign up and enroll to listen to this audio lesson
Letβs briefly discuss test planning. Why is it crucial in our analysis process?
It ensures that our requirements are validated and functions as expected!
Exactly! During this phase, we write test cases linked to our requirements. Who can give me an example of a test case?
For the cart feature, we might test if a user can successfully add items to it.
Right! The test case should have clear steps and expected results. Can anyone tell me about the defect log and its importance?
It records any issues found during testing so we can prioritize fixes!
Precisely! Remember, testing validates that what we've built meets user needs and requirements before the final rollout.
Presentation & Review
π Unlock Audio Lesson
Sign up and enroll to listen to this audio lesson
Finally, letβs talk about the last phase: Presentation & Review. What are the key elements we should include in our project summary presentation?
We need to highlight the business problem and our proposed solutions.
Yes! What else does our presentation need to convey?
We should include user stories and the visual diagrams we created!
Exactly! A concise presentation communicates our findings effectively to stakeholders. Anyone remember what format can the presentation material take?
It can be a PDF or a PPT, and we could even record a video walkthrough as an option!
Brilliant recall! By the end of this phase, our goal is to provide clarity and confidence in our business solution.
Introduction & Overview
Read summaries of the section's main ideas at different levels of detail.
Quick Overview
Standard
The section provides a comprehensive guide on the phases of a business analysis project for creating an Online Grocery Ordering System, including deliverables such as requirement elicitation, documentation, modeling, test planning, and final presentation.
Detailed
Deliverables in Business Analysis
In this section, we cover the essential phases and corresponding deliverables required for completing an end-to-end business analysis project aimed at developing an Online Grocery Ordering System. The project is structured into four main phasesβEliciting Requirements, Documenting Requirements, Modeling the System, Test Planning, and Presentation & Reviewβwith specific tasks and outputs for each.
Phase 1: Elicit Requirements
This phase focuses on gathering requirements through stakeholder identification, mock interviews or persona development, and creating a stakeholder matrix. The deliverables include a comprehensive stakeholder list, interview notes, and a requirement summary.
Phase 2: Document Requirements
Here, students will learn to write user stories using the INVEST criteria and define acceptance criteria with Gherkin format. Deliverables also include categorizing requirements and creating a Requirement Traceability Matrix (RTM).
Phase 3: Model the System
This phase involves visual modeling with use case diagrams, activity diagrams, and wireframes to represent the user flow and system functionalities effectively.
Phase 4: Test Planning (Optional)
Students will create test cases linked to the requirements to ensure the functionality is properly validated. This is optional but helps in understanding practical application.
Final Phase: Presentation & Review
In the last phase, the emphasis is on summarizing the project in a concise presentation format, highlighting the business problem, solution scope, and user stories.
By following these phases and deliverables, learners can simulate a realistic business analysis project, hone their skills, and prepare for real-world applications.
Audio Book
Dive deep into the subject with an immersive audiobook experience.
Phase 1: Elicit Requirements
Chapter 1 of 5
π Unlock Audio Chapter
Sign up and enroll to access the full audio experience
Chapter Content
β
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 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.
Examples & Analogies
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
Chapter 2 of 5
π Unlock Audio Chapter
Sign up and enroll to access the full audio experience
Chapter Content
β
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, 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.
Examples & Analogies
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
Chapter 3 of 5
π Unlock Audio Chapter
Sign up and enroll to access the full audio experience
Chapter Content
β
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
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.
Examples & Analogies
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)
Chapter 4 of 5
π Unlock Audio Chapter
Sign up and enroll to access the full audio experience
Chapter Content
β
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
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.
Examples & Analogies
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
Chapter 5 of 5
π Unlock Audio Chapter
Sign up and enroll to access the full audio experience
Chapter Content
β
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
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.
Examples & Analogies
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.
Key Concepts
-
Phases of Business Analysis: Defines the complete lifecycle from eliciting requirements to final presentation.
-
Stakeholder Engagement: Crucial for gathering accurate requirements and ensuring successful project outcomes.
-
User Stories: A foundational component that represents user needs and drives the development process.
-
Requirement Traceability Matrix: Links requirements to corresponding tests, ensuring validation of features.
-
Visual Modeling Tools: Includes diagrams and wireframes that help represent and communicate system functionality.
Examples & Applications
A stakeholder list containing customers, store staff, delivery teams, and administrative personnel.
A user story: 'As a customer, I want to view product details so that I can make informed purchase decisions.'
A Gherkin acceptance criterion: 'Given I am on the product page, when I select an item, then it should be added to my cart.'
A wireframe that displays the layout for the shopping cart page, including product items, total price, and checkout button.
A defect log recorded during testing: 'Defect ID 001: Unable to add items to the cart - Status: Open'.
Memory Aids
Interactive tools to help you remember key concepts
Rhymes
User stories tell us what they need, for developing features to succeed!
Stories
Picture a customer shopping online, adding items to their cart, looking to buy fine. With user stories, their needs we find, shaping the system, making it aligned.
Memory Tools
RACI helps to remember who plays the role: Responsible, Accountable, Consulted, Informed, to reach the goal.
Acronyms
RTM for tracking, Requirement Traceability Matrix, keeping our project intact and on axis.
Flash Cards
Glossary
- Stakeholder
An individual or group with an interest in the outcome of a project.
- User Story
A short, simple description of a feature from the perspective of the user.
- Acceptance Criteria
Conditions under which a user story is considered complete, often expressed in the Gherkin format.
- Requirement Traceability Matrix (RTM)
A tool used to link requirements to their corresponding user stories and test cases.
- Use Case Diagram
A visual representation that depicts the interactions between users and the system.
- Activity Diagram
A diagram that outlines the flow of processes within a system.
- Wireframes
Low-fidelity visual representations of interface components of a system.
- Test Case
A set of conditions or variables under which a tester determines whether a system or software application is working correctly.
- Defect Log
A document that records defects and issues identified during testing.
- Gherkin
A business-readable language used to describe tests in a specific format (Given-When-Then).
Reference links
Supplementary resources to enhance your learning experience.
- Introduction to Business Analysis
- Understanding User Stories
- Creating Wireframes
- Use Case Diagrams Explained
- Acceptance Criteria Examples
- How to Write Good Test Cases
- Business Requirement Document (BRD)
- Understanding the Requirement Traceability Matrix (RTM)
- Defect Tracking and Analysis
- Introduction to Activity Diagrams