Requirements, Scope and Deliverable Management

Introduction

Projects create value by producing outputs that satisfy identified needs. Yet many project failures arise not from poor technical execution, but from building the wrong product, omitting required capabilities, or accepting outputs that stakeholders do not consider adequate. Requirements, scope, and deliverable management therefore form a connected control system. Requirements express stakeholder needs; scope defines the work and product boundaries; deliverables are the verifiable outputs produced within those boundaries.

In graduate-level project management, these subjects should not be treated as administrative documentation. They are mechanisms for aligning strategy, operations, governance, quality, risk, procurement, and benefits realization. Weak requirements create ambiguous scope. Ambiguous scope produces unstable plans, disputes, rework, and uncontrolled change. Conversely, disciplined requirements engineering and scope governance improve predictability while preserving legitimate adaptability.

This chapter develops an integrated approach to eliciting and prioritizing requirements, defining scope and acceptance criteria, constructing work breakdown structures (WBSs), validating deliverables, controlling changes, and maintaining traceability.

Learning Objectives

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

1. Distinguish business, stakeholder, solution, transition, quality, and project requirements.
2. Select appropriate elicitation and prioritization techniques for different contexts.
3. Define product and project scope using a scope statement, assumptions, exclusions, and acceptance criteria.
4. Construct a deliverable-oriented WBS and explain its relationship to planning and control.
5. Differentiate verification, validation, and formal acceptance.
6. Design a requirements traceability structure that supports governance and change control.
7. Analyze scope change requests using impact, authority, and benefits considerations.
8. Recognize ethical, organizational, and technological risks in requirements and deliverable management.

1. The Integrated Logic of Requirements, Scope and Deliverables

A requirement is a documented representation of a capability, condition, or characteristic needed by a stakeholder or imposed by an authority, contract, standard, or policy. Requirements may describe what a product must do, how well it must perform, constraints on its design, or conditions under which the project must be conducted.

Scope has two related meanings:

• Product scope: the features, functions, characteristics, and performance of the result.
• Project scope: the work required to produce that result, including management, assurance, procurement, transition, and closure activities.

A deliverable is a unique and verifiable product, result, or capability produced to complete a process, phase, or project. Deliverables can be internal, such as an approved design baseline, or external, such as an operating facility or software release.

These concepts form a logic chain:

Need → requirement → scoped capability → planned work → deliverable → verified and accepted outcome → realized benefit

The chain is not purely linear. Learning from prototypes, testing, users, or regulatory review may refine requirements and lead to approved scope changes. Consequently, requirements management is both a definition activity and a controlled learning process.

Requirements hierarchy

A useful hierarchy is:

A requirement should be necessary, clear, feasible, testable, traceable, and sufficiently atomic. Words such as “user-friendly,” “efficient,” or “robust” are not automatically invalid, but they require operational definitions. For example, “user-friendly” may become “a trained user shall complete a standard order entry in no more than three minutes with no more than one help prompt.”

2. Requirements Elicitation and Analysis

2.1 Stakeholder identification and engagement

Requirements are elicited from people and organizations affected by, governing, supplying, operating, or benefiting from the project. Stakeholder analysis should consider not only formal sponsors and users but also regulators, maintainers, data owners, suppliers, communities, and people who may be adversely affected.

A stakeholder register commonly records interests, influence, impact, knowledge, decision rights, preferred communication channels, and engagement risks. Influence must not be confused with legitimacy: a powerful stakeholder is not necessarily entitled to override safety, legal, or ethical obligations.

2.2 Elicitation techniques

No single technique reveals all requirements. Selection should reflect uncertainty, stakeholder accessibility, political sensitivity, and the maturity of the proposed solution.

• Interviews provide depth and permit probing, but may reflect individual bias.
• Workshops create shared understanding and expose conflicts quickly; they require skilled facilitation.
• Observation and contextual inquiry reveal tacit work practices that participants may omit in interviews.
• Document and process analysis identify contractual, regulatory, historical, and operational constraints.
• Surveys efficiently collect broad input but are less effective for ambiguous or innovative needs.
• Prototyping helps stakeholders react to an emerging solution and is particularly useful when users cannot articulate needs abstractly.
• Use cases and user stories organize interactions around actors, goals, and outcomes.
• Benchmarking and market analysis identify external expectations and competitive requirements.
• Interface analysis identifies dependencies between systems, organizations, equipment, and processes.

