High-Level Requirements, Scope and Success Criteria

Introduction

Project initiation is often treated as a period of agreement: sponsors authorize a project, a project manager is appointed, and a charter is produced. In practice, initiation is also a period of disciplined inquiry. The project team must determine what problem is being addressed, whose needs matter, what the intended product or service must do, what work is included, how completion will be judged, and which uncertainties must remain visible.

High-level requirements, scope and success criteria provide the bridge between strategic intent and controlled delivery. They do not constitute a complete specification or a detailed work breakdown structure. Rather, they establish a sufficiently clear decision boundary for authorization, planning and governance. If they are vague, the project may begin with incompatible assumptions. If they are excessively detailed too early, the team may create false certainty, constrain innovation and spend effort analysing requirements that may later change.

This chapter examines how project managers elicit and prioritize initial requirements; distinguish product scope from project scope; define deliverables, exclusions and acceptance criteria; identify constraints and assumptions; establish measurable success indicators; and control ambiguity, stakeholder bias and premature commitment.

Learning Objectives

By the end of this chapter, the reader should be able to:

1. Distinguish needs, requirements, scope statements, deliverables, acceptance criteria and success criteria.
2. Elicit high-level requirements from diverse and sometimes conflicting stakeholders.
3. Analyse requirements for clarity, feasibility, traceability, testability and priority.
4. Define product and project boundaries, including explicit exclusions.
5. Construct measurable success indicators linked to benefits and strategic outcomes.
6. Apply prioritization methods while recognizing their assumptions and limitations.
7. Manage ambiguity, scope bias, assumptions, constraints and early uncertainty.
8. Use a charter-level requirements and scope baseline as a governance instrument.

1. From Strategic Intent to Charter-Level Definition

A project is normally initiated because an organization seeks a change: a new capability, a regulatory response, a service improvement, a cost reduction, a risk treatment or an opportunity. Strategic intent is usually expressed at a high level—for example, “improve customer access” or “modernize the claims process.” Such statements are valuable but insufficient for authorization because they do not identify the boundaries of the proposed intervention.

A useful hierarchy is:

These levels are related but not interchangeable. A requirement describes a necessary capability or condition. A deliverable is an output produced by project work. An acceptance criterion determines whether a deliverable is acceptable. A success criterion assesses whether the project, product or resulting change has achieved intended value.

The distinction is particularly important because a project can deliver its specified outputs and still fail to generate benefits. Conversely, benefits may improve because of external factors even when project execution was weak. Governance should therefore assess at least three dimensions:

• Output performance: Were agreed deliverables produced to the required quality?
• Project performance: Was the work managed within approved time, cost, risk and compliance boundaries?
• Outcome performance: Did the completed capability produce the intended operational or strategic results?

2. High-Level Requirements

2.1 Nature and quality

High-level requirements state what the project must enable or provide without prematurely prescribing every design detail. They may address functions, performance, quality, compliance, interfaces, information, security, accessibility or transition needs.

A strong high-level requirement is:

• Necessary: Its absence would undermine the intended outcome.
• Unambiguous: Reasonable readers interpret it similarly.
• Feasible: It can be achieved within known constraints or through an approved change.
• Verifiable: Evidence can establish whether it has been met.
• Traceable: It can be linked to a stakeholder need, objective, deliverable and acceptance test.
• Prioritized: Its relative importance is explicit.
• Singular: It expresses one principal obligation rather than combining unrelated demands.

Words such as “fast,” “user-friendly,” “robust,” “flexible” and “state-of-the-art” are not automatically invalid, but they are incomplete until operationalized. For example, “the system shall be fast” can become “95% of standard searches shall return results within two seconds under the agreed reference load.” The latter identifies a metric, threshold, operating condition and verification method.

2.2 Requirement categories

A practical classification helps expose omissions:

This classification should not become a bureaucratic exercise. Its purpose is to prompt questions about the complete change, including people, processes, technology, data, controls and operations.

2.3 Elicitation methods

