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.
Let's begin with user stories. User stories are a simple way to describe a feature from the perspective of the end user. They follow the INVEST criteria, which stands for Independent, Negotiable, Valuable, Estimable, Small, and Testable. Can anyone explain one of these terms?
Independent means that the story can be developed on its own without relying on others.
Negotiable means the details can change, allowing for flexibility in development.
Exactly! Flexibility is crucial. Remember the acronym INVEST to aid your memory. Now, what do you think 'Valuable' means?
It means the story should provide value to the user or the customer.
Correct! Each story must deliver tangible benefits. Let’s finalize this session with a summary. What have we learned about user stories?
User stories should be clear, follow the INVEST criteria, and be user-centric.
Now, let’s delve into acceptance criteria. They define the conditions under which a user story is considered complete. We typically use Gherkin syntax to write these. What does Gherkin syntax look like?
It uses the format 'Given', 'When', and 'Then' to outline the scenarios for testing.
Could you give us a simple example?
Sure! For a user story like 'As a customer, I want to add products to my cart', I can say, 'Given I am on the product page, when I click the add to cart button, then the product should be added to my shopping cart.' Let’s practice. Can someone give another example?
Given I have items in my cart, when I proceed to checkout, then I should see a summary of my order.
Great job! Always ensure your acceptance criteria are clear and testable. Let’s summarize: Remember to follow Gherkin syntax when writing your criteria for user stories.
Moving on, let’s discuss how to categorize our requirements. There are business, functional, and non-functional requirements. Can anyone define what a business requirement is?
A business requirement describes what the business needs to achieve for the project.
And functional requirements detail how the system should behave to fulfill those needs.
Exactly! Now, why are non-functional requirements important?
They specify the quality attributes of the system, like performance and security, right?
Correct! So now, can anyone give examples of each type of requirement?
For business, it could be 'increase customer satisfaction'; for functional, 'the system must allow users to reset their password'; and for non-functional, 'the system must load in under 2 seconds'.
Well done! Remember how to classify requirements as it’s crucial for proper documentation.
Finally, let's explore the Requirement Traceability Matrix. What do you think the purpose of the RTM is?
It helps track the relationship between requirements and user stories.
Isn’t it also used to ensure all requirements are met through testing?
Absolutely! An RTM ensures that every requirement can be traced through to its corresponding user story and the tests that validate it. Let’s recap how to set one up. What columns might we include?
We should include Requirement ID, Description, User Story ID, and the test case ID.
Great! Also consider including the status of each requirement. Can anyone summarize what we've gone over in this session?
We’ve learned that the RTM is essential for tracking requirements throughout the project for clarity and validation.
Brief narratives that describe desired functionality from the end user’s perspective.
Conditions that define when a user story is complete, articulated using Gherkin syntax.
A tool to track the relationship between requirements and their corresponding user stories and tests.
Dividing requirements into business, functional, and non-functional for clarity.
Example of a user story: 'As a shopper, I want to view items in my cart so that I can review my purchases before checking out.'
Example acceptance criteria using Gherkin: 'Given the user adds an item to the cart, when they view the cart, then the item should be displayed in the cart summary.'
For requirements that we write, make them clear, precise, and right. User stories in a line, will help us meet the timeline.
Imagine a customer named Sam who wants to shop online. He is happy when he adds items to his cart, but dislikes waiting too long while the interface loads. This showcases the importance of user stories and non-functional requirements.
To remember the requirement types: 'Bingo Freestyle' - where B stands for Business, F for Functional, and N for Non-Functional.
To remember Gherkin, think of the acronym 'GWT' for Given, When, Then.
Term
User Story
Click to flip
Term
Gherkin Syntax
Click to flip
Term
Requirement Traceability Matrix (RTM)
Click to flip
Term
Acceptance Criteria
Click to flip
Term
Non-Functional Requirements
Click to flip
A concise description of a feature from the end user's perspective, often written in the format 'As a [type of user], I want [some goal] so that [some reason]'.
A domain-specific language used to describe software behaviors without detailing how that functionality is implemented; it follows the format 'Given, When, Then'.
A document that maps and traces user requirements with the test cases that validate those requirements.
Conditions that a user story must satisfy to be considered complete, typically expressed in Gherkin syntax.
Criteria that specify 'how' a system performs a certain function, such as security, reliability, and performance metrics.
Phase 2 focuses on documenting the requirements for the Online Grocery Ordering System project through user stories, acceptance criteria, and a traceability matrix.
In this phase, students transform elicited requirements into formal documentation. They practice writing user stories using the INVEST criteria, defining acceptance criteria with Gherkin syntax, categorizing requirements, and creating a Requirement Traceability Matrix (RTM) for the Online Grocery Ordering System.
In this instructional phase, learners are tasked with taking the identified stakeholder needs and transforming them into structured documentation critical for the success of the project.
The completion of this phase results in comprehensive documentation that includes User Stories, Acceptance Criteria Sheets, a Business Requirements Document (BRD) or Functional Requirements Document (FRD), and an RTM formatted in Excel or table format. This phase is foundational, laying the groundwork for future system modeling, testing, and project presentation.