The collection of user requirements can be a difficult and time-consuming process, working towards Agile principles the collection of requirements should be a collaborative process helping the requestor (customer/colleague) to discover what they want through requirements collection sessions to build a document that contains the necessary information for the design teams to build a solution that meets those “User Stories” to the desired “Condition of Satisfaction”.
As a template to collect these requirements it is fairly simple, you just need some columns as follows to allow you to collect the information you need, you may of course add additional over time.
- Identifier – A unique alphanumeric code to identify a particular requirement.
- Source/Requestor – Who (or what group) is this requirement emanating from.
- User Story – A user story is a statement (or statements) that describes a requirement in a way that makes it easily digestible.
- Condition of Satisfaction (Definition of Done) – A statement (or statements) that provide a measurable (beit it qualitatively or quantitatively) definition of how we decide that the User Story has been successfully implemented (i.e. done).
- Requirement Status – Status of if it has been accepted, rejected or needs clarification.
- Notes/Rationale – Any notes needed to provide additional context.
Definition of Terms
The definitions of terms used within requirements collection.
Epic
A user story that is (very) general in scope, i.e. a strategic requirement. An Epic describes a high level requirement, for example: “As a system administrator I want a fully resilient solution so that I can offer a fault-tolerant service to my customers”. An Epic might encompass a number of “User Stories” within it.
User Story
A user story is a statement (or statements) that describes a requirement in a way that makes it easily digestible, it should be something that is achievable and deliverable by 1 FTE within 8 Hours (1 Day) roughly as a guide, a user story may need to be bigger than this in certain cases, however; but this is rare.
User Stories should be technology-agnostic. It should be written from the point of view of the business need and should not presuppose any particular (technological) solution/delivery method within its wording unless it is impossible to write a user story without it. An example would be if you had an existing product that needed to communicate with a specific database technology (outside of the scope of this activity), you may need to specify that technology within the user story, even though it does presuppose or direct the (technological) solution/delivery in some way.
Condition of Satisfaction (Definition of Done)
A statement (or statements) that provide a measurable (beit it qualitatively or quantitatively) definition of how we decide that the User Story has been successfully implemented (i.e. done). A condition of satisfaction again should be technology-agnostic (where possible) unless its impossible to define it without.
Functional
A requirement that states “what the product does”, e.g. a functional requirement of a washing machine is that it washes your clothes.
Non-Functional
A requirement that states “characteristics about the product”, e.g. a non-functional requirement of a washing machine would be that it is quiet.
Requirements Collection Techniques
These are techniques (or just questions) you can ask of the requestor to assist both getting at the minimum the requirement articulated, but once you have a requirement, improving and clarifying it to bring out the true meaning so that all those involved come to a common understanding of what is required, by when and how it being complete can be measured; thus providing the design (and delivery teams) what they need to design a solution to meet the requirements and for it to be delivered to the desired specification.
Use a Straw Man
The use of a straw man can be helpful in getting you going, avoiding the cold start, its daunting trying to write a requirement from a blank page. So instead listen to the requirement, then write a first pass at it for the requestor to review and say: “yeah that’s it”, or “now what I meant was” or “yeah kinda, change this bit”.
User Story Format
A user story should be written in a form that describes the requestor, the input and the output (in general terms).
As an X I want/need Y so that I can do Z.
For example:
As a System Administrator I want the system to provide a programmatic interface (e.g. an API) so that I can manage the system settings without needing to use a GUI and can programmatically maintain the system.
As a User I want to be able to retrieve information from the system so that I can easily determine which samples are reaching the end of their life and need to be destroyed to ensure compliance.
Don’t Make Assumptions
Ensure that the requirements’ collection is performed and documented within the same meeting, i.e. write directly onto the sheet as you are discussing with the requestor, don’t leave things to make notes later. Don’t add requirements outside the requirements meeting (unless you really know for sure) and don’t add requirements from the point of view of another party (that is not you) to avoid putting words into people’s mouths.
Ask for Requester to: “Describe to me your Utopia for this?” (Start High Level)
Ask the requestor to “Paint” you a picture of what your ultimate goal/ideal situation would look like for this requirement/request, you should start high level, to get the birds eye view, then work you way down into the individual User Stories to support it.
Some ideas to jog discussion:
- What obstacle/s would be removed by moving to the new solution?
- What is your driving factor for this request?
- What are you trying to fix with this solution?
- What will the ideal solution/situation mean in your daily activity?
- You are looking for things like “it means I won’t spend so much time doing XYZ”, “It means I won’t get into trouble for not having a secure DR plan”, “I will have a modern process for doing X ………which maybe indicating new tech on the horizon AI… etc.
Ask for Requester to: “Describe to me what it will mean if the project can’t be done?”
As the requestor to describe the worst case, i.e. if we didn’t do this what would happen? Here you’re looking for the requestor to question themselves or their own thinking to draw out the value of what they are looking to achieve.
Some ideas to jog discussion:
- What would happen if this change (or solution) is not made?
- If the answer is nothing, then you’ve identified that User Story (requirement) may not have value, so could be assigned “Won’t Have” or “Could Have” status, definitions of these are explained below.
- You’re looking for them to say something like “if I don’t get this, we’ll get fined by the ICO, or if I don’t get this we’ll have increased risk of X, or we won’t be able to do Y”.
- What have you tried so far, and what parts of that have worked?
- What have you tried so far and what parts haven’t worked? And why do you think that is?
Ask the Requester “Why” Five (5) Times
Can be very annoying for the requestor, but can help you drill down each level of the request and ask “why” at each level.
For example:
“I want to have an off-site copy of my data and processing”
“Why?”
“I need to be able to have 2 copies of the data”
“Why?”
“Because I need to ensure the data is recoverable in the event of a failure”
“Why?”
“Because I have a contractual obligation to ensure the data is safe”
Okay, that wasn’t five, but you get the idea, and you’ve managed to drill down to the source of that particular requirement.
Ask the Requester: “Describe to me the process you envisage and the steps you think are needed to get there?”
Helps you get an idea of what they think this involves and what steps they think they need, you’re looking here for them to show gaps in their own understanding or their own processes.
Create a SWOT of the Current Solution or Their Current Situation
The Weaknesses and Threats may indicate why they are trying to move and what it is they are needing to achieve, if they have a weakness (internal) or a threat (external) these will be driving a need, this can help you identify where these are coming from, what the requirement might need to look like, and also help you define its priority in terms of Must-Have, Should Have, Could Have or Won’t Have (see description below).
Ask the Requester: Who will be most affected by this change (if it does or does happen?)
To see If any unexpected players are identified, or maybe it challenges you perception of the stakeholder group.
Always Clarify the Terminology Used by the Requester
For example: e.g. Pipeline, Cloud, data – make sure as a group you are talking the same language with the same reference points from the outset otherwise all the subsequent questions can have a bias which may lead to unintentional results in the User Stories or the Conditions of Satisfaction.
Ask the Requestor: “What does it not need to have?”
As a way to determine must have, could have, should have and Won’t H
MoSCoW – Must Have, Could Have, Should Have and Won’t Have
A method to define the priority of a User Story (Requirement), this should be based off the clarification you have obtained with the techniques described on this guidance. Having 20 User Stories all of which are “Must” isn’t necessarily practical, you need to whittle them down to what you can achieve within the activity full stop, or what you can achieve within the activity but which requirements are most important in this particular phase or activity, or which things are just not going to happen.
- Must Have – A requirement that must be delivered.
- Should Have – A requirement that must be delivered, but can be delayed, useful in situations or solutions where you are incrementally adding functionality over time. Relevant in delivering the MVP (Minimum Viable Product), i.e. “Must Have” is the MVP, a “Should Have” becomes something that will be there but perhaps not in version 1.0, it would come in version 1.1.
- Could Have – A requirement that is optional or a nice to have, something that can be added if there is time, but not on the critical path.
- Won’t Have – A requirement that won’t be delivered, it may be something that the group feels is no longer relevant, so is discarded, but you still want a record in case it is needed eventually or as a guidance to other requirements. It may also be something that is technically impossible, breaks a law or cannot be delivered without breaching an internal security policy.
Minimum Viable Product
Essentially a statement or statements of what will be the minimum acceptable solution/product to be delivered by the requestor, it can be helpful to break a deadlock.
Defining and agreeing what version 1.0 will look like, helps you discard or deprioritise User Stories to allow you to make progress with a known discrete solution, avoiding scope creep and at least delivering something of value, rather than continuing on trying to work out what everything should look like. I.e. “Not letting perfect be the enemy of good”.
Also, helpful when you are able to agree with the requestor phases (or sprints) of activity to incrementally add functionality over time from a backlog of requirements that are prioritised and taken forward accordingly.
Define What You are Willing to Deliver as User Story or User Stories
As a way to break a stalemate, you define what you are willing to deliver based on your understanding of their requirements.
Can be useful to limit scope to something manageable and deliverable, but can also help define where the edges are, if you’re defining the edges for them, you find what is left over, and if what is left over is vast, you’ve helped work out what’s missing and also if you need to reconsider the whole scope of this particular activity.
Conclusion
Hopefully the summary of the requirements gathering techniques I’ve collected will give you some ideas and guide towards assisting your own collection of requirements from stakeholders, customers or colleagues.
