Business analyst

{{subst:#ifeq:a|b||{{subst:#ifexist:Wikipedia:Articles for deletion/{{subst:PAGENAME}}|{{subst:lessthan}}!-- The nomination page for this article already existed when this tag was added. If this was because the article had been nominated for deletion before, and you wish to renominate it, please replace "page={{subst:PAGENAME}}" with "page={{subst:PAGENAME}} (2nd nomination)" below before proceeding with the nomination. -->}}}}This template must be substituted. Replace {{afd with {{subst:afd.

{{subst:lessthan}}!-- Once discussion is closed, please place on talk page:

This article was nominated for deletion on {{subst:#time:j F Y|{{subst:CURRENTTIMESTAMP}} }}. The result of the discussion was keep.

-->

You must add a |reason= parameter to this Cleanup template – replace it with {{Cleanup|November 2005|reason=<Fill reason here>}}, or remove the Cleanup template.

General Definition of Business Analyst

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 analytical skills to high-level Business requests to determine what the business wants/needs 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, etc. that are used by the Project Manager in a Work Breakdown Structure. The analysis may consist of several areas such as Business/subject Knowledge, IT capabilities, feasibilities, costs, relevance, data, and dependencies across other business or project areas.

What skills and knowledge does the Business Analyst need?

Business Subject knowledge: The BA should have some background 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. This kind of investigation is also known as Domain Analysis.

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 System Development Life Cycle, otherwise the BA would not be able to play the different roles during a Project. In short terms, the SDLC contains 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). This is also known as Project Methodology.

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 and document requirements include UML, process flows, use cases, interview skills, workshop facilitation, investigation of current state (existing systems and/or processes) etc.

Skills required to support the Business analysis include communication skills, understanding of a variety of technologies and platforms (client, server and mainframe), ERD’s and relational database concepts, Object-Oriented 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
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
Improve business processes
Gather and define business requirements
Analyze and map processes (current state/future state)
Analyze data
Produce high quality documentation (version control)
Report status and issues to Project Manager(s)

What are the Deliverables that a BA produce?

(The What): The 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.

(The How): The Functional requirements 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. Non Functional requirements refer to the performance, scalability and security requirements.

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 BA does not always work in IT related projects, for example could 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. Some helpful text books are: UML for the IT Business Analyst: A Practical Guide to Object-Oriented Requirements Gathering by Howard Podeswa, Writing Effective Use Cases by Alistair Cockburn and Discovering Real Business Requirements for Software Project Success by Robin F. Goldsmith. Unfortunately most of the books describe the functional requirements gathered and specification process in full detail without clarifying the Business requirements gathering and specification process.

BAs work in different industries such as Finance, Banking, Insurance, Telco, Utilities, etc. It is common that BAs switch between industries. The Business Domain 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.

External References

Business Analyst Resources

Business Analyst Certification Programs