Scenario practice questions

A project manager is initiating a project to develop a new mobile application. The business environment is highly uncertain, and requirements are expected to evolve frequently. Which business analysis framework is most appropriate for this scenario?

Trap 1: Waterfall

Waterfall fixes scope, schedule and cost baselines before build begins, so late requirement changes force formal change requests and rework of completed phases. It suits stable, well-understood deliverables such as regulatory or construction projects. Here, evolving requirements demand iterative delivery, which Waterfall's sequential gating cannot accommodate.

Trap 2: PRINCE2

PRINCE2 governs delivery through defined stages, tolerances and a product-based plan, so it assumes requirements can be baselined at stage boundaries — the opposite of continuously evolving scope. It is tempting because PRINCE2 excels at controlled, governance-heavy projects with stable, pre-agreed outputs, where its stage-gate structure genuinely adds value.

Trap 3: Six Sigma

Six Sigma reduces process variation through DMAIC and statistical control, which assumes stable, measurable processes rather than emergent requirements. It suits manufacturing or service delivery seeking defect reduction. Here, evolving mobile-app requirements demand iterative elicitation and adaptive scope, which Six Sigma's define-measure-analyse-improve-control cycle does not accommodate.

A
Waterfall
Why it fails: Waterfall fixes scope, schedule and cost baselines before build begins, so late requirement changes force formal change requests and rework of completed phases. It suits stable, well-understood deliverables such as regulatory or construction projects. Here, evolving requirements demand iterative delivery, which Waterfall's sequential gating cannot accommodate.
B
PRINCE2
Why it fails: PRINCE2 governs delivery through defined stages, tolerances and a product-based plan, so it assumes requirements can be baselined at stage boundaries — the opposite of continuously evolving scope. It is tempting because PRINCE2 excels at controlled, governance-heavy projects with stable, pre-agreed outputs, where its stage-gate structure genuinely adds value.
C
Six Sigma
Why it fails: Six Sigma reduces process variation through DMAIC and statistical control, which assumes stable, measurable processes rather than emergent requirements. It suits manufacturing or service delivery seeking defect reduction. Here, evolving mobile-app requirements demand iterative elicitation and adaptive scope, which Six Sigma's define-measure-analyse-improve-control cycle does not accommodate.
D
Agile (Scrum)
Agile (Scrum) suits volatile requirements through iterative sprints, delivering working increments every two to four weeks so feedback reshapes the backlog continuously. This directly satisfies the stem's highly uncertain environment and frequently evolving requirements, which predictive frameworks cannot accommodate without costly change control.

Question 2easymultiple choice

A business analyst needs to gather input from a large number of geographically dispersed stakeholders about their preferences for a new system. The project has a limited budget and timeline. Which elicitation technique is most efficient in this scenario?

Trap 1: Focus groups

Focus groups require participants to convene simultaneously, which is impractical for geographically dispersed stakeholders and costly to arrange within a tight budget. They suit exploring shared views among a small, co-located group, not collecting input from a large remote population.

Trap 2: One-on-one interviews

Interviews consume substantial time per participant and require scheduling across time zones, which strains a limited budget and timeline with many dispersed stakeholders. They suit deep, individual insight from a few key people, not broad preference gathering at scale.

Trap 3: Observation

Observation reveals actual behaviour rather than stated preferences, and it demands the analyst travel to each site, consuming budget and time. It suits uncovering undocumented workflow steps, not efficiently surveying many dispersed stakeholders about system preferences.

A
Focus groups
Why it fails: Focus groups require participants to convene simultaneously, which is impractical for geographically dispersed stakeholders and costly to arrange within a tight budget. They suit exploring shared views among a small, co-located group, not collecting input from a large remote population.
B
One-on-one interviews
Why it fails: Interviews consume substantial time per participant and require scheduling across time zones, which strains a limited budget and timeline with many dispersed stakeholders. They suit deep, individual insight from a few key people, not broad preference gathering at scale.
C
Survey / Questionnaire
Surveys reach many dispersed stakeholders simultaneously at minimal cost, satisfying the limited budget and timeline constraint. Responses are collected asynchronously, avoiding travel and scheduling overhead that workshops, interviews or focus groups would impose across multiple locations.
D
Observation
Why it fails: Observation reveals actual behaviour rather than stated preferences, and it demands the analyst travel to each site, consuming budget and time. It suits uncovering undocumented workflow steps, not efficiently surveying many dispersed stakeholders about system preferences.

