Рамки за бизнис-анализа

A. The process manager runs the process day to day, allocates the people and watches its throughput; that is the supervisor in the stem. Operating a process is not the same as being accountable for its design, so this signature is not the one that authorises a redesign.

B. A product manager is accountable for a product's strategy, market fit and roadmap. Loan approval is an internal process, not a product line, so this role has no authority over how the process is designed.

C. The process owner is accountable for the end-to-end design and performance of the process and is the role that approves changes to it. The supervisor's agreement is valuable input, but the redesign is only authorised when the owner signs it off.

D. A product owner orders a product backlog and decides what an adaptive team builds next. The stem is about who can authorise a change to an operating process, which is the process owner's accountability rather than a backlog decision.

A. Finance was affected by the invoicing feature but was never identified, so their needs never entered the requirements. Stakeholder identification and analysis exists precisely to find every group whose needs, influence or acceptance the solution depends on before elicitation begins.

B. Prioritisation orders the requirements that have already been captured. It cannot surface a need from a department that was never consulted, so ranking the sales requirements more carefully would not have added the finance rules.

C. Traceability shows that each captured requirement is covered by design and testing. The finance requirement was never captured, so a complete matrix would still have shown a fully tested feature that was wrong for finance.

D. Prototyping is a strong elicitation and confirmation technique, but a prototype reviewed only with sales would confirm the sales view. The gap was in who was consulted, not in how well their needs were understood.

A. A regulator imposes requirements from outside the organisation and is a classic external stakeholder, however much influence it has over the solution.

B. Co-location and daily contact are tempting cues, but the analyst is employed by a supplier under contract. Where a person sits does not change whose organisation they belong to; a supplier's staff are external stakeholders.

C. End customers are among the most important stakeholders, but they are outside the organisation delivering the solution and are therefore external.

D. The operations manager is employed by the airport authority, the organisation sponsoring and delivering the project. Internal stakeholders are those inside that organisation, regardless of how often the analyst meets them.

A. A status report is the right channel for periodic progress information, but it is one-way and does not support a discussion that must end in a decision. Sending it beforehand may help, yet it does not use the thirty minutes to reach the decision.

B. A decision-focused presentation suits a senior audience with little time: it frames the two options, states the trade-offs and recommendation, and leaves room for the questions the decision makers need answered before they commit. It matches both the audience and the purpose.

C. A workshop is the tool for building consensus or eliciting requirements with many contributors. The options are already analysed and the audience has thirty minutes, so a half-day co-creation session fits neither the purpose nor the time available.

D. A dashboard supports ongoing monitoring by people who track detail over time. Senior decision makers choosing between two funded options need a synthesis and a recommendation, not requirement-level status.

A. Waiting until the review means the team may build for days on an interpretation that the requirement owners never held. The review is for confirming a completed increment, not for discovering that the two groups understood a requirement differently.

B. Nothing has changed yet: the requirement is ambiguous, not altered. Change control comes into play only if clarification reveals that the agreed scope must actually move, and even then after the meaning has been confirmed.

C. The analyst's central communication role is to keep the people who own the need and the people who build the solution working from the same understanding. Clarifying now, at the source, and passing the answer to the team prevents rework and is why the analyst sits between the two groups.

D. Reserving time for rework accepts the misunderstanding rather than removing it. The analyst can eliminate the cause with a short clarification, which is the better use of the moment than planning around the consequence.

A. A user story captures a single need from one role's point of view in a sentence or two. It is deliberately small and does not show a sequence of hand-offs across departments.

B. A process model (a flow diagram with swimlanes) shows the steps, decisions and hand-offs between roles from the start of a process to its end. It is the tool for seeing where work waits, which is exactly what the team wants.

C. A use case describes how an actor interacts with a system to reach a goal, step by step. It centres on one interaction with the solution, not on how work flows between several departments.

D. A prototype makes a proposed solution tangible so stakeholders can react to it. The team is trying to understand the current process, not to try out a future screen or product.

A. Observation shows what people actually do, including the workarounds they would not think to describe. It is the technique for learning how a process really runs today, and a sample of branches makes it feasible within the month.

B. An interview is right for depth with one person, but the sponsor is not the one performing the work and cannot say how forty branches would receive the change. It answers neither of the two questions the analyst has.

C. Brainstorming generates ideas for how something could be done; it does not produce evidence of how nine hundred clerks handle a claim today, and a single head-office group cannot show how forty branches would receive the change.

D. A survey reaches a large, dispersed population quickly and gives a measurable picture of how a proposed change is received. For nine hundred people in forty locations within a month, it is the technique that scales.

E. A focus group gathers the views of a selected group of stakeholders, but the developers neither perform the claims process nor decide whether the approval change is acceptable in the branches. The wrong participants make the technique miss the target.

A. Ranking is the job of prioritisation techniques such as MoSCoW or multivoting. The table in the stem records relationships, not the relative importance of one requirement over another.

B. Those conditions are acceptance criteria, written with the requirement or user story. The linking table may reference the test that checks them, but it does not define them.

C. Effort belongs to estimating and to the schedule or backlog, not to the linking table. Knowing where a requirement came from and what covers it says nothing about how long it takes.

D. That is the requirements traceability matrix: it shows that every requirement has a source and a covering deliverable and test, exposes orphans and gaps, and supports impact analysis when something changes.

