How to Tell When the Requirements Are Done


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?

How to Tell When the Requirements Are DoneIn 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 -

Like this article:
  11 members liked this article


Tony Markos posted on Tuesday, December 21, 2010 1:23 PM
Isn't it so interesting that many long, complex books on requirements analysis exist; but, when it comes to something as fundamental and important as the question: How does a BA know when he/she is done with discovery?, the "Popcorn Way" is about as sophisticated a method as currently available?

Problem: The complete lack of any of the currently popular requirements modeling techniques, especially use cases and user stories, to provide any litmus test of completedness. A old time DFDr can only sit back and chuckle.

Adriana Beal posted on Monday, December 27, 2010 3:08 PM

I' m not sure If I got the point you were trying to make, but I'm unaware of any of the "currently popular requirements modeling techniques" (including use cases and user stories) having an effective test that can be used to indicate whether the requirements work is "done".

I have been working on complex software projects for more than 10 years, and the only thing that I've seen working well to make sure you don't overlook important requirements that becomes much more expensive to "retrofit" into the solution is to divide the work in smaller pieces (incremental) and develop the requirements through repeated cycles of definition (iterative).

Thanks for leaving your comment, and feel free to expand your ideas if you were disagreeing with the opinions I expressed in the article -- I'm sure others will learn from the exchange.


Tony Markos posted on Tuesday, December 28, 2010 1:23 PM

You state: " I'm unaware of any of the "currently popular requirements modeling techniques" (including use cases and user stories) having an effective test that can be used to indicate whether the requirements work is "done".

My response: This agrees with my first comment to your article.

You further state that you: "...have been working on complex software projects for more than 10 years, and the only thing that I've seen working well to make sure you don't overlook important requirements that becomes much more expensive to "retrofit" into the solution is to divide the work in smaller pieces (incremental) and develop the requirements through repeated cycles of definition (iterative).

My comment: I agree with you here Also. And I add that a big problem with currently popular techniques is that they are very poor at logically partitioning complex systems into smaller pieces.

Adriana, the above two short comings (along with others) are but symptoms of the REAL problem: Almost all the "experts" (authors, college professors, etc.) espousing methods that, while they work for smallish efforts, do not work for larger scale requirements analysis efforts.


Adriana Beal posted on Tuesday, December 28, 2010 2:34 PM

Thank you so much for taking the time to clarify what you meant -- written communication sometimes makes it harder to interpret that is said.

Yes, I agree that partitioning complex systems into smaller pieces in a way that makes sense to humans, without losing the view of the whole, is a challenge in existing software development techniques.

I don't think I can agree, though, that the existing techniques we are talking about don't work for large scale requirements analysis efforts, or don' t allow for logically partitioning. In my opinion, "hybrid" methods that selective apply the available techniques and use an incremental/iterative model work very well in practice (I have participated on several successful complex projects in the past few years that could be used to corroborate this conclusion).

I definitely agree that the existing models are far from perfect, and believe that we will see more refined frameworks focused on high-complexity projects in the near future. I am not convinced, though, that the "popcorn way" will ever cease to be a good reference for determining when a "portion of requirements" can be considered "done", even when better methods exist to tackle lafter scale requirements efforts.
Adriana Beal posted on Tuesday, December 28, 2010 2:36 PM
(Sorry for the typo -- in the last line I meant "tackle larger scale requirements efforts".)
zarfman posted on Tuesday, January 11, 2011 8:16 PM


Its been sometime since I've used statistics. However, if I remember correctly the Poisson distribution has been has been applied to problems of this nature. A grad student in statistics could probably help you.

Perhaps the bathtub curve is applicable to this problem.

I'm uncertain about the concept of partitioning complex systems. If relationship between the partitioned pieces is clearly understood then perhaps all is well. Absent that understanding I suspect problems will arise in the future.

Perhaps someone who is really clever could determine how to apply control systems theory to business problems. That leaves me out.


Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC