Let’s stop talking about requirements
I get a bit sad when I hear the word “requirements”. It is a word that strongly reminds me of the bad old Waterfall days. We don’t want a return to that way of thinking. So let’s find a better approach, more in line with the agile mindset.
The origin of requirements
Back then, we would talk about “requirements” all the time. Projects would start with a big scary BRD (Business Requirements Document), which sometimes spilt over into a Business Solutions Requirements Document. Why would you want to have one requirements document when you could have two? Duh!
These documents contained all the “business requirements”, which was another way of saying “we Business People have decided in our infinite wisdom that this how this software should work and this is what it should do. Go build it!”. A group of Business Analysts would then clarify these requirements by way of something called “requirement elicitation” (don’t get me started). And out of that, the BAs would write a bunch of “specification” documents, which would translate the “business requirements” into something that developers could understand and build.
There are some big problems with this whole approach. I think we should stop talking about requirements at all.
The problem with requirements
There are several problems with this concept of “requirements”, “specification” and so on. Let’s go through them one by one.
The business shouldn’t own the requirements, the customers should
The idea that the “business” owns the requirements i.e. behaviour of the software is nonsense. The value of the software is in the hands of end-users, not the stakeholders. The business doesn’t have a requirement for a menu or a button or a feature, the customer does. If we are going to talk about requirements, we should talk about customer requirements, not business requirements.
The business has one requirement only: to attract and retain profitable customers. Except there’s another problem here: customers don’t have requirements for buttons and websites and dialogs and databases. These so-called “business requirements” are doubly deceptive. Not only do they not belong to the business, they aren’t requirements either, they are generally solutions. Customers don’t require things (what I.T. people would call “solutions”), they require outcomes.
Customers don’t actually “require” software features at all
The most important lesson I learnt in studying marketing was a painfully simple yet elusive concept: customers don’t want things. They don’t want cars, they don’t want websites and buttons and menus, they don’t want phones. They want outcomes. And they want benefits. Instead of cars, they want convenient private transportation. That happens to often take the form of buying a car, but not necessarily. They don’t want smartphones, they want on-demand communication and information. It might take the form of a smartphone, but not necessarily.
It is the job of marketing (and fundamentally product management) to not sell products, but to sell benefits, or outcomes. That is what makes people purchase products.
So talking about “customer requirements” is less inaccurate than talking about “business requirements”, but it is still not quite right. We should be talking about outcomes and benefits, not requirements.
Requirements break the INVEST rule
When Agile people talk about software features (or more specifically, user stories and acceptance criteria), they often talk about the INVEST rule: they must be Independent, Negotiable, Valuable, Estimable, Small, and Testable. Calling something a “requirement” (i.e. it is required no matter what) breaks the N part. If something is negotiable, it is optional and can be traded for or against other things.
Requirements are tightly coupled to specifications and specifications are awful
Requirements are tightly bound to the old Waterfall language and concepts, including “specifications”. These were awful things (I used to work with them but haven’t for years) that described systems in a strange and unpleasant way. “The system shall do this”, “the system shall do that”. This is a bad way of thinking about software systems. It further reinforces the idea that the systems are things whose behaviour are valuable in their own right and exist purely for “the business” to possess.
User stories describe things from the point of view of those using the system, i.e. people.
An agile approach tends instead to talk about things from the point of view of people using the system, not the system itself. These are often in the form of “user stories”, which tell a story about how someone wants to achieve some outcome, for a certain reason. E.g. “As a sales agent, I want to view my prospects, so I can open them and create a lead”.
Interestingly, the system itself is often not mentioned at all! That is not a coincidence. The story describes the outcome, the benefit, the problem statement, i.e. the problem to be solved – how can we achieve this outcome for the customer? The tasks, documentation and acceptance criteria start describing the solution.
We should talk about outcomes and benefits, not requirements and specifications
It is better when describing how we want a software system to work to think about the the users or the customers first, not the system. We don’t have a “requirement” that a system looks like this or perform this action, we have customers who have needs and want to achieve outcomes. If you start with those, then think about how the system can meet those needs or deliver those outcomes, you’re more likely to deliver value for the users.
That is why Agile practitioners often talk about “user stories” instead of “requirements”, and why they usually phrase them in terms of the user (via Story Normal Form). That is why we try not to create “technical user stories”. It’s also why we try to focus on outcomes instead of outputs. It is all too easy to deliver a system that meets a bunch of “requirements” but provides little or no value to users.
The one exception
There is an exception where it makes sense to talk about requirements: for compliance related work. Say you are working on a financial system, and there is some work you have to do to make your system PCI (Payments Cards Industry) compliant. Such as modifying how you store credit card data in your backend. This is a situation where the work does not provide any direct customer value, but it is nevertheless extremely important for your business.
This would be a case where it does make sense to talk of requirements. The compliance rules require businesses follow these protocols, otherwise they are in breach, and that is generally a very bad thing. The traditional customer-centric way of talking about user stories and journeys and value and outcomes simply doesn’t work here. But unless you work in a heavily regulated industry like finance or healthcare, this shouldn’t come up very much.
What about non-functional requirements?
You might be thinking “but what about NFRs (Non-functional requirements)? Every system has those, right? The homepage must load in under 3 seconds. The database must be available 99.9% of the time.” The non-functional aspects of a system are certainly important. These are things that people building a system should be thinking about from pretty early on – though they don’t necessarily need to be building it in from very early on. Remember Donald Knuth’s warning that “premature optimisation is the root of all evil”.
To avoid using the “R” word altogether, I suggest we talk about non-functional value or quality. Remember, everything needs to be negotiable. It is overly simplistic to say the homepage “must” load in three seconds. Always? At peak times? Off-peak times? For 100% of people? Or 90th percentile? Time to first paint or time for full data load? These things are usually much more subtle and complex than people realise. This thinking could also lead to poor design decisions or experiences in other parts of the application. Value and quality can be traded against other; requirements by definition cannot.
It might seem like a minor change, but it’s not
Try to get people to stop saying the word “requirement”, even if you’re doing Agile and have user stories and don’t write or read specification documents. It might seem like a little thing but I think it’s not. Requirement is a bad word that keeps people in a bad old mindset. Of command and control, of conformance to specification, of business centred design. It’s the 21st century, we’ve all moved on, so let’s update our language.
