3 November 2007

A Carnival of Business Analysts #4; Requirements elicitation

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.

Dennis Somer writes a post of effective meeting management PMHut in How to conduct meetings like a top performer. As most requirements elicitations happen in meetings of one sort or another this is quite relevant.

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

  • Modern Analyst’s Requirements Discussion Board
  • Requirements Engineering Yahoo Message Group

  • 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.


    1. Anonymous1:05 pm

      Issues in Requirements Elicitation
      By Michael G. Christel and Kyo C. Kang

      This is an 80 page discussion on specific requirements elciictation techniques. Even though this paper is 15 years old it still has a lot to offer on this reatvely unexplored discipline. Examples of techniques include considering what the needs of the business and developer are, breaking down requirements into particular domains, and more.

      What is missing is content on some of the more recent modelling techniques, but it's more than made up for with considerred thought on sme of the macro level issues in eliciting requirements. Think consider our udience, be clear, etc.

      You can access this paper via Modern Analyst's Articles archive

    2. Anonymous3:29 am

      Every time I read these disertations I am more and more convinced that the principles of the Assurance Science needs to be taught in all of our schools. Since assurance is the basis of every thought, decision, action and expense, one would think that it would be good to know what assurance really is. Oue brains make over 10,000 assutance decisions every minute and this is our life. The Assurance Science can quantify assurance and improve our decisions by over 1000 to one. I will try to write more when I can find out how to submit it. Thank you. Assurance is the understanding developed from previous experience that detrmines future expectations.