Essential Skills for a BA Career

Dearest Readers,

This is one of the simplest blog-posts. The intended audience for this blog post would be all of them who aims to start their career as a Business Analyst. The below picture describes the list of essential skills required for a BA Career.

Pic: Skills for Business Analyst Career

1. Facilitation Skills: Facilitation sessions are mostly helpful for BAs to elicit and gather requirements from various stake holders during project initiation and requirements gathering phases. Facilitation sessions are very structured, planned, working sessions where every participant is carefully chosen and has a critical role to play. As a Facilitator the BA should have the art of bringing people together, face-to-face or remotely, to elicit requirements and get agreement on solutions.

2. Presentation Skills: Having excellent Presentations Skills is an asset for any Business Analyst. Once the BA document the requirements, then he has to present/hand-over that to multiple parties, such as Design Team, Development Team, Testing Team, etc. Even sometimes the BA has to present the result of his analysis and documentation to the Business Users. So for all these, the BA needs to have proper Presentation Skills.

3. Analysis Skills: As the profession is Business Analysis, a Business Analyst should be very sharp at his Analysis Skills. This will help him to analyze complex requirements easily and to arrive at some solution. A BA should analyze all the dependencies, issues and risks at a earlier stage of the project, which will help in proper Project Planning and Project Risk Management.

4. Visualization & Modeling Skills: Visualization & Modeling skills help a Business Analyst to represent the Project Requirements in the form of Business Process Models. At the initial stage a BA can create a Context Diagram through the Modeling Skills and at a later stage that can be decomposed to various Process Flow Diagrams. Visual representation of Requirements helps all the Stake holders to understand the scope easily.

5. Working Virtually: If we talk about any Project in this large global corporate world, then various Stake holders of a Project will be located in different geographic locations. But all work seamlessly as if all are present in the same place to achieve the common goal. As a Business Analyst most of the time we need to work virtually to attend meetings, manage project hand-overs, handle JAD Sessions, etc. through teleconference or e-Meetings.

6. Questioning Skills: Proper Questioning Skills is an Art which a Business Analyst should possess. Through Questioning Skills a BA can elicit all the Project requirements from various Stake holders. Sometimes the Stake holders are not clear about the Requirements, at that time as a BA one should ask various Questions (such as How…When..What..Where..etc. etc.) to obtain more clarity on the Requirements.

7. Thinking Out of Box: This is a main key differentiator for any Business Analyst. If a BA is able to think differently and achieve some project objectives with minimum time & cost, then it would be a great achievement for him. At times a BA needs to think out of the box and propose some alternate solutions to a problem if an already proposed solution fails.

8. Documentation Skills: A Business Analyst should be having excellent Documentation Skills. As a BA acts as a bridge between the Business Users and the Technical Team, he should document all requirements clearly so that other stake holders can clearly understand it and all Customer/Business User’s needs will be fulfilled / developed by the technical team.

9. Planning & Management Skills: Requirements Planning & Management is a core activity of Business Analyst. To do this effectively, a BA Should have very strong Planning & Management Skills. Going forward in his career-path, this skill even helps in proper Project Planning & Estimation.

10. Skills on CASE Tools: A Business Analyst should be equipped with skills on Computer-Aided Software Engineering (CASE) Tools such as MS Visio, Rational Software Modeler (RSM), Rational Rose, Rational Software Architect (RSA), SmartDraw, etc. With all these tools a BA can model the Project Requirements visually.

11. Communication & Interpersonal Skills: Most of cases a Business Analyst acts as a single point of contact in as Project Requirements are concerned. Before the requirements documentations, a BA needs elicit all requirements from various Business Users through proper communication skills. Once the documentation is over, he needs to interact with other Project Teams to explain the requirements. In an SDLC, a BA has to participate more or less in all the stages, which require great Communication & Interpersonal Skills.

12. Influencing Skills: A Business Analyst should work as an Influencer which will help in motivating other team members. At times Customers ask for some features in the Project which is technically feasible but little complex in developing those. In this instance, generally the Development/Technical team proposes some alternate solutions or asks not to include that requirement, as they don’t understand the Business Values of that requirement completely. So as a BA we need influence the team by communicating the proper rational behind it.

