Requirements, Architecture and Delivery Planning

Introduction

DevOps begins well before code is written or a deployment pipeline is configured. A team can automate testing and delivery effectively only when it understands what it is building, why it matters, how success will be judged, and what technical structure can support it. Requirements, architecture, and delivery planning connect stakeholder intention with a reliable working product.

Requirements describe desired outcomes and constraints. Architecture provides the structural explanation of how a system will achieve those outcomes. Delivery planning turns the work into an ordered, visible, and adaptable sequence. In DevOps, these activities are not isolated phases completed once at the beginning. They are continuous collaborative practices involving product owners, developers, testers, operations engineers, security specialists, users, and other stakeholders.

A useful planning process therefore seeks sufficient clarity without pretending that all uncertainty can be removed in advance. Requirements evolve as users provide feedback, architecture evolves as evidence is obtained, and backlogs are continually refined according to value, risk, dependency, and learning.

Learning Objectives

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

• distinguish business, functional, and non-functional requirements;
• translate stakeholder needs into user stories and acceptance criteria;
• create and refine a product backlog;
• explain architectural concerns and common architectural styles;
• identify technical debt, dependencies, risks, and constraints;
• use relative estimation and delivery-planning techniques responsibly;
• prioritize work using value, urgency, risk, and effort;
• apply these concepts to a realistic DevOps product scenario;
• recognize governance, security, privacy, accessibility, and ethical responsibilities in planning.

1. From Stakeholder Need to Implementable Requirement

A stakeholder need is an expression of a problem, goal, or desired outcome. It is not necessarily a complete specification. For example, “customers need a faster way to find suitable courses” identifies a problem but does not define the exact interface, performance target, data source, or success measure.

A requirement is a documented and agreed statement of a capability, quality, constraint, or condition that a product must satisfy. Good requirements are understandable, testable, traceable, and connected to a business or user outcome. They should be precise enough to guide implementation while remaining open to learning where uncertainty is high.

Types of requirements

Requirements should be connected through traceability. A business objective may lead to several user outcomes, which lead to functional and non-functional requirements, tests, and operational measures. Traceability does not mean producing paperwork for its own sake; it helps teams explain why a feature exists and what evidence will demonstrate that it works.

Elicitation and discovery

Requirements elicitation is the process of discovering needs, constraints, assumptions, and acceptance conditions. Techniques include interviews, workshops, observation, surveys, document analysis, service blueprints, prototypes, and analysis of support incidents or product analytics.

No single stakeholder possesses the entire truth. Users understand their work, operations staff understand production constraints, security staff understand threats and controls, and product leaders understand organizational priorities. Cross-functional discovery reduces the risk that a seemingly simple feature creates unacceptable operational or compliance consequences.

A useful elicitation conversation asks:

1. Who experiences the problem?
2. What task or outcome is currently difficult?
3. What happens if the problem is not solved?
4. What constraints must be respected?
5. How will users and the organization know that the change is successful?
6. What assumptions remain unverified?

2. User Stories and Acceptance Criteria

A user story is a concise expression of a valuable capability from a user or stakeholder perspective. A common form is:

As a [type of user], I want [capability], so that [benefit or outcome].

For example:

As a learner, I want to filter courses by delivery mode, so that I can find courses compatible with my schedule.

The template is not a complete specification. It provides a reminder that work should be connected to a user and a benefit. A story should be sufficiently small to discuss, estimate, build, and test. The well-known INVEST criteria provide a useful guide: Independent, Negotiable, Valuable, Estimable, Small, and Testable. These are heuristics rather than rigid laws; for example, complete independence is often impossible when a feature has technical dependencies.

Acceptance criteria

Acceptance criteria define the conditions that must be satisfied for a story to be accepted. They make the expected behaviour observable and reduce disagreement between product, development, testing, and operations.

For the course-filter story, acceptance criteria might include:

• the learner can select one or more delivery modes;
• the result list contains only courses matching the selected mode;
• selecting no mode displays all eligible courses;
• the filter is usable with keyboard navigation;
• an automated test verifies the filtering behaviour;
• the response meets the agreed performance target under the stated test conditions.

Acceptance criteria should describe outcomes rather than prescribe unnecessary implementation details. “The system uses database index X” is normally a design decision, whereas “search returns results within two seconds for the agreed workload” is a testable quality condition.

A scenario format can make criteria particularly clear:

• Given the learner is viewing available courses,
• When the learner selects “online”,
• Then only online courses are displayed.

This format is often called Given–When–Then. It supports shared understanding and can later inform automated acceptance tests, but it should not become a substitute for thoughtful analysis.

Definition of Ready and Definition of Done

A team may define a Definition of Ready to indicate that a backlog item is sufficiently understood to enter active development. It might require a clear outcome, acceptance criteria, identified dependencies, and an approximate size.

A Definition of Done states the conditions for completed work. It may include reviewed code, automated tests, security checks, documentation, deployment to the required environment, monitoring, and product acceptance. “Code written” is not equivalent to “done” in a DevOps context. A feature that cannot be operated, observed, secured, or safely released is incomplete.

3. The Product Backlog

A product backlog is an ordered collection of work needed to improve or sustain a product. It may contain features, defects, technical improvements, research or spikes, operational work, security tasks, compliance obligations, and documentation.

The backlog is not merely a list of requests. It is a decision model showing what the product team currently believes will deliver the greatest value or reduce the greatest risk. Items should be ordered, described at an appropriate level of detail, and regularly refined.

Backlog refinement

Refinement is a collaborative activity in which the team:

• clarifies the user or business outcome;
• divides oversized items;
• identifies acceptance criteria;
• exposes assumptions and dependencies;
• considers security, privacy, accessibility, and operations;
• estimates relative size or effort;
• removes obsolete or duplicate items.

Refinement should not attempt to specify every future detail. Items near the top need more precision than distant items because they are more likely to be implemented soon. This is sometimes described as progressive elaboration.

Prioritization

Prioritization is a resource-allocation decision, not a popularity contest. Relevant factors include customer value, strategic alignment, urgency, risk reduction, regulatory importance, learning value, effort, and dependencies.

One useful technique is Cost of Delay divided by Duration (CD3), conceptually similar to the Weighted Shortest Job First approach:

Cost of Delay represents the consequence of postponing an item; Job Duration represents the relative time or effort required. The score is a prioritization aid, not an objective truth. It assumes that the inputs are sufficiently comparable and that high-scoring work can actually be scheduled without violating essential dependencies or controls.

Cost of Delay may be considered through components such as user or business value, time criticality, and risk reduction or opportunity enablement. Teams should avoid false precision: scores such as 7.3 can imply accuracy that the evidence does not support. Relative categories such as low, medium, and high may be more honest.

Example of relative prioritization

Suppose three backlog items have the following illustrative assessments:

Using the stated ratio, the payment security improvement has the highest score. However, if a legal deadline applies to another item, or if the security work is a prerequisite for payment release, the team must incorporate those facts explicitly. A formula cannot replace professional judgment.

4. Architecture as a Set of Important Decisions

Software architecture describes the significant structures of a system, the relationships among those structures, and the principles governing their design and evolution. It includes more than technology selection. Architecture addresses boundaries, responsibilities, data, communication, deployment, security, resilience, observability, and the consequences of design choices.

Architecture is best understood as a set of decisions made under constraints. Important decisions should record:

• the context and problem;
• considered alternatives;
• the selected option;
• reasons for the decision;
• consequences and known risks;
• conditions that might require revisiting it.

A lightweight Architecture Decision Record (ADR) is often sufficient. ADRs prevent teams from repeatedly rediscovering why a decision was made and make trade-offs visible to new team members.

Architectural styles

A layered architecture separates concerns such as presentation, application logic, domain logic, and data access. It is approachable and can support clear responsibilities, but excessive layering may create indirection and slow change.

A modular monolith is a single deployable application whose internal modules have explicit boundaries. It can provide simpler deployment and transactions than distributed systems while preserving many benefits of modular design.

Microservices divide a system into independently deployable services, commonly organized around business capabilities. They can support independent scaling and team autonomy, but introduce network failure, distributed data, observability, deployment, and operational complexity. Microservices are not automatically more modern or more reliable.

An event-driven architecture uses events to communicate that something has happened. It can support loose coupling and asynchronous processing, but requires careful handling of ordering, duplication, replay, schema evolution, and eventual consistency.

A serverless architecture delegates much infrastructure management to a cloud provider. It can accelerate delivery for suitable workloads, while introducing concerns about vendor coupling, execution limits, cost visibility, and local development.

