Building software solutions begins with identifying business requirements, and many project failures can be traced to poor requirements.
Part of the problem is that features and requirements language is often too broad or ambiguous, leading to conflicting interpretations, as I discussed in a blog post Stuff Passing as Requirements. These include meaningless expressions such as "intuitive," "user friendly" and "seamless integration" as well as impossibly broad statements like "meets all applicable compliance requirements."
One of my favorite classic information technology textbooks is Exploring Requirements: Quality Before Design by Donald C. Gause and Gerald Weinberg. The book is a great foundation for understanding product development, not just for software development. It will encourage you to ask more questions and think about requirements in new ways to make your projects more successful.
Another, related problem, is that information technology is by its nature both abstract and plastic, because it may be applied in so many different ways. We often search for metaphors to help us scope software projects. Sometimes the metaphor can illuminate, but often it obscures.
One of the most common metaphors I hear in software projects is the automobile. "Do you want a Chevrolet, or a Cadillac?" The idea is to separate required features from optional features. This often fails in software projects, because a requirement of "red, has four wheels and carries passengers" applies to Radio Flyer wagons and to Ferraris. One of our clients described a software requirement as so broad, you could use it to build an aircraft carrier.
We also hear the analogy of a house or building. How many rooms, or stories, or how tall do you want your software? Again, this can be a point of departure, but often we end up with a skyscraper resting on the foundation of a shack because of changes made during the course of a project.
In the end, I often find that users cannot determine what they want or need until they see it. Prototyping and looking at comparable systems is much more useful than blue sky requirements brainstorming. This approach allows you to benefit from the experience of others who have already covered similar territory rather than starting from scratch.
Please share your software requirements experiences with me on Twitter @jamestownsend.