Do let me know your feedback through comments.

As We Work... We Learn...

Read more »

Posted in: Center of Excellence

Documenting Non-Functional Requirements

Dearest Readers,

Whenever we work on a Project, the Business Users of that project/ system will have some implicit expectations on how effectively the software will work. These expectations may include how user friendly the software will be to use, how fastly it will execute transactions, how durable it will be, and how well it behaves when unexpected conditions or exceptions arise. The Non-Functional Requirements (NFRs) define these aspects about the system. In our previous blog post we understood all about NFRs. In this blog post we will discuss on how to identify and document the Non-Functional Requirements (NFRs) for a Project.

In the below Picture (Table), I have listed possible Non-Functional Requirement Statements under each category and respective Target values. So while documenting the NFRs for your project, you can list similar NFRs and obtain the answer (target value) for the NFR from various Stake-holders. Some inputs you can obtain from Business Users, some from IT Department, some from Design Team, some from Database Team, so on and so forth...

Pic: Documenting Non-Functional Requirements

The above list is not the final set of NFR Statements Vs Values, out of my experience I have documented these. Depending on your Project Requirements there may be some new NFR Categories and some more NFR Statements. Here, my intention was just to show a path to identify and document NFRs. Hope you all will like this. Please share your experience and feedback through comments.

As We Work...We Learn...

Read more »

Posted in: Requirements Gathering

Understanding Non-Functional Requirements

Dearest Readers,

Requirements are the backbone of any Project and its a core competency of a Business Analyst to identify and document various Requirements correctly and completely. Its very important to understand and document Non-Functional Requirements along with the Functional Requirements, which do have an impact on the Project. In this blog post we will try to understand the so called Non-Functional Requirements and their categories.

What are Non-Functional Requirements (NFRs)?

NFRs specify ‘how’ the system should operate, rather than ‘what’ the system should do ‘functionally’. Examples include, but are not limited to, availability, reliability, capacity, scalability and security. These requirements are for a business system and address the aspects of the system that can possibly have a significant impact on how the system will work, and how it is accepted and operated both by the users and the people responsible for supporting and maintaining that system. 

The NFRs along with the functional requirements define the baseline against which the business system must be designed. It is essential that both sets of requirements are captured during the initial stages of a project. 

Non-Functional Requirements Categories:

NFRs define the Qualities expected in the system and the Constraints that may impact the system design and development.

The purpose of a non-functional requirements specification is:

• To specify required properties of the system.
• To define constraints on the system.
• To facilitate early system sizing and estimation of cost.
• To assess the viability of the proposed system.
• To give a basis for designing the operational models.
• To provide input to the component design.

The below diagrams depict various Categories of Non-Functional Requirements and respective Sub-Categories. 

Pic:  Non-Functional Requirements

The list of NFRs portrayed in the above list would help you guys to understand various categories of NFRs in your projects. Hope this will provide you all a glimpse of understanding NFRs. In the next blog-post I will provide a list of scenarios to document these NFRs for your project.

As We Work...We Learn...

Read more »

Posted in: Requirements Gathering

Feature Comparison Matrix

Dearest Readers,

In this Blog Post I will take you through one of the simplest concepts, i.e. Feature Comparison Matrix. We will discuss what is a Feature Comparison Matrix, how to prepare it and when it is required...

What is a Feature Comparison Matrix?

As the name specifies, it is a matrix which compares the availability of different Features of various Products of similar kind. 

When do you need a Feature Comparison Matrix?

• If you want to compare Features of various Products of similar class.

• If you are working in Software Product Development Company, and you are part of a new Product Development Process. At that time, you need to do a Market Analysis & Industry Analysis to understand the Vendors (Competitors) who are providing similar kind of Products. As a result of your Market/Industry Analysis, you need to come up with a Feature Comparison Matrix which will show-case the various features offered by similar kind of Products and which all features exist in which Product.

