An Algorithm For Requirements Analysis

Introduction

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.

Conclusion

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]

Website: www.adamalami.com