Elicitation should be followed by analysis. Analysts consolidate duplicate statements, identify conflicts, distinguish needs from preferred solutions, test feasibility, and expose assumptions. A request such as “add a dashboard” is not yet a complete requirement. The underlying decision need, users, data, refresh frequency, security rules, and acceptance conditions must be clarified.

2.3 Requirement quality

High-quality requirements generally have the following attributes:

• Correct: represents a genuine need or obligation.
• Complete: includes necessary conditions, interfaces, exceptions, and constraints.
• Unambiguous: has one reasonable interpretation.
• Consistent: does not conflict with another approved requirement.
• Feasible: can be delivered within authorized constraints.
• Verifiable: can be tested, inspected, demonstrated, or analyzed.
• Traceable: has an identifiable source and links to downstream work and evidence.
• Prioritized: its relative importance and urgency are understood.
• Atomic: expresses one principal obligation rather than several unrelated ones.

A useful requirement template is: “The [system/product/process] shall [observable behavior or characteristic] under [specified condition], measured by [criterion].” This is a writing aid, not a substitute for professional judgment.

2.4 Prioritization

Prioritization makes trade-offs explicit. A common method is the MoSCoW classification:

• Must have: essential for viability, compliance, safety, or contractual obligation.
• Should have: important but temporarily deferrable.
• Could have: desirable if resources permit.
• Won’t have this release: explicitly excluded from the current increment.

Other methods use weighted scoring, pairwise comparison, cost of delay, risk reduction, or value-versus-effort analysis. A weighted scoring model can be represented as:

Here, S_j is the score of option or requirement j, w_i is the weight assigned to criterion i, and r_ij is the rating of option j against criterion i. Usually, weights are non-negative and sum to 1, while ratings use a defined common scale. The model is appropriate for comparative screening, not for disguising political or ethical decisions as objective facts. Sensitivity analysis should test whether rankings change when weights or ratings change.

Prioritization should also identify mandatory constraints. A legally required requirement should not lose merely because its numerical business-value score is low. Similarly, safety and human-rights considerations may establish veto conditions rather than compensable preferences.

3. Scope Definition and Baselines

Scope definition converts analyzed requirements into an authorized boundary. A scope baseline commonly consists of the approved scope statement, WBS, and WBS dictionary. The baseline is not a promise that nothing will change; it is the reference against which proposed changes and performance are evaluated.

A strong scope statement normally includes:

1. Product description and purpose.
2. Major deliverables and required capabilities.
3. Acceptance criteria.
4. Explicit exclusions and non-goals.
5. Constraints, such as budget, regulatory, technical, or schedule limits.
6. Assumptions that underpin the plan.
7. Interfaces and organizational boundaries.
8. A statement of what constitutes completion.

Progressive elaboration and boundary discipline

At project authorization, scope may be expressed at a high level. As knowledge improves, it can be elaborated through decomposition, prototypes, design decisions, and stakeholder review. Progressive elaboration does not authorize silent expansion. New knowledge must be recorded and assessed through the agreed change process.

The distinction between scope creep and legitimate change is important. Scope creep is uncontrolled addition, omission, or alteration of work. An approved change, by contrast, is evaluated, authorized by the appropriate authority, incorporated into the baseline, and communicated to affected parties.

Acceptance criteria

Acceptance criteria are measurable conditions that must be satisfied for a deliverable or project outcome to be accepted. They should describe observable evidence rather than vague approval language. Criteria may address functionality, performance, safety, reliability, usability, documentation, compliance, data quality, training, and operational readiness.

A criterion should specify, where relevant:

• the object being assessed;
• the condition or test environment;
• the method of assessment;
• the threshold or permitted tolerance;
• the responsible assessor;
• the evidence required; and
• the decision authority.

For example, “The warehouse system shall process 500 concurrent order sessions with at least 99% of transactions completing within three seconds during the defined test window” is more useful than “The system shall be fast.” The criterion must still be checked for feasibility, test design, workload definition, and relationship to service-level obligations.

Acceptance criteria should be agreed before final delivery where possible. Late invention of criteria is a common source of disputes because it changes the basis on which performance is judged.

4. Work Breakdown Structures