Question 3mediummultiple choice

A business analyst is facilitating a requirements workshop for a new customer relationship management (CRM) system. Participants include sales representatives, customer service managers, and IT support staff. The BA needs to ensure that all perspectives are captured and that the group reaches a shared understanding of the requirements. Which technique is most appropriate for this purpose?

Trap 1: Observation

Observation involves watching users perform their tasks in their work environment to understand actual processes and identify implicit requirements. It is valuable for uncovering details that stakeholders may not articulate, but it does not actively engage multiple stakeholders in a collaborative discussion. In this scenario, the BA needs to reconcile diverse perspectives and build agreement, which observation alone cannot accomplish. Observation is typically a complementary technique, not the primary one for consensus building.

Trap 2: Brainstorming

Brainstorming is a group creativity technique used to generate a large number of ideas or options, often in a short time. While it can surface diverse thoughts, it does not inherently build shared understanding or resolve conflicting viewpoints among participants. In this scenario, the BA needs structured collaboration to align stakeholders on requirements, not just idea generation. Brainstorming lacks the facilitation structure to ensure all perspectives are heard and reconciled.

Trap 3: Focus groups

Focus groups gather a small group of pre-qualified participants to discuss a specific topic, often to gauge reactions or preferences. They are useful for eliciting qualitative feedback, but they are not designed to produce a consolidated set of requirements or drive consensus. Here, the BA needs to integrate input from multiple roles into a coherent set of requirements, which focus groups do not typically achieve. Focus groups are more exploratory than consensus-building.

A
Observation
Why it fails: Observation involves watching users perform their tasks in their work environment to understand actual processes and identify implicit requirements. It is valuable for uncovering details that stakeholders may not articulate, but it does not actively engage multiple stakeholders in a collaborative discussion. In this scenario, the BA needs to reconcile diverse perspectives and build agreement, which observation alone cannot accomplish. Observation is typically a complementary technique, not the primary one for consensus building.
B
Facilitated workshops
Facilitated workshops bring key stakeholders together in a structured session led by a neutral facilitator to define requirements collaboratively. They are specifically designed to build shared understanding, resolve conflicts, and produce a agreed-upon set of requirements. In this scenario, with diverse participants, a facilitated workshop enables cross-functional input and real-time validation, making it the most appropriate technique for capturing all perspectives and reaching consensus.
C
Brainstorming
Why it fails: Brainstorming is a group creativity technique used to generate a large number of ideas or options, often in a short time. While it can surface diverse thoughts, it does not inherently build shared understanding or resolve conflicting viewpoints among participants. In this scenario, the BA needs structured collaboration to align stakeholders on requirements, not just idea generation. Brainstorming lacks the facilitation structure to ensure all perspectives are heard and reconciled.
D
Focus groups
Why it fails: Focus groups gather a small group of pre-qualified participants to discuss a specific topic, often to gauge reactions or preferences. They are useful for eliciting qualitative feedback, but they are not designed to produce a consolidated set of requirements or drive consensus. Here, the BA needs to integrate input from multiple roles into a coherent set of requirements, which focus groups do not typically achieve. Focus groups are more exploratory than consensus-building.

Question 4mediummultiple choice

A business analyst at a hospital is facilitating a requirements workshop with physicians, nurses, and IT staff. The goal is to define the data elements required for a new patient intake system. The physicians and nurses have conflicting opinions about which data is essential, and the IT staff is concerned about integration with existing systems. Which technique would be most effective to build consensus and clearly document the data requirements?

Trap 1: Document analysis

Document analysis reviews existing materials to extract requirements. It might identify data elements from previous forms or system specs, but it does not engage stakeholders in discussion or help resolve their disagreements. In this scenario, the conflict among physicians, nurses, and IT staff requires interactive techniques, not static document review.

Trap 2: Brainstorming

Brainstorming generates a large number of ideas in a short time, but it does not inherently resolve conflicts or drive consensus. While it could produce a list of potential data elements, the differing opinions would remain unaddressed. A more structured facilitation approach is needed to reconcile views and produce agreed-upon requirements.

Trap 3: Observation

Observation involves watching users perform their tasks to understand their needs. While it can reveal data elements used in practice, it does not actively resolve conflicts between stakeholder groups or facilitate agreement on a single set of requirements. Here, the primary challenge is conflicting opinions, not a lack of understanding of current work, so observation alone would not achieve consensus.

