BCS BA Foundation flashcards
BCS BA Foundation · Build recall with a focused review session.
32 cards. Read the term and the definition here. The deck at the top of this page is optional.
- Business analysis definition
- The set of tasks and techniques used to work as a liaison among stakeholders to understand an organization's structure, policies, and operations and recommend solutions that enable it to achieve its goals.
- BABOK knowledge areas
- Six areas: Business Analysis Planning and Monitoring, Elicitation and Collaboration, Requirements Life Cycle Management, Strategy Analysis, Requirements Analysis and Design Definition, and Solution Evaluation.
- Business requirement
- A statement of a high-level organizational goal, objective, or need that the organization wants to satisfy; it explains why a change is being undertaken.
- Stakeholder requirement
- A statement of the needs of a specific stakeholder group that must be met for the solution to be acceptable to that group; it sits between business and solution requirements.
- Non-functional requirement
- A quality attribute or constraint that describes how well a system must perform a function, such as performance, security, availability, usability, or maintainability.
- Transition requirement
- A temporary capability needed to move from the current state to the future state, such as data migration, training, or parallel running; it is no longer needed after transition.
- Solution scope
- The set of capabilities that a proposed solution must deliver to meet the business need; it defines what is inside and outside the change.
- Requirements traceability
- The ability to link a requirement back to its source and forward to design elements, test cases, and delivered components, supporting impact analysis and verification.
- Elicitation techniques
- Methods for drawing out requirements, including interviews, workshops, focus groups, observation, document analysis, surveys, prototyping, and brainstorming.
- MoSCoW prioritization
- A ranking scheme that classifies requirements as Must have, Should have, Could have, or Won't have this time; all Must-haves must be delivered for acceptance.
- Kano model
- A model classifying features as basic (must-be), performance (more is better), or delighter (unexpected); basic features cause dissatisfaction when absent but do not delight when present.
- SWOT analysis
- A technique listing internal Strengths and Weaknesses and external Opportunities and Threats, used to assess an organization's position before choosing a strategy.
- PESTLE analysis
- A technique examining external Political, Economic, Social, Technological, Legal, and Environmental factors that may affect an organization or a proposed change.
- AS-IS and TO-BE models
- Process models that capture the current state (AS-IS) and the desired future state (TO-BE); comparing them identifies the gap the change must close.
- Use case
- A description of a goal-oriented interaction between an actor and a system, including a main success scenario and alternative flows that handle exceptions.
- Decision table
- A tabular technique listing conditions and the actions to take for each combination, used to express complex business rules precisely and to find missing rules.
- Story mapping
- A technique arranging user stories along a user journey and slicing them into releases by horizontal priority, giving a two-dimensional view of scope.
- Business analysis plan
- A document describing which business analysis activities will be performed, the deliverables, their timing, and the stakeholders involved; it is updated as work evolves.
- Power-interest grid
- A stakeholder analysis tool plotting stakeholders by influence (power) and concern (interest); high-power, high-interest stakeholders are managed closely and low-power ones monitored.
- Verification versus validation
- Verification confirms a requirement is well-formed and meets quality standards; validation confirms it is correct, complete, and aligned with real business needs.
- Business case
- A document justifying an investment, typically covering the problem, options analysis, costs, benefits, risks, and a recommended option.
- Requirements baseline
- An agreed, formally approved set of requirements that serves as the reference for change control; later changes are assessed against it.
- Solution evaluation
- The knowledge area that assesses whether a delivered solution delivers expected value, using metrics, benefits reviews, and post-implementation reviews.
- Peer review
- A quality assurance technique in which colleagues examine requirements or models for defects; inspections are the most formal and most effective form.
- Requirements engineering activities
- Four core activities: elicitation, analysis, specification, and validation, supported by ongoing requirements management including change control and traceability.
- Well-formed requirement
- A requirement that is necessary, unambiguous, complete, singular, feasible, verifiable, and traceable to a source, making it usable for design and testing.
- User story format
- A requirement written as 'As a role, I want a goal so that a benefit', with acceptance criteria defining when the story is complete.
- INVEST criteria
- A checklist for good user stories: Independent, Negotiable, Valuable, Estimable, Small, and Testable.
- Traceability matrix
- A table mapping requirements to their sources, design elements, and test cases; forward traceability links requirements to design and backward traceability links design to requirements.
- Prototyping
- A technique using a partial or preliminary implementation to elicit and confirm requirements; throwaway prototypes are discarded, evolutionary prototypes become the product.
- Kotter's eight steps
- A change model: create urgency, form a guiding coalition, create a vision, communicate it, remove obstacles, create short-term wins, build on change, and anchor it in culture.
- ADKAR model
- A model of individual change requiring Awareness, Desire, Knowledge, Ability, and Reinforcement; all five must be present for lasting change.