Requirements Quality and Traceability

Introduction

Requirements are the foundation on which software scope, architecture, design, testing, procurement, acceptance, and operational support are built. A requirement describes a needed capability, condition, constraint, or quality attribute of a product or service. When requirements are vague, contradictory, incomplete, or impossible to test, defects are likely to appear throughout the project. These defects are expensive because they are often discovered only after design, coding, integration, or deployment.

Requirements quality management is therefore more than proofreading a requirements document. It is a disciplined process of examining whether requirements express genuine stakeholder needs, whether they can be understood consistently, whether the set of requirements is complete and coherent, and whether compliance can be demonstrated. Traceability complements this work by linking requirements to their sources, related requirements, design elements, implementation work, tests, defects, and acceptance evidence.

This chapter focuses on practical foundations for certificate-level software project management. It treats requirements as managed project assets rather than static paperwork. The chapter also explains baselines, change control, requirement risks, acceptance criteria, and the use of traceability in governance and quality assurance.

Learning Objectives

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

1. Explain the characteristics of high-quality software requirements.
2. Assess requirements for clarity, completeness, consistency, feasibility, and testability.
3. Distinguish stakeholder needs, business requirements, user requirements, and system requirements.
4. Write useful acceptance criteria using measurable conditions.
5. Establish and control a requirements baseline.
6. Identify and manage risks associated with requirements.
7. Construct and use a requirements traceability matrix.
8. Apply traceability to impact analysis, testing, change control, and acceptance.
9. Recognise limitations, ethical concerns, and governance responsibilities in requirements management.

1. The Nature and Role of Requirements

A requirement may be a capability that a system must provide, a condition that it must satisfy, or a constraint on how it is developed or operated. For example:

• A business requirement might state that customers must be able to renew a subscription online.
• A user requirement might state that a customer can select a renewal plan and receive confirmation.
• A system requirement might specify that the system shall display available plans based on the customer’s account status.
• A non-functional requirement might state that 95% of renewal requests shall receive a response within two seconds under defined load conditions.

These statements operate at different levels of abstraction. Confusing them can cause omissions or unnecessary detail. A project manager should ensure that requirements are sufficiently detailed for their intended audience while preserving alignment with business objectives.

Requirements and project quality

Software quality is not only the absence of coding defects. A system can be implemented exactly as specified and still fail if the specification does not represent the users’ needs. This distinction is sometimes expressed as:

• Verification: Are we building the product correctly against the stated requirements?
• Validation: Are we building the right product for its intended purpose?

Requirements reviews support both activities. Validation examines business value and stakeholder need; verification examines the precision and internal quality of the requirements.

Levels of requirements

A coherent requirements set should preserve relationships among these levels. A detailed system requirement that cannot be related to a business or stakeholder need may represent unnecessary scope. Conversely, a business objective with no supporting system requirements may not be deliverable.

2. Characteristics of High-Quality Requirements

Several quality characteristics are widely used in requirements engineering and quality assurance. No single checklist guarantees quality, but the following characteristics provide a strong practical assessment framework.

2.1 Correctness and validity

A requirement is correct when it represents a genuine need or approved constraint. Correctness cannot be judged solely by grammar. A grammatically perfect requirement may still be wrong if it reflects an outdated policy or an assumption that stakeholders have rejected.

Questions for assessment include:

• Has the appropriate stakeholder confirmed the need?
• Is the requirement consistent with the business case and policy?
• Does it describe a need rather than an accidental design preference?
• Is its priority appropriate?

2.2 Clarity and unambiguity

A requirement should have one reasonable interpretation. Words such as “user-friendly,” “quick,” “appropriate,” “simple,” and “as soon as possible” are often ambiguous unless defined operationally.

Weak statement: “The system shall quickly produce useful reports.”

Improved statement: “For a report containing up to 50,000 transactions, the system shall display the completed report within 10 seconds for at least 95% of requests measured during the agreed performance test.”

The improved statement defines an observable result, a workload, a target, and a measurement context.

Ambiguity can also arise from grammar. “The manager shall approve requests and notifications” could mean that the manager approves both requests and notifications, or that approval generates notifications. Separate requirements are safer.

2.3 Completeness

A requirements set is complete when it contains all necessary capabilities, constraints, quality attributes, external interfaces, business rules, error conditions, and acceptance information within the agreed scope. Completeness is difficult to prove absolutely; it is normally assessed through structured elicitation, scenarios, process models, stakeholder review, and coverage analysis.

