Category Business Analysis Tutorial

Business Analysis – An Introduction

What is Business Analysis?

According to BABOK®Guid, Business Analysis is the practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders.

In a simple word, it is a set of tasks and techniques which works as a bridge between stakeholders. These help them to understand organization’s structure, policies, and operations. They can also recommend solutions to help the business reach its goals or objective.

Basically Business Analysis is about understanding how your organisation function to full-fill their purposes. Business Analysis help organisation to improve their organisation process.

Who is a Business Analyst?

A Business Analyst is someone who analyse business domain and document them. Business Analyst (BA) is responsible for identifying the business needs of the customer (external or internal) and other stakeholders for determining solutions to business problems.

Typically a BA Identify, Analyse, develops and manages the requirements.

 

Roles and Responsibility of IT Business Analyst?

A business Analyst has following roles and responsibility.

  • Requirement gathering.
  • Analysing and documenting the requirements.
  • Communicate these requirements with stakeholders like designer, developer, business person and managers.
  • Identify the right solutions for the requirements
  • Validate the solution if requirements meet the expected Standards.

You can easily understand BA work cycle by following image.

Requirement Elicitation and Analysis

Requirement Elicitation:

Requirement Elicitation is a process of collection of requirements of any given system or product from users, customers and any other stakeholders.

This process step broadly involves the requirement inceptions, requirement identification, and requirement elicitation activities.

  • Requirement Inception relates to the use of context free questions to establish a basic understanding of the problems, the people who wants the solution, the overall nature of solutions expected and for gauging the effectiveness of the collaboration between customers and developers.
  • Requirement Identification involves enlisting and articulating the basic well known and fairly defined needs.
  • Requirement elicitation refers to finding out or the extracting from the client/users requirements which are unclear, vague or concealed and need explicit articulation for the understanding of developer team. This phase also covers aspect such as what the overall product/solution objectives are, which needs are to be supported on priority, how the product solution fits into the business needs and what kind of use will be made of the product/solutions on a day to day basis.

Requirement Analysis:

Requirement Analysis also called requirement engineering. Requirement analysis is the process to determining the user expectations for a new or modified product.

This process step broadly involves the Requirement Elaboration, Requirement Analysis and Requirements Negotiation activities.

  • Requirement Elaboration focuses on the development of a refined technical model of software function, user interactions, features and constraints based on the Requirement Elaboration information.
  • Requirement Analysis involves the prioritising the requirements, preparing the checklist for each requirement, highlighting and reviewing problems, arriving at a high level of abstract of products/solutions.
  • Requirement Negotiations involves checking requirements and resolving stakeholders/user conflicts, involving requirements categorization and organisation into subsets, establishing relationship among requirements, reviewing requirements for correctness, confirmation of requirement priority based on customer’s needs.

Requirement Elicitation and Analysis process:

Software Development Life cycle(SDLC)

Software Development Lifecycle:

Software Development Lifecycle (SDLC) Refers to Processes used to plan, create, test and deploy an information system.  It consist a detail plan how a system is going to develop, how to maintain and replace specific software.

SDLC metrology helps to improve software development quality and overall development.

Basically it consists 6 steps:

  1. Gather Requirement
  2. Design
  3. Development
  4. Testing
  5. Deploy
  6. Maintenance

 

  1. Requirement Gathering: Understand the user requirements and user business goals.
  2. Design:  Design the software UI and back-end Structures i.e database.
  3. Development: In development phase, developer do the coding on selected  development platform.
  4. Testing:  Once development activity has finished, testing activity takes place. In this phase tester verify the system functionality against the requirement.
  5. Deployment: Given to the users in a production and utilize the system.
  6. Maintenance:  Bug Fixes and other updates needed in the system.

Following figure will help you to understand the SDLC process flow.

SDLC Model – Waterfall

Waterfall Model:

It’s a traditional software development life cycle model. In this model you can see progress as following downward like a waterfall, through different phases like requirement gathering and analysis, design, coding, testing and maintenance.

In this model only next phase begun when the goal of previous phase has been completed.

Advantages of Waterfall:

  • Requirements do not change frequently, so we get a stable product.
  • Very simple to implement
  • Significant project progress visibility to manager as well as client.
  • A perfect model for a big project.

Disadvantages of Waterfall:

  • Reverse engineering is not possible i.e we cannot go back and change requirement once design has been developed.
  • Requirement changes on later stage are difficult to incorporate.
  • Customer may not be satisfied, if the changes they required are not incorporated in the product.
  • It is not suitable for long term projects where requirements may change time to time
  • Waterfall model can be used only when the requirements are very well known and fixed

Waterfall model process flow:

Water Fall Model of SDLC

SDLC Model – Prototyping Model

Prototyping Model –

Prototyping is defined as the process of developing a working replication of a product or system i.e a dummy product or system that has to be developed. It’s not the actual product but give the customer a fair idea what product is going to develop.

This model is very popular software development life cycle model. This model is used when the customer do not know the exact project requirement in beginning. A prototype of the end product is first developed, tested and refined as per customer feedback repeatedly till a final acceptable prototype is achieved which forms the basis for developing the final product.

In this method customer has advantages to see their product in early phases and if they want any changes they can do the same.

There are two approaches for this model:

