1.4.3.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
Eliciting requirements is the first step. It involves identifying key stakeholders such as customers and delivery teams. Can anyone tell me what a stakeholder matrix is?
Isn't it a tool that helps identify roles and responsibilities?
Exactly! A stakeholder matrix often includes RACIβResponsible, Accountable, Consulted, and Informed. So, why do we conduct mock interviews?
To gather more detailed and specific information from stakeholders.
Right! Good job. Letβs summarize this phase. Identifying stakeholders, conducting interviews, and creating a summary of requirements are key actions.
Documenting Requirements
π Unlock Audio Lesson
Sign up and enroll to listen to this audio lesson
In documenting requirements, we use user stories formatted with the INVEST principle. What does INVEST stand for?
Independent, Negotiable, Valuable, Estimable, Small, and Testable!
Great! Along with user stories, whatβs the significance of defining acceptance criteria?
It helps ensure that each requirement can be validated through testing.
Absolutely! Acceptance criteria are vital for that. Letβs talk about categorizing requirements now; can anyone explain the differences between business and functional requirements?
Business requirements define the high-level objectives while functional requirements specify how these objectives will be met.
Exactly, well put! Documenting requirements is pivotal in ensuring everyone is on the same page.
Modeling the System
π Unlock Audio Lesson
Sign up and enroll to listen to this audio lesson
Modeling the system involves creating diagrams like use case and activity diagrams. Whatβs a use case diagram?
It represents the interactions between users and the system.
Correct! Now, can someone explain the importance of creating wireframes?
Wireframes help visualize the layout and functionality of key screens before full development.
Exactly right! They serve as a communication tool between stakeholders and developers. Let's summarize: Use case and activity diagrams, along with wireframes, provide essential visual aids for effective understanding.
Planning for Test Cases
π Unlock Audio Lesson
Sign up and enroll to listen to this audio lesson
Testing ensures that the developed system meets requirements effectively. Why is writing test cases important?
They provide a clear guideline on how to verify that a requirement is fulfilled.
Exactly! And mapping test cases to the requirement traceability matrix helps us keep track of coverage. What's an optional deliverable in this phase?
A defect log, to track any issues found during testing.
Well said! These tools are critical for ensuring the product's quality. Letβs recap: Test cases and defect logs help validate system performance.
Presentation of Deliverables
π Unlock Audio Lesson
Sign up and enroll to listen to this audio lesson
In our final phase, we focus on presenting the findings. What should be included in our presentation slides?
It should summarize the business problem, the solution scope, and key deliverables.
Exactly! A concise presentation can significantly impact stakeholdersβ understanding. Why do we consider recording the walkthrough?
It allows us to review our presentation skills and provides a reference for stakeholders.
Correct! To conclude, recapping the analysis and demonstrating clarity in presentation holds immense value in a project.
Introduction & Overview
Read summaries of the section's main ideas at different levels of detail.
Quick Overview
Standard
The section details the deliverables for each phase of a capstone-style business analysis project for an online grocery ordering system, from requirements elicitation to presentation, ensuring a comprehensive understanding of necessary documentation and analysis.
Detailed
Detailed Summary
This section provides a thorough guide on the necessary deliverables for each phase of a business analysis project focused on developing an online grocery ordering system. The project is structured in five key phases:
- Elicit Requirements: This phase involves identifying stakeholders, conducting interviews or creating personas, and summarizing stakeholder requirements. The deliverables include a stakeholder list with roles, interview notes, and a requirement summary.
- Document Requirements: In this phase, analysts write user stories using the INVEST format, define acceptance criteria in Gherkin format, categorize requirements, and create a Requirement Traceability Matrix (RTM). Deliverables include user stories, acceptance criteria sheets, and a Business or Functional Requirement Document (FRD).
- Model the System: Analysts model the system by drawing diagrams like use case and activity diagrams and creating low-fidelity wireframes for key screens.
- Test Planning (optional): This phase entails writing test cases, mapping them to requirements, and optionally identifying defects.
- Presentation & Review: In the final phase, analysts prepare a succinct presentation summarizing the project and present it to their peers or mentors.
Throughout the section, the importance of clarity, documentation quality, and practical feasibility is highlighted, culminating in a checklist for the final output.
Audio Book
Dive deep into the subject with an immersive audiobook experience.
Phase 1: Elicit Requirements
Chapter 1 of 6
π 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 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.
Examples & Analogies
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
Chapter 2 of 6
π 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 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.
Examples & Analogies
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
Chapter 3 of 6
π 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
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.
Examples & Analogies
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)
Chapter 4 of 6
π 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 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.
Examples & Analogies
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
Chapter 5 of 6
π 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 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.
Examples & Analogies
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
Chapter 6 of 6
π Unlock Audio Chapter
Sign up and enroll to access the full audio experience
Chapter Content
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
Detailed Explanation
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.
Examples & Analogies
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.
Key Concepts
-
Stakeholder Identification: Understanding and defining the roles of individuals involved.
-
Requirement Elicitation: The process of gathering requirements through interviews and workshops.
-
Documentation Standards: Utilizing formats like user stories and acceptance criteria for clarity.
-
Modeling Techniques: Using diagrams to visualize workflow and requirements.
-
Quality Assurance: Implementing testing methods to ensure deliverables meet requirements.
Examples & Applications
Creating a stakeholder matrix to clarify roles in the online ordering system project.
Writing a user story example: 'As a customer, I want to add items to my cart so that I can purchase them later.'
Drafting acceptance criteria using Gherkin format: 'Given I have items in my cart, when I proceed to checkout, then I should see a confirmation page.'
Memory Aids
Interactive tools to help you remember key concepts
Rhymes
To elicit and list, from stakeholders, donβt miss, requirements documented, clarity is bliss.
Stories
There once was a group of hungry customers wanting to order groceries online. The BA gathered their needs by talking to each group, creating a clear path from needs to a functional online ordering system.
Memory Tools
R-E-D-D-S: Requirements, Elicit, Document, Diagram, Deliver, Systems.
Acronyms
B.A.R - Business Analyst Role
for Business
for Analysis
for Requirements.
Flash Cards
Glossary
- Business Analyst (BA)
A professional responsible for analyzing the organization or business domain and documenting its business processes and systems.
- Stakeholder
An individual or group that has an interest in the outcome of a project or program.
- RACI Matrix
A responsibility assignment matrix that clarifies roles and responsibilities for tasks on a project.
- User Story
A definition of a software feature from the end-user's perspective.
- Acceptance Criteria
Conditions that a product must satisfy to be accepted by a user or customer.
- Requirement Traceability Matrix (RTM)
A document that links requirements throughout the project lifecycle.
- Wireframe
A visual guide that represents the skeletal framework of a website or application.
Reference links
Supplementary resources to enhance your learning experience.