Typical omissions include:

• failure and exception handling;
• security and privacy requirements;
• accessibility;
• audit records;
• data retention and deletion;
• performance under realistic load;
• regulatory obligations;
• migration and transition activities;
• user roles and authorization boundaries.

A useful technique is to examine each major user scenario for normal, alternative, and exceptional flows.

2.4 Consistency

Requirements are consistent when they do not conflict with one another or with approved constraints. Conflicts may be direct or indirect. For example, one requirement may require data to be retained for seven years while another requires automatic deletion after two years. A security requirement may also conflict with a usability expectation if no acceptable authentication method has been defined.

Consistency should be checked across:

• terminology and definitions;
• business rules;
• data formats and units;
• roles and permissions;
• timing and performance targets;
• legal, security, and privacy obligations;
• assumptions and constraints.

A controlled glossary reduces the risk that the same word is used with different meanings.

2.5 Feasibility and realism

A requirement is feasible when it can be implemented within the project’s technical, financial, legal, schedule, and organisational constraints. Feasibility does not mean that implementation is easy. It means that an acceptable solution is reasonably achievable.

Feasibility assessment should involve relevant specialists. For example, a proposed response time may be feasible for a small data set but unrealistic when combined with a requirement to process millions of records on existing infrastructure.

2.6 Testability and verifiability

A requirement is testable when objective evidence can determine whether it has been satisfied. Testability usually requires a measurable condition, defined input, observable output, and stated tolerance where appropriate.

Weak statement: “The application shall be secure.”

Improved statement: “After five failed login attempts within 15 minutes, the account shall be locked for 30 minutes and the event shall be recorded in the security audit log.”

Testability does not mean that every requirement must have a fully automated test. Inspection, analysis, demonstration, and review may also be valid verification methods. However, the verification method should be known before acceptance.

2.7 Modifiability and prioritisation

Requirements should be organised so that a change to one item does not require rewriting an entire document. Each requirement should have a unique identifier, a clear owner, a status, and a priority. Common priority schemes include Must, Should, Could, and Won’t for a defined release, although the chosen scheme must be understood by the project team.

2.8 Traceability

A requirement is traceable when its origin and relationships can be followed. Traceability is discussed in detail later, but it should be designed into the requirements process from the beginning rather than added at the end.

3. Requirement Writing and Acceptance Criteria

A practical requirement template may include:

A useful system-requirement form is: “The system shall [observable behaviour] under [defined conditions].” This form is not mandatory, but it encourages precision and avoids describing implementation prematurely.

Acceptance criteria

Acceptance criteria are conditions that must be met for a requirement, feature, or increment to be accepted. They should be agreed before development is considered complete. Good criteria are:

• specific;
• observable;
• measurable where possible;
• relevant to the requirement;
• achievable within the agreed scope;
• linked to an acceptance method.

For a password-reset feature, criteria might include:

1. A registered user can request a reset using a verified email address.
2. The reset link expires after 30 minutes.
3. The link can be used only once.
4. A successful reset requires a password that meets the published password policy.
5. The system records the reset event without storing the password in readable form.

Acceptance criteria should cover positive, negative, and boundary conditions. They should not prescribe unnecessary internal design. “The system shall use framework X” is usually a design or technology constraint, not a user-facing functional requirement, unless the constraint is genuinely required.

Example of refinement

Initial statement: “Users should be able to download invoices easily.”

Issues: “should” may indicate optional priority; “easily” is subjective; file format, permissions, and failure behaviour are missing.

Refined requirement: “An authenticated account administrator shall be able to download an invoice for any settled transaction from the account history in PDF format. The download shall begin within five seconds for invoices up to 10 MB under normal operating conditions. If the invoice is unavailable, the system shall display an explanatory message and record the incident.”

This statement can be decomposed into smaller requirements if the project’s documentation standard requires one obligation per requirement.

4. Reviewing Requirements Systematically

Requirements reviews should be planned activities, not informal conversations held only when defects appear. A review may include the product owner, business analyst, subject-matter experts, developers, testers, security specialists, operations representatives, and, where relevant, legal or compliance advisers.

Review methods

1. Individual inspection: A reviewer examines each requirement against a checklist.
2. Peer review: Several participants discuss defects and proposed corrections.
3. Scenario walkthrough: Participants follow realistic user and system scenarios.
4. Model review: Process, data, state, or interface models are examined for coverage and consistency.
5. Prototype evaluation: Stakeholders assess an early representation of the intended behaviour.
6. Formal approval review: Authorised representatives decide whether the set can be baselined.