The WBS is a hierarchical decomposition of the total scope of work required to accomplish project objectives and create required deliverables. It is deliverable-oriented: it organizes what must exist or be completed, rather than merely listing departmental activities.

The 100 percent rule states that the WBS should include 100 percent of the work defined by the approved project scope, including project management work, and no work outside that scope. Child elements collectively represent the full content of their parent element. The rule does not mean every element must be decomposed to the same numerical depth.

Constructing a WBS

A practical sequence is:

1. Begin with the project objective or final product.
2. Identify major product, service, or phase deliverables.
3. Decompose each deliverable into progressively smaller components.
4. Stop when a work package is sufficiently defined to estimate, schedule, assign, monitor, and accept.
5. Review the structure with technical experts and stakeholders.
6. Document each element in a WBS dictionary.
7. Check the 100 percent rule, interfaces, exclusions, and traceability to requirements.

A work package is the lowest WBS component at which cost, duration, responsibility, and performance can be meaningfully managed. Activities are normally developed from work packages in the schedule; the WBS itself should not be confused with a detailed activity list.

The WBS dictionary may include an identifier, description, accountable owner, assumptions, exclusions, dependencies, estimated resources, quality criteria, acceptance evidence, and related requirements. Coding conventions support integration with scheduling, cost, procurement, risk, and reporting systems.

WBS structures and limitations

WBSs may be organized by product components, lifecycle phases, locations, releases, or contractual packages. The best structure reflects how scope will be understood and controlled. A phase-only WBS can obscure the complete product; a component-only WBS can obscure integration and transition work. Complex programs may use a product-oriented WBS supported by phase and responsibility views.

Common weaknesses include decomposing by organizational department rather than deliverable, omitting project management and integration, creating work packages that are too large to control, and decomposing to excessive detail that creates administrative overhead. The correct level depends on risk, uncertainty, reporting needs, contract structure, and management maturity.

5. Deliverable Verification, Validation and Acceptance

Three related activities must be distinguished:

• Verification asks whether the deliverable conforms to specified requirements. It may use inspection, testing, analysis, or demonstration.
• Validation asks whether the resulting product or capability meets the intended use and stakeholder need in its operational context.
• Acceptance is the formal decision by an authorized party that contractual or governance conditions have been met.

A deliverable can pass verification yet fail validation. For example, a report may contain all specified fields and still be unusable for the decisions it was intended to support. Conversely, a useful prototype may validate a concept while not yet satisfying production requirements.

A deliverable control process typically includes:

1. Define criteria and evidence before execution.
2. Produce the deliverable under controlled configuration.
3. Conduct quality control and record defects or deviations.
4. Perform verification using approved methods.
5. Validate in the intended operational or user context.
6. Obtain documented acceptance or rejection.
7. Record conditions, concessions, residual defects, and follow-up actions.
8. Transfer the accepted output to operations, the customer, or the next phase.

Acceptance is not equivalent to absence of all defects. A governance body may accept a deliverable with documented minor defects, provided their impact, owner, deadline, and risk are explicitly recorded. Informal acceptance creates ambiguity about liability, payment, warranty, and readiness for use.

6. Requirements Traceability and Configuration Control

A requirements traceability matrix (RTM) links each requirement to its origin, interpretation, design elements, work packages, test cases, results, defects, and acceptance decision. Traceability supports completeness analysis, impact assessment, auditability, and change control.

A simplified RTM might contain:

Traceability can be represented as a directed relationship from requirement to implementation and evidence. Forward traceability confirms that every requirement is addressed by downstream work. Backward traceability confirms that every design or test element has a legitimate requirement or approved project need. Both are needed to detect gold plating, which is the addition of unrequested features or work.

Traceability is not merely a spreadsheet exercise. In large projects, it may be maintained through integrated requirements, configuration, test, and work-management tools. However, automation does not guarantee semantic accuracy. A tool can show that two records are linked while the link is conceptually incorrect.

Configuration management establishes controlled versions of requirements, baselines, designs, code, specifications, test assets, and acceptance records. A change should have a unique identifier, rationale, requestor, impact assessment, decision, implementation status, and verification evidence.

7. Scope Change Control

Change control protects value without freezing learning. A proposed change should be evaluated for its effects on:

