Business Analyst
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.
Contents
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
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 & output
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 & output
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
- Traditional Methodology Resource Cost Chart
- BABOK v2.0
- Microsoft.Press.Software.Requirements.3.3rd.Edition.Aug.2013.pdf
- Quick understanding about Waterfall / Iterative / Agile
