An Algorithm For Requirements Analysis



The International Institute of Business Analysis (IIBA) BABOK 2.0 definition of Requirements Analysis is:

“Requirements Analysis (Chapter 6) describes how business analysts 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. It involves analyzing stakeholder needs to define solutions that meet those needs, assessing the current state of the business to identify and recommend improvements, and the verification and validation of the resulting requirements.”

This is the only reference to Business Analysis in the IIBA BABOK 2.0 which is basically a set of tasks that is meant to lead to the identification of the requirements. It is a valuable process. However, the bit of ‘analyzing stakeholder needs to define solutions that meet those needs’ is quite generic. What ‘analyzing’? and how to ‘analyze’? are left to interpretations.

Let’s take up a simpler route to exhibit Requirements Analysis in its purest form/ 

Going by the definition of ‘Requirement’ as stated by IIBA, ‘Requirement’ can be defined as –

  1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
  2. A condition or capability that must be met of possessed by a solution or solution component to satisfy a contract, standard, specification or other formally imposed documents.
  3. A documented representation of a condition or capability as in 1) or 2).

Extrapolating this definition, we can simply say that ‘Requirement Analysis’ is the process of identifying the “condition or capability”.

It is cited as one of the essential tools critical to the accomplishment of systems or software projects. On theoretical basis, requirements analysis encompasses following three types of activities –

  • Eliciting requirements – Elicitation can be defined as a process of gathering raw information that needs to be processed in order to identify a valid need. This process is not exact science and there are endless scenarios where this process takes place.
  • Analyzing the requirements – The process of transforming raw information into the final product, requirements and problem(s) statement. The next stage is determining whether the elicited requirements are pellucid, consummate, consistent and unambiguous, and resolving any ostensible conflicts.
  • Recording the requirements – this involves documenting the requirements in various forms like use cases, user stories, etc.

Despite of all the extensive literature available on Requirements Analysis, it is hard to find one which proposes an established framework on how to use this tool in general sense of application. However, let’s try to map a generic algorithm that can be leveraged for suitable circumstances since every problem or situation is different from the other. We need to calibrate our analytic skills such that a general algorithm can be applied suitably depending on the situation(s). Some of the situations can be -

  1. What is the problem?
  2. Why it is a problem?
  3. Why and what we are proposing is different? How it adds value?

Step -1: Identify the ‘As is’

This deals with identifying the current state of the business. How the processes in question operate? What functions we have? Who does what and how? Why it’s done that way?

It is a process of intelligence gathering – that of raw information – and subjecting it to a process that converts unrefined data into polished perspicacity for intelligence analysis. Gathering raw information may include activities like interviews, surveillance – both technical and physical, human source operation, searches and liaison relationships.

The critical factors, the underlying causes of the problem must be identified by observing the activity non-invasively, using convergence tools.

To arrive at the actual problem, it is always advisable that you go for multiple sources since one source may not just suffice in presenting all the facts. Some other reasons for using multiple sources are –

  1. Using a single biased source will produce biased facts thereby hampering correct analysis.
  2. Since different sources have different objectives, one needs to take into account each one of them for comprehensive understanding.
  3. To arrive at the truth, one must resolve all the conflicting facts from multiple sources.
  4. A near perfect version of truth can only be deduced after a proper synthesis of multiple versions.

Now we have gathered the information. But in order to define requirements in clearly understood context we need to analyze ‘pain points’ which help in ascertaining how far the “wave of pain” travels within the business.

Step -2: Identify the ‘Pain Points’

Organizations often get off on the erroneous foot when trying to identify business pain points. They start off with rigid postulations about what is going wrong, they conflate root causes and symptoms, and go on to prescribe ready-made solutions without first taking the time to understand how the business works and what the quandaries might be.

Business can self-diagnose themselves but it does not mean they know what their problem is? In addition to other pain points that stakeholders may not be aware off, they don’t see them or they underestimate them. A Business Analyst need to bring them to their attention.

State the pain points and seek your stakeholders’ feedback. Sometimes by just presenting unknown facts you can get people to think further; this way they become engaged and contribute to the process actively.

Step -3: Identify the underlying causes that give rise to ‘Pain Points’?

Final stage for discovering the unknowns, this can be aptly described as the analysis stage. Here, one is supposed to process all the inputs obtained from the previous stages such that a logical conclusion can be correctly obtained.

Synthesizing gathered intelligence is putting each piece of the puzzle together to build a valid and solid map of the problem.

Step -4: Propose

By now –

  1. We know about the pain.
  2. We also know what is causing this pain.

But, knowing how to address the causes of the pain in order to provide relief is called as requirement. This is to be obtained in this stage.