Reviews should record findings, decisions, owners, and due dates. A requirement should not be marked approved merely because no reviewer raised an objection; the review must also establish that relevant stakeholders participated and that evidence is sufficient.

A practical quality checklist

For every requirement, ask:

• Is it necessary and within scope?
• Is the source known and authorised?
• Is the wording unambiguous?
• Does it contain only one main obligation?
• Are terms and units defined?
• Is it consistent with related requirements?
• Is it feasible under known constraints?
• Can it be verified by an identified method?
• Are normal, exceptional, and boundary conditions addressed?
• Is its priority, owner, status, and rationale recorded?

For the set as a whole, ask:

• Are all business objectives supported?
• Are all important stakeholders represented?
• Are interfaces and external dependencies covered?
• Are security, privacy, accessibility, performance, and operational needs addressed?
• Are there duplicate, conflicting, or orphan requirements?

5. Baselines and Configuration Control

A requirements baseline is a formally reviewed and approved version of requirements that serves as a reference for subsequent work. A baseline is not necessarily perfect or unchangeable. It is a controlled agreement about what the project currently intends to deliver.

Before baselining, the team should establish:

• the scope and release to which the baseline applies;
• the approval authority;
• the version identifier and effective date;
• the status of unresolved issues;
• the process for submitting and evaluating changes;
• the location and access controls for the authoritative version.

Baseline change process

A controlled change process commonly follows these steps:

1. A stakeholder submits a change request with rationale.
2. The request is logged and classified.
3. The team analyses impact on scope, cost, schedule, architecture, testing, operations, risk, and contractual obligations.
4. Appropriate decision-makers approve, reject, defer, or request more information.
5. Approved changes are incorporated into controlled artefacts.
6. Traceability links, test plans, estimates, and baselines are updated.
7. Stakeholders are informed and the new version is identified.

The purpose of change control is not to prevent all change. Requirements inevitably evolve as knowledge improves. The purpose is to make changes visible, evaluated, authorised, and communicated.

Versioning and status

A requirement may have statuses such as Proposed, Under Review, Approved, Implemented, Verified, Rejected, Superseded, or Retired. Status definitions should be agreed because “complete” can mean implemented, tested, accepted, or deployed, each of which is different.

6. Requirement Risk Management

A requirement risk is an uncertain event or condition related to requirements that may affect project objectives. Examples include an unclear regulatory interpretation, an unvalidated stakeholder assumption, a dependency on an external interface, or a performance target that has not been demonstrated.

Typical requirement risks include:

• Ambiguity risk: different people interpret the requirement differently.
• Volatility risk: the requirement is likely to change frequently.
• Dependency risk: fulfilment depends on another team, supplier, system, or policy.
• Feasibility risk: technical or operational feasibility is uncertain.
• Omission risk: a necessary capability or quality attribute has not been identified.
• Conflict risk: requirements or stakeholder expectations contradict one another.
• Compliance risk: the requirement does not adequately address law, regulation, contract, or policy.
• Acceptance risk: stakeholders have not agreed how satisfaction will be demonstrated.

A simple qualitative risk assessment uses likelihood and impact categories. A project may record a risk rating as a combination of these categories, but the method must be defined consistently. For example, a team may classify likelihood and impact as Low, Medium, or High and use a risk matrix to identify items requiring immediate action. Such ratings are decision aids, not precise measurements.

Risk responses include:

• Avoid: change the scope or approach to remove the risk.
• Reduce: perform discovery, prototyping, clarification, or early testing.
• Transfer: allocate responsibility through a contract or specialist supplier, while retaining appropriate oversight.
• Accept: monitor the risk when further action is disproportionate.

Risk owners should be named, and trigger conditions and response actions should be documented. High-risk requirements should often receive earlier validation, prototyping, or test design.

7. End-to-End Requirements Traceability

Traceability provides evidence of relationships among requirements and project artefacts. A typical chain is:

Business objective → stakeholder need → user requirement → system requirement → design element → implementation item → test case → defect or result → acceptance evidence.

Traceability may be forward, from a source requirement to implementation and verification, or backward, from a design or test artefact to the requirement it supports. Both directions are valuable.

Requirements Traceability Matrix

A Requirements Traceability Matrix (RTM) is a structured record of links. A simplified example is shown below.