• If you are working in a Project, and the Project requires a specific 3rd Party Product to be integrated for a particular module. E.g.: If you are working in a "Treasury" Management System, and you require a 3rd party application for "Forex Pricing Engine". So you need to identify the Vendor's Products you are looking and go through the details of those products and prepare a Feature comparison Matrix, which can be used later for Vendor/Product Evaluation.

How to prepare a Feature Comparison Matrix?

Let's go through a sample Feature Comparison Matrix which I have created. 

Pic: Sample Feature Comparison Matrix

Steps:

1.  Identify the Vendors, whose Products you will be comparing. To do this, go through various Analyst Sites to identify the Top Vendors who offer the similar kind of Products.

E.g.: We would like to have a Product for "Mortgage Management System". Identify all Vendor Products and choose top 5 Vendor Products for comparison. 

2.  Identify all possible Features present in all the Products, which should be a Super Set of Features. List these features Module-wise. If you are aiming for developing any Product, then Identify and list all possible Features you want to have in the Product and then compare the same with other Vendor Products.

E.g.: Identify various Modules in a "Mortgage Management System", such as: Loan Origination, Loan Underwriting, Loan Closing and Loan Servicing. Then list out all possible features/requirements for each of the Modules.

3.  List out all Vendor-Products and mark against the features which are available in that Product. Please refer to the above picture.

Analyzing the Feature Comparison Matrix Result:

1.  The last row (No. of Features Available out of 14) in the picture shows that:

• There are total 14 features in the Matrix. Out of 14 features, how many features are present in each Vendor Product.
• "Vendor 1 - Product 1" satisfies maximum number of features i.e. 10.
• "Vendor 4 - Product 4" satisfies minimum number of features i.e. 5.

2. The last column depicts the count of Vendor Products where a Particular Feature is available. 

• "Feature - 11" is present in all the 4 Vendor Products.
• "Feature - 2" is present in only one Vendor Product.

These kind of analysis helps in understanding and identifying which Vendor Product meets to our expectation. While finalizing a particular Product, we need to consider the Product Pricing as well as a main criteria.

Hope this article help you out in understanding the practical approach of a Feature Comparison Matrix. Do let me know you feedback through your comments.

As We Work...We Learn...

Read more »

Posted in: Center of Excellence

MoSCoW Method for Requirements Prioritization

Dearest Readers,

As we all know, in any Project the Requirements are the key components of Project Scope. The Requirements should be prioritized, so that it will be easy to determine which Requirements are most important and which are least. Though there are different methods to prioritize the Requirements, in this Blog Post we will discuss about the MoSCoW Method for Requirements Prioritization. 

Origination: The MoSCoW approach was originated from the Dynamic Software Development Method (DSDM) Methodology. 

Acronym:  MoSCoW stands for:

• Must have (or Minimum Usable Subset)
• Should have
• Could have
• Won’t have (but Would like in future)

Note: The o's in MoSCoW are added to make the acronym pronounceable, and are often written in lowercase to depict that they don't have any significance.

MoSCoW is a Requirements Prioritization method that is used to take a decision on which requirements must be completed first and which must come later or will not be completed at all. To understand it practically, I have taken a simple example.

Example: You are planning to buy an SUV (of at least 7 seats) to Travel with your family and friends  on the weekends. The SUV should be of Diesel variant. As Red is your favorite color, you want to have Red color body work on it. Additionally you would like to have Bluetooth connectivity for your iPod. You are fond of having a 4-wheel drive mechanism in the SUV...and so on so forth...

As depicting a BA concept through a "Picture" is the uniqueness of my Blog, again I have come up with the below one which explains the MoSCoW Method in detail and prioritization of the above mentioned requirements in the example using the MoSCoW Methodology.

Pic: MoSCoW Methodology

Hope you will have a clear understanding of the MoSCoW Methodoly from the above picture. 

To deliver a successful project requires prioritization of the Requirements and Project Objectives (Scope, Quality, Time-frame and Resources). The below picture will give you an understanding of how 100% of Total efforts of a Project gets distributed as per the MoSCoW Prioritization Framework.

Pic: Project Effort Distribution - MoSCoW Framework

