Tag Archives: Business Analysis

How to be a domain expert

Domain experience and business analysis go hand in hand. With every year added in the career, the employers start expecting the business analysts to be more specific and knowledgeable in the working areas. The business analysts are expected not to be an expert only in the processes but also have good exposure to the core domains so that the communication can be done using the functional terminologies related to specific domains. While discussing with different delivery managers and business unit heads I have noted that most of the individuals are following the strict guidelines for recruiting the business analysts. On one hand if business analysts are expected to be hands-on with different techniques, tools and business processes they are also supposed to have a good understanding of the working domains.

Today is the era when employers want to recruit the most efficient resources  working in their teams and the resources available for multiple tasks are always welcome. This is also true with the recruitment process of business analysts. Most of the times the business analysts are filtered out on the basis of domain expertise. The profile of business analysts is most misunderstood as it is spanned across the full project life cycle at different levels for different roles. They are expected to be the part of the core team throughout the project and thus  they have to be working with different teams. BTW business analysts are experts in working with different teams and the profile meant the same. Isn’t it?

In my recent book on business analysis I have emphasized more on the business processes and the knowledge areas. This is because the domain expertise comes with the continuous working in a specific domain and the terminologies can be learned in the course of time. While the business processes, tools and techniques hold the important role in the profile of business analysts. The business analysts are expected to work in the process oriented environment and they should be more focused on the techniques followed during the entire life cycle. Having domain experience is the added advantage and the people with testing or development background gain the same more easily and comfortably if they held the roles under certain functional umbrellas.

Nevertheless, learning is a continuous process and the domain knowledge can also be learned and developed. I have developed a technique of acquiring knowledge in any domain and I call it as an “AGILE” learning process. This process assists the business analysts to learn different domains and gain knowledge in any of the desirable domains.

A  – Ask Questions: Since our childhood we have been asked to ask. No matter  how silly the query is, but the same is valuable till it is answered.  So build the habit of asking questions. The questions related to the processes, product, techniques etc. always help in gaining knowledge in another domain. The domain understanding and the details related to terminologies come with the experience but in due course the individuals can frame questions to understand the processes. It’s always recommended to pen down the notes once you get answers to your questions as it will become a treasure till you are involved in that project. Asking questions remove the hurdles in the growing path and help the individuals in setting up their career path.

G – Get involved: Showing interest helps the individuals in getting marked and in turn the senior managers can refer them to the important meetings. Show curiosity in getting involved in the routine activities related to the project. Invite yourself to the meetings and show enthusiasm and be inquisitive while attending the meetings. Get involved in the important discussions and be active to be the part of the core team. Taking over the responsibilities and devoting energy to reach the targets helps the individuals in growing in any arena.

I – Increase Networking: Networking is always the best way to explore more options. The individuals looking for options in other domains are advised to increase their professional networking. Talking with  experts and seeking the opinions of the people working in your desirable domains is a smart way of gaining knowledge. Networking most of the times also help in landing to the desirable job position and hence it’s a good option to keep yourself updated on the professional networking sites and be in touch with the experts.

L – Look Around:  “Opportunity Knocks the door, but once”. You should always keep your senses working to look around for the available options and grab the most favorable option. While switching to any other domain, you need to think of the most common link between your current role and the future offering and then design the proposal to sell your profile for the available options. Think about the available options, be open to learn new techniques and work in odd conditions. It’s good to work on your terms but showing adaptability increase your chances of getting introduced to other areas.

E – Educate yourself: Gaining knowledge in desired domains is a stepping stone of getting into the dream role. There are potential trainings, workshops and certifications available in the market where the individuals can learn and improve their credentials. It is said that some portion of your income should be devoted in learning processes. It’s a self-investment which results in unexpected profits in the future.

So above we have learned a technique to grow in the desired field of knowledge and mark the footsteps into the space of new knowledge domains.


Happy Learning!!


Understanding Nonfunctional requirements

Requirements are defined as the conditions or statements which meet the demands of the clientele and the stakeholders. Requirements are documented in order to help the different teams to understand their responsibilities and organizations’ needs and the prospects. The business requirements are broadly classified as functional requirements and non-functional requirements.

Functional Requirements: The statements or conditions which are defined to satisfy the logical aspects of the software are covered under the functional requirements. These statements explain the different aspects of the application/software to be developed. These functional requirements are elicited during the requirement elicitation process headed by business analysts. The elicitation process is carried out in order to pull out the different angles associated with the requirements and to understand the viewpoint of different stakeholders. The most commonly used elicitation techniques are Interview, Brainstorming, Prototyping, reverse engineering, document-analysis and many others which are used as per the requirement and the comfort level of the business analyst or someone wearing the hat of the business analyst.

Nonfunctional Requirements: The statements or conditions which support the usage of the application or the software and which help in aligning the functional requirements are considered under the non-functional requirements. The non-functional requirements are defined to explain the different abilities  of the software developed. The non-functional requirements are also termed as non-behavioral requirements or quality attributes defined in order to support the quality analysts to approve the software against the different constraints which must be met. They define the overall attributes of the end product.

