Business Analysis
BA1. Introduction to Business Analysis
1. What is Business Analysis?
a. Practice of enabling change in an enterprise by defining needs and recommending solutions that
deliver value to stakeholders
b. BACCM: Business Analysis Core Concepts Management
i. Change, Solutions, Context, Value, Stakeholders, Needs
c. BABOK: Business Analysis Body of Knowledge
2. Role of a business Analyst
a. Works as a liaison among stakeholders in order to elicit, analyze, communicate, and validate
requirements for changes to business processes, policies, and information systems
b. Business analysts, IT business analysts, System analysts, …
c. Role of a business analyst = Problem solver, Facilitator, Negotiator, Architect, Planner,
Communicator, Expert, Strategist
3. Competencies of a Business Analyst
a. Main areas of competence: Business knowledge, Analytical thinking, Organization and time
management, Communication and interaction, Tools and techniques
i. External business knowledge: Business acumen, Industry knowledge, Information technology
ii. Internal business knowledge: Business model and strategies, Organizational knowledge
4. BA Planning and Monitoring
Knowledge areas and tasks:
a. Business analysis planning & monitoring
i. Planning parameters: Objective, Needs, Scope, Approach, Activities, Complexity & risk,
Approval
b. Enterprise analysis
c. Elicitation
d. Requirements analysis
e. Requirements management and communications
f. Solutions assessment & validation
5. Stakeholder Engagement
a. A person or group with a relationship to the change or solution
b. Identify -> Attitude -> Expectations -> Contribution -> Communication
c. Stakeholder engagement: Identify, Analyze and Manage stakeholders
d. Who are stakeholders? (Identify)
i. Business analyst, Customers, Domain subject matter expert (SME), End user, Implementation
subject matter expert (SME), Project manager, Tester, Regulator, Sponsor, Supplier
e. Stakeholder analysis (Analyze)
i. Stakeholder matrix based on power of influence of and impact on stakeholder
ii. Onion diagram (most important stakeholders in the core)
iii. RACI matrix: Responsible, Accountable, Consulted, Informed (per deliverable/ activity)
f. Stakeholder management (Manage)
i. Managing stakeholders is about communication: Why, What, When and How ->
communication plan
1
, 6. Conclusion
BA2. Context Analysis
1. Business Strategy
a. The long-term direction of an organization
b. Foundation of success through aligning execution with the
context of the internal & external environment
c. Current state -> strategy execution -> target state
d. SWOT
i. Internal context analysis (SW): VMOST, Resource audit, BSC, Growth share matrix
ii. External context analysis (OT): PESTLE, Porters five forces
2. External Context Analysis
a. PESTLE analysis: Political, Economic, Sociological, Technological, Legal, Environmental. (Add in
an extra E for Ethical)
b. Porter’s Five Forces model: Threat of new entrants, Bargaining power of buyers, Threat of
substitute products, Bargaining power of supplies, Rivalry among existing competitors
c. Blue <-> Red ocean strategy
3. Internal Context Analysis
a. VMOST: Vision, Mission, Objectives, Strategy, Tactics
b. Resource audit: identify strengths and weaknesses per resource type
c. BSC: Balanced scoreboard
d. Boston Box = growth share matrix = BCG matrix
4. Strategy Execution
a. Business Model Canvas (BMC)
i. Customer segments & Value propositions: Customer jobs, Gains, Pains <-> Products &
services, Gain creators, Pain relievers
ii. Channels & Customer Relationships
iii. Key Resources & Key activities
iv. Cost structure and revenue streams
b. Business Capability Model (BCM)
i. Capability = an abstract collection of resources, processes, and technologies that
together in whatever combination, enables an organization to achieve a desired outcome
ii. Only focus on relevant capabilities for the project, unless there is value in having a
capability analysis do not do it
5. Link to Enterprise Architecture
a. Every organization has an EA: represents the core building blocks and demonstrates how it is
organized
b. Business architecture, Application architecture, Data architecture, Infrastructure architecture,
Compliance and security architecture
6. Conclusion
2
, BA3. Requirements Engineering
1. Requirements Definition and Types
a. A requirement is a feature or characteristic that has been
requested by a stakeholder and may form part of a solution
b. Business requirements, Stakeholder requirements,
Solution requirements (Functional requirements and
Non-functional requirements), Transition requirements
2. Requirements Elicitation
a. Qualitative or Quantitative elicitation techniques
3. Requirements Analysis
a. Objective: identify requirements that overlap, are in conflict, are duplicates, need to be separated
b. Categorizing requirements
c. Defining/ accepting requirements
i. Evaluate feasibility (Technical, Business, Financial)
ii. Quality of expression
d. Modelling requirements
e. Prioritizing requirements
i. MoSCoW (Must have, Should have, Could have, Would have)
ii. KANO model (Must-Be, One-Dimensional (Should have), Attractive (Could have), Indifferent,
Reverse)
4. Requirements Validation
a. = Show that the requirements define the system that the customer really wants
b. Formal vs Informal validation
c. Criteria: Validity, Consistency, Completeness, Realism, Verifiability
d. Techniques: Requirements review, Prototyping, Test-case
5. Requirements Documentation
a. Documentation style: Text based or Diagrammatic
b. Project approach: Linear (waterfall) vs Agile (scrum)
c. Requirements catalogue: simple tabular format for defining requirements (typical for linear
projects)
d. User stories: backlog of user stories (typical for agile projects)
6. Requirements Modelling
a. Modelling can be applied to many requirement levels: Business, Stakeholder, Solution, …
b. Diagrammatic models: ideal instruments to provide a picture of the entire solution and confirming
the requirements that are in scope (UML)
i. Business-perspective: UML Use Case Diagrams (Actors, Use case, System boundary,
Associations) (<<include>> and <<extend>>)
ii. Data perspective: UML class diagrams and Entity Relationship Diagrams (ERDs)
iii. Process perspective: BPMN and UML Activity Diagrams
7. Requirements Management
a. Sustainable requirements
b. Volatile requirements
i. Mutable, Emerging, Consequential, Compatibility
3
The benefits of buying summaries with Stuvia:
Guaranteed quality through customer reviews
Stuvia customers have reviewed more than 700,000 summaries. This how you know that you are buying the best documents.
Quick and easy check-out
You can quickly pay through credit card or Stuvia-credit for the summaries. There is no membership needed.
Focus on what matters
Your fellow students write the study notes themselves, which is why the documents are always reliable and up-to-date. This ensures you quickly get to the core!
Frequently asked questions
What do I get when I buy this document?
You get a PDF, available immediately after your purchase. The purchased document is accessible anytime, anywhere and indefinitely through your profile.
Satisfaction guarantee: how does it work?
Our satisfaction guarantee ensures that you always find a study document that suits you well. You fill out a form, and our customer service team takes care of the rest.
Who am I buying these notes from?
Stuvia is a marketplace, so you are not buying this document from us, but from seller HIRb2. Stuvia facilitates payment to the seller.
Will I be stuck with a subscription?
No, you only buy these notes for $10.09. You're not tied to anything after your purchase.
