Undreamt Requirements

In An Early Start to Testing: How to Test Requirements (originally published in 1996) - Suzanne Robertson describes three distinct categories of requirements: "
. Conscious Requirements - Problems that the new system must solve
. Unconscious Requirements - Already solved by the current system
. Undreamed of Requirements - Would be a requirement if we knew it was possible or could imagine it
Conscious requirements are easier to discover because they are uppermost in the stakeholders' minds. Unconscious requirements are more difficult to discover. If a problem is already satisfactorily solved by the current system then it is less likely for it to be mentioned as a requirement for a new system. Other unconscious requirements are often those relating to legal, governmental and cultural issues. Undreamt of requirements are even more difficult to discover. These are the ones that surface after the new system has been in use for a while. "I didn't know that it was possible otherwise I would have asked for it."

Undreamt requirements are essentially where Engineering can provide its greatest value-add by introducing innovations, disruptions, and a new set of possibilities.

Illustration and Related Theories
Although its success can certainly largely be attributed to a mix of outstanding marketing as well as humans' need to follow group behaviors, the iPod is a good example of a product that addresses an undreamt requirement: no average user went to Sony or Aiwa -back then leaders in portable music devices- and told them "If you provide me with a small device that allows me to store and play gigabytes of music in digital format, with a dumb-proof interface, and white headphones, I'd buy it for 10 times the price of a walkman, and millions of people like me will follow".

How an organization can -or cannot- develop an environment that supports the discovery of undreamt requirements is largely addressed by the literature on the issue of innovation and its sustainability for an organization.

The more practical question here is how to ensure that undreamt requirements are identified during the Requirements Analysis process.

Undreamt Requirements Analysis
The key element that impacts whether or not Undreamt Requirements are discovered is how User input is treated.

User involvement is one of the greatest challenges in requirements identification.
A number of issues are regularly invoked:
. Users cannot always articulate what they truly want or need
. Users do not have the necessary technology background and expertise to ask the right questions -let alone to provide the right answers-
. Users only know what they have experienced
. Users are not committed to a given product, and as such do not have the incentive to think hard about the problems

The result of mapping one-to-one customer inputs to product features is invariably a disjointed and over-complexified product, with -at best- incremental improvements, that mimics competitive products, and lack a central and unified vision.

[Yet, the best way not to be successful, is also to ignore user inputs altogether]

The answer to the User input problem is a plain simple concept that is a constant challenge to implement: focus on the users' desired outcome.
In other words, focus on the unstated problem not on the stated solution - be it implicitly or explicitly stated.

Or in Peter Drucker's words: "Instead of buying a product, the customer buys the satisfaction of a need".