A
Document analysis
Why it fails: Document analysis reviews existing materials to extract requirements. It might identify data elements from previous forms or system specs, but it does not engage stakeholders in discussion or help resolve their disagreements. In this scenario, the conflict among physicians, nurses, and IT staff requires interactive techniques, not static document review.
B
Facilitated workshops
Facilitated workshops bring cross-functional stakeholders together in a structured session to define requirements collaboratively. In this scenario, the BA can guide physicians, nurses, and IT staff to discuss and resolve conflicting opinions, ensuring all perspectives are heard. This technique is specifically designed to build consensus and produce documented requirements, making it ideal for the conflicting stakeholder views described.
C
Brainstorming
Why it fails: Brainstorming generates a large number of ideas in a short time, but it does not inherently resolve conflicts or drive consensus. While it could produce a list of potential data elements, the differing opinions would remain unaddressed. A more structured facilitation approach is needed to reconcile views and produce agreed-upon requirements.
D
Observation
Why it fails: Observation involves watching users perform their tasks to understand their needs. While it can reveal data elements used in practice, it does not actively resolve conflicts between stakeholder groups or facilitate agreement on a single set of requirements. Here, the primary challenge is conflicting opinions, not a lack of understanding of current work, so observation alone would not achieve consensus.

Question 5mediummultiple choice

A business analyst is assessing the feasibility of a proposed new online ordering system for a restaurant chain. The BA needs to evaluate whether the system can be developed with the available technology and skills within the organization. Which type of feasibility is the BA primarily assessing?

Trap 1: Operational feasibility

Operational feasibility assesses how well the proposed system will solve business problems and fit into the organization's operations. It focuses on user acceptance, process fit, and organizational readiness. The scenario's emphasis on technology and skills points to technical feasibility rather than operational feasibility, which is more about the people and processes.

Trap 2: Legal feasibility

Legal feasibility examines whether the proposed system complies with laws and regulations, such as data privacy, licensing, and industry-specific rules. The scenario does not mention legal constraints; it focuses on technology and skills. Therefore, legal feasibility is not the primary concern here, although it would be a separate area to assess if relevant regulations exist.

Trap 3: Economic feasibility

Economic feasibility focuses on cost-benefit analysis, return on investment, and financial viability. While cost is important, the scenario specifically mentions technology and skills, which are related to technical feasibility. Economic feasibility would address whether the project is financially worthwhile, not whether it is technically achievable with current resources.

A
Operational feasibility
Why it fails: Operational feasibility assesses how well the proposed system will solve business problems and fit into the organization's operations. It focuses on user acceptance, process fit, and organizational readiness. The scenario's emphasis on technology and skills points to technical feasibility rather than operational feasibility, which is more about the people and processes.
B
Legal feasibility
Why it fails: Legal feasibility examines whether the proposed system complies with laws and regulations, such as data privacy, licensing, and industry-specific rules. The scenario does not mention legal constraints; it focuses on technology and skills. Therefore, legal feasibility is not the primary concern here, although it would be a separate area to assess if relevant regulations exist.
C
Technical feasibility
Technical feasibility evaluates whether the organization has the technical resources, expertise, and infrastructure to build and maintain the proposed system. The scenario explicitly asks about evaluating technology and skills, which are core aspects of technical feasibility. The BA is assessing if the online ordering system can be developed with current capabilities, making technical feasibility the correct focus.
D
Economic feasibility
Why it fails: Economic feasibility focuses on cost-benefit analysis, return on investment, and financial viability. While cost is important, the scenario specifically mentions technology and skills, which are related to technical feasibility. Economic feasibility would address whether the project is financially worthwhile, not whether it is technically achievable with current resources.

Question 6easymultiple choice

A business analyst is creating a data model for a new human resources system. The BA needs to represent the relationships between employees, departments, and job positions. Which type of diagram is most appropriate for this purpose?

Trap 1: Use case diagram

Use case diagrams model interactions between actors and a system, focusing on functional behavior rather than data structure. They are useful for capturing system requirements from a user perspective but do not represent data entities or their relationships. For modeling how employees, departments, and positions relate in terms of data, a use case diagram is not appropriate.

Trap 2: Gantt chart

