Product Requirement Template
Product requirements refer to the capabilities, functionality, or features that a product needs to have. They capture what a product should do for users to find it useful. Traditionally, they are written in a document, which also states the purpose and value of the product or feature. The gathering of requirements is one of the first steps to building a successful product. It helps to ensure that you do not leave out key elements while rushing to ship something new. To clearly lay out these requirements with your team, the Product Requirement Template should help.
Product Requirement Document as User Stories
Requirements are traditionally contained in the product requirements document (PRD) that a product manager creates to communicate what’s to be built. The document identifies who the product is for and what the target market would be able to do with it. These requirement or specification documents are voluminous in Waterfall environments, detailing the capabilities or conditions the system needs to adhere to. They are typically created before any work is done and could contain hundreds of pages.
The approach is different in Agile/ Scrum, with a preference for user stories in place of huge requirements documents. This is partly because work is done in iterations – a step-by-step approach is adopted for building the product. The Agile methodology puts less emphasis on strict documentation and focuses more on the value that a user gets.
The Template
User stories are descriptions of features from the viewpoint of the end-user. It is written in less formal language, compared to the traditional PRD. The user is at the center of attention in agile development. This explains why there is a preference for them in companies using this methodology.
So how do you define requirements as user stories? Neal Cabage’s Product Requirement Template is a helpful guide. It shows what a user story should look like or contain, plus what it takes to make them complete.
The user story takes the form: As [who] I want [what] so that [why]
- Who – This refers to the customer or the user role.
- What – The customer wants to achieve something. What is that goal or intent?
- Why – This is the reason underlying the goal or intent. What is the benefit the user gets from accomplishing the goal in focus?
Here is an example of a user story:
As a customer, I want to see recent orders in my account so that I can track order and know when it will arrive. In the above example, the “I want to” part is the “What” and “so that” is the “Why.”
While user stories can do the work of traditional requirements documents in Agile or Scrum, they are not complete without Acceptance Criteria. These are predetermined conditions or requirements that need to be met for a user story to be considered complete. This is why they are sometimes referred to as the “definition of done.”
The acceptance criteria for the previous user story example could go like this:
- List of orders for the past 12 months (sorted by recency)
- Click Order to see details of order
- Details to include order date, price, and shipping status
- Should have an easy Return button
What Makes Good Acceptance Criteria?
Rules or conditions that define the extent and requirements of user stories should ideally be:
Clear and concise – Your acceptance criteria must not be ambiguous. They should be matter-of-fact, short, and simple to understand.
User-based – What this means is that the criteria must address the problem from the user’s viewpoint. They should give a good idea of what the user gets or expects from a feature.
Testable – It should be possible and easy to test the predetermined requirements to assess whether they are met. Tests must not be ambiguous and should provide clear-cut outcomes indicating either success or failure.
