June 29, 2020
Recently found this visual of a Software Requirements Specification (SRS) outline in my archives from 2010.
The User Story
Albeit with the rise in popularity of Agile Software Development, the User Story has been a key element of the Requirements Expression Phase.
What is a User Story?
User stories follow a very specific format.
As a blank, I want to blank, So that blank.
What’s so special about User Stories?
User Stories are meant to keep all of the requirements of your system to a consistent format. They’re easy to write, easy to read, and easy to evaluate.
The first blank signifies the stakeholder role for whom the requirement is being formed (i.e., the ‘who’).
The second blank signifies the task or function the stakeholder wants to resolve using the product.
This is the meat of the requirement and is usually what people think of most when they think: requirement. This part specifies the “what” of the requirement.
The final blank of the user story specifies “why” the user story is needed in the first place. This is often skipped when user stories are created. But it offers a key insight into their requirement as it gives context to the requirement about the value or benefit it offers, which should align with the product’s goals or vision.
This part specifies the “why” of the requirement.
Adapted from: https://www.coursera.org/learn/client-needs-and-software-requirements