Center Of Excellence For Professional Development



Most organizations decide to fund a project because obviously, they anticipate a return on the investment (ROI). A business case describes this anticipated return. For a BA to know a project, he or she must understand the business case. Sometimes the BA will be asked to develop the business case as the first task of a project or before a project has been approved. Understanding the importance of developing business case is a key business analysis skill.

Have you ever tried to convince your spouse that you should get a new car? Why did you decide to buy a new pair of shoes? When you are working to persuade someone (even yourself) to take action, you are building a case.

A business case is an explanation of why the organization has decided to go with a project. The word case comes from the legal profession and means an argument for or against something: “we are building a case for…”, Business cases which depict the value of an endeavor.

        The mechanisms to evaluate business case are:

Feasibility Study: A feasibility study determines the practicability and workability of a potential solution before a project is approved. It answers the question: “Can it be done?”

Cost/benefit analysis: This activity focuses on financial analysis of the potential solution, using economic calculations to project the potential return on investment and payback period. It answers the questions, “what are the costs VS benefits of doing it?” Some costs and benefits are not easily measurable. Benefits like goodwill and positive public relations are referred to as intangible. Costs that are easily measured are referred to as tangible.

                Building a business case involves bringing together research, logical reasoning, and financial estimates. In addition, business case development requires creativity and big picture thinking.

        Bottom line is,Business case development and cost/benefit analysis are important skills for business analysis professionals to develop early in their careers.


About J A D Session

J A D : Joint Application Development

J A D sessions will come into the picture where the project faces critical phases.

J A D should be conducted between the appropriate stake holders like project manager and development team and the subject matter experts.

J A D should be effective when the right people are selected for the particular topic.

J A D  is a technique to provide high level quality information or solutions  in a shorter time.

SWOT analysis

SWOT Analysis


SWOT is also known as TOWS Analysis, which is also considered as an outside-in and inside-out analysis of an organization's position. SWOT is an abbreviation for Strengths, Weaknesses, Opportunities and Threats.

In any organization, which is looking to improve its performance, this analysis plays a major role to design a strategy to look ahead.

This analysis is used to analyze any industry, locality, individual person or any manufactured product. SWOT helps to examine both internal and external factors that may influence your project, because strengths and weaknesses are internal to the company and opportunities and threats depend on external factors. These results will be achieved by doing brain storming session to identify the factors in each of the four categories.

Once you are finished brainstorming, create a final, prioritized version of your SWOT analysis, listing the factors in each category in order from highest priority at the top to lowest priority at the bottom.

SWOT analysis is also a widely recognized method for gathering, structuring, presenting and reviewing extensive planning data within a larger business or project planning process.


Strengths (internal, positive factors)

Strengths describe the positive attributes, tangible and intangible, internal to your organization. They are within your control.

Weaknesses (internal, negative factors)

Weaknesses are aspects of your business that detract from the value you offer or place you at a competitive disadvantage. You need to enhance these areas in order to compete with your best competitor.

Opportunities (external, positive factors)

Opportunities are external attractive factors that represent reasons your business is likely to prosper.

Threats (external, negative factors)

Threats include external factors beyond your control that could place your strategy, or the business itself, at risk. You have no control over these, but you may benefit by having contingency plans to address them if they should occur.



·        Better durability of product

·        Commitment and confidence of management

·        Scope and process of IT

·        Deliver compatibility of the project

·        High product life

·        Costumer positive feedback and Satisfaction


·        No direct marketing

·        Improper budget for successful delivery of the product

·        Lack of Capabilities

·        No proper morals and leadership

·        No proper knowledge of System and IT flow

·        Underestimating Competitors



·        Latest development in tech and creativity

·        Demand in market volume

·        Training on subject

·        Reliable service compared to others

·        R & D

·        Global Impact


·        Lack of knowledge on latest subject

·        Improper financial support

·        Political and judicial effect

·        Various intentions of competitors

·        Invincible imperfections

·        Changes in Key employee





A realistic recognition of the weaknesses and threats that exist for your effort is that the commencement to countering them with a strong set of ways that devolve on strengths and opportunities. A SWOT analysis identifies your strengths, weaknesses, opportunities and threats to helpyou in creating strategic plans and choices.

How does a BA handle Requirements?

A BA ensures that the client requirements are properly collected and documented then, communicates the same to the technical team in a UML language which is more understood by them.

A BA communicates to the Client in the Business language. BA nurtures these requirements into an IT Solution with help of the Technical Team. Generally, a technical team will be headed by a Project Manager.

The PM takes care of the technical aspects of the Project.
Team management and delivery of the project within Time frames is also taken care by the PM.

