BCS BA Foundation cheat sheet

Business analysis is the set of tasks and techniques used to work as a liaison among stakeholders to understand structure, policies, and operations of an organization and recommend solutions that enable it to achieve its goals.

The Business Analysis Body of Knowledge (BABOK) defines six knowledge areas: Business Analysis Planning and Monitoring, Elicitation and Collaboration, Requirements Life Cycle Management, Strategy Analysis, Requirements Analysis and Design Definition, Solution Evaluation.

A business analyst's core competencies fall into six groups: analytical thinking and problem solving, behavioural characteristics, business knowledge, communication skills, interaction skills, and tools and technology.

Requirements classification: business requirements state organizational goals; stakeholder requirements state needs of a group; solution requirements split into functional (what the system does) and non-functional (quality attributes such as performance, security, usability); transition requirements cover temporary capabilities needed to move to the solution.

Stakeholders are classified by influence and interest; the RACI matrix assigns Responsible, Accountable, Consulted, and Informed roles to activities.

The requirements life cycle has five stages: elicit, analyse, document, validate, and manage change; traceability links requirements to their source, design, and test cases.

A business analyst may hold the titles of business systems analyst, process analyst, product owner, or requirements engineer; the role is defined by the tasks performed, not the job title.

Solution scope defines which capabilities are in scope for a change; enterprise scope covers the whole organization; a solution may be a system, a process change, or an organizational restructure.

Root cause analysis distinguishes symptoms from underlying causes; techniques include the 5 Whys, fishbone (Ishikawa) diagrams, and cause-and-effect analysis.

Elicitation techniques include interviews, workshops, focus groups, observation (job shadowing), document analysis, surveys, prototyping, and brainstorming; each suits different stakeholder availability and information types.

MoSCoW prioritization ranks requirements as Must have, Should have, Could have, and Won't have (this time); Must-haves must all be delivered for the solution to be acceptable.

The Kano model classifies features as basic (must-be), performance (more is better), and delighter (unexpected); basic features cause dissatisfaction if absent but do not delight when present.

A SWOT analysis lists internal Strengths and Weaknesses and external Opportunities and Threats; it is often paired with PESTLE (Political, Economic, Social, Technological, Legal, Environmental) for external context.

Process modelling uses BPMN, swimlane diagrams, or flowcharts; an AS-IS model captures the current state and a TO-BE model captures the desired future state.

Use case diagrams show actors and their interactions with system functions; a use case describes a goal-oriented interaction with a main success scenario and alternative flows.

The RACI matrix and stakeholder onion diagram (identifying stakeholders by proximity to the solution) are engagement-planning techniques.

Decision tables and decision trees express complex business rules; a decision table lists conditions and actions, and a decision tree shows branching logic graphically.

Story mapping arranges user stories along a user journey and slices releases by horizontal priority, giving a two-dimensional view of scope.

The business analysis plan defines which activities are performed, the deliverables, the timing, and the stakeholders involved; it is a living document updated as the project evolves.

Stakeholder analysis maps power versus interest; high-power, high-interest stakeholders are managed closely, while low-power, low-interest stakeholders are monitored.

Communication planning identifies who needs what information, in what format, and how often; it is part of Business Analysis Planning and Monitoring.

Requirements management includes baselining, change control, version control, and traceability; a change request is assessed for impact on scope, cost, schedule, and risk before approval.

Validation confirms that requirements are correct, complete, and aligned with business needs; verification confirms that a requirement is well-formed and meets quality standards.

Solution evaluation measures whether a delivered solution delivers expected value; it uses metrics such as KPIs, benefits realization reviews, and post-implementation reviews.

A business case justifies investment and typically includes problem statement, options analysis, costs, benefits, risks, and a recommendation.

The requirements document should be unambiguous, complete, consistent, verifiable, and traceable; ambiguity is the most common cause of rework.

Peer reviews, walkthroughs, and inspections are quality assurance techniques for requirements and models; inspections are the most formal and most effective.

Requirements engineering has four core activities: elicitation, analysis, specification, and validation, plus ongoing management.

A well-formed requirement is necessary, unambiguous, complete, singular, feasible, verifiable, and traceable to a source.

Functional requirements describe behaviour; non-functional requirements describe quality attributes and constraints, including performance, availability, security, usability, and maintainability.

User stories follow the form 'As a , I want so that '; acceptance criteria define when the story is done, and INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable) assess story quality.

A traceability matrix maps requirements to sources, design elements, and test cases; forward traceability goes from requirement to design, backward traceability from design to requirement.

Prioritization techniques include MoSCoW, ranking, and time-boxing; a requirement's priority may change as business value and risk are reassessed.

A prototype is a partial or preliminary implementation used to elicit requirements; throwaway prototypes are discarded, while evolutionary prototypes become the product.

Requirements can be documented in a requirements specification, a backlog, a model, or a combination; the chosen format depends on the methodology and audience.

Elicitation is not the same as gathering: stakeholders often cannot articulate needs, so the analyst must probe, observe, and confirm assumptions.

Business change management covers the people side of change: communication, training, resistance management, and adoption, complementing the technical solution.

Kotter's eight-step model: create urgency, form a guiding coalition, create a vision, communicate the vision, remove obstacles, create short-term wins, build on the change, and anchor changes in culture.

The change curve (Kubler-Ross adaptation) describes stages of denial, resistance, exploration, and commitment; stakeholders move through these at different rates.

Stakeholder engagement levels include inform, consult, involve, collaborate, and empower; the appropriate level depends on impact and influence.

Resistance to change is often caused by fear of loss, lack of understanding, or low trust; addressing the cause is more effective than suppressing the symptom.

The ADKAR model describes individual change as Awareness, Desire, Knowledge, Ability, and Reinforcement; all five must be present for lasting change.

Benefits realization management tracks planned benefits against actual outcomes; benefits may accrue after the project closes, so ownership must be assigned.

Communication plans for change should specify audience, message, channel, timing, and feedback mechanism; face-to-face channels suit complex or sensitive messages.

A stakeholder map should be reviewed regularly because influence, interest, and attitudes shift as the change progresses.