- Posted on March 31, 2007 6:29:PM by Earl Beede to Practicing Earl
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 idea 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", then that 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 those are all requirements. Now, we prefer 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 is 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 they need? Too bad! They said it. Impossible to do in the time allotted and with 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 deciding 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 are four levels more detailed than what is in the design document, they said it. Third, it is darn simple. As an instructor, I only need to 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 fond 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? How do I distinguish between requirements and design? And for the regulated folks, what do I perform validation on and what do I perform verification on?
Now I admit that the difference between requirements and design is as clear as the definition of a planet (just ask Pluto). 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, we must make that distinction because if we don't call out a line between requirements and design, we are likely wasting lots of money doing a rocket propelled amount of validation and at worst, solving the wrong problem since we never knew what 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 orbit 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..."