Tag Archives: BA techniques

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

UML

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