Comments for Methods for Eliciting - Not Gathering - Requirements at http://www.batimes.com , comment 1 to 12 out of 12 comments http://www.batimes.com Fri, 03 Sep 2010 05:29:33 +0100 FeedCreator 1.7.3 http://www.batimes.com/articles/methods-for-eliciting-not-gathering-requirements.html#comment-1430 Thanks for your article! Elicitation is both art and science. Great analysts need to draw on all the techniques you mention, selecting a combo that fits the situation. Collaboration is crucial, but doesn't just happen. Collaboration needs to be 'engineered' for effective elicitation. In my book _Requirements by Collaboration: Workshops for Defining Needs_ i discuss ingredients for successful requirements workshops including: shared purpose the right people shared space wise groups pre-work focus questions serious play trust process variety doneness tests collaborative closure flexible structure using both sides of the brain frequent debriefs. we also need know a variety of requirements models (e.g. analysis models) to draw upon that are appropriate to the domain. (and not be "one trick ponies" with our reqts. models). whew, that's alot to know and manage, while managing ourselves to be neutral and fully present throughout a workshop! - ellengott Wed, 19 May 2010 13:48:58 +0100 http://www.batimes.com/articles/methods-for-eliciting-not-gathering-requirements.html#comment-719 Wow! Words do carry a lot of impact, don't they? I think that the kernel of the matter is *participation*. The stakeholders need to play an active role and not just regurgitate information for the BA to scoop up. I routinely will start by giving stakeholders a mini-session on what a use case is and how we use them to take snapshots of what we want, and engage those stakeholders in actually writing and reviewing the use cases. I've had really positive experience with that, and a lot of success. Ron www.casecomplete.com - Ron Phillips Tue, 25 Aug 2009 09:25:06 +0100 http://www.batimes.com/articles/methods-for-eliciting-not-gathering-requirements.html#comment-701 agree with paul1795. Business Analyst should not negotiate on the requirements or scope of the project. but on the timeline, resources, budget etc. - deepthi pasupuleti Wed, 19 Aug 2009 06:15:13 +0100 http://www.batimes.com/articles/methods-for-eliciting-not-gathering-requirements.html#comment-584 I have to disagree with the use of "negotiate" when it comes to requirements - whether they are being elicited, collected, gathered, hunted for or otherwise stumbled upon. Requirements represent the needs of the business that will allow them to meet their goals / objectives - it is not up to the BA to "negotiate" the needs of the business. It is up to the BA to understand the needs of the business, and as best possible, proactively provide solutions that allow them to be successful at achieving their goals / objectives. Negotiation will come into play when a solution is recommended, and the BA needs to collaboratively work with the business to determine which requirements will be included in the scope of the project that provides the solution. Depending on the amount of funding available for the project (and other factors like time lines and resources), some requirements will be addressed, and others will not. - paul horvath Wed, 01 Jul 2009 08:06:37 +0100 http://www.batimes.com/articles/methods-for-eliciting-not-gathering-requirements.html#comment-583 In order for group sessions of any type to be successful they need to be planned with a goal well-specified and facilitated rather than just run as an open forum. Not only are business process modeling skills important - but also data modeling skills, especially clearly defined business rules and data definitions, to ensure that the results are correctly understood. - greta blash Wed, 01 Jul 2009 05:55:34 +0100 http://www.batimes.com/articles/methods-for-eliciting-not-gathering-requirements.html#comment-579 The verb "gather" creates a difficult-to-achieve expectation that BAs just have to conduct an interview and pluck well-formed requirements out of SME's heads like gathering apples from a tree. "Elicit" is better because it implies that it will take a little work to collect/pull the information from the source. I like "negotiate" because it implies a collaborative effort. And, I concur with the comment that BAs need to have business process modeling skills as well as requirements elicitation/negotiation skills. Nice article. - Cecilie Hoffman Tue, 30 Jun 2009 16:59:51 +0100 http://www.batimes.com/articles/methods-for-eliciting-not-gathering-requirements.html#comment-578 Interesting comment about negotiate rather than elicit or gather. I tend to think requirements is a collaborative effort from all parties involved. Those impacting requirements and those impacted. Understanding the needs of the business to effectively develop the right solution takes a village! - Kupe Kupersmith Tue, 30 Jun 2009 16:32:53 +0100 http://www.batimes.com/articles/methods-for-eliciting-not-gathering-requirements.html#comment-577 Personally, I prefer negotiate rather than gather or elicit. Negotiate implies an iterative discussion with all sides fully communicating their business problems and policies. Gather and elicit connotes a one-sided interrogation. A BA needs to be proficient in business modeling as well. You can't just rely on the unstructured English language as a means of communicating the negotiated requirements. From an IT perspective, I expect BAs to have a working knowledge of the Unified Modeling Language (UML). - Dan Tue, 30 Jun 2009 12:17:26 +0100 http://www.batimes.com/articles/methods-for-eliciting-not-gathering-requirements.html#comment-576 Group Interview: Aa meeting with multiple subject matter experts that can contribute to the subject. These may be a one time meeting or multiple meetings to resolve the business needs. Workshop: A workshop is an event where many SME's are assembled in one location for a short period of time (usually one to three days) to have concentrated meetings to address requirements for a project very quickly. Focus Group: A focus Group is more for testing the viability of a product or solution. - J Tue, 30 Jun 2009 11:03:28 +0100 http://www.batimes.com/articles/methods-for-eliciting-not-gathering-requirements.html#comment-575 Jill, Take a look at http://www.sei.cmu.edu/publications/documents/92.reports/92.tr.012.html to see issues with "eliciting" requirements and the approaches to deal with these issues. Glen B. Alleman VP, Program Controls Aerospace and Defense Denver, Colorado - Glen B. Alleman Tue, 30 Jun 2009 10:58:30 +0100 http://www.batimes.com/articles/methods-for-eliciting-not-gathering-requirements.html#comment-574 Jill, Great job! I particularly liked the heading of the article; Business requirements don't just lie there for the BA to collect them. Elicitation is perhaps the most crucial phase of any project, since errors in requirements found down the road are extremely expensive to correct. Thanks! Aaron Gothelf A REAL BUSINESS ANALYST http://www.aarongothelf.com/myblog - Aaron Gothelf Tue, 30 Jun 2009 10:42:13 +0100 http://www.batimes.com/articles/methods-for-eliciting-not-gathering-requirements.html#comment-573 What would be the difference between a group interview, a workshop, and a focus group? They sound about the same to me. - Jay Henderson Tue, 30 Jun 2009 08:57:16 +0100