Best Practices for Defining Requirements

2 minute read

A User Story is a starting point for defining requirements. It is a simple sentence form
consisting of who, what, and why-to describe how the product should behave and what users can do with it. The biggest advantage of a User Story is enabling the development team to
stand in the users’ shoes to define requirements, whereas the traditional approach tends to think from the developers’ point of view. You can see the structure and an example below.

Structure: As a <who>, I want to <what> so that <why>
Example: As a user, I want to send marketing emails to clients of our product so that I can promote new products.

Acceptance Criteria are detailed requirements that are usually created after the User Story and complement it. They actually have two aspects: detailed requirements and acceptance tests. Traditionally, requirements and acceptance tests are usually created separately.
However, in Agile, Acceptance Criteria play both roles in making the process more efficient
and reducing the cost of document management.

A visual image is a wireframe, prototype, design, or any other form of visual representation that helps the development team to visually comprehend what they should build. It promotes shared understanding and prevents misunderstandings.

The 3C Model is a framework consisting of three steps to defining requirements: Card,
Conversation, and Confirmation. It helps to clarify the user story and acceptance criteria by
involving team members in the conversation.

INVEST is an acronym for Independent, Negotiable, Valuable, Estimable, Small, and Testable. It is a framework for ensuring high-quality User Stories. Following these criteria can help reduce bugs, avoid unnecessary requirements, and enable more accurate estimation.

By using this website, you agree to our use of cookies. We use cookies to provide a great experience and help our website run effectively.