A. That is the product backlog: an emergent, ordered inventory of everything that may be built, owned by the product owner, with the items nearest the top refined to a ready state and the rest kept deliberately coarse.

B. A scope baseline belongs to the predictive approach and is changed through change control. The list in the stem is reordered freely as priorities shift, which is the opposite of a baseline.

C. That is the traceability matrix. The backlog may reference acceptance criteria, but its job is to hold and order the work, not to prove coverage between requirements and tests.

D. That is a release plan or product roadmap. The backlog is the ordered pool the releases draw from; it does not itself assign items to dates or releases.

A. A roadmap places themes in broad timeframes, not features on dates. Reading it as a set of date commitments is the most common misuse and the reason product managers stress that it will change.

B. A scope baseline is a controlled, detailed description of what one release contains. The roadmap sits above releases and stays at the level of themes and outcomes.

C. That is what a product roadmap is for: it aligns stakeholders on where the product is heading, why, and roughly when, so that releases and backlog decisions can be judged against a shared intent.

D. A dependency sequence is what a network diagram and the critical path show. The roadmap does not model tasks or their dependencies; it communicates intent at a much higher level.

A. It has clear customer value, but it depends on login, which arrives only in release two. An item cannot ship before the component it depends on, whatever its value.

B. The release goes live before the quarter ends and the banner is a legal obligation from the day after; leaving it out would make the launch non-compliant. It has no dependency on login and is small, so it fits a minimal first release on every criterion: obligation, risk, dependency and size.

C. Sponsor interest is real, but the item serves an internal reporting need with no customer value and no time constraint. It can wait for a later release without cost, which is what a minimal first release requires.

D. Highest desirability is tempting, but an unestimated item cannot be committed to a fixed-date release and is not needed for compliance or for the app to work. It is a strong candidate for release two or three once sized.

A. The analyst elicits and analyses requirements, but ordering the product backlog is the product owner's accountability. Changing the order unilaterally oversteps the role even when the analysis is sound.

B. Escalation is for issues the accountable role cannot resolve. The product owner has not yet seen the analysis, so nothing has been left unresolved; escalating first would bypass the person whose decision it is.

C. Handing the choice to the developers moves a value decision away from the product owner, and detailing both items in full contradicts just-in-time refinement. The developers decide how to build, not which item carries more value.

D. In an adaptive approach the analyst informs the product owner's decisions with evidence and refinement, while the ordering itself stays with the product owner. Sharing the value analysis respects the role and gives the decision maker what they need.

A. In a predictive approach the baseline is protected by change control. The analyst's role is to analyse what the regulator's change touches, across requirements, design, tests and schedule, and to bring that analysis to the change control process for a decision, however certain the outcome seems.

B. This is the informal shortcut: because the change is mandatory, it feels safe to apply it directly. But altering a baselined requirement without change control loses the impact analysis and the approval record that a predictive project depends on.

C. That is the adaptive reflex in a predictive setting. This project has no iteration backlog; it has an approved baseline, and requirements enter or leave it through change control.

D. Implementing first and documenting later bypasses the approval that governs a baseline and leaves the change unassessed. Lessons learned records what the project learned, not what changed in the requirements.

A. "Quickly" and "easy to notice" cannot be tested without someone deciding what they mean. A criterion that two testers could judge differently is not an acceptance criterion yet.

B. It states the condition, the observable result and the point at which it must occur, so a tester can set up the case and see a pass or fail. It is specific, testable and tied directly to the story.

C. This describes an activity of the team, not a property of the product. Acceptance criteria say what the solution must do for the story to be accepted, not what work must be performed.

D. This restates the story at the same level of generality and points to an unstated requirement elsewhere. It adds no condition a tester could check.

A. Finishing the planned work is the team's own completion signal. It shows neither that every requirement is traced to a verified deliverable nor that the stakeholders who own the need have accepted the module against the acceptance criteria.

B. The traceability matrix is the instrument for readiness: when every requirement has a covering deliverable and that deliverable has been verified, nothing has been dropped and nothing is unproven. A gap in the matrix is a gap in the product.

C. Urgency from the sponsor is a constraint on the schedule, not a condition of readiness. Delivering to a date with unmet criteria transfers the problem to the users and to operations.

D. Passing the team's own tests is verification of what the team chose to test. It says nothing about whether every requirement in the traceability matrix is covered, or whether the stakeholders who own the need have validated the result.

E. Validation confirms that the right thing was built, and it belongs to the people whose need the module serves. Their confirmation against the agreed criteria is the second half of readiness alongside a complete, verified traceability matrix.

A. Verification proves the product was built as specified; it is complete here. But acceptance rests on validation, which asks whether the specified product meets the need, and that question has not been put to the people who hold the need.

B. More verification does not answer a validation question. The tests already pass; running them again with other data checks the same thing more thoroughly and still leaves the desk staff unheard.

C. Validation confirms that the solution meets the stakeholders' actual need, and it is done by or with those stakeholders against the agreed criteria. Until the desk staff have done that, the traceability matrix shows a verified product, not an accepted one.

D. The sponsor's signature is the formal act, but signing on test results alone substitutes authority for validation. The sponsor should sign after the owning stakeholders have confirmed the solution against the criteria, not instead of them.