No single elicitation method reveals all requirements. A mixed approach is more reliable because each method exposes different forms of knowledge and bias.

Interviews provide depth and allow probing of tacit assumptions. They are useful for sponsors, subject-matter experts, operational staff and affected users. The interviewer should distinguish facts, preferences, fears and proposed solutions rather than recording every statement as a requirement.

Workshops make conflicts and dependencies visible. A well-facilitated workshop defines its decision rights, uses concrete scenarios, records unresolved issues and prevents the most senior or vocal participant from dominating.

Observation and contextual inquiry reveal workarounds, informal controls and real operating conditions that participants may omit from interviews.

Document and regulatory analysis identifies existing commitments, policies, contractual obligations, service levels and data restrictions.

Surveys and structured questionnaires are useful when a population is large, but response rates and question wording affect validity. A survey should not be used to conceal the absence of stakeholder dialogue.

Prototyping, story mapping and scenario analysis help stakeholders react to something concrete. They are especially valuable where users cannot articulate needs abstractly.

Historical data and operational analytics can test whether perceived problems are widespread, exceptional or caused by a different factor than initially assumed.

Elicitation is an interpretive activity. The project manager should ask: Who benefits? Who bears cost or risk? Who is not represented? What happens in exceptional cases? What current workaround must not be lost? What would make the proposed solution unusable or unsafe?

3. Analysing, Validating and Prioritizing Requirements

3.1 Requirement analysis

Initial requirements should be analysed before they are accepted into the charter. Useful tests include:

• Can the requirement be understood without relying on an unstated assumption?
• Is it a need or merely one stakeholder’s preferred solution?
• Does it conflict with another requirement?
• Is its priority justified by value, risk, compliance or dependency?
• Can it be verified at a defined stage?
• Is the responsible decision-maker identified?
• What is the consequence of not implementing it?

A requirement register commonly records an identifier, statement, source, rationale, category, priority, owner, dependencies, assumptions, acceptance approach and status. At initiation, the register may contain unresolved items. Visibility of uncertainty is preferable to invented precision.

3.2 Prioritization methods

Prioritization is not simply ranking stakeholder preferences. It is a governance decision concerning value, risk, obligation, feasibility and sequencing.

MoSCoW classifies requirements as Must have, Should have, Could have and Won’t have for the current scope. The “Won’t have” category is valuable because it makes deferral explicit. A common weakness is labelling nearly everything “Must.” Governance should therefore impose a credible limit on mandatory items and ask what failure would result if a proposed Must were omitted.

Kano analysis distinguishes basic expectations, performance attributes and delighters. It is useful for product discovery but classifications may change as users gain experience.

Cumulative voting or relative ranking asks stakeholders to distribute a fixed number of points. This exposes trade-offs but does not by itself establish feasibility or strategic alignment.

Weighted scoring is useful where multiple criteria must be considered transparently. Suppose requirement i receives a value score v_i for criterion i, and the criteria have normalized weights w_i whose sum is 1. A weighted priority score is:

Here, P is the total score, w_i is the weight of criterion i, and v_i is the requirement’s rating on that criterion. The method assumes that ratings are sufficiently comparable and that additive trade-offs are acceptable. It should support, not replace, judgement. A legally mandatory requirement cannot normally be rejected merely because its weighted score is lower than a convenience feature.

For example, a team uses three criteria: strategic contribution weighted 0.4, risk reduction weighted 0.35 and user value weighted 0.25. Requirement A is rated 8, 7 and 9 respectively on a ten-point scale. Its score is:

The score is 7.90 out of 10. This calculation does not prove that A should be selected; the team must still examine cost, dependencies, compliance and capacity. Ratings should be accompanied by evidence and sensitivity analysis. If small changes in weights reverse the ranking, the decision is fragile and should be escalated rather than presented as objective fact.

3.3 Controlling scope bias

Scope bias occurs when the proposed scope is systematically distorted. Common forms include:

• Solution bias: A preferred technology is treated as the need.
• Sponsor bias: The interests of the funding authority outweigh affected users.
• Availability bias: Recently observed problems receive excessive attention.
• Sunk-cost bias: Existing investments are protected despite weak future value.
• Optimism bias: Benefits are overstated and effort, risk or adoption difficulty understated.
• Status-quo bias: Necessary change is avoided because current processes seem familiar.
• Scope creep through enthusiasm: Attractive but weakly justified features are added during discovery.

Controls include independent facilitation, anonymous pre-work, stakeholder mapping, explicit decision criteria, evidence-based baselines, challenge reviews, separation of needs from solutions, and recording dissent. A requirements decision log should explain not only what was selected but also what was excluded and why.

4. Defining Product and Project Scope

4.1 Product scope and project scope

Product scope describes the features, functions, characteristics and quality attributes of the product, service or result. Project scope describes the work required to produce that product, service or result, including management, procurement, testing, migration, training and transition activities.

For example, the product scope of a patient appointment service might include online booking, reminders and accessibility support. Project scope may include process redesign, data migration, vendor configuration, staff training, pilot operation and handover. Confusing these categories leads teams to omit essential implementation work or to include unrelated organizational improvements.

The charter should define:

1. The problem and intended change.
2. The product, service or result at a useful level of abstraction.
3. Major deliverables and their intended recipients.
4. Geographic, organizational, technical and temporal boundaries.
5. Explicit exclusions.
6. Dependencies and interfaces with other initiatives.
7. Constraints, assumptions and known uncertainties.
8. The authority and process for changing the boundary.

4.2 Deliverables and exclusions

A deliverable is a verifiable product, result or capability produced by the project. “Implement a new platform” is too broad to govern effectively. More useful deliverables might include an approved process design, configured platform, migrated data set, tested integration, training package and operational handover.

Exclusions are not negative wording for its own sake. They prevent stakeholders from assigning adjacent work to the project by implication. Examples include expansion to regions not named in the charter, replacement of unrelated legacy systems, ongoing operational support after a defined warranty period, or policy reform outside the project’s authority.

Exclusions should be tested for realism. If an excluded capability is essential to adoption or legal compliance, excluding it may merely create a hidden project risk. The correct response may be to change the boundary, create a dependency, or obtain a separate owner—not to ignore the need.

4.3 Acceptance criteria

Acceptance criteria are conditions that must be satisfied for a deliverable or product increment to be accepted by an authorized party. They should identify the subject, condition, threshold and evidence. For example:

• “The portal shall allow an authenticated user to submit a complete application and receive a reference number.”
• “During the agreed user-acceptance test, all critical scenarios shall pass and no unresolved severity-one defect shall remain.”

Acceptance criteria are not the same as success criteria. A portal may pass acceptance tests but fail to achieve the targeted adoption rate. Acceptance criteria generally apply at deliverable or product level; success criteria apply to the broader project and resulting change.

Acceptance authority must also be explicit. A stakeholder who provides useful input is not necessarily authorized to accept the deliverable. Governance should define who verifies, who recommends acceptance and who formally accepts.

5. Constraints, Assumptions, Dependencies and Uncertainty

A constraint is a limitation imposed on the project, such as a statutory deadline, approved budget ceiling, mandated technology, data residency requirement or restricted resource. An assumption is a proposition treated as true for planning purposes but not yet verified. A dependency is a relationship in which one activity, deliverable or decision relies on another party or event.

These categories should not be blurred. “The vendor will provide an interface by June” is an assumption until contractually confirmed; it may become a dependency and a schedule risk. “The system must comply with the privacy regulation” is a requirement or constraint, depending on how the charter frames it.

A useful initiation log records the statement, owner, evidence, implication if false, validation date and response. Uncertainty should be managed through discovery tasks, prototypes, pilots, contingency, decision gates or explicit tolerance. A project that hides uncertainty in a fixed scope statement is not controlled; it is merely opaque.