There is no definition to identify the difference between functional and non-functional requirements and there is a very thin line of difference between two categories. It entirely depends on the experience of the business analyst, details captured during the elicitation process and the constraints or limitations defined for the resulting product to categorize a certain set of requirements into functional or non-functional requirements. This thin line of differentiation between two categories sometimes doesn’t able to limit the functionalities to get categorized into two categories and there are certain conditions where a feature is captured in both functional and non-functional requirements using different expressions or syntax.

The different abilities or the checklist supporting the non-functional requirements are mentioned as below:

  • Availability: It defines the percentage availability of the system which is expected at the time of the system operations. The hardware capacity of the system is designed referring to this availability percentage of the software or application. The details are approved by the business owners and documented by the business analysts during the business requirement documentation.
  • Usability and Reusability: This defines the convenience by which the system can be used by the intended users. This ability of the system explains the capacity of the software to be learned, installed and used by the business users. How easily the users can be trained on the system defines the usability of the software. Some softwares are designed to be used for the development other systems which have common components. This capability is known as reusability of the software. A software is considered as well designed and developed if it can be used for other softwares with some common features.
  • Reliability: A software is authentic if the user can rely on the features of the software and its usage for longer duration. This feature of the software helps the organizations in choosing the product for their sensitive data. The demand of the product is directly proportional to the reliability of the software. The product or software is reliable if it’s also stable. The business owners prefer the stable product in order to get the higher availability of the same for the users.
  • Flexibility: There should be always a scope of the extension of the functionality within the developed product. This feature is known as flexibility. The software is designed in such a way that it should provide a room for expansion even after the deployment of the end product. The flexibility of the product depends on the design and techniques used for the development of the product and thus a business analyst has to take care of certain steps while finalizing the software design and development techniques.
  • Supportability: This feature of the software or the product is massively used during the maintenance phase. The ability to deploy new releases, alter the code, customization as per the users’ locations are covered under this feature. The customization of the product should not hamper the international usage and it should target the local users only.
  • Performance: How well the software performs at different timings for different number of users is defined under this capacity of the software. There is a common agreement on the performance of the software which is signed off at the time of BRD sign-off and it helps in designing the software and hardware structure of the product accordingly.

There are no proper methods present or followed by different business analysts in order to derive the non-functional requirements. This is because the abstraction level of the non-functional requirements are not similar to the functional requirements and for different softwares or products the set of non-functional requirements changes. Some nonfunctional requirements are difficult to define or express due to certain constraints which are evolved during the design and development and thus they are not included during the documentation process. As there are no guidelines or rules comparing with, the non-functional requirements are sometimes secluded or undermined which may result in the catastrophe during extensive usage of the software.

Different stakeholders have their own understanding and in turn requirements. This is also true in the case of the non-functional requirements. The stakeholders’ requirements thus should be catered separately and their needs should not be treated as a landmark while testing the non-functional requirements.

Nonfunctional requirements thus are treated as an important aspect while designing the software and these requirements should be analyzed, precisely measured and developed accordingly for the successful implementation of the software and usage of the end product.


Happy Reading!!!

BA - choice

Business Analysis – By Choice

BA - career choiceDo you aspire to be a business analyst?

Do you think you have taken enough steps but still not got right opportunity?

Have you prepared yourself to grow in the field of business analysis?

Have you thought of other opportunities which better fit your goals?

These are some of those important questions which should be answered before a career plan for a business analyst is followed. Believe me there are certain scenarios where after working for many years people don’t find relevant profiles and this is only because the right approach of growing was not followed. Once you have decided becoming a business analyst, you need to do some introspection to prove your skills to nobody else but to yourself.

With the growth of technologies and techniques, every sector is now growing and the intellect of the people working in these sectors is increasing. With the involvement and growth of outsourcing industry the platter is always full with different ideas and a volunteer is needed to segregate the most correct ones (as no idea is right or wrong till the brainstorming is done on the same). This need of having someone skilled professional is catered by business analysts. Business analysts act as a liaison between different stakeholders and maintain the spirit of collaboration by managing the ideas and requirements. They need to take care of every idea pitched during different sessions of elicitation and document the most correct ones in understandable format. Business analysis is not inbuilt ability and certainly it can be taught and learned. There are different knowledge areas for business analysis which can be learned with course of time but I firmly believe that self-evaluation is needed before stepping into the career of a business analyst. Recognize your skills and groom them to grow in the field of business analysis instead of dying like an elephant whose hind leg is tied with a chain since he was an infant and he could not recognize his strength. Think like that golden eagle which despite of grown with the chickens recognized its strength and have flown in the sky.

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


Seven threats to Business analyst

Business Analysis is now very familiar in IT industry and different organizations have now started creating a separate position for an individual who can act as a bridge among different stakeholders. Before the introduction of this position, the project managers or team leaders were asked to act as a single point of contact for different stakeholders to solve the queries and to maintain the pace of the project. But with the advancement of the techniques, it started becoming difficult for them to manage multiple tasks and thus the productivity was hampered. Then business analysts came into existence who not only have fair understanding of the requirements but also understand the methods to maintain the pace of the project and now IT industry is relied on the business analysts to fulfill the increasing demands and BAs are now the part of the core team.