Gantt charts are project scheduling tools that display tasks over time, dependencies, and milestones. They are not used for data modeling. The scenario requires representing relationships between data entities, which is outside the scope of a Gantt chart. Using a Gantt chart here would not address the BA's need to define data structures.

Trap 3: Swimlane diagram

Swimlane diagrams are used to illustrate business processes, showing the sequence of activities and the roles responsible for each step. They are process-oriented, not data-oriented. While they can show how data flows through a process, they do not model the static relationships between data entities such as employees, departments, and job positions.

A
Use case diagram
Why it fails: Use case diagrams model interactions between actors and a system, focusing on functional behavior rather than data structure. They are useful for capturing system requirements from a user perspective but do not represent data entities or their relationships. For modeling how employees, departments, and positions relate in terms of data, a use case diagram is not appropriate.
B
Gantt chart
Why it fails: Gantt charts are project scheduling tools that display tasks over time, dependencies, and milestones. They are not used for data modeling. The scenario requires representing relationships between data entities, which is outside the scope of a Gantt chart. Using a Gantt chart here would not address the BA's need to define data structures.
C
Swimlane diagram
Why it fails: Swimlane diagrams are used to illustrate business processes, showing the sequence of activities and the roles responsible for each step. They are process-oriented, not data-oriented. While they can show how data flows through a process, they do not model the static relationships between data entities such as employees, departments, and job positions.
D
Entity-relationship diagram (ERD)
An entity-relationship diagram (ERD) is specifically designed to model data entities and their relationships. Entities such as Employee, Department, and Job Position can be represented with attributes and connected via relationships (e.g., an employee belongs to a department, holds a job position). ERDs are the standard tool for data modeling in business analysis, making them ideal for this scenario.

Question 7mediummultiple choice

A project manager is leading a requirements workshop for a new software system. The business analyst suggests using a technique that involves creating a visual representation of the sequence of steps in a business process. Which technique is being suggested?

Trap 1: Use case diagram

A use case diagram models actors and their goals against system boundaries, not the ordered sequence of process steps. It is tempting because it visualises requirements scope and interactions, and would be correct when capturing who uses the system and what functionality each actor needs, rather than process flow.

Trap 2: Mind map

A mind map radiates hierarchical ideas from a central topic, capturing associations rather than ordered process steps. It is tempting because it is a visual requirements-elicitation aid, and would be correct for brainstorming and organising themes during a workshop, not for depicting sequential business process flow.

Trap 3: Data flow diagram

A data flow diagram tracks data movement between processes, stores and external entities, not the chronological sequence of process steps. It is tempting because it is a visual process-related model, and would be correct when mapping how data enters, transforms and leaves a system.

A
Use case diagram
Why it fails: A use case diagram models actors and their goals against system boundaries, not the ordered sequence of process steps. It is tempting because it visualises requirements scope and interactions, and would be correct when capturing who uses the system and what functionality each actor needs, rather than process flow.
B
Mind map
Why it fails: A mind map radiates hierarchical ideas from a central topic, capturing associations rather than ordered process steps. It is tempting because it is a visual requirements-elicitation aid, and would be correct for brainstorming and organising themes during a workshop, not for depicting sequential business process flow.
C
Flow chart
A flow chart maps a process as ordered steps connected by directional arrows, including decision branches, giving the visual sequence the business analyst described. That step-by-step diagrammatic representation is exactly the technique the stem specifies, unlike textual or matrix-based elicitation methods.
D
Data flow diagram
Why it fails: A data flow diagram tracks data movement between processes, stores and external entities, not the chronological sequence of process steps. It is tempting because it is a visual process-related model, and would be correct when mapping how data enters, transforms and leaves a system.

Question 8hardmultiple choice

A software development team is transitioning from a plan-driven approach to Scrum. The Product Owner is enthusiastic but struggles to break down the product backlog into small, independent items. The team frequently encounters dependencies between user stories, causing delays in sprints. What is the best course of action for the Scrum Master to address this issue?

Trap 1: Have the team self-organize to handle dependencies by assigning a…

Assigning a dependency owner imposes a command-and-control role, contradicting Scrum's self-organisation principle and leaving the underlying backlog structure unchanged. It appeals because visible ownership feels tidy, and it would suit a plan-driven environment where a coordinator manages cross-team interfaces.

Trap 2: Increase the sprint duration to allow more time to resolve…

