How to overcome the top two challenges associated with getting requirements right

Expert Sue Burk identifies the top challenges in accurately defining requirements as the challenge of involving the appropriate decision makers and subject matter experts in requirements development, and the struggle to meet the needs of both technical and business audiences. In this expert response, she also explains how to overcome each of these challenges.

What do you think are the biggest challenges with getting requirements right and what suggestions do you have for overcoming them?

Here are the top two challenges I’ve seen with getting requirements right:

  • Inability to involve necessary decision makers and subject matter experts during requirements development (elicitation, analysis, specification and validation). When these key stakeholders are not involved, you may be forced to guess what the requirements should include. When you guess, you are acting in the place of the decision makers and subject matter experts; you become inappropriately empowered -- perhaps unintentionally -- to define the policies and practices of your organization.  Every time you guess, you not only put your project at risk, but also you may be putting your organization at risk.
  • Inability to organize the same requirements in multiple ways so as to meet the needs of technical as well as business audiences. Many organizations have a standard requirements template that they use as their authoritative source of requirements. Having a standard template seems like a good idea, but no single document can meet the needs of all the requirements stakeholders. For example, some organizations  create templates that contain lists of separate, discrete requirements that are organized solely by “type” (functional, nonfunctional, etc.) but lack any business or architectural context. Such templates are difficult for most audiences to read. Other organizations write long use cases that contain not only detailed descriptions of the functionality but also lists of the data elements, error messages, user interface design and even test cases. Although this approach might delight (and tire) some business readers, it dismays architects and developers, who must wade through numerous use cases to obtain a granular, component-based view of the requirements. Still other organizations classify their requirements by small, discrete software components, to the delight of the developers and architects. But the business reviewers, as well as the systems, integration and user acceptance testers, are not served by this kind of template because it gives them no context for these many disparate pieces. Without a context, these team members can’t do their jobs.

How can you overcome these challenges? Here are my suggestions:

  • Do not settle for guessing at what the requirements are. In a perfect world, you could demand that the project be stopped or put on hold until the decision makers and subject matter experts can be involved. Yet, in the real world, such an approach could be a “career-limiting” move. As part of project planning or portfolio management activities, pause and plan your approach to business analysis. For guidance on making the most of these kinds of activities, refer to Section 2 (Business Analysis Planning and Monitoring) of The Business Analysis Book of Knowledge (BABOK). 

As you plan your elicitation strategy, give subject matter experts and decision makers a range of estimates -- best case, worst case, most likely -- for the amount of their time you will need to effectively develop, manage and test their requirements. Clarify decision-making roles and rules. If a decision maker delegates requirements activities, ask the decision maker to explicitly and transparently delegate that decision-making authority. If key individuals cannot attend an entire requirements workshop, ask if they can (1) be on call to answer questions during the session and (2) participate in pre-work to assist those who will attend. 

  • Define and store your requirements in a way that enables you to organize requirements in different ways for diverse audiences. For example, you can bundle detailed requirements (such as business rules and data elements and attributes) by use case. Give these “use case bundles” to those who need to work with requirements at the use case level, such as business reviewers and testers. On the other hand, for people such as developers or architects, you can aggregate these same detailed requirements into high-level business groupings (business classes) or technical components.   

Whether aggregated by use case, business grouping or technical component, these bundles should be considered “reports” or “snapshots” of the requirements. The use cases and the detailed requirements -- rather than the bundles -- are the authoritative representation of the business needs.

When approved changes occur, the changes should be made to the applicable requirements. New versions of the requirements bundles can then be made available as needed.  

To keep track of the content of each bundle you create, use traceability. This practice will alert you to which bundles need to be changed as the requirements change. Keep in mind that when you bundle detailed functional requirements by use case, a single, discrete requirement may be associated with multiple use cases. However, when you bundle detailed functional requirements by technical component (or by business grouping), it is likely -- and often desirable -- that each detailed functional requirement will be associated with only one component (or one business grouping).  

Dig Deeper on Topics Archive