Scope boundaries should also reflect systems thinking. A project can be locally successful while shifting cost or risk to operations, customers, suppliers or another department. Boundary analysis therefore asks what upstream inputs and downstream consequences are affected. In complex projects, a deliberately bounded first release may be preferable to an apparently comprehensive scope that cannot be tested or adopted.

6. Success Criteria and Measurement

6.1 From outputs to benefits

Success criteria should connect project outputs to outcomes and benefits. A results chain can be expressed as:

Inputs → Activities → Outputs → Outcomes → Benefits

For example, funding and expertise enable process redesign and software configuration; these produce a digital service; the service changes customer behaviour and staff workflow; those changes reduce processing time and improve access.

Each link contains assumptions. The project may control inputs and activities more directly than benefits. Consequently, the charter should identify both project-controlled measures and post-project outcome measures, with owners and measurement dates.

6.2 Characteristics of useful indicators

A strong indicator is specific, measurable, attributable or plausibly influenced by the project, time-bound and associated with a baseline. A target without a baseline may sound precise but cannot demonstrate improvement.

Common measures include:

• schedule and cost performance against approved baselines;
• deliverable quality and defect levels;
• adoption, usage and completion rates;
• cycle time, throughput and service reliability;
• customer or user satisfaction;
• compliance and control effectiveness;
• financial, environmental or risk-reduction benefits.

Where a percentage change is used, the general calculation is:

The formula assumes that the baseline and new value measure the same phenomenon, use comparable units and are collected under sufficiently similar conditions. A reduction from 10 days to 7 days is ((7 − 10) ÷ 10) × 100% = −30%, meaning a 30% reduction. The team should specify whether lower or higher values represent improvement and should avoid claiming causation without considering external influences.

A success indicator should therefore specify: baseline, target, unit, population or scope, measurement method, timing, owner and decision consequence. For example: “Within six months of regional deployment, median application-processing time for standard cases will fall from 10 days to 7 days, measured from receipt of a complete application to decision, using the operational case-management report; the service owner will review performance monthly.”

6.3 Leading and lagging indicators

Lagging indicators measure realized results, such as actual cost reduction or service time. Leading indicators provide early evidence that benefits are likely, such as training completion, system availability, adoption in a pilot or the proportion of cases processed through the new workflow. A balanced set reduces the risk of discovering failure only after project closure.

Targets can also produce dysfunctional behaviour. If staff are measured only on speed, quality or equity may deteriorate. If adoption is measured only by log-ins, meaningful use may be overstated. Ethical measurement requires attention to unintended consequences, distributional effects and data quality.

7. Integrating the Charter-Level Baseline

The high-level requirements and scope baseline should be concise enough for governance but sufficiently explicit to guide planning. It normally contains:

• problem or opportunity statement;
• objectives and intended benefits;
• high-level requirements;
• product and project scope;
• major deliverables;
• exclusions and boundaries;
• acceptance approach;
• success criteria and measurement plan;
• assumptions, constraints and dependencies;
• high-level risks and unresolved decisions;
• change authority and escalation thresholds.

A traceability chain links each important requirement to its source need, objective, deliverable, acceptance evidence and success contribution. Traceability is not an administrative end in itself. It helps identify orphan requirements, deliverables with no rationale, benefits with no enabling output and stakeholders whose concerns have disappeared from the design.

The baseline is progressive. It should be detailed enough to authorize the next stage and stable enough to govern, but it should not prevent legitimate learning. Change control should distinguish clarification from material scope change. A clarified interpretation may require no reauthorization; a new deliverable, materially higher risk or changed success target normally should.

8. Applied Case: The Northbridge Licensing Service

The following is an illustrative case.

Background

Northbridge, a regional public authority, proposes an online licensing service for small businesses. The sponsor initially states that the project will “digitize licensing and eliminate paper.” The existing process requires applicants to submit forms by post, staff to re-enter data, and inspectors to exchange information through email.

Problem