The appropriate architecture depends on product context, team capability, regulatory obligations, expected scale, change frequency, and operational maturity. A small product may be harmed by adopting distributed complexity prematurely.

Architecture and DevOps

DevOps makes architecture operationally consequential. A design should be assessed not only for functional correctness but also for how it will be built, tested, deployed, monitored, secured, recovered, and changed.

The four commonly discussed dimensions of operational readiness are:

• Deployability: Can changes be released safely and repeatably?
• Observability: Can the team understand system behaviour from logs, metrics, traces, and user-impact signals?
• Reliability: Can the system tolerate faults and recover within agreed objectives?
• Security: Are identity, access, data protection, supply-chain, and vulnerability concerns addressed?

Architecture diagrams should show meaningful boundaries and flows, not merely attractive boxes. A useful diagram identifies users, major components, data stores, external systems, trust boundaries, and communication mechanisms. It should be accompanied by prose explaining assumptions.

5. Non-Functional Requirements

Functional requirements describe what a system does; non-functional requirements describe qualities and constraints governing how it does it. Non-functional requirements are often cross-cutting and can dominate architecture and operational cost.

Important categories include:

• performance and capacity;
• availability and reliability;
• scalability and elasticity;
• security and privacy;
• accessibility and usability;
• maintainability and testability;
• portability and interoperability;
• recoverability and data durability;
• auditability and compliance.

A weak requirement such as “the application must be fast” is difficult to test. A stronger statement specifies the measure, workload, percentile, and conditions. For example: “For 95% of search requests, response time shall be no more than 2 seconds with 500 concurrent users and the agreed dataset.” The percentile matters because averages can hide poor experiences for a minority of users.

Requirements should also define service-level objectives (SLOs) where appropriate. An availability target of 99.9% over a stated measurement period permits approximately 0.1% unavailability during that period, but the practical interpretation depends on the measurement window, exclusions, and whether planned maintenance counts. Teams must not present availability figures without defining how they are measured.

Non-functional requirements create trade-offs. Stronger encryption may increase processing cost; higher availability may require redundancy; extensive retention may increase privacy risk and storage cost. These trade-offs should be discussed with stakeholders rather than hidden in implementation.

6. Technical Debt and Sustainable Delivery

Technical debt is the future cost created when a design or implementation choice makes later change, operation, or maintenance more difficult. Like financial debt, it can be deliberate or accidental and may be useful when managed responsibly. It is not a synonym for all old code or for code that an individual dislikes.

Examples include:

• postponing automated tests to meet a deadline;
• using a temporary integration without a removal plan;
• accepting duplicated business logic;
• ignoring dependency upgrades;
• omitting monitoring from a critical service;
• choosing a shortcut that creates security or compliance exposure.

Debt has both a principal—the work needed to improve the situation—and a carrying cost, such as slower delivery, increased incidents, or greater cognitive load. Teams should record debt explicitly, assess its impact, and reserve capacity for reduction. Some debt is intentional and documented; undocumented debt is especially dangerous because future teams may mistake it for a sound design.

Technical debt should not be used to justify unsafe releases. Security vulnerabilities, regulatory violations, and severe reliability risks may require immediate action regardless of feature priorities.

7. Estimation and Capacity Planning

Estimation supports decisions about scope, sequencing, and risk; it does not guarantee a delivery date. Software work contains uncertainty arising from unclear requirements, integration, discovery, defects, and changing priorities.

Relative estimation

Agile teams frequently estimate relative size using story points or size categories. A point is not a universal unit of time. It may combine perceived effort, complexity, and uncertainty. Therefore, points should be used within one team and one working context, not compared as a productivity measure across teams.

Teams may use planning poker to expose different assumptions. The goal is discussion, not mathematical precision. A large spread in estimates is evidence that the item needs clarification or that the team sees different risks.

Velocity and forecasting

Velocity is the amount of estimated work completed by a team in a defined iteration. If a team completes 18, 21, 20, and 23 points in four comparable iterations, its observed average is:

This calculation assumes the iterations are comparable and that the team’s membership, estimation approach, and definition of done are reasonably stable. It should be used for a forecast range, not as a target or individual performance metric. If 82 points remain, a simplistic forecast would be 82 ÷ 20.5 = 4 iterations, but uncertainty in both scope and velocity means the team should communicate a range and update it as evidence arrives.

Flow-based teams may instead track cycle time, throughput, work in progress, and blocked time. Little’s Law is sometimes used in stable systems:

The units must be consistent. For example, if throughput is 5 items per week and average cycle time is 2 weeks, average work in progress is approximately 10 items. The relationship assumes a reasonably stable system over the measurement period; it is not a promise that reducing work in progress alone automatically increases throughput.

8. Dependencies, Risks, and Release Planning

A dependency exists when one item, team, system, supplier, or decision relies on another. Dependencies may be technical, organizational, data-related, environmental, contractual, or regulatory. They should be made visible because hidden dependencies create waiting, rework, and unexpected release risk.

Useful dependency-management practices include:

• identify dependencies during refinement;
• distinguish hard prerequisites from convenient sequencing;
• assign an owner and expected resolution date;
• use interfaces and mocks to reduce blocking;
• negotiate contracts with external teams and suppliers;
• review dependency status during planning;
• remove or redesign unnecessary dependencies.

A risk is an uncertain event or condition that may affect objectives. A simple qualitative risk assessment considers probability and impact. Teams can use a risk register with fields for description, cause, consequence, owner, mitigation, contingency, and review date. A risk is not the same as an issue: a risk may occur; an issue is already occurring.

Release planning should connect product goals to increments of usable value. A release is not merely a date on a calendar. It should specify scope, quality conditions, operational readiness, migration or rollback strategy, communication, and measures of success. Feature flags, canary releases, blue-green deployment, and progressive delivery can reduce exposure, but they do not remove the need for testing, monitoring, or governance.

9. An Illustrative Case: Campus Course Enrolment Platform

Background

A college uses email and spreadsheets to manage short-course enrolments. Learners report that course availability is unclear, administrators duplicate data entry, and instructors receive late updates. The college wants an online platform that improves enrolment while protecting personal information.

Problem analysis

Stakeholder discovery identifies several outcomes:

• learners need to search and enrol in available courses;
• administrators need accurate capacity information;
• instructors need timely class rosters;
• finance staff need reliable payment status;
• the college must protect personal data and provide an audit trail.

The product team converts these needs into initial backlog items. One example is:

As a learner, I want to view available courses by date and delivery mode, so that I can choose a course I can attend.

Acceptance criteria include filtering, clear availability status, keyboard accessibility, and response-time expectations under an agreed test load.

Architecture approach

For the initial release, the team chooses a modular monolith rather than microservices. The product is small, the team is inexperienced with distributed operations, and strong consistency is useful for course capacity and payment status. Modules are defined for catalogue, enrolment, identity, payment integration, and notifications. The design leaves room for later extraction if evidence demonstrates a need.

An ADR records the decision and its consequences. The team also identifies trust boundaries around payment processing and chooses not to store unnecessary card data. Personal data retention and access rules are reviewed with the college’s privacy officer.

Delivery plan

The first increment establishes identity, course catalogue, and administrator capacity management. The second adds learner search and enrolment. Payment integration is developed with a sandbox and contract tests. Notifications and reporting follow after the core enrolment flow is validated.

The backlog includes enabling work: automated deployment, database migration scripts, audit logging, monitoring, backup restoration tests, accessibility testing, and security scanning. These are not optional technical extras; they are part of a usable and governable product.

A pilot release is offered to one department. Product measures include successful enrolment completion, support contacts, failed payments, page performance, and reconciliation accuracy. Feedback reveals that administrators need a waitlist, which is added after assessing its value and operational implications.

Outcome and learning points

The modular approach enables a short pilot without imposing unnecessary distributed-system complexity. Early operational testing discovers a database indexing problem before institution-wide release. The team also learns that “available course” requires a precise definition: capacity, enrolment deadline, payment status, and instructor approval all affect availability.

The case demonstrates that requirements, architecture, and delivery planning are connected. A vague business goal becomes testable user outcomes; architecture reflects scale, risk, and team capability; and delivery includes operational, security, and learning work alongside visible features.

10. Governance, Ethics, and Contemporary Practice

Planning decisions can affect people who are not present in workshops. Teams should consider accessibility, language, digital exclusion, privacy, surveillance, algorithmic bias, and the consequences of service failure. For example, a rule that automatically rejects incomplete applications may disproportionately affect users with disabilities or limited connectivity.

