In my final article on requirements development, I want to discuss the processes involves in eliciting requirements from business stakeholders.  There are several commonly held techniques that are used for gathering requirements from business customers.  Some of these methods are specific to software systems or systems with some type of user interface, and some are applicable to any type of deliverable:

  • Interviews – a one on one or one on several (2-3) of stakeholders question and answer session guided by a pre scripted list of tailored questions.  The questions should be comprised of a set of context free inquiries to promote bias free discussion.  Once the context free answers have been documented, some solution specific questions can be used to explore stakeholder leanings related to specific solutions.
  • Brainstorming workshops – a facilitated multi hour, perhaps all day session with all key stakeholders present.  There are usually ice breaking and warm up exercises to set ground rules and promote free thinking.  Then there is grounding in basic project material, followed by group brainstorming to elicit multiple ideas.  Usual rules are to generate as many ideas as possible, piggy back ideas off each other, and suspend judgment on any idea. Towards the end of the workshop the ideas must be grouped, clarified, reduced and prioritized.  These sessions are notorious for sometimes being difficult to manage and requiring the skills of a trained facilitator – preferable one from outside the organization with no political ties to any of the stakeholders.  Typical challenges include:
    • Time Management
    • Domineering
    • Lackluster participation
    • Negative, petty comments
    • Turf wars
    • Post lunch energy sag
  • Role Playing – basically this is like walking a mile in the stakeholder’s shoes.  When possible the analyst carries out a day in the job of the stakeholder he/she is trying to gather requirements from – i.e. using the computer application to enter an order, welding a part, etc.
  • Scripted walkthroughs – similar to role playing, when an actual role play is not possible, this method allows a simulated experience via a script.
  • Prototypes – typically used in the context of a software development effort, a prototype is a partial implementation – a mock up of the external interface or what the stakeholder experiences when he interacts with the system.  This is a good way to let the stakeholder play with the model and discover what feels to be missing.  This sometimes uncovers entire feature sets that until then were unexpressed.
  • Storyboarding – Similar, but less elegant than prototypes, story boarding is used to gain early reactions from stakeholders on concepts proposed for deliverables.  Story boards can exist in 3 different styles:
    • Passive, containing screen shots, written business rules, process flow diagrams, output reports, etc. all laid out in a sequence so as to paint a picture or tell a “story” about how things will work.
    • Active, containing slideshows, animation, or simulations to try to make stakeholders see a movie that hasn’t been created yet.
    • Interactive, requiring participation in order to allow the stakeholder to experience the system in as realistic a manner as possible.

From my experience, I like to employ a combination of the above methods.  Personally, I never like to convene a large group to discuss anything with a blank sheet of paper.  I believe beginning a large group session with no content already established at least at a high level – i.e. a blank canvass is an invitation for chaos.  My preference is to outline the areas of requirements and determine who the primary stakeholders are for each area first, from analysis of project objectives and discussion with sponsors.  Then create a targeted questionnaire around each focused area and interview 1 – 3 primary stakeholders who are most directly affected / involved with the topic to get the core facts.  Sometimes a role play or scripted walk through can be combined with an interview to allow the stakeholder to demonstrate their world to the business analyst.  The larger “big tent” sessions can then be a refinement or validation session of those core facts by secondary stakeholders who can add their concerns and needs.  These secondary stakeholders may be primary stakeholders of another area. 

Once an initial set of requirements have been gathered story boards and prototypes allow analysts and implementation teams to demonstrate back to the stakeholders whether they “got it” right and seek verification before they commit to final implementation.

Requirements elicitation is hard work requiring a mind meld of those participating in the process on whatever level of detail is being discussed. The more you limit the number to those who have expertise on a focused topic, the more likely you are to reach consensus.

What are your thoughts?

References:

Leffingwell,D., Widrig, D. (2000) Managing Software Requirements, A Unified Approach, Upper Saddle River, NJ: Addison-Wesley.