An RTM should be maintained as a living project artefact. It may be implemented in a requirements tool, issue tracker, spreadsheet, or integrated development platform. The tool matters less than the quality of identifiers, relationships, ownership, and maintenance.

Uses of traceability

Traceability supports:

• impact analysis when a requirement changes;
• test coverage assessment;
• identification of untested or orphan requirements;
• demonstration of contractual or regulatory compliance;
• release planning and scope control;
• defect investigation;
• audit and acceptance evidence;
• communication among business and technical participants.

Traceability does not prove that a requirement is correct. A perfectly linked requirement can still be unnecessary or misunderstood. Traceability is evidence of coverage and relationship, not a substitute for judgement.

Coverage measures

Teams sometimes calculate simple coverage indicators. For example, requirements test coverage can be expressed as:

The numerator counts approved requirements linked to a planned verification activity, and the denominator counts all approved requirements in the defined scope. The percentage is meaningful only when the links are valid and when the verification activities are adequate. A high percentage can be misleading if tests are superficial or if important quality attributes are absent from the denominator.

Similarly, the percentage of requirements with an identified source can be calculated using the same structure. These are management indicators, not direct measures of product quality.

8. Applying Traceability to Change and Testing

Suppose REQ-03, “search response within two seconds,” changes to “within one second for the same workload.” A traceability-enabled team can identify:

• the business or operational source of the change;
• performance assumptions and capacity constraints;
• affected architecture and infrastructure decisions;
• revised development tasks;
• performance test cases and test environments;
• cost and schedule impacts;
• risks introduced by the tighter target;
• acceptance evidence required for release.

Without traceability, the requirement document may be changed while a test plan, estimate, or design decision remains based on the old target. This creates hidden scope and acceptance disputes.

Traceability also helps testers design tests from requirements rather than from implementation alone. Each acceptance criterion should be linked to one or more verification activities. Conversely, a test with no valid requirement link should be examined: it may be valuable exploratory testing, or it may represent unapproved scope.

9. Illustrative Case: Municipal Permit Portal

The following is a fictional illustrative case.

Background

A municipality plans an online portal for building-permit applications. The project includes application submission, document upload, fee payment, status tracking, staff review, notifications, and records retention.

Problem

An initial requirements document states that the portal must be “fast, secure, easy to use, and compliant.” Different departments interpret these statements differently. Staff expect complete audit histories, applicants expect mobile access, and the records office requires retention for a defined period. The supplier estimates the project using only the submission screen and does not include payment failure handling or accessibility testing.

Analysis

A review identifies several weaknesses:

• quality attributes are subjective and lack measures;
• payment, notification, and document-validation exceptions are omitted;
• no requirement identifies who may view confidential documents;
• retention obligations conflict with an assumption of automatic deletion;
• no acceptance criteria exist for mobile or accessibility support;
• requirements are not linked to tests or policy sources.

The project manager establishes a requirements register and assigns identifiers. Workshops with applicants, permitting staff, information security, records management, and finance produce scenarios and a glossary. Each requirement receives a source, owner, priority, acceptance criteria, and risk rating.

Approach and solution

The team refines the requirements, for example:

• “An applicant shall submit a completed permit application with mandatory fields identified before submission.”
• “The portal shall reject files that exceed the approved size or prohibited-type limits and shall explain the reason to the applicant.”
• “Only authorised permitting staff assigned to the relevant jurisdiction shall view submitted confidential documents.”
• “The system shall record submission, review, payment, and status-change events with timestamp, actor, and action.”
• “The service shall conform to the accessibility standard adopted by the municipality, with conformance assessed through automated checks and representative manual review.”

The team creates an RTM linking municipal policy, user scenarios, system requirements, design components, security tests, accessibility checks, and user-acceptance tests. A baseline is approved for the first release. A change-control group reviews a later request to add online appeals and determines that it belongs in a subsequent release because it affects workflow, records retention, notifications, and staffing.

Outcome

The project avoids a late dispute about what “secure” and “easy to use” mean. Missing exception paths are identified before development. Testers can prepare acceptance tests early, and managers can explain the impact of proposed changes. The portal is not guaranteed to be defect-free, but its scope and evidence of acceptance are substantially clearer.

Learning points

1. Quality attributes require operational definitions.
2. Requirements must include exceptions and stakeholder responsibilities.
3. Regulatory and records obligations should be traced to system behaviour and evidence.
4. Baselines support agreement but must be governed through controlled change.
5. Traceability improves decision-making when it connects business intent to acceptance evidence.

