Solving the requirements puzzle
The most important single aspect of software development is to be clear about what you are trying to build. — Bjarne Stroustrup
The genesis of every new innovation is an idea which was laughable at first. It is only after the requirements are fleshed out, the idea starts to take shape of a software.
That’s why the very first step in any software development life cycle is gathering requirements. During this phase, the product owners state the expectations of the project including who are the intended users, how they have visualized the product to look/work or any other specific information that the team needs to know before the development starts.
If you look at the dictionary definition of requirements, it defines it like this- a thing that is needed or wanted. Quite apt! Why would anyone make something which is not wanted?
However, surprisingly, that’s what we struggle with software development these days. We are building things which nobody wants. We fall in love with dreamy requirements. Often, we misconstrue what the other person is trying to convey and build an altogether different product.
I found the below comic very appropriate in the context of gathering wrong requirements and building a product which is far far away from customer’s expectations-
I hope you get my point.
This problem is not new. Even during the waterfall days, requirement gathering phase was a puzzle for product owners and developers. It was one of the areas where painstaking efforts were needed to take care of the requirements. But alas! By the time the project was completed and came out in the market, it turned out to be nothing close to what users had wished for a few years ago. The cycle was endlessly annoying and the entire blame was put on ‘continuous change in requirements’.
This was the turning point when the Agile manifesto came as the Knight in shining armor and promised to ease out the pains software development.
But here’s the thing- whether it’s agile or waterfall, there are certain facets of requirements gathering that do not differ.
To ‘gather’ means to assemble or collect. In the context of software, it’s never as simple as it sounds. Requirements aren’t scattered all over the surface and we aren’t just supposed to pick them up. True requirements are rarely lying out there. Looking at you with hopeful eyes and saying to you- “I have been here for long. Why don’t you free me up from this wilderness? Get me into the code, please.”
It is much more complex than that. It’s equivalent to digging. The real requirements live in dark shadows. They lie deep under the surface and are hard to spot; hard to dig.
Why requirements are so hard?
“The greatest challenge to any thinker is stating the problem in a way that will allow a solution.”― Bertrand Russell
Requirements are hard because communication is usually hard. Look at it like this- if someone finds it hard to communicate their problems or if the person at other end finds it hard to understand what troubles the user, then there is no way in which we can arrive at a solution.
I am sure you have heard of Chinese whispers. The similar happens in software development. By the time, a requirement reaches developer, the metamorphosis has already happened. This is not the only challenge though. There are others as well. Like, changing business context, conflicting priorities, over-specification, under-specification, lack of empathy with users etc.
With my experience, I can say that lack of empathy for user’s problems and broken communication are two of the topmost reasons that make requirement gathering hard. And that is the reason why extensive digging is required.
Need inputs on how to do that? Below are my recommendations-
Know your users
“Know thy user, and YOU are not thy user.” — Arnie Lund
Users play a crucial role in the requirement gathering phase. It is they whose problems we intend to solve by building that product.
Can problems be understood without understanding the users? Absolutely no!
To know users, it is not only important to know their personas and their needs but to know why they have that particular need. In Agile, user stories cover this part in ‘so that …’ phrase.
Let’s take an example-
You need to build a store management software. One of the requirement is: As a supervisor, I should be able to add new employees to the system so that I can manage their on-boarding.
But is this the real requirement? This requirement shows no empathy to the supervisor. It may actually be adding a burden to his job. How many employees does she add in a day, week or a month? It could be anything from one employee to one hundred employees in a month.
What problems do supervisors face with on-boarding? How we as engineers can solve them? How can software enable the supervisor to do her work more efficiently? These are some of the very important questions which can only be answered when you spend time with your users and ask the right questions. If the situation permits, be with the users. See them doing tasks and note down the observations. This will go long way in setting the context for requirements coming in future. Know their motivations and pain points- try to seek answers to the five W’s (why, who, what, where, when) with just enough clarity.
If you empathize with the supervisor, the real requirement could be: As a supervisor, I need the system to help me in on-boarding new employees in the easiest and least time-consuming way so that I can focus on other things.
Even this is somewhat complicated. Why should supervisor be spending time filling all the details that the employee knows best? How about something like- as a supervisor, I should be able to generate a link for an employee which they can access to add their personal details. Later, their profile can be approved and activated after verification.
Simplicity always wins
In character, in manner, in style, in all things, the supreme excellence is simplicity. -Henry Wadsworth Longfellow
The moment requirements start becoming monstrous to implement, or to understand or stop making sense- it’s time to take a pause and breathe. Take a step back. Probably, the ship is sailing in the wrong direction. Probably, you had been working on the wrong idea all along. Try to go back and understand the context; the why. You can borrow Sakichi Toyoda “five whys” theory which is one of the ways to approach your ’why’.
As project implementation progresses far into the timeline, context is often lost. Which is why every requirement has to be contested and questioned if it brings complexity into the implementation. There could be simpler ways to do things and we might have overlooked them. So, try to think rationally and keep your solutions simple.
Save yourself from over-specification
Perfection is achieved, not when there is nothing left to add, but when there is nothing left to take away. -Antoine de St. Exupery
Going overboard with anything is usually worse than being under. It takes the focus away from the core of the problem and engulfs you in tiny details. I found an interesting blog which does the comparison between different styles of writing user requirements.
If not reviewed thoroughly, specifications may lead to cost overruns. There could be a simple ‘nice to have’ which do not provide much of the value to users. But will eat away the cost in the implementation. Another kind of over-specification could be elements of technical design in the requirements itself. It is better to keep requirements coarse and leave finer details to be discovered later. If you are seeing a lot of requirements churn, one of the reasons could be, you are specifying too much and too early.
Look beyond the functional requirements
There are two kinds of needs- one, which talks about ‘what’ the user wants to achieve. The other is ‘how’. What is typically about the features in the application. How tells about the experience in using the application.
Additionally, you must also identify requirements that aid in the usability of the application. Because if the application isn’t easy to use, responsive and resilient, users won’t be happy using it. Such requirements are called non-functional requirements.
Non-functional requirements (NFR) should be in focus all the time. Usually, most of the non-functional requirements are common across the application. They can be documented at one place and can be linked with other functional stories or features as applicable.
Do not ignore operational needs
This is one area that is usually missed. Especially during the starting phase of the project. It bites very hard in later phases. Once application gets traction and users start using it, there is pressure to release new features quickly. At the same time, the operations team is also getting formed. the operations team has support staff, administrators etc. Some of the functions they do include- handling user’s complaints, enabling on-boarding of new clients (if SaaS), monitoring the health of the application, managing deployments, data backup and archiving etc.
More often than not, when building products, these functions are never thought of. Resulting into the missing provision of these in the technical design. Then they will have to be retrofitted later on. And, retrofitting is way more costlier than it would have been if it had been done all along.
Keep an eye on business policies
To improve is to change; to be perfect is to change often. — Winston Churchill
Do not treat requirements as the Gospel of Truth. They all come with an expiry date. In today’s times, changes are happening faster than you can imagine. It is important to anticipate what could change and what could remain static.
Business rules are termed as policies. And changes often happen in business rules. So, it is important to dig policies out of the requirements and document them in a way that they are referenceable.
Also, policies should not be hardwired into the code. They should be kept separately from the code. The code should implement abstractions and not the policies. This way, it will be easy to implement ever-changing business rules and workflows without breaking the system every now and then. In their book — ‘Pragmatic Programmer — From Journeyman to Master’, Andrew Hunt and David Thomas have addressed the need and ways of metaprogramming at length. Metaprogramming is all about programming for the general case and putting specifics somewhere else.
Maintain a glossary
Communication has always been challenging. How often do you hear from your colleague, friend or your family member — “I never meant that”. It happens way too often. It happens so many a times that product owner or your peer meant something else and it is understood as something different.
For example, there could be a different meaning of ‘client’ and ‘customer’ in a project. Especially if it is a SaaS project. Not knowing the difference can lead to a lot of confusion. As your project evolves, new team members may join in. They won’t have the same context as old people in the team. It is always very helpful to maintain a project glossary where all the common terms used in the system are defined clearly. All the participants, product owner, engineers, support staff etc. can use a glossary to have a common understanding when collaborating on requirements or design or anything else.
I can’t stress enough on the importance of gathering right requirements if you want to build a product that conforms to the needs of the users. There are many techniques and methods which you can use to collect the right information.
I understand, all of this can get too overwhelming at first. But this step is critical if you want to develop a product which users love to use. Just make sure that you do not confuse requirements with design or architecture. Requirements are needs. And if you are able to capture this one right, you have conquered half the battle.
I wrote this blog for our Medium Publication- Unboxing Product Management. The publication is a weekly column by leaders of Quovantis to share their learning and knowledge with the world. If you liked reading the blog, clap your heart out and help others find it.