So with this blog post my objective is to make you all understand the MoSCoW Concept for Requirements Prioritization. Hope you all will like this.

Please do let me know your thoughts, feedback through comments...so that I can improve my blog post presentation for all the Dearest Readers... :)

As We Work...We Learn...

Read more »

Posted in: Requirements Gathering

Requirement Types with Examples

Dearest Readers,

Here we go with another post for our BA Blog on Software Requirement Types. As Requirements are the PILLAR of any Software Application or System, hence Identifying correct Requirements and documenting those properly is one of the core competencies of any Business Analyst. 

In this post, I tried to depict a glimpse of different Software Requirement Types along with relevant examples. Please check the below picture:

Pic: Software Requirement Types

It is not mandatory that, we shall document all types of Requirements in our deliverables (Business Requirements Document or Software Requirements Specification) for all the Projects. Depending upon the Project nature, we can identify and document requirements belonging to some or all of the Requirement Types.

Below is the Examples of various Requirements Types. To do the same, I have taken a simple Example of "Log-in" Functionality and tried to differentiate various types of Requirements.

Pic: Requirements Documentation - Example

Requirements Documentation Guidelines:

Requirement ID (Req. ID):  Each Requirement shall be identified with a unique ID. In this example, I have used Acronyms of the Requirement Types followed by a Requirement Number for documenting Requirement IDs. Such as:

• FR.01 (Functional Requirement 01), FR.02 (Functional Requirement 02), so on and so forth...
• NFR.01 (Non-Functional Requirement 01)...

Requirement Description: This describes the Requirement of the Proposed System completely.

Priority & Complexity:  While documenting Requirements, generally we assign the Priority and Complexity of each Requirement. Here I have taken measures as Low, Medium and High to assign the Priority and Complexity. At some places, you will see a numeric scale as well. There are so many factors to determine the Priority and Complexity of Requirements. Hopefully, I will write a separate Blog Post on"Requirements Prioritization" soon.

Hope, this post will help you guys in understanding various Requirement Types and the way to document them.

Let me know your feedback...

As We Work...We Learn...

Read more »

Posted in: Requirements Gathering

Questioning Skills - Requirements Elicitation

Dearest Readers,

Proper Questioning skills is the simple way to get more out of your Requirement Elicitation sessions.

Whenever you go ahead with the Requirements Questioning sessions, you need to make better use of yours and your stake holder's Time. A critical part of preparing for Requirements Elicitation is identifying a list of SMART questions. 

Would you be interested in learning a simple technique for improving your stakeholder meetings?

Without writing anything further, I am providing you the below Picture which would help you in easy understanding  so that you can use it in your future Requirements Gathering processes.

Picture: Questioning Skills for Requirements Elicitation

So did you get anything from the above picture :) ?

There are broad range of questions which can be asked in the requirements gathering sessions to understand the Business Requirements clearly. With the help of all these "What", "Why", "When", "How", "Where" and "Who" related questions you can collect clear requirements from your Stakeholders.

Note: The Questions listed in each of the Categories in the above image are just sample Questions. You can frame your own questions relevant to your Project.

One more tips for you guys: While eliciting and documenting the requirements, always make sure that all the Requirements follow the SMART Rule. Refer the below picture for more details.

Picture: SMART Rules for Requirements

Though this is one of the basic posts related to Business Analysis Concepts, I hope it would help you all in your future work. 

As We Work...We Learn...

Read more »

Posted in: Requirements Gathering

BA Interview Preparation Watch-list

Dearest Readers,

Do you have any interviews ahead?

Hope you are preparing well for it. A Business Analyst interview will be very professionally structured. You will have to think laterally when encountering all Business Analyst interview Questions. For that its always advised that you prepare well ahead of any BA Interview.

Per my experience, I have divided the entire interview preparation Process into different stages and a list of checklists for each stage. Please check the below image for the same.

BA Interview Preparation Watch-list

Hope the above checklists will help you out in your interview preparation. Let me know your feedback.

All the best for your interviews !!!

As We Work...We Learn...

P.S.: Take along copies of your Resume while going :) ...

Read more »

