Requirements and User Stories
What are we building?
In order to build a product, it's important to all understand what we're building! There are two primary ways to define those things at a high level that we use as part of our software development lifecycle. The first (and probably the most prevalent) is the user story. For any feature that is being built that an actual end user of the system will interact with, we want to define the "what" in terms of those end users. Note that for some projects, your end users may be programmers or researchers, and not typical client consumers of web or mobile applications, that's fine! The second way is the requirement. For any feature that an actual end user of the system would not be able to realistically test or observe (for example, end to end encryption or maximum latency or HIPAA compliance) but which the solution must support, we will use the term requirement. Note that if feature has both a user facing and a non user facing component (like a screen that makes API calls to the server), the user story format must be used, with the components being tasks under that story.
The User Story
All user stories are written using the following pattern: As a <type of user> I want to <do some action> so that <I achieve some goal>. This serves multiple purposes. The first is to verify that the type of user being served is in fact a valid user of your system; if you are building an application to sell cookies, and you have user stories that start out "as a real estate agent", then something has gone awry somewhere. The second is to ensure that the action that they are trying to perform is relevant to that user type and aligns to the product vision; if you have a user story that says "as a marketing manager I want to have all my personal data triple DES encrypted and stored on RAID storage" then you likely have a requirement masquerading as a user story. The final thing is to make sure that the motivating factor is understood, in the event that the action is impossible for some reason - if you have a user story that says "as a customer, I want to receive a text message when an item in my shopping cart goes on sale so that I can decide to buy it now", but it turns out that text messaging is too expensive to implement, you can explore other options that would allow for the user to be notified in order to make the buying decision that are NOT text messages.
User Story Examples
- As a social media participant, I want to be able to register for a new account using a unique email address and username so that I can use the application
- As a social media participant, I want to be able to reset my password if I have forgotten it via an emailed link so that I can regain access to my account at any time
- As a social media participant, I want to be able to edit my profile to update any and all of my personal information so that I can keep it current
- As a social media participant, I want to be able to maintain a profile picture or avatar to represent me in the platform so my connections can recognize my posts
- As a social media participant, I want to be able to remove my account and have it delete all of my posts to ensure my data privacy if I choose to discontinue using the platform
The Requirement
Requirements do not follow as proscribed a pattern as user stories, but they should capture what needs to be done, and why, similar to the user story.
Requirement Examples
- All personal data must be encrypted both in transit and at rest, using the AES algorithm, to comply with our HIPAA controls
- All API calls must return in 2 seconds or less, to comply with our customer service level agreements.
- All transactions in the application must be timestamped and logged with the user id of the person doing the transaction, to provide tracibility for due diligence controls.