10. Governance, Ethics, and Responsible Use of Tools

Requirements decisions can affect access to services, privacy, safety, employment, and financial outcomes. Stakeholders with less organisational power may be underrepresented. A responsible process therefore seeks inclusive participation and examines consequences for vulnerable users.

Important governance practices include:

• protecting personal and confidential information in requirements repositories;
• limiting access according to legitimate need;
• recording the source and authority for regulatory requirements;
• avoiding discriminatory or inaccessible assumptions;
• documenting unresolved disagreements rather than hiding them;
• ensuring that acceptance is not declared by a person lacking appropriate authority;
• preserving an audit trail for significant changes.

Artificial intelligence tools can assist with classifying requirements, identifying duplicate phrases, suggesting missing scenarios, or generating draft test ideas. However, AI-generated text can reproduce ambiguity, invent assumptions, omit minority needs, or expose confidential information. Human stakeholders remain responsible for correctness, approval, privacy, and regulatory compliance. AI suggestions should be treated as review inputs, not authoritative requirements.

11. Challenges and Limitations

Requirements quality is constrained by uncertainty. Stakeholders may not yet understand what they need, markets may change, and technical feasibility may be unknown. Excessive documentation can also become burdensome and discourage maintenance. The appropriate level of formality depends on project size, risk, regulation, contract, and delivery method.

Other challenges include:

• requirements that evolve continuously in agile environments;
• disagreement between stakeholder groups;
• pressure to begin coding before clarification;
• over-specification of design rather than outcomes;
• traceability links that become obsolete;
• metrics that reward the number of documents rather than useful evidence;
• false confidence caused by a high coverage percentage.

These limitations do not invalidate quality practices. They show why requirements management must combine structured artefacts with conversation, prototyping, domain expertise, testing, and continual validation.

Best-Practice Guidance

A project team should:

1. Start with business outcomes and stakeholder needs.
2. Use unique identifiers and a controlled glossary.
3. Write observable, testable requirements and separate distinct obligations.
4. Include normal, alternative, failure, security, privacy, accessibility, and operational conditions.
5. Record source, rationale, owner, priority, status, assumptions, and acceptance criteria.
6. Review requirements with appropriate business and technical participants.
7. Baseline approved scope and control changes transparently.
8. Identify requirement risks early and assign owners.
9. Maintain forward and backward traceability to design, implementation, tests, defects, and acceptance evidence.
10. Use metrics as indicators for investigation, not as substitutes for professional judgement.
11. Revalidate requirements when context, law, technology, or stakeholder needs change.
12. Treat tools, including AI tools, as aids that require accountable human review.

Chapter Summary

High-quality requirements are correct, clear, complete, consistent, feasible, testable, modifiable, prioritised, and traceable. They translate business and stakeholder needs into agreed capabilities and constraints without imposing unnecessary design decisions. Acceptance criteria make expectations observable and provide a basis for verification and user acceptance.

Requirements reviews use inspections, walkthroughs, scenarios, models, prototypes, and formal approval to identify defects before they spread into design and implementation. A requirements baseline establishes a controlled reference point, while change control ensures that new or altered requirements are evaluated for their effects on scope, cost, schedule, risk, architecture, testing, and operations.

Requirement risks include ambiguity, volatility, omission, dependency, feasibility, conflict, compliance, and acceptance risk. Traceability connects objectives and sources to requirements, design, implementation, tests, defects, and acceptance evidence. It supports impact analysis, coverage assessment, auditability, and release decisions, but it cannot replace validation or professional judgement. Ethical governance requires inclusive stakeholder involvement, protection of sensitive information, attention to accessibility and fairness, and accountable human oversight of automated tools.

Key Terms

Requirement: A capability, condition, or constraint needed by a stakeholder or system.

Business requirement: A statement of the organisational objective or value sought.

Stakeholder requirement: A need expressed from the perspective of an interested party.

System requirement: A detailed, verifiable capability or constraint of the system.

Functional requirement: A required behaviour or service provided by the system.

Non-functional requirement: A quality attribute or constraint, such as performance, security, or accessibility.

Acceptance criteria: Conditions and evidence used to decide whether a requirement or feature is accepted.

Verification: Evaluation of whether the product conforms to specified requirements.

Validation: Evaluation of whether the product addresses the intended need.

Ambiguity: Wording that permits more than one reasonable interpretation.

Completeness: The extent to which necessary requirements and conditions are included.

Consistency: The absence of contradictions among requirements and constraints.

