Category Archives: BA Techniques

Requirements Prioritization

Requirements once elicited and approved from the authentic sources are further put for analysis and the first step in the process of requirement analysis is to prioritize the requirements in the order of their implementation. It is mandate for business analysts to prioritize the requirements as it’s a process to add value to the deliverables. The business analyst (or the one seated on the business analyst’s chair) has to consider certain factors while prioritizing the requirements so that the smooth process can be implemented. These factors or aspects which are considered at the time of prioritizing the requirements are: importance, risk, cost, benefit, time, strategy etc. The software development is a set process and the requirements are said to be changing till the final version is deployed in the production environment for the end-users and thus its a challenge for a business analyst to keep track of the requirements and alter the priority with the progress in the development but the decision on prioritizing the requirements depends on the decisions made by the stakeholders involve in the project and business analysts being a liaison between different stakeholders have to co-ordinate the activity.

Why to prioritize the requirements?

Eliciting the requirements and fit them into the releases to develop the functionality is a major step towards the success of the development of the software/project and it’s very important to understand the risk of not prioritizing the requirements. In the words of Frederick P. Brooks, “The highest single part of building a software system is deciding precisely what to build… No other part of the work cripples the resulting system if done wrong. No other part is more difficult to rectify later” Thus to mitigate the risk of re-work in the later part of the development, it’s advisable to define the requirements and prioritize them before starting the implementation. In simple words, “No matter prioritization technique is considered simple, medium or difficult it’s a fundamental activity for successful implementation.”

Continue reading

Requirement Management

Requirements Management

Requirement ManagementThe gap between “what we know” and “what we think we know” is filled by the knowledge and the experience. What we know is about the facts and what we think we know succinct the assumptions. This is marked as the baseline for the business analysts (or the one seated on the chair of BA) during the requirements management and thus the BAs have to strive always to maintain the credibility of the requirements throughout the project life-cycle. The most appropriate way to mitigate the chances of bogus requirements getting developed or documented is to frame questions and avoid muddiness. The BAs are advised to focus on the different aspects of the requirements and then frame questions to nullify the chances of any ambiguity during the requirement elicitation and documentation.

What is Requirement?

Referring to the world of dictionary, the requirement is described as, “Something which is necessary and must be fulfilled to achieve the result”. Requirement word itself is self-explanatory and sometimes begets a cringing feeling (especially with the phrase “change in requirement”). But this should not happen with the BAs as they have the primary tasks to manage and maintain the requirements’ credibility throughout the life-cycle of the project.

Continue reading

communication techniques

Requirement Communication

Requirements are the spine to any project. The more precisely requirements are gathered and analyzed; the more effective becomes the implementation. Thus it is important for a Business analyst to understand all the details of the requirements shared by business owners and subject matter experts and more importantly communicate the same to different stakeholders on time to avoid any delays in the implementation. Communication is one of the pillars of the project and it helps in explaining the tasks and responsibilities to different stakeholders. Business analyst being a bridge between different stakeholders is responsible for managing the requirements throughout the project life cycle. Proper and on-time communication of the requirements helps the stakeholders to reach the common understanding and which results in on-time and hassle-free implementation.

Requirements once elicited, analyzed and documented should be communicated to different stakeholders to maintain the authenticity of the same. Business analyst manages the requirements throughout the project life-cycle, thus it becomes his core responsibility that everyone involved in the project implementation should know the details of the requirements. The documents prepared with the requirements (functional and non-functional) details should be validated from the business sponsors. Solution design and assessment is done on the basis of the requirements elicited and thus it’s very critical that the designers and architects should know about the requirements and variations as the design is completely influenced by the nature of the requirements. There are certain methods followed by different business analysts to communicate the requirements including presentation and workshops but the end result is to convey the meaning and the stakeholders should be able to understand all the details.

Continue reading

solutions-featured image

Solution Assessment and Validation

