Analysis, design, and never the twain shall meet
We bring you a new Reg Developer author, a specialist in crossing the chasm between analysis and design Not many people know how to get from analysis to design. Software agilists “solve” the problem by blurring the distinction between the two. There has to be a better way... It’s a familiar scenario to many. Deep in the …
It seems a little rum to complain about 'Agilists' and then promote ideas recommended by arch-agilist Scott Ambler in his book:The Object Primer : Agile Model Driven Development..., where he recommends robustness diagrams and detailed use cases; and from what I've read Ivar Jacobson is now an 'Agilist'. Agile shouldn't be an excuse not to properly gather requirements, but rather provide tools for dealing with changing/evolving requirements.
I have a problem with this article on a fairly fundamental level. The model you suggest is the same old tired "The developer shouldn't deal with the users" approach.
If you don't have developers that can deal with users and perform well as Systems Analysts (To use an old, but accurate term) then you shouldn't be doing the project.
Having BA's or Project Managers making any type of technical assesment or decision is a sure recipe for disaster.
The developers themselves should be completing the detailed Use Cases alongside appropriately selected users.
Agile methods can be used or not, depending on preference, but final requirements gathering and detailed design belong to people that understand both the business impact and the technical impact of design decisions.
The more layers between the developers and the day to day business users, the more a project is doomed to fail.
