Where do you think the responsibility lies? Do you trust business-side stakeholders to come up with good requirements on their own? How does collaboration between the two groups happen at your organization—or does it at all? Tell us in the talk.editors.devx discussion group.
Alternative programming methods challenge the status quo, but taking developers out of the requirements process is one idea that just doesn't transition from theory to reality.
by Lori Piquet, Editor-in-chief
April 2, 2003
he more time I spend thinking about alternative programming methodologies, the more I wonder why there's so much resistance. Which is to say that I generally believe in the concepts of agile programming—except, at least, one. Last week I attended a presentation by Scott Ambler, the guru of the Agile Modeling methodology. The talk was one in a series of lectures put on by SDForum. Ambler clearly knows what he's talking about and has seen it work. But it wasn't until I read more about Ambler's belief that requirements are the sole domain of business managers, or "stakeholders," that I felt a rift opening. In an online essay, Ambler says defining requirements and prioritizing them are solely the responsibility of business-side stakeholders and not the concern of developers.
I don't wish to oversimplify Ambler's position. He has written volumes about what he calls "Active Stakeholder Participation" and on close study, much of it is quite sensible. But I cannot agree with the basic premise: The process of creating software requirements simply cannot be decoupled from the technical knowledge base, and that technical knowledge base lies in the brains of developers.
Editor's Note: Though the Agile Modeling methodology states that requirements are the responsibility of business people and not developers, the particulars of its recommendations are complex. The full body of Ambler's work encourages, rather than discourages, better communication between business managers and developers. My issue is not with the Agile Modeling methodology per se, but with any philosophy or practice that says that developers should not be full participants in requirements planning at every level. Interested readers should read Scott Ambler's response at http://www.agilemodeling.com/essays/passingTheBuck.htm.--LP
However much development wants business stakeholders to be perfectly equipped to define and prioritize software tasks, it's simply wishful thinking. Sure, it would be great if you had interested, technically astute business people who could clearly formulate software requirements and help with design and who are given adequate time to devote to the process, but this circumstance is far too rare to expect.
It's quick, easy and you get access to all the articles on DevX.
This registration/login is to allow you to read articles on devx.com. Already a member?
To become a member of DevX.com create your Member Profile by completing the form below. Membership is free!
he more time I spend thinking about alternative programming methodologies, the more I wonder why there's so much resistance. Which is to say that I generally believe in the concepts of agile programming—except, at least, one. Last week I attended a presentation by Scott Ambler, the guru of the Agile Modeling methodology. The talk was one in a series of lectures put on by 
