Difference between revisions of "Business Analyst"
From Officience
m |
m |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
[[File:Nobody mess with my Best Amigos (BA) !.png]] | [[File:Nobody mess with my Best Amigos (BA) !.png]] | ||
| − | + | ||
| − | Thao Lan NGUYEN | + | |
| + | |||
| + | 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 == | == Session 1 == | ||
| Line 222: | Line 225: | ||
=== Analysis === | === 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 | * Prioritize the requirements | ||
* Create a data dictionary | * Create a data dictionary | ||
* Analyze requirement feasibility | * Analyze requirement feasibility | ||
| − | + | |- | |
| − | '''Output''' | + | | '''Output'''|| Requirements [solid]: Prototype (visual form), Document (textual form) |
| − | + | |} | |
| − | Requirements [solid]: Prototype (visual form), Document (textual form) | ||
=== Specification === | === Specification === | ||
| − | + | {| class="wikitable" style="width: 60%;" | |
| − | + | |- | |
| − | Requirements specification is to document requirements of different types in a consistent, accessible, and reviewable way that is readily understandable by the intended audiences | + | |'''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 | * Specify non-functional requirements | ||
* Record business rules | * Record business rules | ||
* Identify requirement origins | * Identify requirement origins | ||
| − | + | |- | |
| − | ''' | + | | '''output''' || User requirements typically are represented in the form of use cases or user stories. |
| − | + | |} | |
| − | User requirements typically are represented in the form of use cases or user stories. | ||
===Validation=== | ===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. | |
| − | 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 | * Simulate the requirements | ||
* Define acceptance criteria | * 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=== | ===Sources=== | ||
Latest revision as of 02:31, 4 March 2018
_!.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)
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.
To remember :
- BA as a skill
- BA is not only a single person.
Sources
- What is Business Analysis by iiba.org
- BABOKv2.0.pdf
Session 2
What’s my career path in BA?
| Business Focused | IT focused |
|---|---|
|
|
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 |
|
|
|
| Specialist |
|
|
|
| Hybrid |
|
|
|
Sources
Session 3
Requirements Engineering
Definition of “Requirement”
(Based on IEEE 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology)
- A condition or capability needed by a stakeholder to solve a problem or achieve an objective
- 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.
- 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
| 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
- Traditional Methodology Resource Cost Chart
- BABOK v2.0
- Microsoft.Press.Software.Requirements.3.3rd.Edition.Aug.2013.pdf
- 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
| 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 |
|
| 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 |
|
| 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 |
|
| 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
- Traditional Methodology Resource Cost Chart
- BABOK v2.0
- Microsoft.Press.Software.Requirements.3.3rd.Edition.Aug.2013.pdf
- Quick understanding about Waterfall / Iterative / Agile