• business case and expected benefits;
• requirements and acceptance criteria;
• product architecture and interfaces;
• schedule and critical path;
• cost, resources, and procurement;
• quality, safety, security, privacy, and compliance;
• risks, assumptions, and operational readiness;
• contracts and stakeholder commitments.

A formal change process generally follows this sequence:

1. Submit and log the request.
2. Clarify the requested outcome and reason.
3. Analyze impacts and alternatives.
4. Obtain a decision from the authorized change authority.
5. Update requirements, scope baseline, WBS, schedule, cost, risk, quality, and procurement records as necessary.
6. Communicate the decision and responsibilities.
7. Implement and verify the change.
8. Close the request with evidence.

The appropriate authority depends on governance design. A project manager may approve changes within delegated tolerances; changes affecting the business case, contractual obligations, regulatory compliance, or organizational strategy may require a sponsor, steering committee, customer, or change control board.

The project team should distinguish change evaluation from change advocacy. Analysts should present impacts and alternatives transparently rather than inflating estimates to discourage inconvenient requirements or understating impacts to secure approval.

8. Worked Application: A Regional Distribution Visibility Project

The following is an illustrative case.

Background

A regional distributor initiates a project to improve visibility of inventory and outbound deliveries across six warehouses. Executives want more reliable service-level reporting, while warehouse managers want fewer manual reconciliations. The initial concept is described as “implement a real-time logistics dashboard.”

Problem analysis

Interviews reveal that different stakeholders mean different things by “real-time.” Executives require hourly service-level visibility; warehouse supervisors need exception alerts within ten minutes; the information-security team requires role-based access; and operations staff need data definitions that match existing procedures. The project also depends on data from a transport provider whose interface is incomplete.

The team identifies the following requirements:

• The solution shall display order, shipment, and delivery status for authorized users.
• Warehouse exceptions shall be visible within ten minutes of receipt of valid source data.
• The system shall retain an auditable history of status changes.
• Access shall be role-based and logged.
• Data reconciliation rules shall be documented and approved.
• Users shall receive training and operating procedures before deployment.

The requirement concerning ten-minute visibility is qualified by the condition “receipt of valid source data.” This avoids making the project responsible for an external provider’s transmission delay while still exposing the interface dependency.

Prioritization and scope

The sponsor classifies secure access, status visibility, audit history, and reconciliation as Must requirements. Advanced predictive delay analytics are classified as Could requirements and excluded from the first release. Exclusions are documented: replacement of the transport provider’s system, redesign of warehouse processes unrelated to status visibility, and predictive analytics are outside the current scope.

The scope statement identifies four major deliverables:

1. Approved data and interface design.
2. Configured visibility platform and security controls.
3. Tested dashboards, alerts, and audit history.
4. Operational transition package, including training and procedures.

Acceptance criteria include successful role-access tests, evidence that defined status changes appear within ten minutes under the agreed test conditions, reconciliation accuracy against a sampled source dataset, and completion of training for designated users.

WBS excerpt

The WBS decomposes the platform deliverable into data model, interfaces, access control, dashboard configuration, alert configuration, and integration testing. The transition deliverable includes training materials, user training, support procedures, and operational handover. This structure prevents the common omission of transition work.

Change event

Midway through implementation, executives request predictive arrival-time analytics. Analysis shows that the feature requires new external data, model validation, privacy review, and approximately eight additional weeks. The team presents three alternatives: add it to the current release with schedule and cost impact; defer it to a second release; or conduct a limited feasibility prototype. The change authority chooses the prototype. The decision preserves learning without silently changing the committed release scope.

Outcome and learning points

The first release is accepted after verification of performance and security criteria, operational validation by warehouse supervisors, and documented resolution of minor defects. The predictive prototype remains separately governed. The case demonstrates that scope clarity depends on operational definitions, exclusions, dependencies, acceptance evidence, and disciplined change decisions—not on the length of the requirements document.

9. Challenges, Ethics and Contemporary Practice

Ambiguity and conflicting interests

Stakeholders may intentionally or unintentionally use vague requirements to preserve bargaining power. Analysts should expose ambiguity rather than resolve it privately. Conflicts should be documented, prioritized using agreed principles, and escalated when authority is unclear.

Bias and representation

Requirements based only on senior managers may ignore frontline users, accessibility needs, cultural differences, or communities affected by the project. Inclusive elicitation is both a quality practice and an ethical obligation. Requirements should consider accessibility, safety, privacy, non-discrimination, and the distribution of benefits and burdens.

