Tasks

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?

Are customers considered stakeholders?

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

What about store staff and delivery teams?

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?

I think we could conduct interviews or create stakeholder personas.

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?

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

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.

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

We can use the INVEST criteria!

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?

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

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

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

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.

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

It helps visualize how users will interact with the system!

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

We could also create activity diagrams to show flow!

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

Wireframes help us visualize the layout of the user interfaces.

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.