If you’ve taken part in any sort of web project, you have hopefully defined, referenced, and/or tested a requirement. You’ve also felt the impact of requirements gathering on your work. A good requirement can make your job easier by taking the mystery out of what is needed. A bad requirement can lead to more work, or even wasted effort. I explored how to mine for detailed requirements in Questioning (the) Authority. In the year since I wrote that article, I’ve wrestled with how to manage the natural evolution of business requirements to functional requirements as you progress through a project. How do you create traceable requirements?
Wait a minute, what exactly are we building here?
We’ve written 3 blog posts about Project Definition. View all topics »
In the last six years I’ve done a fair amount of business travel. On occasion, there have been a few memorable trips due to the flight (Nashville, I don’t know how you deal with that kind of turbulence), the destination, the clients (like good old “Poet’s Eye”), or just the circumstances of our meeting. The last two years have been especially busy and I’ve built up a good catalog of stories from experiences on the road from Lansing to Birmingham, Bend to Boston, and beyond.
The success of any project hinges upon your ability to extract information from people. I’m not talking about summary-level information, I’m talking about the microscopic stuff. It’s harder than you might think.
The reason for this may be best identified by a Hungarian–British polymath named Michael Polanyi who wrote a book called “The Tacit Dimension” in 1967. It is an overview of something he called “tacit knowledge,” which is the belief that creative acts (especially acts of discovery) are charged with strong personal feelings and commitments.