How to begin the software requirements gathering process: Elicitation and analysis techniques

The software requirements gathering process for a new agile development project can seem daunting at first. In this expert response, Sue Burk offers advice on how to begin using elicitation techniques and choosing analysis models that fit your business needs.

I’m starting a new project and don’t even know how to begin the requirements gathering process. What do you recommend?

Rather than think solely about gathering requirements, think of what you are about to do for requirements elicitation and analysis. The International Institute of Business Analysis (IIBA) defines elicitation as “an activity within requirements development that identifies sources for requirements and then uses techniques such as interviewing, prototyping, facilitated workshops, and documentation studies to gather requirements from these sources.”1 The IIBA notes that requirements analysis encompasses the ability to “prioritize and progressively elaborate stakeholder and solution requirements in order to enable the project team to implement a solution that will meet the needs of the sponsoring organization and stakeholders.” 

You begin the first step of elicitation -- stakeholder analysis -- by understanding the sources you will tap for requirements, including stakeholders and physically accessible references (e.g., documentation, manual procedures, polices, and so on). To identify your stakeholders, look for people within these categories: the sponsor, product champions, direct and indirect users, advisers, and suppliers. Consider their interests, concerns, and success criteria, and remember that not all stakeholders are equal. Stakeholder analysis provides useful information about which requirements elicitation techniques are best for your situation.

Now you’re ready to elicit the requirements from the stakeholders, and in agile development, you analyze requirements as you elicit them. For analysis, choose models that fit your business domain; for example, data models, business rules, scenarios and tests are useful for data-centric applications. You’ll want to also consider events and use cases or user stories for transactional applications. Remember to analyze each requirement just enough to understand it. Don’t worry too much about the modeling notation; your goal is to understand the requirement. And be sure to prioritize as you elicit and analyze. In this way, you spend time focusing only on those requirements you’re going to deliver next.

No matter which elicitation and analysis techniques you use, some common thought processes apply:

  • Set the stage for requirements elicitation and analysis by gaining a clear understanding of the business value (goals and objectives) and product vision.
  • Define or confirm the scope of the project -- what’s in and what’s out of scope.
  • Understand your stakeholders, identify the optimal means of eliciting requirements from them, and ensure that everyone is clear and agrees, from the beginning, about what it means for a requirement to be “done.”
  • Use multiple elicitation techniques to uncover requirements that are in scope. Prioritize requirements continually.
  • Start requirements analysis and development with the highest-priority requirements, and identify enough details to achieve “doneness.”

You mention you don’t know where to begin. I suggest you inquire about the goals, objectives, vision, and scope of your project. Ask about which elicitation techniques have been most effective in your organization to clarify a product’s scope. If you don’t have a clear definition of scope, you have no product boundaries. Without boundaries, it’s not possible to prioritize, to assess the impact of inevitable changes or even to know when you are finished. If at all possible, consult with a mentor or someone who has hands-on experience with analysis to help you apply your organization’s techniques. 

1. International Institute of Business Analysis,  Guide to Business Analysis Body of Knowledge® (BABOK®), 2nd edition. This definition, along with a major portion of the BABOK® glossary, is taken with permission from The Software Requirements Memory Jogger:  A Pocket Guide to Help Software and Business Teams Develop and Manage Requirements by Ellen Gottesdiener (GOAL/QPC, 2005).

Dig Deeper on Topics Archive