Java Software Factories: Part 11 - Requirements Flexibility
Project sponsors rarely know exactly what they really want. It's not their fault, really. A project sponsor would have to be truely remarkable to anticipate and document every requirement in advance. It's reasonable to expect that new ideas will emerge (good developers often get into the spirit of the project and suggest improvements) or gaps will be spotted as soon as a solution is tried by end users for the first time. From personal experience, if the project is for a software product, then the product manager will by under constant pressure from the sales team to add new customer requested features.
Business requirements can change mid project even if the project sponsor has done a good job decribing the initial requirements.
Rather than complain about moving targets, developers should anticipate that the project is not finished even if all the requirements are satisfied.
Simple message: assume the deliverable is a moving target.
One essential element of Java Software Factories is the ability to deliver results quickly (for example, cutting out protracted architectural discussions and vendor selection at the start of a project). But the true key to speed is code generation of as much as sensible of the application. Code generation also means code re-generation. This means that changing requirements can be accomodated really quickly.
PJ Murray
CodeFutures Software
Comments
Grady Booch explains why he disagrees with Microsoft's rejection of the UML in favor of proprietary domain-specific languages and his thoughts on Software factories.
Microsoft's conveyor belt methods for software are dead wrong, witless, and counter-effective. Organizations that build good software know that software is an R&D activity, not a production line just-in-time effort.
Posted by: Thomas | February 5, 2007 09:01 PM