Software requirements can’t be gathered

Requirements don’t exist until they are invented. Some of you reading this may think that I’m wrong…I’m not and here's why.

After decades of working with business people and building software tools for them, I can say without question - requirements are invented, not gathered. As humans, we invent things all the time - the things we invent aren’t often incredibly innovative concepts, but they are invented. A simpler way to say it is: we make them up.

If software requirements existed, then they could be gathered by anyone. Gathering requirements implies that they are laying about waiting to be picked up like fallen leaves in Autumn or tomatoes freely growing on a vine - just waiting to be picked.  But look as you might, you won’t find a pile of requirements anywhere.

Anyone that has ever engaged another human in an exchange / dialog to determine what the requirements are that would satisfy them, knows that the requirements don’t exist until they are spoken. And, until they are spoken, they don’t exist. This becomes painfully clear when you are building software and the development team begins asking questions to clarify what you have written to guide their development effort. Good development teams ask great questions when what you have written for them isn’t clear to them. And, because it isn’t clear to them, they can’t create the code required to automate the task or calculate the outcome required.

So, requirements are invented - either by you or by the development team. In highly effective teams, they are invented together - because they have to be invented that way. Inventing them in isolation from the business will create flawed or ineffective software. Inventing them without the technology team will produce the same result…here’s why:

Requirements exist in the context of the situation in which the business exists. Simply put, software is written to produce a new situation - a new, more satisfactory situation. If this weren’t true, then why would you go to the cost of building software? The challenge for both the business and the technology team is that they don’t know both contexts well enough to create the requirements on their own.

Below are some contexts that can be considered with writing software requirements:

• The unsatisfactory situation or business conflict. This is what is broken or no longer working from the business’s point of view.

• The specification of the end state that will be accepted as satisfactory to the business (and the tech team).

• How am I going to produce this new satisfactory situation? What are the interim steps required to resolve the conflict for both the business and the technology team?

• What is the current business situation - what is our starting point?

• What is my current technological situation - what technology already exists and what tools can be used?

• What is the status of my team - skill sets, willingness, etc.?

There is no magic.

The art of producing the requirements is dependent on the questions you ask, the completeness of the answers you receive, and your ability to collaborate with your business/technology partners to make them complete. This includes your follow-up/clarifying questions and the ability to stay focused on the intended outcomes without drifting into “good idea” territory that wastes time and effort chasing something that is irrelevant. (Check here for some insights into what I mean about “good ideas”.)

The strength of the partnership between the business team and the technology team is the reason your software project will be successful - it’s also why software projects fail. Building software requires more skill than just hiring developers. It requires business acumen, the “soft” skills necessary to draw out what is obvious to your partner, but not obvious to you, and the discipline to stay focused on the goal while still being able to explore product improvements that create value for the users of the software.

At 8 Penny Labs, we are experts that help our customers build the collaborative teams necessary to build great software.

Follow us on Linked In (8PennyLabs) to be the first to learn when a new blog post drops.