With the inclusion of business analysts in the core work force, many organizations believe that the implementation rate is much higher than before and this not only matters with the quantity but also with the quality of the work delivered. Business analysts being the liaison among different stakeholders remain in touch with all stakeholders and in case of any variance in the requirements mark them and escalate it with the dependent parties. That is they always intend to manage the requirements throughout the project life cycle or SDLC.

Continue reading


Seven sutras for Business Analysis

Sutra:  Sutra is a Sanskrit literature which means rule or short instructions prepared for memorization. It is well accepted word around the globe and world of dictionary explains it as “A rule or aphorism in Sanskrit literature or a group of aphoristic doctrinal summaries prepared for memorization”

With the advancement of the technologies and the development of different domains, a job title which developed exponentially and the most prevalent is business analyst. Business analysts are the people who can be the spine of any organization and has the potential to think of the profits during the losses. Business analysts (BA) are like the warriors for any organization who have to keep away the worries throughout the project life-cycle. A business analyst is a renowned and process oriented individual who has to live with certain conditions which sometimes are unacceptable to him but as he is considered as a most important aspect of any project he has to work selflessly with an inspired heart and steady mind to give his best during the odd times. He is the person who has to use his intellect without being egoist and thus he has to show an altruistic commitment to the work and behave like a sage to achieve the best results out of the work.

An individual either develops or possesses habits of a business analyst but there are certain sutras which I think should be followed while performing the routine activities, some of them are listed below:

  • Educate yourself: Education always plays a very vital role in the personal and professional development. It is the most important aspect and it doesn’t matter what the source of learning is. The same formula is applied to business analysts as well. A business analyst should always be in learning mode and it helps him in increasing the intellect and referring the live examples of senior business analysts act as a catalyst in the growth of junior analysts.  There are certain techniques and skills which should be groomed regularly in business analysts. The set of knowledge areas as defined by BABOK is also a necessary field to be learned by business analysts.

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

Knowledge Areas of BA

Business Analysis is all about tasks and techniques followed to qualify the business needs and finding the business solution. The solution may include the system development, process development or improvement and change in the organizational structure. It is about the process to complete the tasks with quality and those who follow these processes are known as business analysts. In some organizations, these business analysts are referred as system analysts, SME (subject matter experts), business process analysts, business system analysts and many more.

The tasks followed by business analyst require specific knowledge areas and a business analyst should focus on them while performing the activities. Many writers have defined these knowledge areas by different names and in different formats. BABOK (Business analysis body of Knowledge) has also defined these knowledge areas which group together related tasks and techniques.

Knowledge areas define the set of techniques which a BA should understand and try to practise during the routine activities. There is no arrangement for these knowledge areas and the tasks from all these knowledge areas can be performed in rapid succession depending on the pertinent inputs from the business owners.

As per BABOK, the list of these knowledge areas (KA) is as below:

  1. Business Analysis Planning and Monitoring
  2. Requirements Elicitation
  3. Requirements Management and Communication
  4. Enterprise Analysis
  5. Requirements Analysis
  6. Solution Assessment and Validation
  7. Underlying Competencies

Continue reading

Introduction to business analysis

Success is not achieved by hard-work but by perseverance.

Over the past several years, one job title which has emerged out as the most prevalent is Business Analyst. When I started my career in 2007, I had a mindset that the business analyst must be those people who are the owners of any business, but as the years rolled and as I became more familiar with the IT industry, I came to know more about the business analysts and the task they perform.

business analysisOne should understand that the business analysts are not by birth but by the process. If I refer IIBA BABOK to explain business analyst, the definition would be like, “A business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems”.

But business analyst is not only bound to this definition. He is the one who has lot more things to do well in time with quality. While most organizations have the designation “Business Analysis” and hire a high-profile “Business Analysts” to fulfill the demands but there is always a lack of clarity about the work should be given to business analysts. There are always many questions in the mind like, who are business analysts? What is business analysis? What do business analysts do? What should be the minimum qualification to be a BA? Etc.

In the glimpse of these unclear questions organizations are always in a dilemma in order to whom to hire as a business analyst. Business analyst’s posts can be filled by former product user, a subject matter expert (SME) or a senior developer involved in developing the product, a PM who has always been there to understand the requirement or a person having only business background having limited computer skills. But there are always many other dedicated IT professionals who worked as analysts for any product. If I give my example, I have been given a role of Business Analysts after gaining experience in Business Process Management application. This application was new to our organization and thus I had a lot of scope to develop my business analysts’ skills in order to understand the functionality of the application and the tool on which the application was built. One thing which I believe is most of the times is unacknowledged when we talk about BA and i.e. “customer service”. A BA is not just a liaison between the stakeholders but a bridge to support the customers. Customer satisfaction is one thing which a BA should develop in him.  Customer service itself is a broad area which varies from conflict management, stakeholder management, building rapport before the stakeholders and not the least building comfortable environment for all the members to perform. Continue reading