Enrol to start learning
Reading is open to everyone. Enrolling is free, and it is what unlocks the audio lessons, practice tests and progress tracking.
1.4.2. Phase 2: Document Requirements
Learn content
Interactive Audio Lesson
Unlock the classroom podcast
The transcript is free to read. A free account plays the conversation back.
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.
Unlock the classroom podcast
The transcript is free to read. A free account plays the conversation back.
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.
Unlock the classroom podcast
The transcript is free to read. A free account plays the conversation back.
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.
Unlock the classroom podcast
The transcript is free to read. A free account plays the conversation back.
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.
Overview
Short Summary
Phase 2 focuses on documenting the requirements for the Online Grocery Ordering System project through user stories, acceptance criteria, and a traceability matrix.
Medium Summary
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.
Detailed Summary
Phase 2: Document Requirements
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.
Key Activities Include:
- User Stories: Write 5-8 user stories utilizing the INVEST criteria, which stands for Independent, Negotiable, Valuable, Estimable, Small, and Testable. This ensures that each story is clear and actionable.
- Acceptance Criteria: Define the criteria for each user story using Gherkin syntax (Given, When, Then), which helps in understanding what defines the successful implementation of the user story.
- Categorization: Classify the requirements into business, functional, and non-functional types to provide clarity and structure.
- Requirement Traceability Matrix (RTM): Create an RTM to track the relationship between requirements, user stories, and acceptance criteria which aids in managing changes and validating that all requirements are met.
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.
Audio Book
Unlock the audio lesson
The script is above and free to read. A free account plays it back, in the voice you pick.
Create a free account🎯 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)
Detailed Explanation
In this phase, the main focus is on documenting the requirements gathered during the elicitation phase. You will complete several tasks, including writing user stories in a specific format called INVEST, defining acceptance criteria with the Gherkin syntax, categorizing different types of requirements, and creating a Requirement Traceability Matrix (RTM) to track requirements throughout the project.
Examples & Analogies
Think of documenting requirements like writing a recipe. Each task represents a step to ensure you have all the ingredients and instructions needed to make a great dish. If you miss a step or don’t categorize your ingredients, the final dish might not turn out as expected.
Unlock the audio lesson
The script is above and free to read. A free account plays it back, in the voice you pick.
Create a free account● Write 5–8 user stories using INVEST format
Detailed Explanation
User stories describe features from the perspective of the end user. The INVEST acronym stands for Independent, Negotiable, Valuable, Estimable, Small, and Testable. Each user story should embody these characteristics to ensure clarity and effectiveness. For example, an independent user story can be developed separately from others, making it easier to manage.
Examples & Analogies
Imagine you are planning a birthday party. A user story could be: 'As a guest, I want to have a variety of cake flavors so that I can choose one I like.' This story is valuable because it addresses the needs of the guest, and it's clear and testable.
Unlock the audio lesson
The script is above and free to read. A free account plays it back, in the voice you pick.
Create a free account● Define acceptance criteria using Gherkin (Given–When–Then)
Detailed Explanation
Acceptance criteria describe the conditions that must be met for a user story to be considered complete. Gherkin provides a clear structure for writing these criteria in the format of Given (context), When (action), and Then (outcome). This helps ensure all stakeholder expectations are understood.
Examples & Analogies
Think of acceptance criteria like the rules of a game. For a game to end successfully, certain conditions must be met. For instance, 'Given I am on the checkout page, When I click the 'Proceed to Payment' button, Then I should see the payment options.' These clear criteria ensure everyone knows what success looks like.
Unlock the audio lesson
The script is above and free to read. A free account plays it back, in the voice you pick.
Create a free account● Categorize requirements: business, functional, non-functional
Detailed Explanation
Categorizing requirements helps clarify what is needed. Business requirements define why a project is undertaken, functional requirements describe what the system should do, and non-functional requirements set quality standards (like performance or security). This categorization ensures a comprehensive understanding of expectations.
Examples & Analogies
Imagine you are building a house. The business requirement is to create a home for a family. Functional requirements would include the number of rooms, bathrooms, and kitchen specifications. Non-functional requirements might dictate that the house should withstand severe weather or be energy-efficient.
Unlock the audio lesson
The script is above and free to read. A free account plays it back, in the voice you pick.
Create a free account● Create a Requirement Traceability Matrix (RTM)
Detailed Explanation
A Requirement Traceability Matrix (RTM) is a tool that documents and tracks the relationships between requirements throughout the project lifecycle. It helps ensure that all requirements are met during development and testing, and it provides a reference point for any changes made.
Examples & Analogies
Think of an RTM as a roadmap for a journey. Just like a map shows the locations you need to visit, an RTM keeps track of each requirement, ensuring that no essential stops are missed on your way to project completion.
--
Key concepts
Core takeaways and short definitions to help you quickly recall the key ideas from this section.
- User Stories:
Brief narratives that describe desired functionality from the end user’s perspective.
- Acceptance Criteria:
Conditions that define when a user story is complete, articulated using Gherkin syntax.
- Requirement Traceability Matrix:
A tool to track the relationship between requirements and their corresponding user stories and tests.
- Categorization of Requirements:
Dividing requirements into business, functional, and non-functional for clarity.
Examples
Step-by-step examples to apply the section's ideas and test your understanding.
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.'
Memory aids
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.
Flash Cards
Glossary
User Story
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]'.
Gherkin
A domain-specific language used to describe software behaviors without detailing how that functionality is implemented; it follows the format 'Given, When, Then'.
Requirement Traceability Matrix (RTM)
A document that maps and traces user requirements with the test cases that validate those requirements.
Acceptance Criteria
Conditions that a user story must satisfy to be considered complete, typically expressed in Gherkin syntax.
Non-Functional Requirements
Criteria that specify 'how' a system performs a certain function, such as security, reliability, and performance metrics.