Requirements vs. user stories in software development
User stories fulfill the same purpose as software requirements but through different means. Learn how to write user stories and how they relate to software requirements.
In software development teams, it is easy to confuse software requirements with user stories. After all, both describe what the stakeholder expects from the application in terms of design, functionality and usability.
At the highest level, software requirements are critical. Without clear, unambiguous requirements, development teams cannot fully deliver on the expectations of their stakeholders. Therefore, software requirements form the basis of all aspects of software development. Since there are many types of and approaches to software requirements, it is important that development teams and their stakeholders understand the differences to facilitate and develop software that meets and exceeds expectations.
What are software requirements?
Business analysts usually present software requirements to development teams in the form of a requirements document. They are comprehensive, which makes them useful not only in actual development, but also in traceability and documenting test coverage.
Effective development teams use many types of software requirements. For this reason, teams often use software requirements in the Waterfall methodology and often associate them with large, heavily regulated projects.
In the context of the Waterfall methodology, software requirements document development begins with design requirements, followed by technical and nonfunctional requirements and then functional and usability requirements. Teams complete requirements documents before development starts. If they need to make changes after approval, they must follow a change control process.
Requirements documents include functional and nonfunctional requirements, whereas user stories are increments of functional requirements.
What are user stories?
User stories are a method by which teams develop requirements within the Agile methodology. Since Agile focuses on incremental development to create potentially shippable software in each sprint, requirements must be focused and detailed. Therefore, user stories can be thought of as increments of functional requirements.
User stories are components of Agile epics, which describe the application functionality in terms of the big picture. Teams write user stories from the perspective of the end user, describing what the user wants to do and why. Teams develop user stories and place them in the backlog until they are assigned to Scrum teams' sprints.
Software requirements provide a comprehensive view of the application and include both functional and nonfunctional expectations, whereas user stories provide details on small increments.
Software requirements vs. user stories
There are major differences in how testing teams implement requirements and user stories. Software requirements provide a comprehensive view of the application and include both functional and nonfunctional expectations, whereas user stories provide details on small increments. This means testing with user stories enables teams to delve deeply into the details and is more flexible and adaptable to change.
Benefits of testing with requirements include the following:
Traceability. Tracing test cases to each software requirement provides an effective approach to meeting compliance requirements.
Test coverage. Linking test cases to requirements ensures full test coverage.
Benefits of testing with user stories include the following:
Collaboration. User story-based testing invites collaboration as developers and product owners need to discuss the story and any necessary changes.
User focus. Testing with user stories enables a clear focus on the user and ensures that the user's needs are met.
Early defect detection. The iterative approach of user story testing lets teams find defects earlier in the testing process.
How to write a user story
Well-written user stories have the following elements:
Feature. The epic to which the user story is related.
Scenario. The short description of the feature, i.e., the story name.
User role. The persona who provides the point of view.
Achievable action. The value which the persona gains -- this narrows the perspective.
Desired business value. The value the business stands to gain from the achievable action.
Acceptance criteria. The criteria that work must meet in order to determine completeness.
The most effective user stories are written from the user's perspective. They are designed to answer three questions:
Who wants something? The answer describes the user persona and their role.
What do they want? The answer provides the action that the user wants to do.
Why is this needed? The answer provides the benefit that the user needs to achieve.
User stories are formatted as follows: As a <user>, I want to <perform some action> so that I can <achieve some benefit>.
Acceptance criteria are a critical part of the user story. The acceptance criteria describe in detail how to determine if the requested functionality meets the needs of the user. Depending upon the type of user story, teams can write acceptance criteria as rules or as scenarios.
When teams use the rules approach, acceptance criteria are usually a numbered list that defines the criteria for the action. Scenario-oriented acceptance criteria are expressed in a "given, when, then" format -- given (list preconditions), when (describe the action taken), then (the expected result). Teams can write and link test cases within user stories using acceptance criteria.
Teams often use INVEST criteria -- which stands for Independent, Negotiable, Valuable, Estimable, Small and Testable -- to determine that a user story is ready for development.
User stories are suited to Gherkin syntax, as this format provides a structured and understandable way to define scenarios and expected outcomes. Gherkin syntax is plain language text that can be used with the software testing tool Cucumber to create code directly from requirements. This approach is most often used with behavior-driven development.
Both software requirements and user stories are effective approaches to defining needs in a software project. Although requirements tend to be associated with the Waterfall methodology and user stories form the basis for Agile incremental development, both can and should be used for effective testing, complete traceability and test coverage.
Gerie Owen is lead quality engineer at ZS. She is a conference presenter and author on technology and testing topics, and a certified Scrum master.
