This article will cover some useful techniques and methods of working with requirements. Here are some simple tips and tricks for developers on how to manage requirements.
The first steps while working with requirements
The first step while working with requirements is that they must answer the following questions:
- Is the requirement complete?
- Is the requirement clear?
- Is the requirement implementable?
- Is the development plan clear and acceptable?
To sum up, the requirements must be SMART:
Documentation’s attributes
The next step can be organizing requirements into the right structure in a document form. This can help with:
- minimizing the number of requirements,
- understanding large amounts of information,
- finding sets of requirements relating to particular topics,
- detecting omissions and duplications,
- eliminating conflicts between requirements,
- managing iteration (e.g., delayed requirements),
- rejecting poor requirements,
- evaluating requirements,
- reusing requirements across projects.
The most basic form of requirements document should include:
- project name,
- project goal,
- scope statement,
- stakeholders,
- timeline,
- business requirements,
- technical requirements.
Presenting stakeholder requirements as a set of statements may help to put a particular capability in context, which makes it easier to understand what is being requested. Each statement should contain only one system capability and clearly provide information about who will perform what action and what should happen at the end of that activity. If there are some aspects of performance or constraint associated with the requirement, they may also be added to that statement.
Analysis of the request or an issue isn’t complete unless the recommendation/conclusion is explained in one simple statement. Here is an example of a typical capability requirement statement:
The <stakeholder> shall be able to <capability> within <performance> of <event> while <operational condition>.
In addition to the requirements statements, gathering and adding additional annotations and descriptions to the documentation is helpful. They may be technical and non-technical texts and will support understanding the requirements.
Here are some examples:
- background information that provides the context to the requirements,
- definition of the scope of the requirements (what is included and what is excluded),
- definitions of terms used in the requirement statements,
- descriptive text that bridges different sections of the document,
- stakeholder descriptions of the business process,
- references to other documents and links.
“Tell me why” – 5 whys technique
The simplest technique that allows us to reach the bottom of the root cause or the reason that lies at the center of the matter is the technique of asking 5 why questions.
Each “why” question brings us one level deeper into understanding the fundamental nature of the issue. You should ask as many why questions as possible until the lowest possible level of detail is uncovered and no more answers can be provided.
It also helps to reveal the true reason behind the request and establish a business objective, which sets the direction and points to the project’s final output.
Here is an example of how the 5 Why technique works. A colleague arrived late to the team meeting, explaining it was not their fault but was caused by a parking ticket. A few questions were asked about the ticket, and it turned out the parking ticket was a consequence of other actions, not the cause.
Q1. Why did you get a parking ticket?
A. I parked in a spot I wasn’t meant to be in.
Q2. Why?
A. I was running late, so I parked there to get to work on time.
Q3. Why?
A. I got up late.
Q4. Why?
A. The alarm didn’t go off.
Q5. Why?
A. I stayed up late to watch a film and forgot to set it.
After asking 5 “why” questions, we went down 5 layers into the button of the problem, and the real root cause was uncovered. Once the true root cause is identified, it is easier to apply the proper solution, which will prevent the problem from happening again.
The devil in her heart – the devil is in the details
It is very common to ignore diving deeper into seemingly simple requests. At first glance, it may appear to be a very obvious and straightforward requirement. However, you might be familiar with the situation when a business stakeholder asks for a tent, and the developer delivers a bed. They both serve the same purpose but are completely different objects. That is the outcome when there is not enough time and effort spent on understanding the problem’s true nature or the stakeholder’s real needs. Time and money are not well spent.
Don’t assume you fully understand the request or a problem, even if it appears very clear at first sight. There might be many underlying requirements, dependencies, and constraints that you may not be aware of. Some of them may have more significant implications. It can be anything from how the business process is set up and how the new system fits into that process to technical limitations. The unknowns will play a crucial role in shaping your analysis.
To avoid challenges, don’t be afraid to ask many questions, and don’t rely on assumptions.
Signed, sent, delivered – review, confirm and approve
The process of requirements gathering is an iterative and incremental activity. Don’t underestimate the value of having a review session with your stakeholders while gathering requirements. This ensures you and your stakeholders are on the same page every step of the way and that you have the same understanding of the problem or request and the nature of the solution being designed to support it. Such sessions may help clarify any doubts and confirm stakeholders’ expectations.
It never hurts to confirm your understanding. When somebody mentions a request, summarize what they’ve shared with you. This quick summary gives them the opportunity to confirm the direction you are taking or correct you before you start development.
The review may refer to going through meeting notes, user stories, diagrams, models, or any other type of requirements container. Make sure that such a session ends up with requirements getting the final confirmation and approval. This officially ensures that the project is going in the right direction.
I have my mind set on you – focus on business needs, not tools or solutions
Every project ends with success when the business request is fully met and satisfied. That is why focusing on the stakeholders’ needs is so important. Requirements should reflect the nature of the problem or demand. A reasonable requirement should reflect a solution to a business challenge. Understanding the core need of the product is one of the most important tasks during the requirements-gathering process.
Set your mind to understand the problem from their perspective rather than jumping into the final tool you want to use to solve it. Even if there is a system you already know and find a perfect candidate, it may require some adjustments. The system must be adapted to the user, not vice versa. Only then will the solution bring value, and only then will it be used by the users.
Once you fully understand the problem, you will identify the gap between stakeholders’ needs and any existing product you may have in mind. Remember: requirements are about the what, not the how.
Thank you for your time!
***
You can also find the author’s previous article on the blog: Requirements 101 – what you need to know to get you started
Leave a comment