Comments on: Eliciting Requirements http://www.b2ttraining.com/2007/09/04/eliciting-requirements/ Connecting Business Requirements to Technology Mon, 30 Aug 2010 03:15:53 -0400 http://wordpress.org/?v=2.8.5 hourly 1 By: Angie http://www.b2ttraining.com/2007/09/04/eliciting-requirements/comment-page-1/#comment-1058 Angie Sat, 15 Sep 2007 01:09:53 +0000 http://www.b2ttraining.com/2007/09/04/eliciting-requirements/#comment-1058 Oh by the way, Chris - may I say "Amen" to your comments about documenting system use cases before moving on to the mock-ups!!! Oh by the way, Chris – may I say "Amen" to your comments about documenting system use cases before moving on to the mock-ups!!!

]]> By: Angie http://www.b2ttraining.com/2007/09/04/eliciting-requirements/comment-page-1/#comment-1057 Angie Sat, 15 Sep 2007 01:07:15 +0000 http://www.b2ttraining.com/2007/09/04/eliciting-requirements/#comment-1057 Thanks for your contributions - These are great. Keep 'em coming. I hope we get some more folks to comment. Thanks for your contributions – These are great. Keep ‘em coming. I hope we get some more folks to comment.

]]> By: Claudio Kerber http://www.b2ttraining.com/2007/09/04/eliciting-requirements/comment-page-1/#comment-1056 Claudio Kerber Wed, 12 Sep 2007 12:12:43 +0000 http://www.b2ttraining.com/2007/09/04/eliciting-requirements/#comment-1056 Well, I can say I'm lucky. Since my company works on the IT field, it's often easy to jump right to the entity classes with the user and later think about the use cases that affect them. Of course we first map the current process and then work on the new concept. - Kerber ITBA - Digitro Technology www.digitro.com Well, I can say I’m lucky. Since my company works on the IT field, it’s often easy to jump right to the entity classes with the user and later think about the use cases that affect them. Of course we first map the current process and then work on the new concept. – Kerber ITBA – Digitro Technology http://www.digitro.com

]]> By: Chris http://www.b2ttraining.com/2007/09/04/eliciting-requirements/comment-page-1/#comment-1055 Chris Sat, 08 Sep 2007 06:52:32 +0000 http://www.b2ttraining.com/2007/09/04/eliciting-requirements/#comment-1055 Instead of talking about the entire process of Eliciting Requirements I will comment on some of the pitfalls. I think the biggest mistake that most companies/analysts make is not creating Business Process Flows and Business Use Cases of the current state of the business process. This unifies the understanding of the business process among all of the Subject Matter Experts/Business Users. As I'm sure we have all experienced even the so called SMEs have different explanations and views of the current business process. Then, from the current business process flows and business use cases we can begin to document the functional and non-functional requirements of a system that facilitates and optimizes the business process. How do we do this? Not by jumping into screen design. Before creating screen mockups, take the time to document functional requirements and system use cases. This gives everyone an unbiased view and opinion of what the system needs to achieve. Most analysts start creating the screen mockups too soon and then create system use cases. This typically results in screen designs that don't support the system requirements as elegantly as they could. System Use Cases are written mentioning dropdowns, buttons, and links. Even worse, they mention specific screens instead of allowing a function to be fulfilled across as many or as few screens as makes sense based on the purely logical requirement. -Chris ModernAnalyst.com, Core Member Instead of talking about the entire process of Eliciting Requirements I will comment on some of the pitfalls.

I think the biggest mistake that most companies/analysts make is not creating Business Process Flows and Business Use Cases of the current state of the business process. This unifies the understanding of the business process among all of the Subject Matter Experts/Business Users. As I’m sure we have all experienced even the so called SMEs have different explanations and views of the current business process.

Then, from the current business process flows and business use cases we can begin to document the functional and non-functional requirements of a system that facilitates and optimizes the business process. How do we do this? Not by jumping into screen design.

Before creating screen mockups, take the time to document functional requirements and system use cases. This gives everyone an unbiased view and opinion of what the system needs to achieve. Most analysts start creating the screen mockups too soon and then create system use cases. This typically results in screen designs that don’t support the system requirements as elegantly as they could. System Use Cases are written mentioning dropdowns, buttons, and links. Even worse, they mention specific screens instead of allowing a function to be fulfilled across as many or as few screens as makes sense based on the purely logical requirement.

-Chris
ModernAnalyst.com, Core Member

]]> By: iraig Brown http://www.b2ttraining.com/2007/09/04/eliciting-requirements/comment-page-1/#comment-1054 iraig Brown Thu, 06 Sep 2007 06:51:30 +0000 http://www.b2ttraining.com/2007/09/04/eliciting-requirements/#comment-1054 Good old fashioned research is another path. For example research into best practices via google, industry hubs, research firms etc. I've just done this as a first step into researching the functions and design of a new website. Good old fashioned research is another path. For example research into best practices via google, industry hubs, research firms etc. I’ve just done this as a first step into researching the functions and design of a new website.

]]> By: Jakub Strzemżalski http://www.b2ttraining.com/2007/09/04/eliciting-requirements/comment-page-1/#comment-1053 Jakub Strzemżalski Tue, 04 Sep 2007 15:13:56 +0000 http://www.b2ttraining.com/2007/09/04/eliciting-requirements/#comment-1053 Angie, most often the mixture of prototyping and interviews is the way to go for me. I like to include the business representatives early in imagining the final product. Usually I'm trying to avoid the very rough theory and create some tangible solutions on which we can work on later on. Using prototypes you can easily verify whether you have the commons understanding with your business customer. Angie, most often the mixture of prototyping and interviews is the way to go for me. I like to include the business representatives early in imagining the final product. Usually I’m trying to avoid the very rough theory and create some tangible solutions on which we can work on later on. Using prototypes you can easily verify whether you have the commons understanding with your business customer.

]]>