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