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 http://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 (http://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
