In the requirements forum at Construx Conversations, I asked a question about how to present the concept of problem space vs. solution space. You see, I think this is a fundamental aspect of good requirements. My very smart and never opinionated Construx Steves (Tockey and McConnell) told me I was spaced out. (You can see the thread here) They suggested that my ideas of problem space and solution space was at best, misguided, and at worst, out to launch.
They believe in what I call the They/We model. A requirement, the Steves tell me, is something "they" tell you to do. If they say, "I need shelter", that then is a requirement. If they say, "I want a 1800 square foot single story home with colonial features, green paint, a double doorway, six car garage, two steps up to the front door, a Home Depot item number 117398 door knob, ..." well then that is all requirements. Now, we prefer it if they left the design of the solution/system to the design experts but hey, if they want it, they get it. They get to decide and that all there is to it.
The They/We model has some appealing aspects. First, it is darn simple. How do I know it is a requirement? They said it. Doesn't do what you want? Too bad! They said it. Impossible to do in the time allotted and the resources allocated? Oh well, they said it. Second, it is darn simple. No real thought has to go into planning a requirements process or what goes where. If they say it, it goes into the requirements document. If we say it, it goes into the design specification. So what if the statements in the requirements document is four levels more detailed that what is in the design document, they said it. Third, it is darn simple. As an instructor, I can just show you how to make what they said a bit clearer. I don't have to push you into challenging your customers. They are the customers after all and the customer is occasionally right.
Now I am sure the Steves would encourage the "they" to stay out of the technical, solution part of the process. Requirements instructors are found of saying that the requirements are about the "what" not the "how". Unfortunately, this is where the simplicity, straight forwardness of the They/We model starts to enter zero gravity. How do I know that are actually telling me the "what"? Do I really care if they tell me "what" or "how"? How do I tell the difference between requirements and design? And for the regulated folks, what do I do validation on and what do I do verification on?
Now I admit that the difference between requirements and design is as clear as the definition of a planet. Both requirements and design are decisions based on available knowledge. There really is a sense of who is making the decision where the They/We model resonates. However, make that distinction we must because if we don't call out a line between requirements and design, we are at best, wasting lots of money doing rocket propelled amount of validation and at worst, solving the wrong problem since we never knew what the problem the solution was ever to solve. If you have heard, "Yes, you built what I wanted, but it doesn't do what I need it to do," you have been there.
This is compounded by the fact that the "they" in the They/We model seldom actually talks about the "what". They float in a world of tangle things: screens, reports, drop down boxes, menu items. If they want something, they will use the language that is available, the language of solutions. And this is where problem space vs. solution space comes in ever so handy. By thinking about the current situation and clarifying the problem space vs. the solution space for the task at hand, I know when I need to confirm the problem so that I have confidence that the solution I am creating actually delivers what the customer needs, not just what they want.
So I am still a space cadet. Perhaps the Steves will win me over. One is my boss after all. But until then, I am in suited up and ready ready for blast off! "Ground control to major Tom..."