tag:blogger.com,1999:blog-15466608.post6215340282877470328..comments2008-01-08T16:53:54.998+11:00Craig Brownhttps://profiles.google.com/112202012347971122168noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-15466608.post-80607903025457277682008-01-08T16:53:00.000+11:002008-01-08T16:53:00.000+11:00(Disclaimer: I work for a company called <A HREF="http://www.accompa.com" REL="nofollow">Accompa</A> - we make affordable requirements management software.)<BR/><BR/>With that out of the way - Craig, you make a very good point in this post. In our customer surveys - "misunderstood requirements" are consistently rated as one of the biggest problems our customers face.<BR/><BR/>Your suggestion of "Have developers feed back their interpretation of requirements to the stakeholders and clients. Do it early and often." is an excellent suggestion. As a matter of fact, this is one of the 7 tips we share with our new customers to help them improve their requirements management as well! :)Raj Phttp://www.accompa.comnoreply@blogger.comtag:blogger.com,1999:blog-15466608.post-88165909770828928202007-11-01T13:10:00.000+11:002007-11-01T13:10:00.000+11:00Thanks for the feedback guys. All useful.<BR/><BR/>There is a lot of knowledge around business rules management. My focus in this blog is not so much on the tchnical aspects of requirements management, but principles like this are very important to understand.<BR/><BR/>When I want to look into topics like this I go to Scott Sehlhorst's blog at <A HREF="http://tynerblain.com/blog/" REL="nofollow">Tynerblain</A><BR/><BR/>Scott doesn't always have the answers but canoften oint you in the right direction.Craighttp://www.blogger.com/profile/04913411035783086223noreply@blogger.comtag:blogger.com,1999:blog-15466608.post-37100381032653291302007-11-01T10:44:00.000+11:002007-11-01T10:44:00.000+11:00I would also suggest managing the business rules for your system separately but linked to your requirements. Especially by defining the decision nodes in use cases that can be described using externalized business rules.<BR/>Check out this entry on the Smart Enough Wiki - <A HREF="http://www.smartenoughsystems.com/wiki/Business_Rules_and_Requirements" REL="nofollow">Business Rules and Requirements</A><BR/>JT<BR/>James Taylor<BR/><A HREF="http://www.smartenoughsystems.com/wp" REL="nofollow">The Smart (Enough) Systems blog</A><BR/><A HREF="http://www.ebizq.net/blogs/decision_management" REL="nofollow">My ebizQ blog</A><BR/><A HREF="http://www.smartenoughsystems.com/wp/about-the-book" REL="nofollow">Author of Smart (Enough) Systems</A>James Taylorhttp://www.blogger.com/profile/04589456040368641147noreply@blogger.comtag:blogger.com,1999:blog-15466608.post-89307858686715027772007-10-31T21:29:00.000+11:002007-10-31T21:29:00.000+11:00Just some short comments: ad 1. documents aren't sufficient enough - have a prototype (even a very rough one) ready ASAP to earlier avoid possible misunderstanding and possible complete re-development.<BR/>Ad 2. regular communication and feed back of developers with stakeholders - subject matter experts and requirements creators is a must! On some of my projects, where development was off-shored, Skype helped a lot.<BR/>And maybe 4. have your developers make developments in one run if possible! They usually tend to do it in more separate approaches, alternating different developments for different customers which protracts time of the development and allows more misunderstanding between what was requested and what was really delivered.<BR/>And don't forget to manage your developers in their promises. "Anything" can be developed, the only question is in what time and for what money - developers usually have no responsibility for these issues, but they tend to make a Porsche Carrera where only Fiat Punto is needed :-)Juraj Kantorhttp://www.blogger.com/profile/00492872748602193385noreply@blogger.com