Rapid/ Throwaway prototyping –

Through this technique team is getting an idea about system through customer feedback. In this method it’s not necessary that initial prototype will be the final accepted prototype. Continuous customer feedback help to prevent unnecessary design faults and hence, the final prototype developed is of a better quality.

Evolutionary Prototyping –

Evolutionary prototyping also called as breadboard prototyping. In this method, the prototype developed initially is incrementally refined on the basis of customer feedback till it finally gets accepted. In comparison to rapid/throwaway prototyping, it’s a batter approach because this method saves lots of time and efforts. This is because developing a prototype from scratch for every iteration can be very frustrating for the developers and manager.

Following figure shows process flow of Prototype model.

 

Advantages of prototype model –

  • Customer satisfaction, because customer can see their product dummy at early stage.
  • At early stage missing functionality can be identified.
  • Requirement can be change at early stage.
  • Developer and tester can re-use the developed prototype.

Disadvantages of prototype model –

  • It’s a time consuming model if customer continuously ask for changes.
  • Customer may get confused in the prototypes and real systems.
  • There is no parallel deliverable.
  • Poor Documentation due to continuously changing customer requirements.
  • The customer might lose interest in the product if he/she is not satisfied with the initial prototype.

 

 

SDLC Model – Agile

SDLC Model – Agile

These days Agile is a very popular SDLC model. Agile methodology is a practice that supports continuous iteration of development. It’s a combination of iterative and incremental approach which focuses on process adaptability and customer satisfaction.

In agile, whole project breaks in to the small incremental builds. Every iteration typically takes 1 to 3 weak times. After every development iteration, the customer is able to see the result and understand if he is satisfied with it or not. Scrum approach is one of the popular approaches used in agile model.

To know more about agile scrum click here

Advantages of Agile –

  • Less Documentation.
  • Change adaptability, even at the last stage of build.
  • Batter customer engagement.
  • Fast development process
  • Agile promote team work and cross training.
  • Concurrent development and delivery within define time frame work gives agile an extra edge.
  • Agile project is easy to manage.

Disadvantages of Agile –

  • Not much compatible for large and complex project
  • Customer heavily interaction required, so if customer is not clear about their product they can mislead the agile team.
  • Transfer of technology to new team members may be quite challenging due to lack of documentation.
  • Each individual in agile team should be self-motivated and self-driven. If these things missing in team member, it can cause problem for project.

BRS VS SRS VS FRS

BRS: Business Requirement Specification –

It is a high level document which include all requirement demanded by client. Basically it includes all requirements which should be the part of proposed system.

BRS says, proposed system supposed to include this requirement as functionality.

Business Analyst prepare this document.

To Know more about BRS template Click Here 

SRS: System Requirement Specification –

SRS describes the entire system flow, overall functionality of the system, how the data will flow within the system. It describes each module functionality.

SRS also include use cases that explain user interaction with the system or software. It also describes non- functional requirements like security, availability etc.

This document is developed by System Analyst but in small organisation BA also prepare SRS.

To Know more about SRS template Click Here

FRS – Functional Requirement Specification –

There is a very minor difference between FRS and BRS. FRS converted into functionality and says that how this requirement is going to work as a part of proposed system. FRS also explains sequence of operations to be followed on every single process.

This document is developed by developers and solution architect.

Now I am going to summaries it in tabular form

BRS

SRS

FRS

BRS stands for Business requirement specification. SRS stand for software requirement specification. FRS stand for functional requirement specification.
BRS does not include use case generally. SRS include use case to describe user interaction with system. In this use case are not included.
In BRS , we define what exactly customer wants. In SRS we describe all the business functionality of the application. In FRS, we describe the particular functionalities of   every single page in detail from start to end.
BRS explain story of whole requirements. SRS explain all functional and non- functional requirement. FRS explains the sequence of operation process on each and every stage.
SRS is a complete document which describe complete system behavior. It describe the all functionality of the system which would be efficient for end user. IT describe the business requirements in detail level.

 

Use Case

What is use case?

Use case a technique which use in requirement analysis. Simply it describes how a user uses a system to accomplish particular goal.

It’s a step of a particular use of the system by an actor or user.

Purpose of use case diagram

  • Define goal of the system
  • Define user interaction steps with the system.
  • System architecture validation
  • Easy to understand by end user and developer.

How do you write a Use Case?

Use case contains the following elements:

  1. Name – A clear verb/Noun/actor which describe the overall use case.
  2. Brief Description – A brief paragraph that describing the scope of use cases.
  3. Actors – A list of all types of users, who will use the system. Actor names should not correspond to job titles. Actor can be primary and secondary.
  4. Preconditions – List of conditions that need to be true when the use case begin.
  5. Basic Flow – It’s a set of steps that user need to take for successfully accomplish thegoal of use cases. A clear description what the system does in response to each user action.
  6. Alternate Flows – Capture the less common users, whose interaction with the system will very less.Document other, legitimate usage scenarios that can take place within this use case separately in this section. State the alternative course, and describe any differences in the sequence of steps that take place. Number each alternative course using the Use Case ID as a prefix, followed by “AC” to indicate “Alternative Course”. Example:  X.Y.AC.1.
  1. Post Conditions – Anything that must be true when the use case is complete.