Competencies of a Business Analyst - PowerPoint PPT Presentation

View by Category
About This Presentation
Title:

Competencies of a Business Analyst

Description:

COEPD - Center of Excellence for Professional Development is a primarily a Business Analyst Training Institute in the IT industry of India head quartered at Hyderabad. COEPD is expert in Business Analyst Training in Hyderabad, Chennai, Pune, Bangalore, Delhi, NCR, Mumbai, Solapur, Vizag. We offer BA Training with affordable prices that fit your needs. COEPD conducts 4-day workshops throughout the year for all participants in various locations i.e. Hyderabad, Chennai, Pune, Bangalore, Delhi, NCR, Mumbai, Solapur, Vizag. The workshops are also conducted on Saturdays and Sundays for the convenience of working professionals. For More Details Please Contact us: Visit at or Center of Excellence for Professional Development 3rd Floor, Sahithi Arcade, S R Nagar, Hyderabad 500 038, India. Ph# +91 9000155700, helpdesk@coepd.com – PowerPoint PPT presentation

Number of Views:68

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Competencies of a Business Analyst


1
Competencies of a Business Analyst
(Professional Business Analyst Training
organisation)
2
  • Core competencies of a Business Analyst

1. Eliciting Requirement 2. Creating the Business
Requirements Document 3. Structured Analysis 4.
Object-Oriented Analysis 5. Business Process
Re-Engineering 6. Testing 7. End-User Support
3
  • Eliciting Requirements
  • A major aspect of a business analysts job is
    eliciting and documenting user
  • requirements.
  • Requirements can be conditions, functionality,
    products or services for
  • internal or external use.
  • Requirements are needed by a user or client to
    solve a business problem,
  • and theyre tied to the needs of business
    rather than the constraints
  • imposed by technology.
  • The techniques necessary for capturing
    requirements are often referred to as
  • elicitation.
  • Depending on an individuals level of
    competency and the situation, the type
  • of elicitation techniques applied will
    vary. 

4
  • 2. Creating the Business Requirements Document 
  • A business requirements document (BRD) is a
    written study of all facets
  • of  business, user, functional or
    non-functional requirements and provides
  • insight into both the as-is and to-be states
    of the business area.
  • In creating the BRD, business analyst will be
    largely responsible for defining
  • the various sources for requirements as well
    as the placement and relevancy
  • of those requirements.

5
  • 3. Structured Analysis
  • Structured analysis refers to the art of
    modeling.
  • In business analysis, modeling is used to
    support and enhance text-based
  • requirements, help identify and validate
    requirements, document and
  • communicate requirements and, finally,
    organize information into coherent
  • ideas.
  • The most common types of business analysis
    models are business models,
  • process models, data models and workflow
    models.


Traditional BA (Waterfall) Agile BA
Requirements are documented in Use Cases,Business Requirements, Functional requirements, UI Specifications, Business Rules. Requirements are documented in Epics, User Stories and optionally Business (or Essential) Use cases.
   
Focuses on completeness of requirement and spends time in ensuring the requirement is unambiguous and has all the details. Focuses on understanding the problem and being the domain expert so that s/he can answer questions from the development team swiftly and decisively.
Focuses on getting a sign off on the requirements. Focuses on ensuring the requirements meet the currentbusiness needs, even if it requires updating them.
Often there is a wall between the BA/Business and the Development team. Agile BA (Often called as Product Owner) is part of the team.
Tends to dictate solutions. Has to remain in the problem domain, leaving the development team space to explore different solutions.
Long turnaround. Quick turnaround.
Focus on what the requirements document said. In other words, output (Artifact) is a well written thorough requirements document. Focus on the functionality of the developed software. In other words, output (Artifact) is the software that meets thebusiness needs.
   
6
 
  • 4. Object-Oriented Analysis
  • Within a business context, an object model is an
    abstract
  • representation of a systems process and data
    requirements based on
  • decomposing the system into unitswhich are
    called objects.
  • Each object encompasses the data and operational
    characteristics of
  • one business item.
  • Object-oriented analysis is particularly
    important as a business
  • planning tool to depict the hierarchy of
    business functions, processes
  • and sub-processes.

7
 
  • 5. Business Process Re-Engineering
  • Considered the big-picture thinking of business
    analysis, business process
  • re-engineering (BPR) is a rapidly growing
    part of business analysis.
  • In fact, lately, many companies have been
    grouping business analysts
  • around this specialty and developing teams
    of process analysts.
  • This is the phase in which business analysts seek
    out and identify problems
  • and opportunities. BPR uses a variety of
    modeling techniques in order to look at the
  • bigger picture while still thinking
    tactically.


8
 
  • 6. Testing
  • The first thing to understand about testing is
    that the term applies to several
  • different levels of work.
  • First, business analysts are looking to test the
    products to validate whether the
  • requirements have been met.
  • Test scripts, test plans and test scenarios are
    based on the as-is state as well as
  • the to-be models.
  • The second level of testing is more familiar and
    consists of testing the
  • functionality of the physical product.
  • This ensures that the desired state has been
    reached based upon user
  • acceptance.


9
 
  • 7. End-User Support
  • Its a common misconception among project teams
    that the project ends
  • when the deliverable is completed.
  • Not so, Business analysts should be aware that
    end-user support after
  • the product is delivered is a vital part of
    the process.
  • Also, its important to note that the role of the
    business analyst is not to
  • act on behalf of the training team, but to
    complement the training teams
  • efforts with their knowledge of the business
    requirements.

10
(No Transcript)
About PowerShow.com