At one time or another, all people are concerned about the unknown, especially the unknown-unknowns. It happens frequently while driving a car. You change lanes and don’t see the car that’s in your blind spot. Or, you are on a business trip, driving at night, and your GPS tells you to take a left on a street that is one-way to the right. If it wasn’t dark, you might be able to find a landmark to regain your sense of direction.
Business executives, product managers, architects, and engineers are not immune to the unknown-unknowns, in spite of our years of experience and depth and breadth of knowledge. We write requirements for a new product. We’ve talked with our key customers. We understand what they want. We have them reviewed. After a few discussions and suggestions, we leave the room agreeing that this is what needs to be done. Let’s get started! Sure, there are uncertainties, but nothing we haven’t handled in the past. But the “invisible requirements” are there waiting – the unknown-unknowns.
The article on Invisible Requirements, at https://charliealfred.wordpress.com/invisible-requirements/, is a white paper that I co-authored with Garrett Thurston. Thanks to Tim Bowe, CEO of Foliage for giving me permission to republish it. This paper has a similar theme to a paper I wrote a few years ago, titled Requirements vs. Architecture (https://charliealfred.wordpress.com/requirements-vs-architecture/) , but looks at the problem from a different angle. Hopefully, it will act like a flashlight and give you a few techniques for illuminating those invisible requirements that stand in the way of your product development effort.
Charlie
Charlie Alfred's Weblog 
This is an excellent point. I would also suggest that invisible requirements may also be invisible because they are masquerading as a very specific requirement. This is particularly true when the specific requirement relates to the use of a standard or similar specification. If we have a requirement to comply with some standard, the typical approach would be to create architecture components associated with the standard. However, careful consideration of the operational context within which a system derived from the architecture is embedded may indicate a hidden requirement of which the specified standard is an instance. Additionally, examination of the standard itself beyond the details gives clues as to the real requirement(s).
For example, consider an unmanned ground system with the stated requirement that such a system comply with the JAUS specification. This is a very specific requirement that influences approaches taken to system implementations of such a UGS. However, consideration of the operational context likely indicates that such a system does not operate in isolation, but may need to operate with other similar systems, possibly from different vendors, or with other modes of unmanned vehicles, such as aerial vehicles. This context suggests that while the stated requirement is use of JAUS, the underlying, invisible requirement is interoperability between unmanned systems. Indeed, the JAUS specification is an interoperability standard, but focuses primarily on ground vehicles. An architecture created to support interoperability will look fundamentally different from an architecture created to support only JAUS. In the latter case, additional risk is created because the architecture may not support use of other standards or the inclusion of multiple standards.
Examples of this are numerous. Analysis of not just the stakeholders but the context within which those stakeholders exist and function provides critical insight that can be used to reduce the risk of creating the wrong thing.
Just my 2cents worth…
Comment by Dan Hestand, PhD — June 17, 2011 @ 3:37 pm
Great observation, Dan. I fully agree with your addition. Let’s name this category of invisible requirements the “Total Eclipse”.
Jack Greenfield of Microsoft made a very astute comment to me a few years back about requirements. He said, “Most people believe that requirements are statements about the problem. They aren’t. They are actually statements made by some stakeholders about what they want some part of the solution to be.”
As a result, some requirements imposed by powerful stakeholders with narrow perspectives definitely can eclipse some more important challenges in the problem. In the worst case, they hide them from view until after some critical decisions have been made which are very costly to undo
Comment by charliealfred — June 18, 2011 @ 12:32 pm
Dan, this is a great observation and Charlie, your Eclipse comment is both accurate and humorous.
In this white paper we talked about the notion of cognitive biases and the use of analytical tools to help manage or overcome those cognitive biases.
Charlie, in your comment you talk about “Powerful Stakeholders”. I am not sure about the suitability here but part of the analytical tools suite that we bring to bear on such problems involves brainstorming.
Frequently, this brainstorming is done on an individual basis and there is a lot of trust put into the technical capabilities of the individual in their completion of the requirements analysis task. There are a number of brainstorming techniques to help manage a group effort. In the case of brainstorming where there is a team member that is one of these powerful stakeholders, that is someone that is a Senior member, or particularly outspoken team member where there is a very real risk that (s)he will dominate the session, the junior members are reluctant to speak or a heated discussion ensues making little progress to the end objective of the brainstorming session.
In such situations one of the analytical methods for brainstorming that can be used is Nominal Group Technique — NGT. In NGT it encourages equal participation by all participants by requiring participants to present ideas on at a time in round-robin fashion until all participants feel that they have run out of ideas.
On a side note Dan, JAUS was a good example, recall it was also to help both interoperability and reuse, STANAG-4586 also has as a key variability management aspects included. If you are working in the area. It might be worthwhile for you to close the loop with Bob Welsh over at XPRT Solutions.
Ref: AIR5665, AS5669A, AS5684, & AS5710
Comment by aerogman — September 16, 2011 @ 12:13 pm
Charlie,
You may recall Daniel Kahneman from a reference we reviewed on framing bias.
http://science.dodlive.mil/2013/05/05/improving-the-science-of-decision-making/
Talk to you soon. Garrett
Comment by aerogman — May 6, 2013 @ 8:45 am