Jump to content

Business analyst: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
m grammer
m spelling
Line 22: Line 22:


Techniques that the Business analysts use to gather requirements are UML, process flows, interview skills, workshop facilitation etc.
Techniques that the Business analysts use to gather requirements are UML, process flows, interview skills, workshop facilitation etc.
Skills required to support the Business analysis are good communication skills, good understanding of a variety of technologies and platforms (client server and mainframe), ERD’s and relational database concepts, Object oriented related technologies (Rational Rose, OOA, OOD, OOP), and Project SDLC.
Skills required to support the Business analysis are good communication skills, good understanding of a variety of technologies and platforms (client, server and mainframe), ERD’s and relational database concepts, Object oriented related technologies (Rational Rose, OOA, OOD, OOP), and Project SDLC.
Also the BA need to have the ability to assemble, analyse and evaluate data and to be able to make appropriate and well-reasoned recommendations and decisions to support the Business stakeholders and the Project team.
Also the BA needs to have the ability to assemble, analyze and evaluate data and to be able to make appropriate and well-reasoned recommendations and decisions to support the Business stakeholders and the Project team.


Other activities and skills:
Other activities and skills:

Revision as of 16:28, 25 October 2005

A business analyst is responsible for identifying the business needs of their clients and stakeholders to help determine solutions to business problems. They typically have a high degree of industry experience and perform a liaison function to software developers or other service providers.

What does a Business Analyst do?

A Business Analyst is someone who applies analytic skills to high level Business requests to determine what the business wants and if these requests or requirements are consistent and not in contradiction with each other. The emphasis in the role is to understand the requirements from the business perspective and translate them into ability statements, smaller sub requirements, functions, tasks, which are used by the Project Manager in a work break down structure. The analysis consists of several areas such as Business/subject Knowledge, IT capabilities, feasibilities, costs, relevance, data, and dependencies across other business or project areas.

Business Subject knowledge: The BA must have some back ground knowledge of the subject to make the requirements gathering efficient although it is not always a must and depends highly on the complexity of the project.

IT Capabilities: understanding of what systems can and cannot do.

Feasibility: analysis around the feasibility of requirements in terms of effort, time, costs.

Relevance: requirements must serve a purpose otherwise they are not real requirements and hence must be de-scoped.

Data: this area is very broad and it can be described as collecting data requirements, what data do we currently have and need to be carried over into the new systems or analysis around what can be achieved with a new system by projecting previous figures of a successful project on the business.

The above mentioned analysis requires knowledge of the software development life cycle otherwise the BA would not be able to play the different roles during a Project. In short terms, the SDLC contains of well defined phases which are executed by the project team: a business idea or request, feasibility (business case), planning (Business requirements, Functional requirements), deliver (Coding, execution of activities), Test (testing, test cases, pilot), implementation (roll out of the idea or request), close out (documentation, post implementation review). The BA will provide different services during the SDLC: assisting with the Business case, high level feasibility, gathering of the requirements, reviewing the design and test cases, processing change requests and trace the requirements during implementation (traceability matrix). Also there are many Project Methodologies such as RAD, SDM, Rational Rose etc.

Techniques that the Business analysts use to gather requirements are UML, process flows, interview skills, workshop facilitation etc. Skills required to support the Business analysis are good communication skills, good understanding of a variety of technologies and platforms (client, server and mainframe), ERD’s and relational database concepts, Object oriented related technologies (Rational Rose, OOA, OOD, OOP), and Project SDLC. Also the BA needs to have the ability to assemble, analyze and evaluate data and to be able to make appropriate and well-reasoned recommendations and decisions to support the Business stakeholders and the Project team.

Other activities and skills: • Provide guidance to stakeholders on devising effective and efficient approaches to achieve the project objectives • Identify and resolve issues and manage the risks • Liaise with other project areas to coordinate interdependencies and resolve issues • Liaise with various business units to gather requirements and resolve issues • Process improvement • Hands-on business analysis (gather and define business requirements, analyse and map processes, data analysis, functional design, etc) • Produce high quality documentation (version control) • Report status and issues to Project Manager(s)

What are the Deliverables?

BRS (The What): Business requirements specification which defines what the business wants (mostly ability statements without any reference to systems or functions or design because this is irrelevant to the requirement. In case it’s relevant it is a functional requirement). Example: The ability to provide Customers with a charge out option for their contracts.

FRS (The How): This describes what the system, process or product/service must do in order to full fill the business requirement. Note that the Business requirement often can be broken up into sub business requirements and many functional requirements. An example that follows from previous business requirement example: The button “Charge Out” must populate field “Charge Out amount” with a calculated pay out charge for the remainder of the contract.

Reports: The reporting requirements (Purpose of the report, justification of the report, the report attributes and columns, runtime parameters)

Traceability Matrix: A cross matrix that traces the original requirement back to the end result (function, product or task), if the end result has been achieved or not which reasons, any change requests on the requirement and the date of the implementation.

How to become a BA?

The BA role is one of those occupations you cannot apply for unless you have some experience in related roles. Often Software developers follow the career path of Software developer, Functional analyst, Systems analyst, and Technical Business analyst to become Business Analyst. Business analysts often grow further into other roles as Project manager or consultant.

A Business analyst does not always work in IT related projects but can be working on marketing proposition projects or in consultancy tasks.

A few consulting companies provide BA training courses and there are some consulting books (UML, workshop facilitating, consultancy, communication skills) on the market. Unfortunately most of them describe the Function requirements gathered and specification process in full detail without clarifying the Business requirements gathering and specification process.

BA’s work in different industries such as Financial world, Banking, Insurance, Telco, Utilities and it is common that BA’s switch between industries. The Business functional subject areas are workflow, billing, mediation, provisioning, customer relationship etc. The Telco industry has mapped these functional areas in their eTOM (Telecommunications Operational Map) model.

The author of this article is a full time BA himself who worked in several countries: The Netherlands, US, India, New Zealand and Australia. Author: Paul de Groot (e-mail: pauldg@tpg.com.au)