Comments on: When to stop analyzing requirements and start shopping for software solutions http://www.bridging-the-gap.com/when-to-stop-analyzing-requirements-and-start-shopping-for-software-solutions/ Helping business analysts become leaders and advance their careers. Fri, 12 Mar 2010 17:33:53 -0700 http://wordpress.org/?v=2.8.6 hourly 1 By: Richard Lynn Paul http://www.bridging-the-gap.com/when-to-stop-analyzing-requirements-and-start-shopping-for-software-solutions/comment-page-1/#comment-498 Richard Lynn Paul Tue, 05 May 2009 20:23:47 +0000 http://www.bridging-the-gap.com/?p=727#comment-498 Leave problematic/difficult stories vague as the programmers, or more often, the domain experts will often come up with a solution that is better than what was originally planned/conceived. This is the benefit of talking to them prior to or during a FEATURE BLITZ. (Programmers read about the latest and greatest and often can plug in something immediately and not have to re-invent the wheel.) Leave problematic/difficult stories vague as the programmers, or more often, the domain experts will often come up with a solution that is better than what was originally planned/conceived. This is the benefit of talking to them prior to or during a FEATURE BLITZ. (Programmers read about the latest and greatest and often can plug in something immediately and not have to re-invent the wheel.)

]]> By: Leslie http://www.bridging-the-gap.com/when-to-stop-analyzing-requirements-and-start-shopping-for-software-solutions/comment-page-1/#comment-352 Leslie Wed, 22 Apr 2009 18:18:39 +0000 http://www.bridging-the-gap.com/?p=727#comment-352 "The line between business requirements and functional requirements is a bit gray, but use it as a guide stick in your project." -------------- I have posted several articles about the difference between business use cases and system (or application) use cases. The same principals can be applied to any business vs system requirement types. Think of business requirements as system independent. I like to think that a business requirement is written such that it can be implemented using nothing more than pencil and paper. A system requirement describes a functional interaction with an application. Another way to think of the difference is project vs product. A business requirement is part of a project and may impact several applications. A system requirement is specific to an application and is derived from a business requirement on a project. Leslie. You can find information on my website; http://www.umllmu.com “The line between business requirements and functional requirements is a bit gray, but use it as a guide stick in your project.”
————–
I have posted several articles about the difference between business use cases and system (or application) use cases. The same principals can be applied to any business vs system requirement types.

Think of business requirements as system independent. I like to think that a business requirement is written such that it can be implemented using nothing more than pencil and paper.

A system requirement describes a functional interaction with an application.

Another way to think of the difference is project vs product.

A business requirement is part of a project and may impact several applications. A system requirement is specific to an application and is derived from a business requirement on a project.

Leslie.

You can find information on my website; http://www.umllmu.com

]]>