A colleague of mine invented a new word recently.
Every time we had a meeting, and he mentioned requirements, I would point out that, of course, there is no such thing as a requirement – it’s all design. He took my point (or at least he humoured me), but was struggling to let go of the word “requirements” because he was so used to it.
And so he came up with a new word – “desirements”.
It started out as a contraction: design-requirements became “des-irements”. But I quite like the alternative interpretation. Desirements are what stakeholders desire. What they want. Not what they necessarily need. Not necessarily the best thing for them. They are ideas, suggestions, proposals.
This term helps me out of a hole. I’ve been trying for some time now to avoid using the word requirements (walking the talk, as it were) but it’s actually quite hard in an environment where it’s a de-facto standard. Desirements gives me the perfect get-out. People will know what I mean, and will also instantly get that I have an alternative view on requirements, without me having to pause the conversation to present by 5 minute monologue on why there’s no such thing as a requirement.
I’m going to try using the term and see where it gets me. I don’t suppose it will catch on but you never know.
Desirements it is!
Desirements is a much better term, but can we get stakeholders to accept the fact that some of what they consider “requrements” are not 100% essential for a project?
@Steve: it’s not always appropriate, though, to try to convince stakeholders that what they consider requirements are “not 100% essential”.
It’s not always that you can substitute “desirements” for “requirements” in projects. All the time I come across “non-negotiable business needs”, which become “requirements” to be fulfilled by a business change initiative.
Some quick examples would be a healthcare company with a deadline to comply with regulatory rules, and an analytics company that has to build a new reporting feature within the next quarter to respond to an ultimatum from top revenue customers ready to cancel their contracts and move to the competitor that already offers the feature. The requirements derived from these needs (I’m not talking about the functional design here, which may very well be negotiable) are indeed essential.
It goes back to a statement from Tony in a previous article, in which he mentions his preference for “business objective” rather than “business need”. I don’t see a compelling reason to not call something a “business need” when not meeting the need / objective will get you out of business :-). A lot depend on the context of the problem/opportunity you are trying to address.
So I could argue that there are always alternatives. There is an option to not comply with a regulatory rule, or at least to delay compliance (miss the deadline). There is an option to negotiate with the regulator if compliance is proving too costly. But in truth I agree – some “needs” are indeed non-negotiable, at least not by the BA. My key point is to encourage BAs to challenge the “requirements” until they find out what truly is non-negotiable.
Tony,
Indeed, what I’m talking about is “the alternative is not on the table anymore”. Meaning, yeah, the business owner or Board of Directors might have the option to miss the deadline or try to renegotiate, but they didn’t, and the mandate is for the CIO to produce a solution to become compliant. For all purposes, it is a requirement for everybody involved. Of course one could argue that you can always opt not to fulfill an externally imposed constraint, or ignore the orders from above, but I don’t see how it can be useful to treat something as a “desirement” when the alternative is having the business closed down, or the entire IT team fired because they didn’t fulfill their mandate :-).
I’ve doing some thinking about this recently. We often talk about “discovering the underlying business need”. I’ve always argued that there’s no such thing as a business need – nothing is truly needed. But there is a process whereby the BA challenges the “requirement” or “need” and considers alternatives, working backwards until they hit the point where they have discovered the decision that *is* non-negotiable. But that’s not a fixed place. I have many times challenged supposedly non-negotiable decisions and won (especially where I have been able to demonstrate a much better/cheaper/simpler alternative). The moral being to challenge, challenge, challenge until either you agree with the decision, run out of energy or get fired (in the latter case you’re clearly better off elsewhere!)
Tony,
I couldn’t agree more with the idea of always challenging traditional beliefs to get to the optimal solution. But I feel that’s besides the point here. Perhaps a real-life example (details changed to protect client confidentiality) will help explain:
A software-as-a-service provider in the hospitality business decided to create a new product, a location-based guest database. As the “desirements” for the new product are discussed, the business owner declares that he expects the location-based guest database to be implemented as an “add-on” to the flagship product they offer to hotels, a global sales and booking network.
The BA takes that “desirement” into consideration in the analysis, and comes back with plenty of evidence that having the location-based guest database available as a standalone app (which could be purchased as part of a larger package, or by itself) would have a much larger market and profitability.
The business owner looks at the data, and says, “no — I still want to make the new product only available to customers that purchase our flagship product. They must sign up for the main product first, and then opt to pay an extra fee to have access to this supplemental app.” You may argue back, but at some point, the decision is final.
That’s the point where I consider this a “requirement” for the solution to be built. No matter how wrong the decision is, it is a decision by the person commissioning the work, and meeting this requirement is now a non-negotiable condition for the solution to be considered successful. I don’t see any benefit of still calling it a “desirement the owner has” at this point. Do you?
By the way, in my consulting practice, “desirements” are called “requirements candidates”. They only become real requirements when there’s no more question that that’s what needs to be delivered (in a release, or sprint, or story implementation) in order for solution to be deemed fit for purpose.
Tony, I enjoy your articles, and am a big believer in your basic premise that everything is design.
In my experience, mainly in large financial institutions, developers want “requirements” so that they have a way of knowing what to build without having a full understanding of the business processes they are automating. Because gaining a deep understanding is hard, and takes time. What they really want is a high-level functional design, that will allow them to work on their data modeling and coding without having to be distracted by things like talking to people outside their group and asking questions.
In my world the big problem is the gap between business and IT. IT doesn’t know the business well enough to design a system to satisfy them, so they clamor for “more detailed requirements”. But if requirements were really what they needed, they should be satisfied with the bank’s policies and procedures and the government’s regulations. (God forbid a developer should ever look at such materials!)
They’re really clamoring for a good functional design. But I’m afraid that by not calling the thing by its proper name, we end up giving short shrift to the design activities, which are key to successful software, and we downplay the need for deep knowledge and creativity in the process.
Thanks for your comment Adam – it’s always good to hear from people who are on the “its all design” wavelength – your experiences sound very similar to my own. Please do spread the word!