Lengthening sprints preserves the dependent stories and merely stretches the feedback loop, so delays persist and empiricism weakens. It is tempting because extra time appears to absorb the coordination overhead, but the Scrum Master should instead coach the Product Owner to slice backlog items into small, independent, vertically deliverable stories.

Trap 3: Ask developers to manage dependencies during the sprint by…

Pushing dependency coordination onto developers during the sprint leaves the backlog structure unchanged, so the delays recur each sprint. It is tempting because self-managing teams do coordinate, but the Scrum Master should coach the Product Owner to split stories along vertical, independently deliverable slices, removing dependencies at refinement.

A
Coach the Product Owner on how to split user stories to minimize dependencies.
Coaching the Product Owner to split stories along dependency-free seams directly addresses the backlog refinement constraint. Vertical slicing by user value, rather than technical layer, yields independently deliverable items, removing cross-story coupling that stalls sprints. The Scrum Master owns this coaching duty, so the fix targets the root cause rather than scheduling workarounds.
B
Have the team self-organize to handle dependencies by assigning a dependency owner.
Why it fails: Assigning a dependency owner imposes a command-and-control role, contradicting Scrum's self-organisation principle and leaving the underlying backlog structure unchanged. It appeals because visible ownership feels tidy, and it would suit a plan-driven environment where a coordinator manages cross-team interfaces.
C
Increase the sprint duration to allow more time to resolve dependencies.
Why it fails: Lengthening sprints preserves the dependent stories and merely stretches the feedback loop, so delays persist and empiricism weakens. It is tempting because extra time appears to absorb the coordination overhead, but the Scrum Master should instead coach the Product Owner to slice backlog items into small, independent, vertically deliverable stories.
D
Ask developers to manage dependencies during the sprint by coordinating with other teams.
Why it fails: Pushing dependency coordination onto developers during the sprint leaves the backlog structure unchanged, so the delays recur each sprint. It is tempting because self-managing teams do coordinate, but the Scrum Master should coach the Product Owner to split stories along vertical, independently deliverable slices, removing dependencies at refinement.

Question 9mediummultiple choice

In a requirements prioritization session, the team uses MoSCoW. A feature that is important but not critical, and could be postponed without major impact, should be classified as:

Trap 1: Could have

MoSCoW reserves Could have for desirable but optional items, not those deemed important; the stem's wording matches Should have, which sits between Must and Could. Could have would be correct for a genuinely marginal nice-to-have with minimal consequence if dropped entirely.

Trap 2: Must have

Must have denotes non-negotiable requirements whose absence makes the release unusable; the stem explicitly says the feature is not critical and can be postponed. Must have would be right for a legal or safety requirement that blocks go-live.

Trap 3: Won't have

Won't have means the feature is agreed out of scope for this release, not merely deferrable; the stem describes something important that could slip, which is Should have. Won't have suits items consciously excluded after negotiation, often parked for a later increment.

A
Should have
MoSCoW's Should-have category covers requirements that are important and valuable but not vital; they can be deferred to a later release without breaking core functionality. This satisfies the stem's constraint of a feature that is postponable without major impact, unlike Must-have items.
B
Could have
Why it fails: MoSCoW reserves Could have for desirable but optional items, not those deemed important; the stem's wording matches Should have, which sits between Must and Could. Could have would be correct for a genuinely marginal nice-to-have with minimal consequence if dropped entirely.
C
Must have
Why it fails: Must have denotes non-negotiable requirements whose absence makes the release unusable; the stem explicitly says the feature is not critical and can be postponed. Must have would be right for a legal or safety requirement that blocks go-live.
D
Won't have
Why it fails: Won't have means the feature is agreed out of scope for this release, not merely deferrable; the stem describes something important that could slip, which is Should have. Won't have suits items consciously excluded after negotiation, often parked for a later increment.

Question 10hardmultiple choice

In a requirements gathering workshop, two stakeholders have differing opinions on the system interface design. The business analyst decides to use a technique that involves listing pros and cons of each option. Which technique is being used?

Trap 1: Prototyping

Prototyping builds a preliminary working model of a solution so stakeholders can react to something tangible; it produces no pros-and-cons comparison of competing options. It is tempting because prototyping resolves interface disagreements, but it does so through demonstration rather than written evaluation.

Trap 2: Interface Analysis

Interface Analysis examines the characteristics, inputs and outputs of interfaces between systems or components; it does not weigh competing design options by listing pros and cons. It is tempting because the scenario concerns interface design, but the described activity is option comparison, not interface specification.