This is one of the knowledge areas for the business analysts as described in BABOK. This knowledge area deals with the solutions provided against the requirements. The solution should add a value and it is the duty of a business analyst to select, review and finalize the solution for the set of requirement. In this area the business analyst plays a very vital role as sometimes it’s his call to select the most appropriate from the list of the solutions. The solution selected by the business analyst should ensure that it meets the agreements between the stakeholders, enhance the business values and also do not contradict the organizational structures. So this knowledge area sometimes becomes more critical as the accepted solutions should meet the requirements of the business and the stakeholders should be able to understand the same. A business analyst should be able to explain the details of the most appropriate solution to all the stakeholders, so there may be some scenarios that he has to explain it to the people with minimum technical expertise.

Difference between Verification and Validation

Before moving further to learn more on solution assessment, let’s check out the difference between Verification and validation. On the first instance they both look almost similar, but there is a slight difference in the understanding.

Verification: To ensure that the selected work meets the specified requirements and the work is being done rightly on the product

Validation: To ensure that the selected work is on the track and it is being done on right product.

John E. Parker in his presentation defines the both as below:

Verification: Are we building the product right?

Validation: Are we building the right product?

Continue reading


UML Reloaded

UML, an acronym to Unified Modelling Language, is defined as the graphical notations of the real system which allows both design and viability of a system. The requirements elicited from business owners are sometime too complex to explain to the stakeholders and thus to summarize those requirements and abstract the essential details UML is widely used. It helps in visualizing the problem and in turn the solutions with better approach and reduction of cost and rework. In short UML is a mean to visualize, specify, construct and document software systems.

Graphical modeling languages have been around in the software industry for a long time. Some articles show that this technique is being used for more than 15 years now. The UML is a relatively open standard, controlled by the Object Management Group (OMG), an open consortium of companies. The OMG was formed to build standards that supported interoperability, specifically the interoperability of object-oriented systems. The OMG is perhaps best known for the CORBA (Common Object Request Broker Architecture) standards. UML is so wide and vast that nobody, not even the creators of the UML, understands or uses all of it. We all use a small subset of the UML.

The UML is a relatively open standard, controlled by the Object Management Group (OMG), an open consortium of companies. The OMG was formed to build standards that supported interoperability, specifically the interoperability of object-oriented systems. The OMG is perhaps best known for the CORBA (Common Object Request Broker Architecture) standards.

Continue reading

Business Planning and Monitoring

Business Planning and Monitoring is classified as one of the knowledge areas of Business analysts by IIBA in BABOK. Under this knowledge area the business analysts are assumed to perform certain planning activities which should be valid throughout the project life-cycle. The parameters which are defined and set during the planning phase should retain their validity throughout the project phases and it becomes the responsibility of the business analyst to perform the activities classified under this knowledge area precisely.

The activities which are marked under this knowledge area can be broadly classified as below:

  • stakeholder-managementIdentify the stakeholders: Stakeholder is defined as person or group that has stake and interest in the success of the project. Stakeholders are considered as the important aspect of the business and project life-cycle. The inputs from the stakeholders throughout the life-cycle are recommended. This is the task of the business analysts to identify the stakeholders and each one of them should be coordinated effectively as the project proceeds. These stakeholders review the requirements which was elicited, analysed and documented by the business analysts. The business analysts create a list of all the stakeholders associated in the project referring the available information on the type of the project and the skills required in the completion of the project.

Continue reading

Gap Analysis

Business Analyst Techniques #4 GAP Analysis

Gap analysis is the technique used to define the difference between the current state and the proposed state of any business and its functionalities. This technique comes under Enterprise Analysis, knowledge area of business analysts. The technique revolves around two basic questions:

1. Where are we?

2. Where do we want to be?

Gap AnalysisUnder the first question, the present situation of the business is explained. It consists of the current factors like business attributes, competencies of the people involved in the business, performance factors etc. And the second question explains the future of these current factors. The delta between these two is known as gap and the technique which is used to fill this gap is known as Gap Analysis. It can also be defined as the process to identify the delta between the proposed and existing functionalities in any application. A gap analysis helps bridging that delta by highlighting which requirements are being met and which are not.

There is no formal method to conduct gap analysis and it can be performed in different perspectives like organization structure (HR processes), business processes, information technology etc. Gap analysis provides a foundation for measuring investment of time, money and human resources required to achieve a particular outcome.