To put in simple words – ‘Propose’, as the final stage, is arriving at the answer to the basic question for which we performed ‘requirements analysis’ in the first place – what does a business needs to do in order to solve the problem? Here we propose the needs based on the results of the analysis stage i.e. step-3 which would by now must have answered all the questions of the nature – what is the problem? Facts? Causes? Etc.

Step -5: Validation

In true sense, validation is an iterative process which must takes place throughout the lifecycle of the project. During elicitation, analysis and specification one should perpetually be querying and elucidating the data given in order to check its validity.

During the formal requirements validation process one is aiming to ascertain that the requirements are complete, veridical, feasible, indispensable, prioritized, unequivocal and verifiable. This may seem a humongous task but it is essential to pin point up any gaps or errors at this stage in order to minimize the defects later.

The BABOK Requirements Validation is defined as follows:

“Ensure that all requirements support the delivery of value to the business, fulfil its goals and objectives, and meet a stakeholder need.”

This is a quality assurance of the requirement, a check that it is reliable and it guarantees the right outcome of the defined needs.


To sum up, Requirements Analysis is more of an intuitive process whose efficiency and veracity of concluding results depends on how a Business Analyst does the job. As stated earlier it cannot be purely based on techniques of elicitation only; rather a Business Analyst needs to come up with analogy of her/his own cognitive skills which she/he develops through the process. Remember that every problem is different and so should be its solution. This Requirements Analysis algorithm can be tweaked accordingly.


Author: Adam Alami, Sr. Business Analyst


Adam Alami is a seasoned IT consultant with over 18 years’ experience. Business Analysis is his passion. His experience revolves around major business transformation projects. He is a versatile IT professional. He accumulated a wealth of cross industry experience with Tier 1 businesses in major projects in the areas of Enterprise Transformation, Integration, Migration, and Systems Modernization.

Email: [email protected]


Like this article:
  17 members liked this article


smzachary posted on Monday, November 16, 2015 1:34 PM
This is a good introductory article for BAs getting lost in the war between tools, lifecycles, and organizational preferences.

I would say, I'd refer to this more as a high-level overview or map of some of the BA functions and not an algorithm. Algorithm implies more of a detailed description of the item in mention. If I was to plug this articles "algorithm" into an "engine" to "run" the processes defined within, it would certainly not prove ineffective.

Although, when I clicked this I was thrilled for a quantitative approach to modeling. That is surely something that could use more attention in the field.
adamalami posted on Monday, November 16, 2015 7:42 PM
'let’s try to map a generic algorithm that can be leveraged for suitable circumstances since every problem or situation is different from the other.' The key word is generic. It's a generic algorithm. In other words, high level, overview... It doesn't clam to be detailed or can be used in every situation, 'Requirements Analysis is more of an intuitive process'

'Algorithm implies more of a detailed description.' Not necessarily. An Algorithm can be very brief or very detailed.
JamesRutherford posted on Tuesday, November 24, 2015 4:33 AM
The algorithm is good itself and helps to make the process of analysis easier and faster. Thanks to the author for creating the one.
adamalami posted on Tuesday, November 24, 2015 3:17 PM
Thanks James. Appreciate the feedback
RobinGoldsmith posted on Thursday, December 31, 2015 11:58 AM
Putting aside that this doesn’t seem like an algorithm to me either, there’s a far more critical issue with this approach. That is, it leaves out the most important part of analysis that BABOK (which reflects and institutionalizes conventional but in this instance misguided wisdom) also continues to miss, as evidenced in the cited BABOK quote.

It’s easiest to understand what’s missing and why conventional business analysis continues to create creep by looking at the Problem Pyramid™ described in my book, related seminars, and my Modern Analyst featured article, “BAs Will Falter Until They Learn to Discover REAL, Business Requirements” at

The proposed approach skips Box 5 REAL business requirements deliverable _whats_ that provide value when satisfied by some product/system/software _how_ and instead goes directly to said product/system/software _how_ Box 6. Inadequately defined Box 5 REAL business requirements is a major reason presumed Box 6 products turn out not to be right and appear to creep. BABOK focuses analysis only on the Box 6 product expected to be created instead of on the far more important understanding of the Box 1 REAL problem, Boxes 2 and 3 measures and value, Box 4 causes, and Box 5 REAL business requirements deliverable _whats_ that achieve the Box 3 goal measures and thereby achieve the value when satisfied by a Box 6 product _how_.
Only registered users may post comments.

Latest Articles

The Business Value of Better Requirements
Jan 18, 2021
 Not every manager is convinced that his team needs to do a better job on requirements development and management or that such an investment will...

Copyright 2006-2021 by Modern Analyst Media LLC