Trap 3: Brainstorming

Brainstorming generates a broad set of creative ideas from participants without evaluating or ranking them; listing pros and cons is structured evaluation, not divergent idea generation. It is tempting because workshops often begin with brainstorming, but the technique described requires comparing two defined alternatives.

A
Prototyping
Why it fails: Prototyping builds a preliminary working model of a solution so stakeholders can react to something tangible; it produces no pros-and-cons comparison of competing options. It is tempting because prototyping resolves interface disagreements, but it does so through demonstration rather than written evaluation.
B
Decision Analysis
Decision Analysis compares alternatives by weighing their advantages and disadvantages against defined criteria, producing a reasoned recommendation. This satisfies the stem's requirement because listing pros and cons of each interface design option is the defining activity of that technique.
C
Interface Analysis
Why it fails: Interface Analysis examines the characteristics, inputs and outputs of interfaces between systems or components; it does not weigh competing design options by listing pros and cons. It is tempting because the scenario concerns interface design, but the described activity is option comparison, not interface specification.
D
Brainstorming
Why it fails: Brainstorming generates a broad set of creative ideas from participants without evaluating or ranking them; listing pros and cons is structured evaluation, not divergent idea generation. It is tempting because workshops often begin with brainstorming, but the technique described requires comparing two defined alternatives.

Question 11mediummulti select

A BA is prioritizing a large number of requirements. Which TWO techniques are best suited for this scenario?

Trap 1: Benchmarking

Benchmarking compares organisational practises against peer or industry standards, producing gap data rather than a ranked order of requirements. It is tempting because the comparison feels like evaluation, yet prioritisation needs techniques such as MoSCoW, weighted ranking or voting that assign relative value across the requirement list.

Trap 2: Focus group

A focus group gathers qualitative opinions from selected stakeholders, yielding discussion rather than a ranked requirement order. It is tempting because stakeholder input informs priority, but with a large requirement set you need techniques such as MoSCoW, weighted ranking or voting that produce comparative rankings across every item.

Trap 3: Observation

Observation watches users performing tasks to uncover tacit requirements, generating new information rather than ranking existing ones. It is tempting because it reveals real behaviour, but prioritising a large requirement set needs techniques such as MoSCoW, weighted ranking or voting that assign relative value across the list.

A
Benchmarking
Why it fails: Benchmarking compares organisational practises against peer or industry standards, producing gap data rather than a ranked order of requirements. It is tempting because the comparison feels like evaluation, yet prioritisation needs techniques such as MoSCoW, weighted ranking or voting that assign relative value across the requirement list.
B
Focus group
Why it fails: A focus group gathers qualitative opinions from selected stakeholders, yielding discussion rather than a ranked requirement order. It is tempting because stakeholder input informs priority, but with a large requirement set you need techniques such as MoSCoW, weighted ranking or voting that produce comparative rankings across every item.
C
Kano model
The Kano model classifies requirements by how their presence affects satisfaction: basic, performance, delighter, indifferent and reverse. With a large backlog, it identifies which requirements genuinely drive customer satisfaction, letting the BA prioritise by value impact rather than by stakeholder volume alone.
D
MoSCoW analysis
MoSCoW analysis sorts each requirement into Must, Should, Could or Won't have, forcing explicit agreement on what the current delivery must include. This directly handles the stem's large requirement volume by ranking items into four decisive priority bands, so stakeholders can defer lower-value work without losing it.
E
Observation
Why it fails: Observation watches users performing tasks to uncover tacit requirements, generating new information rather than ranking existing ones. It is tempting because it reveals real behaviour, but prioritising a large requirement set needs techniques such as MoSCoW, weighted ranking or voting that assign relative value across the list.

Question 12easymultiple choice

A business analyst is working on a project to replace a legacy customer relationship management (CRM) system. The project manager asks the BA to ensure that all requirements are aligned with the organization's strategic goals. Which of the following best describes the purpose of tracing requirements to business objectives?

Trap 1: To estimate the cost and effort required to implement each…

Cost and effort estimation is part of project planning and budgeting, not the purpose of tracing requirements to business objectives. While traceability can provide context for estimates, its main goal is to ensure alignment with strategic goals. The scenario emphasizes alignment, so this option is not the best answer.

Trap 2: To document the technical specifications for how each requirement…

