Business Analyst Articles: Business Analysis & Systems Analysis



BA ARTICLE ARCHIVE
» April 2014 (3)
» March 2014 (7)
» February 2014 (6)
» January 2014 (6)
» December 2013 (7)
» November 2013 (4)
» October 2013 (5)
» September 2013 (6)
» August 2013 (8)
» July 2013 (8)
» June 2013 (7)
» May 2013 (8)
» April 2013 (8)
» March 2013 (4)
» February 2013 (6)
» January 2013 (6)
» December 2012 (5)
» November 2012 (7)
» October 2012 (6)
» September 2012 (6)
» August 2012 (5)
» July 2012 (9)
» June 2012 (5)
» May 2012 (9)
» April 2012 (7)
» March 2012 (7)
» February 2012 (5)
» January 2012 (7)
» December 2011 (6)
» November 2011 (6)
» October 2011 (8)
» September 2011 (6)
» August 2011 (8)
» July 2011 (7)
» June 2011 (7)
» May 2011 (5)
» April 2011 (8)
» March 2011 (6)
» February 2011 (5)
» January 2011 (6)
» December 2010 (5)
» November 2010 (9)
» October 2010 (5)
» September 2010 (6)
» August 2010 (8)
» July 2010 (6)
» June 2010 (6)
» May 2010 (10)
» April 2010 (5)
» March 2010 (8)
» February 2010 (7)
» January 2010 (7)
» December 2009 (7)
» November 2009 (7)
» October 2009 (6)
» September 2009 (8)
» August 2009 (10)
» July 2009 (9)
» June 2009 (5)
» May 2009 (10)
» April 2009 (5)
» March 2009 (12)
» February 2009 (8)
» January 2009 (6)
» December 2008 (9)
» November 2008 (8)
» October 2008 (9)
» September 2008 (4)
» August 2008 (6)
» July 2008 (8)
» June 2008 (17)
» May 2008 (12)
» April 2008 (7)
» March 2008 (21)
» February 2008 (16)
» January 2008 (13)
» December 2007 (9)
» November 2007 (25)
» October 2007 (2)
» September 2007 (23)
» August 2007 (12)
» July 2007 (11)
» June 2007 (7)
» May 2007 (6)
» April 2007 (9)
» March 2007 (5)
» February 2007 (3)
» January 2007 (2)
Articles and White Papers
Monday, December 20, 2010
12060 Views 6 Comments 7 members voted Article Rating

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 - Fotolia.com

Rate this:

COMMENTS

Posted on Tuesday, December 21, 2010 1:23 PM by
ajmarkos
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.

Tony
ajmarkos
Posted on Monday, December 27, 2010 3:08 PM by
adrianab
Tony,

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.

Cheers,

Adriana
adrianab
Posted on Tuesday, December 28, 2010 1:23 PM by
ajmarkos
Adriana:

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.

Tony

ajmarkos
Posted on Tuesday, December 28, 2010 2:34 PM by
adrianab
Tony,

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.
adrianab
Posted on Tuesday, December 28, 2010 2:36 PM by
adrianab
(Sorry for the typo -- in the last line I meant "tackle larger scale requirements efforts".)
adrianab
Posted on Tuesday, January 11, 2011 8:16 PM by
zarfman

Hi:

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.

Regards,

Zarfman
zarfman
Only registered users may post comments.

Do you twitter?: If you want short updates on what's going on in the BA world and at ModernAnalyst.com, simply follow us on Twitter: http://twitter.com/ModernAnalyst



Featured Digital Library Resources 

Big Data Analytics for Dummies
Finally, a Big Data book written for business analysts, BI professionals, and data scientists!  Big Data Analytics for Dummies is a valuable resource that addresses the practical dilemmas surrounding Big Data...

A Buyer’s Guide to Customer Analytics
Discover the five crucial criteria of a customer analytics platform in A Buyer’s Guide to Customer Analytics now.

Free Analytics software: Alteryx Project Edition
Alteryx Project Edition provides you with a single solution that delivers the data blending, analytics, and sharing capabilities of Alteryx with just enough allowed runs of your workflow to solve one business problem or to complete one project.

The Business Analyst's Guide to Hadoop
Get started with Hadoop using this whitepaper, "The Business Analyst's Guide to Hadoop".

Copyright 2006-2013 by Modern Analyst Media LLC