Space Cadet

  1. Posted on March 31, 2007 6:29:PM by Earl Beede to Practicing Earl
  2. requirements

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..."

Practicing Earl said:

August 24, 2009 11:12:AM

I recently went with trepidation into a class with Pragmatic Marketing called “ Requirements that Work

Steve McConnell said:

September 4, 2009 10:54:AM

I believe the They/We distinction is not a good generalization of the idea that "If it's required, it's a requirement." For anything after version 1, the behavior of the existing system implies a large body of de facto requirements, i.e., in many, many ways the new system is required to act like the old system, regardless of whether the specific behaviors of the old system were originally thought to be "requirements," "design," or just an accident.

There's no "they" in the "must behave like the last version in all important respects" requirement. There are just a lot of required behaviors.

The idea that "anything that's required is a requirement" somehow makes the requirements analysts job superficial or easy is also not right, I think. Part of the requirements analysts job is to determine if when someone says "I want a house with a Home Depot item number 117398 door knob" whether that's a real requirement (ala "the house I grew up in had that exact door knob and I want that exact door knob on my house") or whether it's a vague desire masquerading as a specific requirement ("I was in Home Depot one time and saw a sign that this door knob had excellent security features, and I want the best possible security features").

Another way of stating this is, There are no requirements that are theoretically "off limits" to customers. If the customer truly wants something, even if it seems like design to a developer, then it's a requirement. But there are lots of statements that customers might initially present as "requirements" that won't turn out to be real requirements once you understand what they're really asking for.

I like the definition of quality as "conformance to requirements, stated and *implied*." To achieve a quality system, you have to discover not just the stated requirements but dig deep enough to discover what requirements are really implied.

Post a Comment:


Earl Beede

Earl Beede, CSDP is a Senior Fellow at Construx Software, where he designs and leads seminars and provides consulting services on early project-lifecycle practices, estimation, requirements, quality assurance, contract management, and software methodologies.

With more than 20 years experience as a quality assurance representative, systems analyst, process architect, and manager, Earl has designed and written software development processes for companies across a wide variety of industries. Prior to joining Construx, he held quality assurance and systems analyst positions at organizations that include the Department of Defense, Boeing Computer Services and Verizon Wireless.

Earl has a Bachelor's degree from the University of Washington. He is a member of the IEEE Computer Society and a past coordinator of the Seattle Area SPIN (Software Process Improvement Network).


Contact Earl