Posted in: Center of Excellence

Who is a Business Analyst?

Dearest Readers,

May be all of you start laughing by seeing the Title of this Blog-Post, i.e. "Who is a Business Analyst?". At this stage, why this post? As all of us know more or less know about Business Analysis and what a Business Analyst means.

My objective of writing this Blog-Post is to just outline the highlighted activities which a BA performs from the start of Project to end. I tried to depict the basics of a Business Analyst Profile in the below picture, As a Picture speaks thousand words :)

A Business Analyst's Profile

I have come across many of friends who ask me "What is your role in the Company?", even though I answer, they do not get exactly what I do. Even people who wants to be a Business Analyst or switch from their current career to Business Analysis can get a high-level idea of the Business Analyst Role through this post.

Just to focus on BA Profile and to make it simple, I have not included other Stakeholders such as Project Manager, Developer, Architect, etc. in the above Picture. Hope this will give you the basic overview of a BA.

In my other Blog Post I had covered detailed Skill Set required by a BA. Below is the URL:

http://www.businessanalysis.in/2011/03/make-difference-with-your-ba-skill-set.html

Added on 25 May 2013: As requested, adding the below Acronyms used in the above Picture:

• BRD: Business Requirements Document
• URD: User Requirements Document
• SRS: Software Requirements Specification
• FSD: Functional Specification Specification
• SSD: System Specification Document
• RTM: Requirements Traceability Matrix

As We Work...We Learn...



Read more »

Posted in: A Glimpse

SCRUM - Lingo...

Dearest Readers,

It won’t be wrong if I say, SCRUM has become the “Buzzword” these days in most of the organizations. Most of us, who work in the IT Organizations, have already come across this process more or less. In this blog post I am trying to cover the “SCRUM-Lingo” with one picture which may help others who look for the details regarding SCRUM. Hope you all will like it …

SCRUM is an iterative and incremental agile software development framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

SCRUM is:

•      Lightweight
•      Simple to understand
•      Extremely difficult to master

Scrum Framework: The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each constituent within the framework obliges a specific purpose and is vital to Scrum’s success and usage.

Below picture is self-explanatory which describes the basic elements used in the SCRUM Framework.

Pic: Scrum Sheet

This is just an overview, will try to cover SCRUM in detail in another post.

As We Work…We Learn…

Read more »

Posted in: A Glimpse

Business Modeling

Dearest Readers,

As we work in the Business Analysis field, always our focus is: how to represent Customer’s Requirements clearly. While we move ahead with the Process of Requirements Elicitation & Requirements Gathering, the Requirements get narrowed-down. Out of my experience I found, if we represent or drill-down the Business Requirements in the way of Process Modeling then it provides much more clarity in understanding the Business Processes. Same time Business User’s approval on the Business Process Models gives us a green signal to move ahead with further Analysis and Documentation. In this Blog Post I am trying to put the Basics of Business Modeling and its Types.

Business Modeling is a technique for improving organizational efficiency and quality through representing its Processes graphically. Business Modeling generally aims to improve business performance by elevating the efficiency of inter-related processes in the provision of a product or service.

Various types of “Flow Diagrams” are the core techniques of this methodology. The diagrammatic representation of Business Modeling is commonly referred as "Notation", which refers to a structural representation of a specified flow of activities in a particular Business or Organizational Unit.

The below picture depicts the basics of Business Modeling.

Pic: Business Modeling Basics

Business Modeling is an analysis of Business Processes, mostly represented as a collection of inter-elated activities. To start with Business Modeling for any Project:

• First we need to work on the Business Process Models (which details out the Business Processes Enterprise-wide),
• Then the Process Flow Models (which details out the collection of Processes and their relationships),
• And Finally the Data Flow Models (which details out the flow of information with-in a Process)

Below picture illustrates various Business Modeling Types: 

Pic: Business Modeling Types

This is just a glimpse of Business Modeling. Hopefully, I will be posting a detailed descriptions for each of the Business Modeling Types in recent future. Let me know your feedback on this.

As we work...We learn...

Read more »

Posted in: Center of Excellence