Regulatory and contractual governance

Requirements may derive from laws, licenses, industry standards, procurement rules, data-protection obligations, and contracts. The project should identify which requirements are mandatory, who interprets them, and what evidence demonstrates compliance. Legal review is appropriate when requirements involve regulated data, safety, intellectual property, employment conditions, or public procurement.

Agile and hybrid environments

Agile methods often express requirements as epics, features, user stories, and acceptance criteria, while maintaining a prioritized product backlog. A backlog is not automatically a complete scope baseline. Governance still requires clarity about release objectives, non-functional requirements, dependencies, definition of done, and decision rights. In hybrid projects, high-level requirements and architecture may be baselined while detailed requirements are elaborated iteratively.

Digital tools and artificial intelligence

Requirements-management platforms can automate versioning, linking, approval workflows, test evidence, and impact reports. AI may assist with clustering duplicate requirements, identifying ambiguous language, generating candidate trace links, or summarizing stakeholder interviews. Such outputs require human review because models can omit minority viewpoints, reproduce bias, infer unsupported requirements, or create false confidence in traceability. Confidential requirements and personal data must not be entered into tools without appropriate security, contractual, and governance controls.

Best practices

Effective organizations generally:

• establish a single source of truth for approved requirements;
• define decision rights and escalation routes early;
• involve users and operational owners, not only sponsors;
• write measurable acceptance criteria;
• maintain explicit exclusions and assumptions;
• use a deliverable-oriented WBS;
• link requirements to work and evidence;
• baseline configuration items and preserve decision history;
• assess changes for benefits, risk, and operational impact;
• validate in the environment where the result will be used; and
• treat transition, training, data migration, and support as part of scope when needed for usable outcomes.

Chapter Summary

Requirements translate needs, obligations, and constraints into statements that can guide design and assessment. Scope defines the boundaries of both the product and the work required to create it. Deliverables are verifiable outputs that must be checked, validated in context, and formally accepted.

Effective practice begins with inclusive stakeholder analysis and uses multiple elicitation techniques. Requirements should be clear, feasible, testable, prioritized, and traceable. Scope statements should identify deliverables, acceptance criteria, assumptions, constraints, interfaces, and exclusions. A deliverable-oriented WBS applies the 100 percent rule and provides a foundation for estimating, scheduling, assigning, and controlling work.

Verification establishes conformity to requirements; validation establishes fitness for intended use; acceptance records an authorized decision. Traceability connects requirements to design, WBS elements, tests, defects, and acceptance evidence. Change control evaluates impacts before authorization and updates all affected baselines. Ethical governance requires attention to representation, accessibility, privacy, safety, regulatory duties, and the limits of automated tools. Together, these practices convert stakeholder intent into controlled, usable, and defensible project outcomes.

Key Terms

Requirement: A needed capability, condition, characteristic, or constraint.

Business requirement: A high-level statement of organizational purpose or expected benefit.

Stakeholder requirement: A need expressed by an affected or interested party.

Solution requirement: A capability or characteristic the proposed solution must provide.

Non-functional requirement: A quality, performance, security, usability, or constraint requirement.

Transition requirement: A requirement needed to move from the current state to operational use.

Product scope: Features and characteristics of the project’s result.

Project scope: Work required to produce and transition the result.

Deliverable: A unique and verifiable product, result, or capability.

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

Scope baseline: The approved scope statement, WBS, and WBS dictionary.

Work Breakdown Structure: A hierarchical decomposition of total project scope.

Work package: The lowest WBS component managed for estimating, assignment, and control.

100 percent rule: The principle that the WBS contains all approved scope and no unauthorized work.

Verification: Evaluation of conformity to specified requirements.

Validation: Evaluation of fitness for intended operational use.

Requirements traceability: The ability to follow a requirement from origin through implementation and evidence.

Scope creep: Uncontrolled addition or alteration of scope.

Configuration management: Controlled identification, versioning, and change management of project artifacts.

Gold plating: Adding unrequested features or work beyond approved scope.

Review Questions

Short Answer Questions

1. Distinguish product scope from project scope.
2. What is the purpose of acceptance criteria?
3. State the 100 percent rule for a WBS.
4. How does verification differ from validation?
5. Why are explicit exclusions useful in a scope statement?

