|« ECS5 – ECMAScript 5th edition released||How to create a template engine in 1 hour »|
This morning I had a new mail from a customer asking for some advice. Currently we have to develop a new system and had a few meetings to discuss about the project, it's feasibility, and also to define a plan. The next step now is to gather the business requirements. But the question which arises is : "Who has to do the business requirements".
The answer we had was obvious: "The business people". But it reminded me of an episode of The Simpsons. In this episode Homer discovers he has a half-brother, Herb, who is also the head of a big automobile manufacturer. During this episode Herb asks Homer to design a brand new car and that he has full power to decide. He defines the requirements, and the engineers produce it, as requested. The car was produced, as requested. Disaster.
What I want to say is that when a house is built, an architect should be in the process because he has some experience of the domain, has already faced a lot of problems and thus their solutions. When a car is designed it's the same. And for software ?
The business should not define requirements alone. Because Software Architects or Program Managers are paid for that, and because an advice is better to be given before everything is done than after. This could be to prevent from failure, but also to suggest features or behaviors that business wouldn't have imagined. And with a little chance, it can also make the difference between delivery and success.
Trackback address for this post
The problem with UML is that you can't add presentation layers and deploy the application without developers codding methods. If you code manually methods then the traditional MDD is impossible because only code from a static model is possible. This is why MDD is stupid !!
I mean that UML as a language is certainly the best way for documenting a project but using the model in a waterfall approach with MDD is just ridiculous !!
I have written an article on this waterfall versus agile approach available at: http://www.forum-omondo.com/documentation_eclipseuml_2008/waterfall_versus_incrementale_modeling_cycle.html
The contrary is also true: Don't let designers working alone.
In this case you'll certainly produce a nice piece of engineering, but useless for business...
Communication should be continuous, and use a common language that both world understand (e.g. usecase don't need much background).
This post has 14 feedbacks awaiting moderation...