Early workshops reveal competing views. The sponsor wants rapid visible modernization. Licensing officers want accurate information and fewer incomplete applications. Businesses want status visibility and shorter processing times. The information-security team requires stronger identity verification. A disability advocacy group reports that some applicants cannot use the authority’s existing web forms.

The initial phrase “eliminate paper” is identified as a solution-oriented aspiration rather than a complete requirement. Interviews and process observation show that some supporting evidence must still be received in physical form under current regulation, although the policy may be reviewed separately.

Analysis

The team constructs a high-level requirement set:

The project boundary includes service design, the online portal, workflow configuration, integration with the existing licensing database, accessibility testing, staff training, pilot deployment and operational handover. It excludes replacement of the licensing database, reform of licensing law, and digitization of evidence that regulations still require in physical form.

The team identifies a critical dependency: the existing database owner must provide a stable interface. It also records an assumption that the authority’s identity provider can support external applicants; this is assigned for validation before detailed design.

Approach and solution

The charter defines three levels of success. Output acceptance requires the portal, workflow and interface to pass agreed tests, with no unresolved critical security or accessibility defect. Project success requires deployment within the approved time and budget tolerances and completion of staff readiness activities. Outcome success is assessed six months after launch: at least 60% of eligible standard applications are submitted digitally, median processing time falls from 12 to 8 working days, and the proportion of incomplete submissions declines from 28% to 15%.

The targets are accompanied by baselines, data definitions and an owner in the licensing service. The team also adds leading indicators: pilot completion, staff training, successful identity verification and the percentage of users who abandon an application. A governance review is scheduled after the pilot rather than assuming that the full solution is ready for immediate scale.

Outcome

The project launches a narrower first release than the sponsor originally imagined, but it has clearer acceptance evidence and an explicit exclusion for legal reform. During the pilot, identity verification fails for a significant group of applicants. Because the assumption was recorded and tested early, the issue is handled through a controlled design change and not discovered after full deployment. The authority later reports improved digital uptake and shorter processing times, while the physical-evidence requirement remains visible as a separate policy initiative.

Learning points

1. A compelling slogan is not a sufficient scope statement.
2. Users, operators, regulators and security specialists reveal different requirements.
3. Exclusions can protect the project from hidden policy work, but excluded dependencies must remain visible.
4. Acceptance criteria, project measures and benefit measures answer different questions.
5. Explicit assumptions enable early validation and reduce surprise.
6. A smaller, testable release may be strategically superior to an undeliverable comprehensive promise.

9. Governance, Ethics and Contemporary Practice

Requirements decisions allocate value and burden. A service that is efficient for the majority may exclude people with disabilities, limited connectivity, low literacy or insecure identity documents. Ethical scope definition therefore requires impact assessment, accessible participation and consideration of affected non-users, not only paying customers or executive sponsors.

Privacy, information security, records management, procurement and sector-specific regulation should be considered at initiation rather than appended at the end. “Compliance later” is often expensive because architecture, data flows and operating processes may already be fixed.

Digital tools and artificial intelligence can assist with clustering feedback, detecting duplicate requirements, summarizing interview transcripts and identifying missing traceability links. They should not be treated as authoritative interpreters of stakeholder intent. AI-generated summaries may omit dissent, reproduce bias, expose confidential information or confuse a suggestion with an approved requirement. Human review, source traceability, access controls and explicit approval remain necessary. Where automated tools influence prioritization, the team should disclose the criteria and retain an auditable decision record.

Contemporary projects increasingly use adaptive delivery. Adaptive methods do not eliminate scope; they move some detail from an initial commitment into a managed discovery and prioritization process. The product vision, guardrails, outcome targets, minimum viable capability and decision rights still need early definition. Iterative delivery is therefore compatible with disciplined chartering, provided that learning results in visible decisions rather than uncontrolled expansion.

10. Challenges and Limitations

