Almost a month ago, we published an article titled Broken Requirements Ecosystem. That article built on a discussion thread at Seilevel. Since that time, the original thread has grown, and a new one has been spawned at the Catalyze site.
In short, the question was asked on the Seilevel forum- why are specs sometimes ignored by developers, and four possible reasons were suggested. We followed up with our view, and the discussion picked up again, this time at Catalyze.
- Original discussion thread on Seilevel’s forum: Reasons Reqs Go Unread (Discussion from 19 Jun to 26 Jun )
- Article at Tyner Blain: Broken Requirements Ecosystem (Written on 21 Jun, Discussion to 26 Jun)
- Thread spawned on the Catalyze forum: Broken Requirements Ecosystem (Discussion from 23 Jun to 15 Jul)
Even if you read our article before, go back and follow the discussions again – starting with Seilevel’s article, and progressing to ours, following up with the conversation at Catalyze.
I think you have to figure that collaboration is, in the end, the name of the game. Having business users and IT collaborate on engineering the solution to the business problem is what you need and the requirements are just a means to that end.
Check out http://www.ebizq.net/topics/biz_opt/features/6387.html for instance or http://www.edmblog.com/weblog/2006/03/business_and_it.html
JT
You’re definitely right! The discussion threads here were more trying to understand the root cause of the problem (specs not being followed), but you’re definitely right – it is collaboration.
If a spec is to be useful, it should represent what the team agrees on and understands – not a fiat passed down from on high. Regardless, it is the people on the team that make things happen, and if people aren’t doing what you expect (and rely on them to do), you need to work with them to correct your mistakes and theirs.
Collaboration.