Business Analyst
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Business Analyst as PDF for free.
More details
- Words: 1,282
- Pages: 4
Business analyst A business analyst (BA) is responsible for analysing the business needs of their clients and stakeholders to help identify business problems and propose solutions. Within the systems development life cycle domain, the BA typically performs a liaison function between the business side of an enterprise and the information technology department or external service providers. Common alternate titles are business systems analyst, systems analyst, and functional analyst, although some organizations may differentiate between the above titles and corresponding responsibilities.
Contents • • • • • • •
1 Roles and responsibilities 2 Skills and knowledge 3 Role in the system development life cycle 4 Other activities and skills 5 Typical deliverables 6 Prerequisites 7 See also
•
8 External references
Roles and responsibilities The role of the BA is to apply analytical skills to business requests (which are often high-level or lacking in detail) and communicate these business wants/needs in a clear and unambiguous manner.
Skills and knowledge Business subject knowledge: The BA should have some background knowledge of the subject to make the requirements gathering efficient, or at least have the skills to apply logical analytical thought to a business issue. The degree of prior knowledge required 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 how realistic the requirements are in terms of effort, time, costs. Relevance: the purpose served by individual requirements in relation to larger business and/or project goals.
Data: this area will usually focus on identifying what data the business currently has, what data need to be carried over into the new systems and/or analysis around what can be achieved with a new system. Techniques that a BA uses to gather and document requirements include UML, process flows, use cases, interview skills, workshop facilitation, and investigation of current state (existing systems and/or processes). Skills required to successfully execute the business analysis process include communication skills, understanding of a variety of technologies and platforms (client/server and mainframe), entity-relationship diagrams (ERDs) and relational database concepts, object-oriented technologies (Rational Rose, object-oriented analysis, object-oriented design, object-oriented programming), and the systems development lifecycle (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.
Role in the system development life cycle The BA plays a central role in the systems development life cycle (SDLC). In general 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), delivery (coding, execution of activities), testing (test cases, unit testing, integration testing, user acceptance testing), implementation (roll-out of the idea or request), close-out (documentation, post-implementation review).
This is also known as project methodology. A version of the SDLC is part of many different project methodologies such as rapid application development (RAD), system development methodology (SDM), and Rational Unified Process. The business analyst will provide different services during the SDLC: • • • • • • • •
assisting with the business case high-level feasibility studies gathering of the requirements designing and/or reviewing test cases processing change requests tracing the requirements during implementation (traceability matrix) manage project scope acceptance, installation, and deployment
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 Report status and issues to the Project Manager(s) Contribute to enterprise architecture development from a business needs point of view Great communicator and diligent team member
Typical deliverables Business Requirements constitute a specification of simply what the business wants. This is usually expressed in terms of broad outcomes the business requires, rather than specific functions the system may perform. Specific design elements are usually outside the scope of this document, although design standards may be referenced. •
Example: The ability to add notes to a project plan.
Functional Requirements describe what the system, process, or product/service must do in order to fulfill the business requirement(s). Note that the business requirement often can be broken up into sub-business requirements and many functional requirements. These are often referred to as System Requirements. •
An example that follows from previous business requirement example: (1) System must provide the ability to associate notes to a project plan. (2) System must allow the user to enter free text to the project plan notes, up to 255 characters in length.
Non Functional Requirements are requirements that cannot be met by a specific function, e.g. performance, scalability, security and usability requirements. These are often included within the System Requirements, where applicable. Report Specifications are reporting requirements such as the purpose of the report, justification of the report, report attributes and columns, or runtime parameters. The Traceability Matrix is a cross matrix that traces the requirements through each stage of the requirements gathering process. High level concepts will be matched to scope items which will map to individual requirements which will map to corresponding functions. This matrix should also take into account any changes in scope during the life of the project. At the end of a project, this matrix should show
each function built into a system, its source and the reason that any stated requirements may not have been delivered.
Prerequisites There is no one defined way to become a BA. Often the BA has a technical background, whether having worked as a programmer or engineer, or completing a Computer Science degree. Others may move into a BA role from a business role their status as a Subject Matter Expert and their analytical skills make them suitable for the role. Business analysts often grow further into other roles as Project manager or consultant. A BA does not always work in IT-related projects, as BA skills are often required in marketing and financial roles as well. 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 functional requirements gathering and the specification process in full detail without clarifying how to accurately gather business requirements up front. Goldsmith's book in fact deals exclusively with how to discover the REAL, business requirements and also identifies more than 21 ways to test/evaluate the adequacy of the business requirements which have been defined. The book strongly distinguishes the REAL, business requirements from product, system, software, or functional requirements/specifications, which are actually high-level design of a presumed way of accomplishing the presumed requirements. Goldsmith also presents public and inhouse training on both discovering and evaluating business requirements. 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 BAs may work in include workflow, billing, mediation, provisioning and customer relationship management. The Telco industry has mapped these functional areas in their eTOM (Telecommunications Operational Map) model
Contents • • • • • • •
1 Roles and responsibilities 2 Skills and knowledge 3 Role in the system development life cycle 4 Other activities and skills 5 Typical deliverables 6 Prerequisites 7 See also
•
8 External references
Roles and responsibilities The role of the BA is to apply analytical skills to business requests (which are often high-level or lacking in detail) and communicate these business wants/needs in a clear and unambiguous manner.
Skills and knowledge Business subject knowledge: The BA should have some background knowledge of the subject to make the requirements gathering efficient, or at least have the skills to apply logical analytical thought to a business issue. The degree of prior knowledge required 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 how realistic the requirements are in terms of effort, time, costs. Relevance: the purpose served by individual requirements in relation to larger business and/or project goals.
Data: this area will usually focus on identifying what data the business currently has, what data need to be carried over into the new systems and/or analysis around what can be achieved with a new system. Techniques that a BA uses to gather and document requirements include UML, process flows, use cases, interview skills, workshop facilitation, and investigation of current state (existing systems and/or processes). Skills required to successfully execute the business analysis process include communication skills, understanding of a variety of technologies and platforms (client/server and mainframe), entity-relationship diagrams (ERDs) and relational database concepts, object-oriented technologies (Rational Rose, object-oriented analysis, object-oriented design, object-oriented programming), and the systems development lifecycle (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.
Role in the system development life cycle The BA plays a central role in the systems development life cycle (SDLC). In general 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), delivery (coding, execution of activities), testing (test cases, unit testing, integration testing, user acceptance testing), implementation (roll-out of the idea or request), close-out (documentation, post-implementation review).
This is also known as project methodology. A version of the SDLC is part of many different project methodologies such as rapid application development (RAD), system development methodology (SDM), and Rational Unified Process. The business analyst will provide different services during the SDLC: • • • • • • • •
assisting with the business case high-level feasibility studies gathering of the requirements designing and/or reviewing test cases processing change requests tracing the requirements during implementation (traceability matrix) manage project scope acceptance, installation, and deployment
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 Report status and issues to the Project Manager(s) Contribute to enterprise architecture development from a business needs point of view Great communicator and diligent team member
Typical deliverables Business Requirements constitute a specification of simply what the business wants. This is usually expressed in terms of broad outcomes the business requires, rather than specific functions the system may perform. Specific design elements are usually outside the scope of this document, although design standards may be referenced. •
Example: The ability to add notes to a project plan.
Functional Requirements describe what the system, process, or product/service must do in order to fulfill the business requirement(s). Note that the business requirement often can be broken up into sub-business requirements and many functional requirements. These are often referred to as System Requirements. •
An example that follows from previous business requirement example: (1) System must provide the ability to associate notes to a project plan. (2) System must allow the user to enter free text to the project plan notes, up to 255 characters in length.
Non Functional Requirements are requirements that cannot be met by a specific function, e.g. performance, scalability, security and usability requirements. These are often included within the System Requirements, where applicable. Report Specifications are reporting requirements such as the purpose of the report, justification of the report, report attributes and columns, or runtime parameters. The Traceability Matrix is a cross matrix that traces the requirements through each stage of the requirements gathering process. High level concepts will be matched to scope items which will map to individual requirements which will map to corresponding functions. This matrix should also take into account any changes in scope during the life of the project. At the end of a project, this matrix should show
each function built into a system, its source and the reason that any stated requirements may not have been delivered.
Prerequisites There is no one defined way to become a BA. Often the BA has a technical background, whether having worked as a programmer or engineer, or completing a Computer Science degree. Others may move into a BA role from a business role their status as a Subject Matter Expert and their analytical skills make them suitable for the role. Business analysts often grow further into other roles as Project manager or consultant. A BA does not always work in IT-related projects, as BA skills are often required in marketing and financial roles as well. 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 functional requirements gathering and the specification process in full detail without clarifying how to accurately gather business requirements up front. Goldsmith's book in fact deals exclusively with how to discover the REAL, business requirements and also identifies more than 21 ways to test/evaluate the adequacy of the business requirements which have been defined. The book strongly distinguishes the REAL, business requirements from product, system, software, or functional requirements/specifications, which are actually high-level design of a presumed way of accomplishing the presumed requirements. Goldsmith also presents public and inhouse training on both discovering and evaluating business requirements. 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 BAs may work in include workflow, billing, mediation, provisioning and customer relationship management. The Telco industry has mapped these functional areas in their eTOM (Telecommunications Operational Map) model
Related Documents
Business Analyst
October 2019 26
Master Business Analyst
December 2019 28
Senior Business Analyst
June 2020 4
Dasaradhi Cv Business Analyst
May 2020 8