Security and privacy should be addressed from discovery onward. Practices include data minimization, least-privilege access, threat modelling, secure defaults, dependency management, auditability, and explicit retention and deletion rules. Regulatory requirements vary by jurisdiction, so teams must consult appropriate legal and compliance specialists rather than assuming that a generic checklist is sufficient.

Artificial intelligence can assist with backlog summarization, duplicate detection, test-case suggestions, and code or architecture exploration. However, generated material may contain incorrect assumptions, insecure code, copyright concerns, or fabricated requirements. Human review, provenance, privacy controls, and organizational policy remain necessary. AI should support accountable decisions, not obscure who made them.

Contemporary product teams increasingly use continuous discovery, platform engineering, infrastructure as code, policy as code, software supply-chain security, and observability-driven development. These practices are valuable when they solve an actual product or operational problem. Tool adoption alone does not create DevOps capability.

Challenges and Limitations

Requirements can conflict, change, or remain ambiguous. Stakeholders may optimize for local interests rather than system-wide outcomes. User stories can become shallow implementation tickets if teams omit the underlying benefit. Prioritization frameworks can create false objectivity when scores are invented without evidence.

Architecture diagrams can become outdated, and an architecture that is appropriate at one scale may be harmful at another. Estimation is affected by uncertainty and should not be used to punish teams for discovering complexity. Metrics such as velocity can be gamed when treated as targets. Finally, continuous delivery does not mean releasing every change immediately; it means maintaining the ability to deliver safely and choosing release timing responsibly.

The practical response is transparency: record assumptions, expose uncertainty, validate with users, measure outcomes, review decisions, and revise plans when evidence changes.

Best-Practice Checklist

• Express work in terms of outcomes and user value.
• Make acceptance criteria observable and testable.
• Include security, privacy, accessibility, and operational concerns early.
• Keep the backlog ordered, refined, and connected to product goals.
• Use architecture decisions to record trade-offs and consequences.
• Prefer the simplest architecture that satisfies current evidence and constraints.
• Treat technical debt as visible work with a cost, owner, and rationale.
• Use estimates for planning, never as measures of personal worth.
• Make dependencies and risks explicit.
• Plan releases around usable increments, feedback, rollback, and evidence.
• Review product and operational outcomes after delivery.

Chapter Summary

Requirements translate stakeholder problems and goals into capabilities, qualities, constraints, and measurable outcomes. User stories provide a concise user-centred expression of value, while acceptance criteria define observable conditions for successful implementation. A product backlog orders features, defects, technical work, research, and compliance activities according to value, urgency, risk, dependencies, and effort.

Architecture is a set of significant decisions about structure, boundaries, data, communication, deployment, security, and operations. Layered systems, modular monoliths, microservices, event-driven systems, and serverless approaches each have benefits and costs. Non-functional requirements such as performance, reliability, security, accessibility, and recoverability strongly influence architecture and must be testable.

Technical debt is future cost created by choices that make change or operation more difficult. Estimation and forecasting support decisions but contain uncertainty and should not be used as individual performance measures. Dependencies, risks, release conditions, monitoring, migration, and rollback belong in delivery planning. Effective DevOps planning is iterative, evidence-based, ethical, and oriented toward a product’s real outcomes rather than the completion of isolated tasks.

Key Terms

Acceptance criteria: Conditions that a backlog item must satisfy to be accepted.

Architecture: Significant structures, relationships, principles, and decisions governing a software system.

Backlog refinement: Collaborative clarification, decomposition, estimation, and ordering of upcoming work.

Business requirement: An organizational objective or desired outcome.

Cost of Delay: The value, urgency, risk, or opportunity cost associated with postponing work.

Definition of Done: Shared conditions that determine whether work is complete.

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

Event-driven architecture: An architecture in which components communicate through events representing occurrences.

Functional requirement: A capability or behaviour a system must provide.

Non-functional requirement: A quality, constraint, or condition governing system behaviour or operation.

Product backlog: An ordered collection of work for improving or sustaining a product.

Relative estimation: Estimation by comparison of size, complexity, effort, or uncertainty rather than absolute time.

Risk: An uncertain event or condition that may affect objectives.

Service-level objective: A defined target for a service property such as availability or latency.

Technical debt: Future cost caused by choices that make software harder to change, operate, or maintain.

Traceability: The ability to connect objectives, requirements, implementation, tests, and operational evidence.

User story: A concise statement of a valuable capability from a user or stakeholder perspective.

Velocity: The amount of estimated work completed by a team in a defined iteration.