Technical specifications describe the design and implementation details, which are separate from business objectives. Tracing requirements to objectives is about ensuring business value, not documenting how to build them. In this CRM replacement project, the BA needs to align requirements with strategic goals, not create technical designs.

Trap 3: To assign each requirement to a specific project team member for…

Assigning requirements to team members is part of resource planning and task allocation, not requirements tracing to business objectives. While traceability can help with impact analysis, its primary purpose is not to assign work. The scenario focuses on alignment with strategic goals, so this option misinterprets the intent of tracing.

A
To estimate the cost and effort required to implement each requirement
Why it fails: Cost and effort estimation is part of project planning and budgeting, not the purpose of tracing requirements to business objectives. While traceability can provide context for estimates, its main goal is to ensure alignment with strategic goals. The scenario emphasizes alignment, so this option is not the best answer.
B
To document the technical specifications for how each requirement will be built
Why it fails: Technical specifications describe the design and implementation details, which are separate from business objectives. Tracing requirements to objectives is about ensuring business value, not documenting how to build them. In this CRM replacement project, the BA needs to align requirements with strategic goals, not create technical designs.
C
To assign each requirement to a specific project team member for implementation
Why it fails: Assigning requirements to team members is part of resource planning and task allocation, not requirements tracing to business objectives. While traceability can help with impact analysis, its primary purpose is not to assign work. The scenario focuses on alignment with strategic goals, so this option misinterprets the intent of tracing.
D
To validate that each requirement delivers value and supports the business case
Tracing requirements to business objectives ensures that every requirement contributes to the strategic goals and the business case. This alignment helps prioritize requirements and prevents scope creep by identifying requirements that do not add value. In this scenario, the BA can use tracing to confirm that CRM requirements support the organization's goals, such as improving customer retention or increasing sales.

Question 13hardmultiple choice

A business analyst is assessing the feasibility of a proposed solution that involves integrating a new mobile app with an existing legacy system. The legacy system has no documented APIs and uses a proprietary protocol. Which factor is most critical to evaluate when determining technical feasibility?

Trap 1: The cost of licensing the mobile app development platform

Licensing cost is a financial consideration, not a technical one. While budget is important, the question asks for technical feasibility, which focuses on whether the solution can be built with current technology and skills. Cost does not determine technical viability.

Trap 2: The project timeline as defined in the charter

The project timeline is a schedule constraint, not a measure of technical feasibility. While timeline pressure can affect decisions, it does not determine whether the integration is technically possible. Technical feasibility is about capability, not schedule.

Trap 3: The user interface design preferences of the marketing department

User interface design is a usability and aesthetic concern, not a technical feasibility factor. The marketing department's preferences may influence requirements, but they do not affect whether the legacy system can be integrated with the mobile app.

A
The availability of skilled developers who know the proprietary protocol
Technical feasibility hinges on whether the integration can be built with available resources and expertise. If the proprietary protocol is obscure and no developers have the necessary skills, the project may be delayed or fail. Assessing skill availability is therefore a critical first step in evaluating technical feasibility.
B
The cost of licensing the mobile app development platform
Why it fails: Licensing cost is a financial consideration, not a technical one. While budget is important, the question asks for technical feasibility, which focuses on whether the solution can be built with current technology and skills. Cost does not determine technical viability.
C
The project timeline as defined in the charter
Why it fails: The project timeline is a schedule constraint, not a measure of technical feasibility. While timeline pressure can affect decisions, it does not determine whether the integration is technically possible. Technical feasibility is about capability, not schedule.
D
The user interface design preferences of the marketing department
Why it fails: User interface design is a usability and aesthetic concern, not a technical feasibility factor. The marketing department's preferences may influence requirements, but they do not affect whether the legacy system can be integrated with the mobile app.

Question 14hardmultiple choice

A project manager is executing a predictive project to build a data center. The project is halfway complete, and the project manager is analyzing cost performance. The earned value (EV) is $500,000, the planned value (PV) is $600,000, and the actual cost (AC) is $550,000. The project manager needs to forecast the total cost at completion, assuming the current cost performance will continue. Which earned value management (EVM) metric should the project manager use to determine the estimate at completion (EAC)?

Trap 1: EAC = AC + ETC

This formula requires an independent estimate to complete (ETC) based on a new bottom-up estimate. The scenario does not mention that a new estimate has been prepared; it assumes the current cost performance will continue. Therefore, using AC plus a manually derived ETC is not appropriate here; the project manager should use the CPI-based formula.