Several limitations deserve attention. First, high-level requirements cannot resolve every technical or organizational uncertainty. They establish direction and boundaries; detailed analysis must continue. Second, stakeholder consensus may be impossible where interests genuinely conflict. The correct response is transparent governance, not artificial agreement. Third, weighted scoring can create an illusion of mathematical objectivity when criteria and ratings are subjective. Fourth, benefits may be influenced by economic, regulatory or behavioural factors outside project control. Fifth, a baseline can become rigid if change control is designed to protect documents rather than value.

The project manager’s role is consequently both analytical and political. The manager must make ambiguity discussable, surface power differences, protect the integrity of evidence, and help decision-makers distinguish a justified change from an attractive addition. Good initiation does not predict the future perfectly; it creates a credible mechanism for learning and deciding.

Best-Practice Checklist

Before authorizing detailed planning, confirm that:

• the problem and intended benefits are stated independently of a preferred solution;
• major stakeholder groups, including affected non-users, have been considered;
• high-level requirements are necessary, testable and prioritized;
• product scope and project scope are distinguished;
• major deliverables have recipients and acceptance authority;
• exclusions are explicit and realistic;
• assumptions, constraints and dependencies have owners;
• success criteria include baselines, targets, timing and measurement ownership;
• unresolved issues and dissent are recorded;
• the change authority and escalation route are clear;
• privacy, security, accessibility, safety and regulatory obligations are addressed;
• the scope is sufficiently bounded to plan without pretending that uncertainty has disappeared.

Chapter Summary

High-level requirements translate stakeholder needs and strategic intent into capabilities and conditions that can guide project authorization. They should be necessary, unambiguous, feasible, verifiable, traceable and prioritized. Elicitation should combine interviews, workshops, observation, document analysis, prototypes and evidence from operations because each method reveals different knowledge and bias.

Product scope describes the characteristics of the product, service or result; project scope describes the work required to create and transition it. A sound charter identifies deliverables, exclusions, boundaries, acceptance authority, assumptions, constraints, dependencies and unresolved uncertainty. Acceptance criteria judge whether a deliverable is acceptable, whereas success criteria evaluate project performance and resulting outcomes.

Prioritization methods such as MoSCoW, Kano analysis, voting and weighted scoring support decision-making but do not replace governance. Scope bias must be controlled through explicit criteria, diverse participation, evidence, independent challenge and documented dissent. Success indicators should connect outputs to outcomes, specify baselines and targets, and include both leading and lagging measures. Ethical and regulatory considerations—including accessibility, privacy, security and distributional impacts—belong in initiation. A disciplined charter is therefore not merely an authorization document; it is a boundary-setting and learning instrument for responsible project governance.

Key Terms

Requirement: A needed capability, condition or obligation.

High-level requirement: An initial requirement stated at sufficient abstraction for authorization and early planning.

Business need: The problem, opportunity or organizational condition motivating change.

Product scope: The features, functions and qualities of the project’s product, service or result.

Project scope: The work required to produce and transition the product, service or result.

Deliverable: A verifiable product, result or capability produced by project work.

Exclusion: Work or capability explicitly outside the approved project boundary.

Acceptance criterion: A condition used to determine whether a deliverable is acceptable.

Success criterion: A measurable condition used to judge project or outcome success.

Baseline: An agreed reference value against which change or performance is assessed.

Constraint: An imposed limitation on the project.

Assumption: A proposition treated as true for planning but not yet verified.

Dependency: A relationship in which one activity, decision or deliverable relies on another.

Traceability: The ability to link a requirement to its source, deliverable, evidence and outcome.

MoSCoW: A prioritization method classifying items as Must, Should, Could or Won’t have.

Scope creep: Uncontrolled expansion of approved scope without appropriate evaluation and authorization.

Leading indicator: An early measure that signals likely future performance or benefit.

Lagging indicator: A measure of realized performance or outcome.

Scope bias: Systematic distortion in the selection or framing of project scope.

Change authority: The person or governance body authorized to approve scope or baseline changes.

Review Questions

Short Answer Questions

1. Why should product scope and project scope be distinguished?
2. State four qualities of a strong high-level requirement.
3. What is the difference between an assumption and a constraint?
4. How do acceptance criteria differ from success criteria?
5. Why are exclusions important in a project charter?