Review Questions

Short Answer Questions

1. What is the difference between a functional and a non-functional requirement?
2. Why are acceptance criteria important?
3. What is the purpose of an Architecture Decision Record?
4. Why should technical debt be made visible in the backlog?
5. What is the difference between a risk and an issue?

Long Answer Questions

1. Explain how a stakeholder need can be transformed into a user story, acceptance criteria, backlog item, and test evidence.
2. Compare a modular monolith and microservices architecture, including their operational implications.
3. Discuss how security, privacy, accessibility, and reliability should influence requirements and architecture.
4. Explain why velocity is useful for forecasting but inappropriate as an individual performance target.
5. Describe a disciplined process for release planning in a DevOps environment.

Analytical / Application Questions

1. A team is asked to implement a high-profile dashboard while a known authentication vulnerability remains unresolved. How should the backlog be analysed and ordered? Justify your answer using value, risk, governance, and delivery considerations.
2. Design three user stories and acceptance criteria for an online library reservation service. Identify at least two non-functional requirements and one dependency.
3. A product team has repeated production incidents because monitoring and rollback were omitted from feature work. Analyse the underlying planning failure and propose changes to the backlog, Definition of Done, architecture decisions, and release process.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a non-functional requirement?

A. The system allows a learner to enrol in a course.

B. The system stores a learner’s selected course.

C. The system returns 95% of search responses within two seconds under the agreed workload.

D. The administrator creates a new course.

Correct Answer: C. The system returns 95% of search responses within two seconds under the agreed workload.

Question 2

What is the primary purpose of acceptance criteria?

A. To select the programming language

B. To define observable conditions for accepting a backlog item

C. To calculate team velocity

D. To replace all architecture decisions

Correct Answer: B. To define observable conditions for accepting a backlog item

Question 3

Which item is most characteristic of a product backlog?

A. Only front-end features

B. Only defects discovered in production

C. An ordered collection containing product, technical, operational, and compliance work

D. A fixed contract that cannot change

Correct Answer: C. An ordered collection containing product, technical, operational, and compliance work

Question 4

A team chooses a modular monolith for an initial product mainly because it wants to avoid unnecessary distributed-system complexity. Which principle does this illustrate?

A. Choose the simplest architecture that satisfies current evidence and constraints

B. Always use microservices for scalability

C. Avoid documenting architecture decisions

D. Treat non-functional requirements as optional

Correct Answer: A. Choose the simplest architecture that satisfies current evidence and constraints

Question 5

A team completes 18, 21, 20, and 23 story points in four comparable iterations. What is its average observed velocity?

A. 19.5 points per iteration

B. 20.5 points per iteration

C. 21.5 points per iteration

D. 82 points per iteration

Correct Answer: B. 20.5 points per iteration

Question 6

Which statement about story points is correct?

A. They are universal units of time across all teams.

B. They should be used to rank individual developer productivity.

C. They are relative estimates interpreted within a team’s context.

D. They eliminate uncertainty from software work.

Correct Answer: C. They are relative estimates interpreted within a team’s context.

Question 7

Using Priority score = Cost of Delay ÷ Job Duration, which item has the highest score?

A. Cost of Delay 8 and Duration 4

B. Cost of Delay 12 and Duration 6

C. Cost of Delay 10 and Duration 2

D. Cost of Delay 15 and Duration 5

Correct Answer: C. Cost of Delay 10 and Duration 2

Question 8

Which practice best addresses hidden dependencies?

A. Avoid discussing dependencies until release day

B. Identify, assign, and review dependencies during refinement and planning

C. Estimate every dependency as zero effort

D. Replace all dependencies with additional documentation

Correct Answer: B. Identify, assign, and review dependencies during refinement and planning

Question 9

Which statement best defines technical debt?

A. Any code written more than one year ago

B. Future cost created by choices that make change or operation harder

C. A financial loan used to purchase servers

D. A defect that has already caused an incident

Correct Answer: B. Future cost created by choices that make change or operation harder

Question 10

Why should AI-generated backlog or code suggestions receive human review?

A. AI output is always too slow to use

B. AI cannot generate any useful technical material

C. Generated output may contain incorrect assumptions, security problems, or privacy and provenance concerns

D. Human review prevents all future changes

Correct Answer: C. Generated output may contain incorrect assumptions, security problems, or privacy and provenance concerns