Some recent work for a client has me struggling over the distinction between requirements and design: not in my own mind, where it’s pretty clear, but in the minds of those who make no distinction between them, or attempt to substitute design for requirements.
First in any project are the business requirements, that is, a statement of what the business needs to achieve. For example, in a transaction processing environment (which is a lot of what I work with), a business requirement would be “the transactions must be categorized by transaction type, since the processing is different for each type”. Many business requirements and constraints of an existing organization are detected, not designed; from a Zachman standpoint, this is rows 1 and 2, although I think that a few of the models developed in row 2 (such as the Business Workflow Model) are actually functional design rather than requirements.
Second is the functional design, or functional specifications, that is, a statement of how the system will behave in order to meet the business requirements. For example, in our transaction processing example, the functional specification could be “the user selects the transaction type” or “the transaction type is detected from the barcode value”. Some references refer to these as “functional requirements”, which I think is where the problem in terminology lies: when I say “requirements”, I mean “business requirements”; when some people say “requirements”, they mean “functional requirements”, or rather, how the system behaves rather than what the business needs. This is further complicated by those who choose not to document the business requirements at all, but go directly to functional design, call it “requirements”, and gloss over the fact that the business requirements have been left undocumented. Personally, I don’t consider functional design to be requirements, I consider it to be design, to be performed by a trained designer, and based on the business requirements.
Lastly is the technical design, about which there is usually little debate, although there’s still way too many projects where this stage is at least partially skipped in favour of going straight from functional design to coding.
All this being said, it’s possible for a designer who is familiar with the requirements to internalize them sufficiently to do a good functional design, which in turn can produce a good technical design and a system that meets the current requirements. So what’s the problem with just skipping the documentation of business requirements and progressing straight to functional design? There are two problems, as I see it. First, there’s a big communcation gap between the business and the technology. The technical designer understands what the system should do, but not why it should do it that way, so can’t make reasonable suggestions for modifications to the functional design if there appears to be a better way to implement the system. Second, the future agility of both the business processes and the technology is severely impacted, since it will be nearly impossible to determine if a change to the technology will violate a business requirement, or to model how a changing business requirement will impact the technology implementation, since the requirements are not formally linked via a functional design to the technical design.
A lot of the work that I do is centred around BPM, and although these principles aren’t specific to BPM, they’re particularly important on BPM projects, where the functional design can sometimes appear to be obvious to the subject matter experts (who are not usually trained designers) and a lot of paving of the cow paths occurs because of that.