Tuesday, January 10, 2006

High and Low Level Requirements

I've seen some references in product management and requirements discussion forums about a supposed distinction between "high" and "low" level requirements. I have three main thoughts on this matter.

First, the distinction, if examined literally, doesn't seem to make sense. A user has certain problems she wants solved; requirements state the least stringent conditions that must hold to know that you've solved them. I don't consider problems as being either high level or low level, so why would there be "requirements levels"? Imagine saying to a user, "Oh, that's just a low level problem, so let's not worry about it now. I'm just documenting high level requirements." What?

Second, I believe the valid distinction is between requirements specifications and design specifications. If you specify user goals and constraints on those goals, you stay at a "high level", and you are documenting requirements. If you specify how the user will interact with the product in order to satisfy those goals and constraints, however, you are certainly getting into low-level details. But then you are specifying design, not requirements.

Third, both high and low level specifications are important. Denying that low-level specifications are requirements by no means diminishes their importance. It just helps to understand when you're doing requirements and when you're doing design. At Cauvin, Inc., specifying market requirements for a product is part of our product management services. We leave product design for design experts.

No comments :