Learn
Games

1.4.3.2 - Deliverables

Interactive Audio Lesson

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

Eliciting Requirements

Unlock Audio Lesson

Signup and Enroll to the course for listening the Audio Lesson

Teacher
Teacher

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?

Student 1
Student 1

Isn't it a tool that helps identify roles and responsibilities?

Teacher
Teacher

Exactly! A stakeholder matrix often includes RACI—Responsible, Accountable, Consulted, and Informed. So, why do we conduct mock interviews?

Student 2
Student 2

To gather more detailed and specific information from stakeholders.

Teacher
Teacher

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

Signup and Enroll to the course for listening the Audio Lesson

Teacher
Teacher

In documenting requirements, we use user stories formatted with the INVEST principle. What does INVEST stand for?

Student 3
Student 3

Independent, Negotiable, Valuable, Estimable, Small, and Testable!

Teacher
Teacher

Great! Along with user stories, what’s the significance of defining acceptance criteria?

Student 4
Student 4

It helps ensure that each requirement can be validated through testing.

Teacher
Teacher

Absolutely! Acceptance criteria are vital for that. Let’s talk about categorizing requirements now; can anyone explain the differences between business and functional requirements?

Student 1
Student 1

Business requirements define the high-level objectives while functional requirements specify how these objectives will be met.

Teacher
Teacher

Exactly, well put! Documenting requirements is pivotal in ensuring everyone is on the same page.

Modeling the System

Unlock Audio Lesson

Signup and Enroll to the course for listening the Audio Lesson

Teacher
Teacher

Modeling the system involves creating diagrams like use case and activity diagrams. What’s a use case diagram?

Student 2
Student 2

It represents the interactions between users and the system.

Teacher
Teacher

Correct! Now, can someone explain the importance of creating wireframes?

Student 3
Student 3

Wireframes help visualize the layout and functionality of key screens before full development.

Teacher
Teacher

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

Signup and Enroll to the course for listening the Audio Lesson

Teacher
Teacher

Testing ensures that the developed system meets requirements effectively. Why is writing test cases important?

Student 4
Student 4

They provide a clear guideline on how to verify that a requirement is fulfilled.

Teacher
Teacher

Exactly! And mapping test cases to the requirement traceability matrix helps us keep track of coverage. What's an optional deliverable in this phase?

Student 1
Student 1

A defect log, to track any issues found during testing.

Teacher
Teacher

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

Signup and Enroll to the course for listening the Audio Lesson

Teacher
Teacher

In our final phase, we focus on presenting the findings. What should be included in our presentation slides?

Student 2
Student 2

It should summarize the business problem, the solution scope, and key deliverables.

Teacher
Teacher

Exactly! A concise presentation can significantly impact stakeholders’ understanding. Why do we consider recording the walkthrough?

Student 3
Student 3

It allows us to review our presentation skills and provides a reference for stakeholders.

Teacher
Teacher

Correct! To conclude, recapping the analysis and demonstrating clarity in presentation holds immense value in a project.

Introduction & Overview

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

Quick Overview

This section outlines the deliverable requirements for a capstone-style business analysis mini-project.

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:

  1. 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.
  2. 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).
  3. Model the System: Analysts model the system by drawing diagrams like use case and activity diagrams and creating low-fidelity wireframes for key screens.
  4. Test Planning (optional): This phase entails writing test cases, mapping them to requirements, and optionally identifying defects.
  5. 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

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 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

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 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

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

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)

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

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

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

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

Unlock Audio Book

Signup and Enroll to the course for listening the Audio Book

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.

Definitions & Key Concepts

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

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 & Real-Life Applications

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

Examples

  • 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

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

🎵 Rhymes Time

  • To elicit and list, from stakeholders, don’t miss, requirements documented, clarity is bliss.

📖 Fascinating 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.

🧠 Other Memory Gems

  • R-E-D-D-S: Requirements, Elicit, Document, Diagram, Deliver, Systems.

🎯 Super Acronyms

B.A.R - Business Analyst Role

  • B: for Business
  • A: for Analysis
  • R: for Requirements.

Flash Cards

Review key concepts with flashcards.

Glossary of Terms

Review the Definitions for terms.

  • Term: Business Analyst (BA)

    Definition:

    A professional responsible for analyzing the organization or business domain and documenting its business processes and systems.

  • Term: Stakeholder

    Definition:

    An individual or group that has an interest in the outcome of a project or program.

  • Term: RACI Matrix

    Definition:

    A responsibility assignment matrix that clarifies roles and responsibilities for tasks on a project.

  • Term: User Story

    Definition:

    A definition of a software feature from the end-user's perspective.

  • Term: Acceptance Criteria

    Definition:

    Conditions that a product must satisfy to be accepted by a user or customer.

  • Term: Requirement Traceability Matrix (RTM)

    Definition:

    A document that links requirements throughout the project lifecycle.

  • Term: Wireframe

    Definition:

    A visual guide that represents the skeletal framework of a website or application.