Comments on: Business Rules And Requirements http://tynerblain.com/blog/2006/10/18/business-rules-and-requirements/ Software product success. Thu, 18 Mar 2010 20:39:50 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: Scott Sehlhorst http://tynerblain.com/blog/2006/10/18/business-rules-and-requirements/comment-page-1/#comment-58957 Scott Sehlhorst Wed, 20 Dec 2006 15:30:17 +0000 http://tynerblain.com/blog/2006/10/18/business-rules-and-requirements/#comment-58957 Vish, thanks for reading and commenting on Tyner Blain - welcome! Good article too, organizing the elements of your approach. Folks - check it out. Vish, thanks for reading and commenting on Tyner Blain – welcome!

Good article too, organizing the elements of your approach. Folks – check it out.

]]> By: Vish Desai http://tynerblain.com/blog/2006/10/18/business-rules-and-requirements/comment-page-1/#comment-58945 Vish Desai Wed, 20 Dec 2006 11:21:07 +0000 http://tynerblain.com/blog/2006/10/18/business-rules-and-requirements/#comment-58945 Your approach towards requirements gathering and analysis is very similar to the methodology we use in YASU Technologies (http://www.yasutech.com) whenever we are called in to help our customers capture and define their own rules. I'd posted something similar a few days ago @ http://usecases.brmsblog.com/2006/12/11/requirements-gathering-with-use-cases/ Your approach towards requirements gathering and analysis is very similar to the methodology we use in YASU Technologies (http://www.yasutech.com) whenever we are called in to help our customers capture and define their own rules.

I’d posted something similar a few days ago @ http://usecases.brmsblog.com/2006/12/11/requirements-gathering-with-use-cases/

]]> By: Scott Sehlhorst http://tynerblain.com/blog/2006/10/18/business-rules-and-requirements/comment-page-1/#comment-56008 Scott Sehlhorst Sun, 29 Oct 2006 01:07:16 +0000 http://tynerblain.com/blog/2006/10/18/business-rules-and-requirements/#comment-56008 James, thanks for reading and commenting! Good articles at the links too. We're using a similar approach right now, where we are capturing requirements and rules in the context of modeled processes. The framework helps us with overall decomposition of the problem, but is adding some complexity for many of the business folks we're working with. Ideas like "recording the same rule twice because it is relevant to two processes" are causing some confusion. But it's the right thing to do, and we are helping them learn why. Thanks again, Scott James, thanks for reading and commenting!

Good articles at the links too.

We’re using a similar approach right now, where we are capturing requirements and rules in the context of modeled processes. The framework helps us with overall decomposition of the problem, but is adding some complexity for many of the business folks we’re working with. Ideas like “recording the same rule twice because it is relevant to two processes” are causing some confusion. But it’s the right thing to do, and we are helping them learn why.

Thanks again,
Scott

]]> By: James Taylor http://tynerblain.com/blog/2006/10/18/business-rules-and-requirements/comment-page-1/#comment-55961 James Taylor Fri, 27 Oct 2006 16:49:41 +0000 http://tynerblain.com/blog/2006/10/18/business-rules-and-requirements/#comment-55961 Nice post. I think more needs to be done by most folks to keep rules separate from requirements. I like the way the book Use Cases: Requirements in Context handles use cases and rules (http://www.edmblog.com/weblog/2006/04/book_review_use.html) I also think that people can become over fixated on solving their problems with requirements - sometimes it is rules that matter (http://www.edmblog.com/weblog/2005/08/writing_better_.html). Thanks for blogging. JT Nice post. I think more needs to be done by most folks to keep rules separate from requirements. I like the way the book Use Cases: Requirements in Context handles use cases and rules (http://www.edmblog.com/weblog/2006/04/book_review_use.html)
I also think that people can become over fixated on solving their problems with requirements – sometimes it is rules that matter (http://www.edmblog.com/weblog/2005/08/writing_better_.html).
Thanks for blogging.
JT

]]>