Designers must do the modeling

Abstract

Put simply, those who construct the system, the designers, should own the requirements. To understand why, let's step back and examine what requirements really are. If we think of the requirements process as a black box, there are inputs to the process, things happening inside the black box, and outputs from the process. Inputs to the process include discussions with customers, past products, competitors' solutions, prototypes, and new ideas. Many authors have claimed that the primary output of a requirements process is a requirements specification. Not so. The primary output is our collective understanding of the customer's problem. The specification is only a representation, a model of that understanding. Although important, it is still a secondary product of the requirements process. One can think of requirements as "anything that drives design choices". Based on that definition, a system's requirements are the collection of the reasons why we choose to design it as we do. Design choices are made not on paper, but inside the minds of designers. The choices are documented on paper. There are many other outputs of the requirements process, such as dataflow diagrams, object models, state models, event models, entity relationship models, natural language statements, and so on. The main benefit of producing all these artifacts is a better and agreed upon understanding of the problem, so that we can design more effective solutions for it.