제가 방금전에 IT회사에서 business analyst직 면접제의를 받았습니다.아는 사람의 소개로 이력서를
넣은 것이 전부이고, internet검색을 해봤지만, 역시 그렇게 도움이 되는 정보가 없습니다.
워낙 생경한 분야라서 아래와 같은 질문을 드립니다.
1. business analyst의 업무영역? - 이부분에 대해서 주로 어떤 직무를 담당하게
되는지에 대해서 말씀하여 주시기 바랍니다. - 답변:
2. business analyst의 요구능력? - 이 부분에 대해서는 IT회사에
적용될 수 있는 것을 말씀해 주시기 바랍니다. - 답변:
3. business analyst가 되기 위한 선수지식? - 저는 경영학
전공이고, 주요 분야는 무역(네고 및 영업)관련 업무를 주로 배웠으며, 직장에서는 무역업체 상담, 웹사이트 기획 등의 업무를 주로
담당하였습니다. 이런 것을 감안해서 말씀을 답을 달아 주시면 대단히 감사하겠습니다. -
답변:
워낙 생경하고 이번에는 꼭 이직을 하여야 하기 때문에 이렇게 질문을 드립니다.
회원님 여러분의 작은 답변도 제게는 아주 큰 해답이 됩니다.
감사합니다.
1/18/2009
Subscribe to:
Post Comments (Atom)
Roles and responsibilities
ReplyDeleteThe 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. A key part of this is ensuring
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 a form that can be understood and
acted on by a service provider. This often takes the form of ability statements,
smaller sub-requirements, functions, tasks, etc. These can be used by a 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.
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.
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/specifictions, which are actually high-level design of a
presumed way of accomplishing the presumed requirements. Goldsmith also presents
public and in-house 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.