Jeff Patton has written an interesting post called Requirements considered harmful to spark a discussion on the use of the word “requirements” in the software industry.
He argues that the word “requirements” leads us to the wrong behavior. There is a long tradition where we think about requirements as something that has already been decided and now the developers should just implement it and everyone will be happy.
As you know – that is not how software development works in general.
I really love the way we think about software requirements when we work with User Stories – and using the acronym INVEST as a guide. In this context the most interesting letter is the N which stands for Negotiable. That means that it is not a requirement in a traditional sense – it is still open for negotiation. And it is open for negotiation all the way until it has been developed – and approved by the Product Owner. A User Story is “a reminder to have a conversation”.
So if a software requirement really isn’t a requirement after all – maybe we ought to change what we call them to make this mindset change easier? Jeff is proposing “decision” as an alternative. I think this has the exact same problem as “requirement” – it makes it sound like the decision has already been made.
I am proposing “perceived need” instead. I think this might fit well with how we think and work with Agile Requirements – for example with the negotiations and conversations mentioned above. And with the commonly heard advice – “ask why five times”. Why do you perceive that you have a need for that? It should fit equally well for functional and non-functional needs.
Let me give you a couple of examples.
A salesperson asks for a new function to be able to sort orders. Lets say we store the request as:
“As a salesperson I want to sort orders on seller name”
If we view this as a requirement we can quickly add this to the user interface – and the person requesting it would most likely be happy with this. But then we haven’t explored the options. Lets see what happens when we add the rationale to the User Story:
“As a salesperson I want to sort orders on seller name so I can quickly find my own orders”
Maybe it turns out to be a much better solution to provide a view where you can see your own orders – or maybe not – this is why there should be a discussion.
Another example:
“As a user I need the system to be available 99,99 % of the time”
These kinds of “requirements” can often be very expensive. But when we start discussing this “perceived need” maybe we see that it is only one of the many parts of the system that has a very critical uptime – which might make it much cheaper to implement. Or maybe when the customer understands how much it will cost with this uptime compared to 99,9 % he/she decides for the latter instead.
Most of the time there exists a multitude of optional solutions to the so called “requirements”. They all have different pros and cons and different costs and time to implement.
Maybe if we start calling them “perceived need” instead of requirements we will see more and more teams “negotiating” the so called “requirements”?
Let’s continue this discussion and see if we can get other suggestions for this!