Difference between revisions of "Business Analyst"

From Officience
Jump to: navigation, search
m
 
(7 intermediate revisions by the same user not shown)
Line 1: Line 1:
−
[[File:BA-is-a-skill.jpg]]
+
[[File:Nobody mess with my Best Amigos (BA) !.png]]
 +
 
 +
 
 +
 
 +
Thao Lan NGUYEN HOANG organized 2 training sessions about the job of '''Business Analyst''' (also known as "'''BA'''") in IT Development in May 2016 and April 2017.
  
−
Thao Lan NGUYEN THI organized 2 training sessions about the job of '''Business Analyst''' (also known as "BA") in IT Development in May 2016 and April 2017.
 
  
 
== Session 1 ==
 
== Session 1 ==
Line 8: Line 11:
 
Business Analysis is the practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders. (IIBA definition)
 
Business Analysis is the practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders. (IIBA definition)
  
 +
[[File:BA-is-a-skill.jpg]]
  
 
=== What is a Business Analyst? ===
 
=== What is a Business Analyst? ===
Line 18: Line 22:
 
* BA as a skill
 
* BA as a skill
 
* BA is not only a single person.
 
* BA is not only a single person.
 +
 +
===Sources===
 +
* [http://www.iiba.org/Careers/What-is-Business-Analysis.aspx What is Business Analysis by iiba.org]
 +
* BABOKv2.0.pdf
 +
  
 
== Session 2 ==
 
== Session 2 ==
Line 120: Line 129:
 
*Enterprise Architect
 
*Enterprise Architect
 
|}
 
|}
 +
 +
=== Sources ===
 +
