A member of an Internet software architecture group I belong to posted a question the other day. His current organization is leaning toward separating requirements specification and architecture, in effect, removing the software architect’s voice from the requirements definition process.
While there are several reasons that people in an organization might follow that path, none of them further the success of the system being built. While I consider myself to be an experienced driver, I don’t consider me to be qualified to lead the requirements definition of the next generation Lexus. While I recognize good accelleration, handling, and braking when I see it, I simply don’t know enough about fuel injection, compression, engine electronics, suspension, fuel economy, cooling, or any of the dozens of concerns that separate one car from another. No. This subject is too complex not to be left to the experts.
Yet, stakeholders of other systems feel empowered to take control of the requirements definition process, feeling as though once the essential “what” decisions have been made, they can safely lob the requirements specification over the wall to the engineers, who will somehow figure out “how” to do it.
This article http://charliealfred.wordpress.com/requirements-vs-architecture/ explores the relationship between requirements and architecture, and illustrates the paradox of how some requirements must driver architecture while others must be subordinate to it.
