Welcome to the November 4, 2007 edition of The Carnival of Business Analysts.
This month I have focused in on Requirements Elicitation, one of the key processes the IIBA define in the BABOK. If you submitted a BA relevant post, but nt on elicitation - thanks but I had plenty of content to deal with.
Actually, most of these posts were sourced by me and and google. I'm still hoping for more support in compilting this list - especially from regular reader - so next month people; lend a hand! Next month's topic will be Requiements Analysis.
So - On with the carnival...
A little bit about Requirements Elicitation
Bob Robason writes about how requirements are important regardless of whether a project is following an agile or waterfall development model at Bob Robason on Software Excellence in Waterfall vs Agile Development.
Barbara at the Business Analyst Blog says “It’s good to have a developer during requirements elicitation” for the added technical expertise and to help short circuit communication breakdown later on in the development cycle.
Akram has a blog called Business Analysis Skills where he writes quite a long post of Requirements Elicitation. His essay looks at the problem teams face with requirements elicitation and them proposes a model he calls Active Structure for effective elicitation.
“Ed” at Hacknot writes an interesting article called The three ages of the developer where he identifies that even though getting the requirements right up front has the biggest potential impact on a project’s success, it actually gets little relative attention. (Hacknot also has an e-book of essays on the topic of software development you can download for free.) The three ages are the age of coding, age of design and age of requirements. Go read the article.
The practical bits
Karel Vandenberghe presents 5 Essential Thoughts for Open Source Innovation posted at Open Innovators, saying, "Pioneering process management today crosses the boundaries of traditional silos. The focus of open innovation is on collaboration and external idea sourcing.
Adrian Marchis presents The Popcorn Way and the Business Analyst posted at Modern Analyst, saying, "How do you know when you're done eliciting requirements?"
Jon Babckock pointed me to the Trials and Tribulations of a Business Analyst blog where the author reminds us that big picture Conceptual Thinking is part of the elicitation process.
Keith Mathis has a series of fiver articles on requirements interviews. You can read the first one here at PM Hut.
Kaka lists some strengths and weaknesses of eight different elicitation techniques at My Learning Path in Requirements gathering techniques.
Trent warns against over-thinking the problem with Beat Analysis Paralysis: Don't Let Good Projects Go Bad at his blog Just for Show. He specifically focuses in on people and leadership. I particularly liked this post.
Robert Rose-Coutré writes about how to identify implied requirements at Sticky Minds in his article Capturing Implied Requirements. My key takeaway from this article was that analysts and requirements managers need to understand business processes to best identify those tricky, unspoken expectations.
Michael Madigan has produced a clear and probably useful “How to” presentation on Requirements Elicitation. It focuses on the human challenges of effective RE at the front and then follows up with some practical techniques.
Scott Sehlhorst has written an article assessing each of the main requirements elicitation techniques in a post called Elicitation Techniques for Processes, Rules, and Requirements at Tyner Blain . If you read this article you will be better able to pick and choose how you go about your elicitation activities based on what particular part of a system or process you are investigating. (In fact maybe I should have included it in the requirements planning carnival.)
Ezie Ann gives some example interview questions (with answers) for you at her livejournal site under the title Requirements Elicitation Round 1.
Lo and Hi fidelity prototypes are compared by Tubious in Prototypes- From the Stakeholders Perspective. It’s a longish but interesting article. And referenced!
R.S. Pressman & Associates present a 22 point Requirements elicitation checklist with the explanation; Eliciting requirements need not be like pulling teeth … but sometimes it is. The problem is lack of preparation by the software engineer and lack of interest by the organization or person requesting the work
MJMurphy highlights he importance of active listening skills in Are you listening? At Seilevel - requirements defined.
Amaya writes about ‘Beautiful requirements' at Portrait of a Business Analyst in a post called From Necessity to Nefertiti.
Lastly, a presentation on Requirements Engineering in the context of object oriented development. It comes with a section to translating use cases into objects.
Some more useful Requirements Elicitation resources
That concludes this edition. Submit your blog article to the next edition of The Carnival of Business Analysts using our carnival submission form. Past posts and future hosts can be found on our blog carnival index page.