*[http://www.iiba.org/Careers/Careers/business-analyst-career-roadmap.aspx|Business Analyst career roadmap by iiba.org]
 +
*[http://www.iiba.org/Careers/Business-Analysis-Careers.aspx Business Analysis Careers by iiba.org]
  
  
 
[[File:You-dont-need-IT-knowledge-to-be-BA.jpg]]
 
[[File:You-dont-need-IT-knowledge-to-be-BA.jpg]]
 +
  
 
==Session 3==
 
==Session 3==
Line 184: Line 198:
  
 
=== Sources ===
 
=== Sources ===
−
* [https://lostechies.com/joeocampo/2007/09/20/agile-vs-traditional-development-cost-models-maybe/ “Traditional Methodology Resource Cost” Chart]
+
* [https://lostechies.com/joeocampo/2007/09/20/agile-vs-traditional-development-cost-models-maybe/ Traditional Methodology Resource Cost Chart]
 
* BABOK v2.0
 
* BABOK v2.0
 
* Microsoft.Press.Software.Requirements.3.3rd.Edition.Aug.2013.pdf
 
* Microsoft.Press.Software.Requirements.3.3rd.Edition.Aug.2013.pdf
 
* [https://www.slideshare.net/MarrajuBollapRagada/agile-vs-iterativevswaterfall Quick understanding about Waterfall / Iterative / Agile]
 
* [https://www.slideshare.net/MarrajuBollapRagada/agile-vs-iterativevswaterfall Quick understanding about Waterfall / Iterative / Agile]
 +
 +
== Session 4==
 +
 +
=== Elicitation ===
 +
 +
====Definition====
 +
 +
#to draw forth or bring out (something latent or potential)
 +
#to call forth or draw out (as information or a response)
 +
These definitions highlight the need to actively engage the stakeholders in defining requirements.
 +
 +
====Frequently used techniques & output ====
 +
'''Techniques :'''
 +
* Hold elicitation interviews
 +
* Identify champion product
 +
* Perform document analysis
 +
 +
'''Output'''
 +
 +
* Requirements [Stated]: Described from the perspective of the stakeholder. Stated requirements describe the stakeholder’s need from the stakeholder’s perspective.
 +
* Stakeholder Concerns: Includes issues identified by the stakeholder, risks, assumptions, constraints, and other relevant information
 +
 +
=== Analysis ===
 +
{| class="wikitable" style="width: 60%;"
 +
|-
 +
| '''Definition'''|| Requirements analysis involves refining the requirements to ensure that all stakeholders understand them and scrutinizing them for errors, omissions, and other deficiencies.
 +
 +
|-
 +
| '''Frequently used techniques'''||
 +
* Prioritize the requirements
 +
* Create a data dictionary
 +
* Analyze requirement feasibility
 +
|-
 +
| '''Output'''|| Requirements [solid]: Prototype (visual form), Document (textual form)
 +
|}
 +
 +
=== Specification ===
 +
{| class="wikitable" style="width: 60%;"
 +
|-
 +
|'''Definition'''|| Requirements specification is to document requirements of different types in a  consistent, accessible, and reviewable way that is readily understandable by the intended  audiences.
 +
|-
 +
| '''Frequently used techniques'''||
 +
* Specify non-functional requirements
 +
* Record business rules
 +
* Identify requirement origins
 +
|-
 +
| '''output''' || User requirements typically are represented in the form of use cases or user stories.
 +
|}
 +
 +
===Validation===
 +
{| class="wikitable" style="width: 60%;"
 +
|-
 +
|| '''Definition''' || Validation ensures that the requirements are correct, demonstrate the desired quality characteristics, and will satisfy customer needs. Requirements that seem fine when you read them might turn out to have ambiguities and gaps when developers try to work with them.
 +
|-
 +
| '''Frequently used techniques'''||
 +
* Simulate the requirements
 +
* Define acceptance criteria
 +
|-
 +
| '''output''' || User requirements typically are represented in the form of use cases or user stories, that are understood correctly by Dev team and Stakeholders
 +
|}
 +
 +
 +
===Sources===
 +
* [https://lostechies.com/joeocampo/2007/09/20/agile-vs-traditional-development-cost-models-maybe Traditional Methodology Resource Cost Chart]
 +
* BABOK v2.0
 +
* Microsoft.Press.Software.Requirements.3.3rd.Edition.Aug.2013.pdf
 +
* [https://www.slideshare.net/MarrajuBollapRagada/agile-vs-iterativevswaterfall Quick understanding about Waterfall / Iterative / Agile]
 +
 +
== References ==
 +
* [https://docs.google.com/presentation/d/1O94mnfFULC_mSGIw63lmPuIUBHK25ENIMz9T7-CMDYk BA Training Course - Part 1 (by Thao Lan NGUYEN HOANG)]
 +
* [https://docs.google.com/presentation/d/1sPMHC_HnyKx4s6ewHeYxZ-DUWe_1R70-Q--Dop_bZVQ BA Training Course - Part 2 (by Thao Lan NGUYEN HOANG)]
 +
* [https://docs.google.com/presentation/d/1T0P99QI7L5Ha9Xf8teJLWpnPIrFHhyptn8m0P8pqGrE BA Training Course - Part 3 (by Thao Lan NGUYEN HOANG)]
 +
* [https://docs.google.com/presentation/d/12HM3EQTGqkcofnOmSpfirRC5T3by5Zbn3ojfQesNiH0 BA Training Course - Part 4 (by Thao Lan NGUYEN HOANG)]

Latest revision as of 02:31, 4 March 2018

Nobody mess with my Best Amigos (BA) !.png


Thao Lan NGUYEN HOANG organized 2 training sessions about the job of Business Analyst (also known as "BA") in IT Development in May 2016 and April 2017.


Session 1

What is Business Analysis?

Business Analysis is the practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders. (IIBA definition)

BA-is-a-skill.jpg

What is a Business Analyst?

Job titles for business analysis practitioners include not only business analyst, but also business systems analyst, systems analyst, requirements engineer, process analyst, product manager, product owner, enterprise analyst, business architect, management consultant, business intelligence analyst, data scientist, and more. Many other jobs, such as management, project management, product management, software development (dev), quality assurance (test/QC) and interaction design (UI/ UX design) rely heavily on business analysis skills for success.

BA-is-not-a-single-person.jpg

To remember :

  • BA as a skill
  • BA is not only a single person.

Sources


Session 2

What’s my career path in BA?

Business Focused IT focused
  1. Business Requirements Analyst: help the business to meet its objectives and goals
  2. Business Process Analyst: bring change to organizations that keep organizations running and manage the changes of those processes.
  3. Decision Analyst – In Demand (often referred to as a Business Intelligence Analyst)
  1. Business Systems Analyst
  2. Agile Analyst
  3. Functional Analyst
  4. Systems Analyst
  5. Service Request Analyst


Decision Analyst

Often referred to as a Business Intelligence Analyst

Input Output
Data & Statistical Methods The ability to gain insight and to drive business planning


Business analysis job profiles

Project/ IT Executes projects Transition/ Functional Guides projects Enterprise/ Strategic Creates projects
Generalist
  • Business Analyst
  • (Project) Management Consultant
  • Account Manager
  • Business Consultant
  • Customer Relationship Manager
  • Management Consultant
  • Portfolio Manager
  • Account Manager
  • Business Architect
  • Management Consultant
  • Strategic Planner
Specialist
  • Agile Business Analyst
  • Business Intelligence Analyst
  • Business Rules Analyst
  • Data Analyst
  • Domain Expert (SME)
  • Process Analyst
  • Product Owner
  • Requirements Engineer/Manager
  • Systems Analyst
  • Business Intelligence Analyst
  • Domain Expert (SME)
  • Functional Business Analyst
  • Process Owner
  • Product Manager
  • Service Owner
  • Systems/Solution Architect
  • Domain Expert (SME)
  • IT Strategist
  • Process Architect
Hybrid
  • BA+PM QA, Development
  • DBA
  • Information Architect
  • Product Manager
  • Project Manager
  • QA Analyst
  • Systems Analyst
  • Usability/UXP
  • Mid-to Senior Management
  • Product Manager
  • Solution Architect
  • Systems Analyst
  • CXO
  • Enterprise Architect

Sources


You-dont-need-IT-knowledge-to-be-BA.jpg


Session 3

Requirements Engineering

Definition of “Requirement”

(Based on IEEE 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology)

  1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective
  2. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.
  3. A documented representation of a condition or capability as in (1) or (2).

Classification

  • Business Requirements
  • Stakeholder Requirements
  • Solution Requirements (Functional / Non-functional)
  • Transition Requirements

Requirements Engineering Good Practices

More than 50 practices, grouped into 7 categories.

Elicitation

Define vision and scope, Identify user classes, Select product champions, Conduct focus groups, Identify user requirements, Identify system events and responses, Hold elicitation interviews, Hold facilitated elicitation workshops, Observe users performing their jobs, Distribute questionnaires, Perform document analysis, Examine problem reports, Reuse existing

Analysis

Model the application environment, Create prototypes, Analyze feasibility, Prioritize requirements, Create a data dictionary, Model the requirements, Analyze interfaces, Allocate requirements to subsystems

Specification Adopt requirement document templates, Identify requirement origins, Uniquely label each requirement, Record business rules, Specify non-functional requirements
Validation Review the requirements, Test the requirements, Define acceptance criteria, Simulate the requirements


Requirements Development Process Framework

Requirements Development Process Framework.PNG


Requirement Management Establish a change control process, Perform change impact analysis, Establish baselines and control versions of requirements sets, Maintain change history, Track requirements status, Track requirements issues, Maintain a requirements traceability matrix, Use a requirements management tool
Knowledge Train business analysts, Educate stakeholders about requirements, Educate developers about application domain, Define a requirements engineering process, Create a glossary


Project Management Select an appropriate life cycle, Plan requirements approach, Estimate requirements effort, Base plans on requirements, Identify requirements decision makers, Renegotiate commitments, Manage requirements risks, Track requirements effort, Review past lessons learned

Sources

Session 4

Elicitation

Definition

  1. to draw forth or bring out (something latent or potential)
  2. to call forth or draw out (as information or a response)

These definitions highlight the need to actively engage the stakeholders in defining requirements.

Frequently used techniques & output

Techniques :

  • Hold elicitation interviews
  • Identify champion product
  • Perform document analysis

Output

  • Requirements [Stated]: Described from the perspective of the stakeholder. Stated requirements describe the stakeholder’s need from the stakeholder’s perspective.
  • Stakeholder Concerns: Includes issues identified by the stakeholder, risks, assumptions, constraints, and other relevant information

Analysis

Definition Requirements analysis involves refining the requirements to ensure that all stakeholders understand them and scrutinizing them for errors, omissions, and other deficiencies.
Frequently used techniques
  • Prioritize the requirements
  • Create a data dictionary
  • Analyze requirement feasibility
Output Requirements [solid]: Prototype (visual form), Document (textual form)

Specification

Definition Requirements specification is to document requirements of different types in a consistent, accessible, and reviewable way that is readily understandable by the intended audiences.
Frequently used techniques
  • Specify non-functional requirements
  • Record business rules
  • Identify requirement origins
output User requirements typically are represented in the form of use cases or user stories.

Validation

Definition Validation ensures that the requirements are correct, demonstrate the desired quality characteristics, and will satisfy customer needs. Requirements that seem fine when you read them might turn out to have ambiguities and gaps when developers try to work with them.
Frequently used techniques
  • Simulate the requirements
  • Define acceptance criteria
output User requirements typically are represented in the form of use cases or user stories, that are understood correctly by Dev team and Stakeholders


Sources

References

Retrieved from "http://wiki.officience.com/index.php?title=Business_Analyst&oldid=802"