Most of you will be familiar with the issue of a customer having vague requirements. Once s/he gets the software, s/he is of course perfectly able to articulate his/her actual requirements, since s/he can explain it on the example.

Is there a name for this scenario / paradoxon?

  • I think it's called homo sapien
    – Daniel
    Commented Apr 12, 2019 at 11:37
  • 1
    I'd call it customer. I'd apply a different name for the customer who knows its requirement beforehand. Something like... Alien?
    – Tiago Cardoso
    Commented Apr 12, 2019 at 11:41
  • One a more serious / helpful note: Customers knows more or less what they want, but they aren't usually experts on a matter. The experts are the providers, the companies. I don't believe there's a specific term to identify this customer incapacity of articulating its needs. Let's see if the community has different thoughts!
    – Tiago Cardoso
    Commented Apr 12, 2019 at 11:50
  • @TiagoCardoso yeah, that is true. I'm just searching for the term describing this circumstance.
    – ugster
    Commented Apr 12, 2019 at 12:15
  • How is this a paradox...?
    – Sarov
    Commented Apr 12, 2019 at 13:23

3 Answers 3


Emergent Properties

I don't believe there's a single word in English that describes this phenomenon. However, it's fairly common in my line of work to consider this a typical property of complex systems such as large software or security projects.

In agile frameworks, the implementation of various features is often an emergent property of the incremental and iterative development process. This is often more effective and visible when using test-first methodologies, and when leveraging agile inspect-and-adapt cycles to their fullest extent.

Because complex systems are complex, it's often difficult to create detailed specifications such as functional requirement specifications (FRS) upfront. In fact, doing so is a known agile anti-pattern. Agile frameworks compensate for this through the use of various techniques that generally boil down to increased collaboration, frequent or continuous integration, tight feedback loops, and incremental scope.

In short, they acknowledge the issue and then work around it by solving knowable problems, rather than the unknown unknowns that fill the funnel of the cone of uncertainty in complex systems. The emergent properties of the system, along with the inspect-and-adapt process, gradually reduce the cone of uncertainty over the life cycle of the project.


There are people who are trained to understand what a customer wants/needs even if the customer cannot describe it. In IT, we call those people 'Requirement Engineers'.

If by "finished software" you meant "something-you-are-able-to-click", then you can call that approach "prototyping". Important: a prototype is not a first version of a product! It is a way to learn what we want/need.


I’d love to have a clever name for this but I dont. For me this is about them lacking the the language required to fully articulate what they want. It’s up to “us” to assist them. This is why solid analysis is require. A good consultant/analyst that can translate non-developer to developer is always key. :-)


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.