Friday, September 13, 2013

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...

Thursday, August 8, 2013

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...

Wednesday, August 7, 2013

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...

Friday, June 28, 2013

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

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...

Friday, June 21, 2013

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 that I can improve my blog post presentation for all the Dearest Readers... :)

As We Work...We Learn...

Tuesday, June 18, 2013

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...

Saturday, May 25, 2013

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...