A BA shall continuously track the Client Requirements through all the stages of SDLC, thus helping the technical team understand the requirements clearly and BA also prepares the client for the UAT and participates in it along with the client. In short, it can be said that a “BA takes the ownership of the Client Requirements”.

Types of Requirements..

·         Business Requirements

·         Stakeholder Requirements

·         Transition Requirements

·         Solution Requirements a. Functional Requirements
                                      b. Non-functional Requirements

  • Business Requirements:  These are the high level statements of goals, they describe the reason for initializing the project. The business requirements describes the needs/requirements of the company as a whole and not as different groups/stakeholders within. These are developed through enterprise analysis.
  • Stakeholder Requirements:  These are the statements of needs elicited from the stakeholder/users of the requirement in a company.  These act as bridge between the business requirements and solution requirements. These are developed and defined through requirement analysis.
  • Transition Requirements: These are one time and temporary in nature and are essential but sometimes cannot be designed until both the existing and new solutions are developed. These are developed and defined through solution assessments and validation.
  • Solution Requirements:  These can be described as the characteristics of a solution that meet both the business and stakeholder requirements and they are developed through requirement analysis.

*      Functional Requirements: These describe the solution requirement which a system essentially needs, for performing a desired task. (non-technical)

*      Non- Functional Requirements: These describe what the work behavior of a system essentially and specifically needs to be,

for performing the desired task. (Technical). Eg: TAT, security.


Documents prepared by a BA.

Different Documents prepared by a BA in a Project. 

Use case Description Document:
A BA has to document the ‘business requirements’ in terms of their functionalities.

This can be done through the use cases. A use case is used to identify, and define system functionalities.

A use case is created from the user perspective and achieves the following objectives:
1. Organizes the functional requirements,
2. Iterative in nature and updated throughout the project life-cycle
3. Records scenarios in which a user will interact with the system
4. But Use case Diagrams does not cover few other aspects like negative flows, UI elements, exceptions, etc. So, for that purpose a BA prepares a Use Case Description Document.

It contains:

·         Actors

·         Description

·         Trigger

·         Preconditions, Post conditions

·         Normal Flow

·         Alternative Flows

·         Exceptions

·         Special Requirements

·         Assumptions

·         Notes and Issues


 Business Requirement Document

A Business Requirement Document’s main objective is to describe the ‘business requirements’ of a proposed project and the intended end result that is expected from that project. It is one of the most widely accepted project requirement document and is referred throughout the SDLC of the project.

A BRD mainly focusses on answering ‘what is the business solution’ as opposed to ‘how to achieve the business solution’ and thus it is mainly centered on the business requirements.


A BRD is created with the help of the project team (BA, client, subject matter exerts, business partners) and is used as a communication tool for other stakeholders/external service providers, etc.


The Business Requirement Document contains:

·         Project Background

·         Business goals and objectives

·         Stakeholders

·         Requirement scope

·         AS-IS Process

·         TO-BE Process

·         Functional requirements

·         Data requirements

·         Non-functional requirements

·         Interface requirements

·         Business glossary/Definitions

·         Dependencies of existing systems

·         Assumptions



Functional requirement specification (FRS)/ Functional Specification Document (FSD)

An FRS or FSD describes how the system, including data, operations, input, output and its properties is expected to behave.

In a BRD the requirements are high level but in a FRS/FSD they are written in much more detail to capture each and every aspect of a requirement.


Thus a functional specification document is more of a technical, accurate and descriptive document.


Owing to their technical nature, FRS/FSD are equally used by developers, testers and the business stakeholders of the project.

An FRS/FSD contains..

·         Product Context

·         Assumptions

·         Constraints

·         Dependencies

·         Functional Requirements

·         User Interface Requirements

·         Usability

·         Performance

·         Manageability/Maintainability

·         System Interface/Integration

·         Security

·         Requirements Confirmation/sign-off


System requirement specification (SRS)/ System Requirement Document (SRD)

A detailed document containing information about ‘how’ the complete system has to function and lists the hardware, software, functional and behavioral requirements of the system.


This document elaborates the requirements from the perspective of observational behavior only and doesn’t consider technical or design bias.



An SRS/SRD contains:

·         Product Perspective

·         Product Functions

·         User Characteristics

·         General Constraints

·         Assumptions and Dependencies

·         External Interface Requirements

·         Functional Requirements

·         Classes / Objects

·         Non-Functional Requirements

·         Inverse Requirements

·         Design Constraints

·         Sequence Diagrams

·         Data Flow Diagrams (DFD)

·         State-Transition Diagrams (STD)

·         Change Management Processes