Long Answer Questions

1. Explain how a project manager can combine interviews, workshops, observation and prototyping to elicit requirements from diverse stakeholders.
2. Compare MoSCoW, Kano analysis and weighted scoring as requirement-prioritization methods. Discuss the limitations of each.
3. Explain how traceability supports project governance from need through acceptance and benefits measurement.
4. Discuss the relationship between outputs, outcomes and benefits, including the role of leading and lagging indicators.
5. Analyse how privacy, accessibility, security and stakeholder power should influence high-level scope definition.

Analytical / Application Questions

1. A sponsor proposes a project to “create the most advanced customer platform available.” Reframe this statement into a problem statement, two high-level requirements, two exclusions and three measurable success criteria.
2. A requirement receives ratings of 8, 6 and 9 on criteria weighted 0.5, 0.3 and 0.2. Calculate its weighted score and explain why the score alone should not determine selection.
3. A project meets all deliverable acceptance criteria, but user adoption is 20% below target six months after launch. Analyse whether the project should be considered successful and identify the governance actions that should follow.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes product scope from project scope?

A. Product scope concerns the work plan, while project scope concerns benefits.

B. Product scope concerns product characteristics, while project scope concerns the work required to produce and transition them.

C. Product scope concerns stakeholders, while project scope concerns regulations only.

D. Product scope is fixed, while project scope can never be changed.

Correct Answer: B. Product scope concerns product characteristics, while project scope concerns the work required to produce and transition them.

Question 2

Which characteristic means that evidence can determine whether a requirement has been met?

A. Traceable

B. Feasible

C. Verifiable

D. Prioritized

Correct Answer: C. Verifiable

Question 3

In MoSCoW prioritization, which category identifies items that will not be delivered in the current scope?

A. Must have

B. Should have

C. Could have

D. Won’t have

Correct Answer: D. Won’t have

Question 4

A requirement is rated 8, 6 and 9 on criteria weighted 0.5, 0.3 and 0.2. What is its weighted score?

A. 6.80

B. 7.30

C. 7.60

D. 8.10

Correct Answer: C. 7.60

Question 5

Which is the best example of an acceptance criterion?

A. Improve customer trust over time

B. Modernize the organization’s technology

C. All critical user-acceptance scenarios pass with no unresolved severity-one defect

D. Become the leading service provider

Correct Answer: C. All critical user-acceptance scenarios pass with no unresolved severity-one defect

Question 6

Which statement is an assumption rather than a confirmed constraint?

A. The project must comply with data-protection law.

B. The approved budget cannot exceed $2 million.

C. The external identity provider will support applicants before pilot launch.

D. The service must meet the mandated accessibility standard.

Correct Answer: C. The external identity provider will support applicants before pilot launch.

Question 7

What is the principal purpose of a baseline in success measurement?

A. To remove the need for targets

B. To provide a reference point for assessing change

C. To guarantee that benefits are caused by the project

D. To prevent all future scope changes

Correct Answer: B. To provide a reference point for assessing change

Question 8

Which situation is an example of solution bias?

A. Including affected non-users in consultation

B. Using operational data to test the scale of a problem

C. Treating a preferred technology as the requirement without examining the underlying need

D. Recording an unresolved dependency in the charter

Correct Answer: C. Treating a preferred technology as the requirement without examining the underlying need

Question 9

A fall in processing time from 10 days to 7 days represents what percentage change?

A. 10% reduction

B. 20% reduction

C. 30% reduction

D. 40% reduction

Correct Answer: C. 30% reduction

Question 10

Why should AI-generated requirement summaries receive human review?

A. AI cannot process any text

B. AI outputs may omit dissent, reproduce bias or confuse suggestions with approved requirements

C. Human review makes requirements unnecessary

D. AI can only be used for financial projects

Correct Answer: B. AI outputs may omit dissent, reproduce bias or confuse suggestions with approved requirements