Trap 2: EAC = AC + (BAC - EV) / (CPI * SPI)

This formula considers both cost and schedule performance and is used when the project manager wants to account for both cost and schedule constraints. However, the scenario only mentions that current cost performance will continue; it does not indicate that schedule performance should also be factored in. Therefore, this formula is not the best fit.

Trap 3: EAC = AC + (BAC - EV)

This formula assumes that the remaining work will be completed at the planned rate, regardless of current cost performance. It is used when the current variances are considered atypical and not expected to continue. In this scenario, the project manager assumes the current cost performance will continue, so this formula is not appropriate.

A
EAC = AC + ETC
Why it fails: This formula requires an independent estimate to complete (ETC) based on a new bottom-up estimate. The scenario does not mention that a new estimate has been prepared; it assumes the current cost performance will continue. Therefore, using AC plus a manually derived ETC is not appropriate here; the project manager should use the CPI-based formula.
B
EAC = BAC / CPI
When the current cost performance is expected to continue, the estimate at completion (EAC) is calculated as budget at completion (BAC) divided by cost performance index (CPI). This is the most common EAC formula used when no other assumptions are made. It uses the CPI to project the remaining work at the same cost efficiency. This directly addresses the scenario's requirement.
C
EAC = AC + (BAC - EV) / (CPI * SPI)
Why it fails: This formula considers both cost and schedule performance and is used when the project manager wants to account for both cost and schedule constraints. However, the scenario only mentions that current cost performance will continue; it does not indicate that schedule performance should also be factored in. Therefore, this formula is not the best fit.
D
EAC = AC + (BAC - EV)
Why it fails: This formula assumes that the remaining work will be completed at the planned rate, regardless of current cost performance. It is used when the current variances are considered atypical and not expected to continue. In this scenario, the project manager assumes the current cost performance will continue, so this formula is not appropriate.

Question 15hardmultiple choice

A project manager is using a predictive approach for an aircraft component project. The team has identified a risk that a critical supplier may fail to deliver a specialized alloy on time. The project manager wants to reduce the probability and impact of this risk by taking action before it occurs. Which risk response strategy should the project manager use?

Trap 1: Avoid

Avoidance eliminates the threat entirely by changing the project plan, such as removing the risky activity or using a different supplier altogether. While that could work, the question specifies reducing probability and impact, not eliminating the risk. Avoidance is a more drastic step and does not match the described intent of lessening the risk's likelihood or consequences.

Trap 2: Transfer

Transfer shifts the impact of the threat to a third party, often through insurance or a fixed-price contract. It does not reduce the probability of the risk occurring, and the scenario asks for reducing both probability and impact. Transfer is a valid strategy for some risks, but it does not fit the described goal of proactive reduction before the risk happens.

Trap 3: Accept

Acceptance acknowledges the risk and does not take proactive action unless the risk occurs. It can be active or passive, but it does not reduce probability or impact. Since the project manager wants to take action before the risk occurs to lessen it, acceptance is not appropriate here. It would leave the project exposed to the supplier's potential failure.

A
Avoid
Why it fails: Avoidance eliminates the threat entirely by changing the project plan, such as removing the risky activity or using a different supplier altogether. While that could work, the question specifies reducing probability and impact, not eliminating the risk. Avoidance is a more drastic step and does not match the described intent of lessening the risk's likelihood or consequences.
B
Mitigate
Mitigation is a risk response strategy that reduces the probability and/or impact of a threat. In this scenario, the project manager wants to take action before the risk occurs to lessen the chance or effect of the supplier's late delivery. This aligns with mitigation, which is appropriate for threats where proactive measures can lower the risk exposure. Therefore, mitigation is the correct strategy.
C
Transfer
Why it fails: Transfer shifts the impact of the threat to a third party, often through insurance or a fixed-price contract. It does not reduce the probability of the risk occurring, and the scenario asks for reducing both probability and impact. Transfer is a valid strategy for some risks, but it does not fit the described goal of proactive reduction before the risk happens.
D
Accept
Why it fails: Acceptance acknowledges the risk and does not take proactive action unless the risk occurs. It can be active or passive, but it does not reduce probability or impact. Since the project manager wants to take action before the risk occurs to lessen it, acceptance is not appropriate here. It would leave the project exposed to the supplier's potential failure.