Long Answer Questions

1. Explain how stakeholder analysis, elicitation, requirement analysis, and prioritization should be integrated in a complex project.
2. Describe a disciplined method for constructing and documenting a deliverable-oriented WBS.
3. Explain the role of requirements traceability in quality assurance, change control, and auditability.
4. Compare formal change control with uncontrolled scope creep, including their effects on governance and benefits realization.
5. Discuss the ethical and managerial risks of using AI to support requirements elicitation and traceability.

Analytical / Application Questions

1. A sponsor requests a new reporting feature three weeks before deployment. Develop an impact-assessment and decision process covering requirements, scope, schedule, cost, risk, acceptance, and authority.
2. A system passes all documented functional tests, but warehouse users report that its workflow is too slow for peak operations. Analyze whether the issue is one of verification, validation, acceptance, or scope definition, and propose corrective action.
3. Construct a short requirements hierarchy and WBS outline for a university online enrolment project. Include at least one business requirement, two solution requirements, one non-functional requirement, acceptance criteria, and explicit exclusions.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes product scope from project scope?

A. Product scope concerns the result’s features; project scope concerns the work required to create it.

B. Product scope concerns the budget; project scope concerns the organization chart.

C. Product scope concerns stakeholder power; project scope concerns regulatory compliance only.

D. Product scope concerns risks; project scope concerns quality tests only.

Correct Answer: A. Product scope concerns the result’s features; project scope concerns the work required to create it.

Question 2

Which requirement is most verifiable?

A. The system shall be user-friendly.

B. The system shall be modern and attractive.

C. The system shall display a standard order summary within three seconds for 95% of tested queries.

D. The system shall provide excellent performance.

Correct Answer: C. The system shall display a standard order summary within three seconds for 95% of tested queries.

Question 3

What does the 100 percent rule require?

A. Every WBS must have exactly 100 work packages.

B. The WBS must include all approved scope and no unauthorized work.

C. Every activity must consume 100 percent of its budget.

D. Each WBS level must contain exactly 100 items.

Correct Answer: B. The WBS must include all approved scope and no unauthorized work.

Question 4

A deliverable conforms to its documented specifications but is unusable in the operating environment. Which conclusion is most appropriate?

A. It has passed validation but failed verification.

B. It has passed verification but failed validation.

C. It has automatically achieved formal acceptance.

D. It demonstrates that acceptance criteria are unnecessary.

Correct Answer: B. It has passed verification but failed validation.

Question 5

Which item is normally part of a scope baseline?

A. The organization’s annual financial statements

B. The approved scope statement, WBS, and WBS dictionary

C. Only the project risk register

D. Only the stakeholder communication plan

Correct Answer: B. The approved scope statement, WBS, and WBS dictionary

Question 6

What is the primary purpose of a requirements traceability matrix?

A. To replace the project schedule

B. To link requirements to their sources, implementation, tests, and acceptance evidence

C. To rank suppliers by price

D. To authorize every procurement contract

Correct Answer: B. To link requirements to their sources, implementation, tests, and acceptance evidence

Question 7

Which action best represents controlled scope change?

A. A developer adds a useful feature without recording it.

B. A stakeholder verbally requests a change and the team implements it immediately.

C. The request is analyzed, authorized, incorporated into affected baselines, and verified.

D. The project manager rejects every request to protect the baseline.

Correct Answer: C. The request is analyzed, authorized, incorporated into affected baselines, and verified.

Question 8

In a weighted scoring model, what does the weight assigned to a criterion represent?

A. The criterion’s relative importance in the comparison

B. The number of people who attended the workshop

C. The duration of the project phase

D. The guaranteed financial return

Correct Answer: A. The criterion’s relative importance in the comparison

Question 9

Which is an example of a transition requirement?

A. The product must support encrypted communication.

B. The project must remain within the approved budget.

C. Historical customer data must be migrated and reconciled before launch.

D. The dashboard must use the corporate color palette.

Correct Answer: C. Historical customer data must be migrated and reconciled before launch.

Question 10

What is gold plating?

A. Testing a deliverable with a higher-quality instrument

B. Adding unrequested features or work beyond approved scope

C. Applying a metallic coating to equipment

D. Correcting a defect before acceptance

Correct Answer: B. Adding unrequested features or work beyond approved scope