In IT industry, Business Analysts or Project Managers have been given this task of performing gap analysis to identify the variation in the future processes or techniques and comparing it with the current ones. As I mentioned above there is no formal way to conduct this analysis, thus an excel-sheet can be used to draw tables with the details of the current and future processes and the delta found, if any. The same template can be embellished in different ways and many organizations have their set template for this process. The important points to be noted before performing any Gap-analysis can be listed as below:

Continue reading

Root Cause Analysis

Business Analyst Techniques #3 Root Cause Analysis

RCADo you believe in getting into the roots of any problem or just happy with the work-around? Indeed root-cause analysis plays very important role in getting the exact reason of the problem. Before getting into roots, let’s understand the meaning of problem. An event which hinders the smooth flow of the process can be termed as an issue and recurrence of same issue is termed as Problem. Root cause analysis (RCA) is done to focus on the identifying and correcting the events which results into problem so that the same can be prevented in future.

RCA should be performed as soon as the defect or variance is detected to avoid major problems in future. Also if the process is delayed, there may be a possibility of information get missed. RCA is not the only responsibility of a business analysts but I believe all the stakeholders should be involved to understand the issue and its criticality. Involving stakeholders also help in getting away from the fictionalization or dilution of the facts. Thus it becomes the responsibility of the analysts to explain the purpose of the RCA to all the stakeholders so that they don’t feel hostile or defensive. We also should keep in mind that one corrective action is not valid for all types of the issues and this is also confirmed by the Root Cause Failure Analysis (RCFA).

There are certain techniques followed by different business analysts and organizations for root cause analysis.

Continue reading

BRD: Really a Need or Time-Crusher?

BRD: Really a Need or time-crusher?

BRD-timecrush1BRD-timecrush2As a BA the one thing which strikes in our mind is to design a high a quality BRD (Business Requirement Document). In my last post I have written an overview of BRD which includes the features of a good quality BRD. Few days back I was attending a webinar on the same topic in which the presenter was discussing all the details. It was really interesting to know that BAs devote most of their times in designing an easy to understand document which contains business requirements. A BA first discusses the details with different stakeholders do the brain storming and then designs a document using all his writing skills to make it as simple as possible so that the others can understand the requirement and the project can run smoothly…. Oh God how much intelligence required in that!

But this all gave me a thought that after designing a document of 100+ pages with all the efforts to include the business requirements will the document find the intended audience? Will that document find space in the INBOX, which is usually flooded with other mails (in a survey it was found that the business decision makers usually get 85+ mails per day), of the stakeholders and will all of them spare their time in reading those 100+ pages? I think NO. So if the answer to this is no, then why BAs are devoting their time in designing BRDs. Documenting a requirement sheet will require tremendous efforts in organizing, double-checking, typing, copying, pasting etc which will turn out as 85% of clerical job and in turn it will reduce the strategic competence of a BA. Thus it can be accepted that a BA who is sparing 85% of his energy in doing clerical job can’t make impact on the organization with his strategic skills. Continue reading

Business Requirements Document: An Overview

Business Requirements Document (BRD)

BRD-documentBRD, an acronym of Business Requirements Document is widely accepted structured document for project requirements which defines what should be delivered in order to gain value in the project. This document is designed to assist with the project management and the implementation during the entire life cycle of the project. Business requirements are consist of both functional and non-functional requirements which lead to creation or update of product, system or a software. BRD mainly emphasize on what should be the end result and it doesn’t bother how the objective is achieved.

There are many variants of BRD known to people like SRS (System Requirement Specification) or SRD (System Requirement Document) and FSD (Functional Specification Document). BRD can be described as a mode of communication in completion of a project. The main objectives of a BRD are as below:


  1. It should be simple and all the involved stakeholders should agree to it.
  2. It should contain more business requirements rather than technical requirements, as the main motto of a BRD is what to achieve and not how to achieve.
  3. It should describe the business needs in clear and concise manner.
  4. It should have a logical flow and can be used as an input for next phase of the project.

Continue reading