Testability: The ability to determine objectively whether a requirement is satisfied.

Baseline: An approved and controlled version used as a reference for project work.

Change control: A process for evaluating, approving, implementing, and communicating changes.

Requirement risk: Uncertainty related to requirements that may affect project objectives.

Traceability: The ability to follow a requirement’s sources and relationships to other artefacts.

Requirements Traceability Matrix: A record linking requirements to sources, work products, tests, and evidence.

Orphan requirement: A requirement lacking an appropriate source, implementation link, or verification link.

Glossary: A controlled list of terms and their agreed meanings.

Review Questions

Short Answer Questions

1. What is the difference between verification and validation?
2. Why are words such as “quick” and “user-friendly” problematic in requirements?
3. What is the purpose of a requirements baseline?
4. Name four common requirement risks.
5. What information should be recorded for each requirement besides its statement?

Long Answer Questions

1. Explain the main quality characteristics of a good requirement and show how they can be assessed.
2. Describe a controlled requirements change process from submission through implementation.
3. Explain how acceptance criteria improve communication between stakeholders, developers, and testers.
4. Discuss the purposes and limitations of a Requirements Traceability Matrix.
5. Explain how security, privacy, accessibility, and regulatory obligations should influence requirements management.

Analytical / Application Questions

1. A requirement states: “The system shall provide a secure and easy-to-use customer portal.” Identify at least four weaknesses and rewrite it into several more testable requirements.
2. A new legal rule requires customer records to be retained for ten years instead of three. Using traceability, explain which project artefacts and stakeholders should be examined before approving the change.
3. A project has 100 approved requirements, of which 90 are linked to at least one planned test. Explain what a reported 90% test coverage might indicate, and why it does not by itself prove that the product is high quality.

Multiple Choice Questions with Answers

Question 1

Which characteristic means that a requirement can be assessed objectively to determine whether it has been satisfied?

A. Testability

B. Volatility

C. Traceability

D. Priority

Correct Answer: A. Testability

Question 2

Which statement best describes a requirements baseline?

A. An informal list of ideas collected during interviews

B. An approved and controlled version used as a reference

C. A final test report issued after deployment

D. A design document containing source code

Correct Answer: B. An approved and controlled version used as a reference

Question 3

Which is the strongest acceptance criterion for a password-reset link?

A. The link should be convenient for users

B. The link should be reasonably secure

C. The link shall expire after 30 minutes and be usable once

D. The link shall use modern technology

Correct Answer: C. The link shall expire after 30 minutes and be usable once

Question 4

What is the primary purpose of forward traceability?

A. To connect implementation and tests back to requirements

B. To remove all requirement changes

C. To replace stakeholder validation

D. To estimate programmer productivity

Correct Answer: A. To connect implementation and tests back to requirements

Question 5

A requirement that uses the word “quickly” without defining a response time is mainly deficient in which quality?

A. Clarity

B. Version control

C. Ownership

D. Source identification

Correct Answer: A. Clarity

Question 6

Which activity is most appropriate after a proposed requirement change is submitted?

A. Implement it immediately to avoid delay

B. Delete the original requirement without recording the change

C. Analyse impacts on scope, cost, schedule, risks, design, and testing

D. Reject it automatically because baselines cannot change

Correct Answer: C. Analyse impacts on scope, cost, schedule, risks, design, and testing

Question 7

A requirement with no known stakeholder, policy, business objective, or other legitimate origin is best described as having a traceability problem involving its:

A. Source

B. Performance

C. Interface

D. Deployment

Correct Answer: A. Source

Question 8

Which of the following is an example of an exception condition that should be covered in requirements?

A. The normal user login screen is displayed

B. A payment failure produces an explanatory message and an audit record

C. The project team holds a planning meeting

D. The product owner attends a demonstration

Correct Answer: B. A payment failure produces an explanatory message and an audit record

Question 9

If 90 of 100 approved requirements have at least one planned verification activity, what is the stated test coverage?

A. 9%

B. 10%

C. 90%

D. 100%

Correct Answer: C. 90%

Question 10

Why should AI-generated requirements be reviewed by accountable humans?

A. AI tools always produce syntactically invalid text

B. AI suggestions may contain omissions, invented assumptions, bias, or confidentiality risks

C. AI cannot identify duplicate phrases

D. Human review prevents all future requirement changes

Correct Answer: B. AI suggestions may contain omissions, invented assumptions, bias, or confidentiality risks