How far can you take requirements elicitation in a project? Clearly, no one knows the ultimate answer. It would be very costly (if even possible) to capture all requirements, assumptions, rules, relationships, and hidden connections associated with a solution being built, so how do we know when we are done?
In his article The Popcorn Way and the Business Analyst, Adrian Marchis offers an interesting method for determining when to stop eliciting requirements, based on the instructions for microwaving popcorn: as you elicit, analyze and document requirements, pay attention to the information that you are getting, and determine the time elapsed between discovering new requirements or significant changes to existing requirements. When this duration exceeds a given threshold, end the requirements gathering activities.
Business analysts often use a similar principle to confirm that the job is done: if, during the requirements discovery process, there comes a time when you continue to accumulate information but it doesn't translate into new or changed requirements, you know that you are probably finished.
“The Popcorn Way” was offered as a solution for situations when a business analyst is set out to elicit and document the detailed business requirements when the project has “a reasonably defined charter and clear business goals”. I believe that it has an even broader application, being valid throughout the project life cycle from the very beginning, when you are trying to define the scope and establish the business requirements for the project. However, it becomes most useful when applied to “smaller bags of popcorn”, rather than to the requirements process as a whole. Otherwise, it is possible to perceive an increased “distance between pops” without being done, if the discovery process is not encompassing all aspects that needs to be investigated during the requirements phase.
As we all know, requirements development is an iterative process, typically started from a high-level understanding of the capabilities required, which are broken down into smaller, identifiable features and requirements that can be modeled and optimized for implementation. By focusing on individual pieces of the puzzle, instead of the final, complete picture, it becomes much easier to determine the point when we are “done” with each piece. Examples of smaller contexts to which “listening to the distance between pops” can be applied include:
-
Scope definition. Description of which capabilities will and will not be included in the project scope.
-
Business rules. Rules concerning operational decision-making that must be taken into consideration by the solution.
-
Fact models. Models that represent the logical connections (“facts”) between core concepts of the solution and offer a blueprint for the subsequent development of data models.
-
Functional requirements. The solution capabilities – functions the solution will perform or allow users to perform with the software.
-
Nonfunctional requirements. The criteria to be used to judge the quality of the solution outside its specific behaviors (requirements on response time, capacity, reliability, usability, etc.).
-
External interfaces. The interfaces to other systems and external entities within the project scope.
I am not suggesting here that those pieces should be necessarily worked on sequentially: a business analyst may be working on developing use cases, or fact models, and in parallel, documenting the business rules that emerge from them. However, by applying the Popcorn Way to each individual goal you are currently working on, you will be able to develop much more confidence in drawing the line and considering the work done. The risks of stopping too early and missing critical requirements, or spending too much time on a given set of requirements (thus wasting valuable time), are highly reduced when you pay attention to the “requirements silence” (the point where more information is no longer helping identify or refine requirements) in each of your individual goals.
For instance, if your company uses standard documentation to communicate requirements, such as a Business Requirements Document in which you are expected to provide the scope of the project and describe the business use cases and business rules, the Popcorn Way can help you determine when you are finished with each of these sections of the document.
As you start the requirements process, you may become more and more confident that the problem statement is correctly defined as you notice that stakeholders of different categories and profiles all agree about what the problem is and what a successful solution would look like. A few days later, as you continue to add details to business requirements and negotiate trade-offs among them, you may determine that for a while there hasn't been any changes to the scope and what is included and excluded from it. You can then declare the scope section of the BRD completed, and start to focus in other sections that you hadn't started investigating yet.
The book Switch: How to Change Things When Change is Hard offers good evidence that shrinking the change may provide a good game plan for building self-efficacy. In the business analysis world, the concept translates into the idea that having a big, distant goal of completing all requirements by a given date makes it much harder than setting close-by, shrink-the-change goals of listing all use cases, completing the statement of scope, identifying all applicable business rules, and so on.
Knowing when the requirements for a project are complete is not always easy, but shrinking the size of your goals is a great way to reduce the struggle we all feel to determine when we are done with the requirements. By setting smaller goals, and applying the Popcorn Way to each of them separately, you will increase your clarity about how far you are from the finish line.
Author: Adriana Beal has a B. Sc. in electronic engineering and an MBA in strategic management of information systems. For the past 10 years, she has been identifying business needs and determining solutions for business problems for a diverse client base that includes IT, telecom, and major U.S. financial institutions. Adriana offers executive-level, management consulting on technology and process solutions and expertise in business-side IT operational functions and processes at Beal Projects.
Article image © iQoncept - Fotolia.com