Loading the lesson
Loading the lesson
Search AllRounder.ai
Search the courses, subjects, tracks, games and features, or jump straight to a page.
Search the courses, subjects, tracks, games and features, or jump straight to a page.
Learn it your way
A short class with Sarah and her students. The other ways are under More.
Sign up free to listen. Transcripts are free to read.
Today, we'll start with the first phase, which is eliciting requirements. Can anyone tell me what we mean by eliciting requirements?
Is it about gathering information about what the users need?
Exactly! Eliciting requirements involves engaging with stakeholders to understand their needs. It’s crucial to identify all key players, such as customers and staff. Can anyone name a few stakeholders for our grocery project?
Customers, store staff, and delivery teams would be stakeholders.
Great! Now let’s create a stakeholder matrix to clarify their roles. The acronym RACI can help us remember: Responsible, Accountable, Consulted, and Informed.
So, we’ll assign who is responsible for what task regarding requirements?
Exactly! A stakeholder matrix can clarify responsibilities and facilitate effective communication. Let's summarize: identify stakeholders, conduct interviews, and document findings.
Now that we've gathered our requirements, how do we organize and document them effectively?
We could use user stories?
Exactly right! User stories should follow the INVEST criteria: Independent, Negotiable, valuable, Estimable, Small, and Testable. How does that sound for our grocery project?
It sounds structured, but could you explain the Gherkin format for acceptance criteria?
Absolutely! The Gherkin format uses 'Given-When-Then' statements. For example, 'Given I am a customer, when I add an item to my cart, then it should appear in my cart.'
That simplifies defining what needs to work!
Exactly! By following these guidelines, we ensure that everyone has a clear understanding of the requirements. Always remember to categorize them into business, functional, and non-functional requirements!
Moving on to Phase 3, we begin modeling the system using diagrams. Why do you think this is important?
It helps visualize how users will interact with the system!
Exactly! We’ll create a Use Case Diagram for ordering, along with an Activity Diagram to depict the customer flow. Who can explain what a Use Case Diagram entails?
It shows the interactions between users and the system for specific functions.
Well done! Let’s not forget about creating low-fidelity wireframes. These sketches give a basic representation of key screens. What tool could we use for that?
We could use Balsamiq or Figma!
Right! Visual tools facilitate understanding and promote feedback. Let’s summarize: User flows, diagrams, and drafts help visualize the system and enhance clarity.
If time allows, we can conduct Phase 4 – Test Planning. Is anyone familiar with why we write test cases?
To ensure that the system meets the requirements and functions as expected!
Exactly! We’ll map test cases back to our requirements in the RTM. Let's say one requirement states a user can schedule a delivery, what might be a test case for that?
We could check if a user can select a delivery time and confirm the order?
Spot on! By planning our tests, we enhance the likelihood of identifying defects before launch.
Finally, we need to present our project. What elements do you think are necessary for our presentation?
We should include the business problem, proposed solution, and user stories!
Correct! A summary presentation should include all facets clearly and engagingly. How can we make our presentation more engaging?
Including visuals like diagrams and wireframes can help!
Absolutely! Visuals enhance clarity and engagement. Let’s remember to review what we’ve learned through this project: Eliciting, documenting, modeling, testing, and presenting our findings.
Engaging with stakeholders to gather their needs.
Short narratives describing a feature from the user's perspective.
Specific conditions under which a feature is accepted.
Visual representation of the functionality of a system.
Basic visual sketches representing UI layouts.
In malls or stores, to get what's in store, elicit their needs, and open the door.
Once upon a time in a grocery store, a business analyst listened at the door. They asked the customers what they wished to see, creating a system designed perfectly!
Remember the acronym RACI: Responsible, Accountable, Consulted, Informed for tracking who does what.
To remember user story quality: INVEST – Independent, Negotiable, Valuable, Estimable, Small, Testable.
Term
What is Elicitation?
Click to flip
Term
Define User Stories.
Click to flip
Term
What does Gherkin represent?
Click to flip
The process of gathering requirements from stakeholders.
An individual or group with an interest in the project.
A brief statement defining a feature from the user's perspective.
A language used to define acceptance criteria in a structured format.
A diagram showing the interactions between users and the system.
A diagram that illustrates the flow of control or data in a system.
A visual guide that represents the skeletal framework of a website or app.
This section outlines the process of preparing a mini-project in business analysis, covering requirement elicitation, documentation, system modeling, test planning, and presentation.
Learners will engage in a capstone-style activity simulating a real-world business analysis project, where they will elicit and document requirements, model the system, conduct optional test planning, and finally present their findings related to the development of an online grocery ordering system.
In this section, the capstone activity aims to provide learners with a comprehensive understanding of the business analyst's role throughout a project lifecycle. The primary objective is to prepare and present a complete business analysis deliverable pack by working through five phases: