it’s not just software requirements that suffer the problem of being vague, open-ended and non-descript. anytime we want to express anything we require, we speak a kind of short-hand which is just something we’re terribly used to, and rely on, in everyday communication.
Starting with birth, we express our requirements in one word “Mommy” meaning anything from food to nurturing to play. We grow up expressing one word “food” to mean anything from a sandwich to an ice cream.
What do you feel like eating? Mmm… Food 🙂
So unless we’re particularly motivated, and capable, we express our requirement in sufficient detail so as not to leave any room for interpretation. Like a food craving.
What do you feel like eating? Tuna sandwich on wholewheat with lettuce and onion.
Software requirements fall into the same communication trap. When the product manager has “an” idea of what is required, but is not particularly motivated, or capable, of expressing that requirement, it comes off in short-hand, leaving many gaps in the interpretation. On the other hand, when the same is particulalry motivated, and/or capable, the requirement usually comes through in one detailed description requiring very little formal “Requirements Gathering” interaction. It’s understood with accuracy. Job requirements are much the same.
Everyone wants a developer who:
has at least n years experience, is motivated, can work independantly, can work under pressure, can communicate both technically and commercially, is a team player, delivers on time, understands patterns, knowledge of databases, fill-in-the-technology [related to the position]. thing is, these specs don’t describe what the company actually wants. All that it communicates is that the company [or recruiters] have “an” idea of what they’re looking for and are prepared to shop around and see what they can find. And then very rarely, there are companies who post up their requirements in such a way that it communicates what you really need to know about the going position:
company culture and problem domain. Knowing that up front saves a lot of communicating. i guess that’s why you need to check out the website. but even that just reflects the marketing department’s image of the corporate and not what’s really going on :p