TEST ARCHED key terms

A documented justification for starting or continuing a project, showing expected benefits, costs, risks, and the rationale for choosing one option over alternatives.

The process of ensuring that the outcomes promised in the business case are actually delivered and measured after the solution goes live.

A short authorizing document that names the project, its sponsor, its objectives, and the authority granted to the project manager before work begins.

A group of related projects managed together so that shared dependencies and combined benefits are coordinated rather than handled project by project.

The full collection of an organization's projects and programs, prioritized and balanced as investments against strategy, capacity, and risk appetite.

The senior executive who owns the business case, secures funding and resources, and resolves escalated issues beyond the project manager's authority.

A decision-making body of senior stakeholders that approves funding, arbitrates priorities, and reviews project health at defined checkpoints.

A planned review point between project phases where funding and continuation are confirmed, conditioned, or withdrawn based on evidence presented.

A table linking each requirement to its source, design element, build component, and test case so coverage and impact can be verified end to end.

The structured activity of drawing requirements out of stakeholders through interviews, workshops, observation, and review of existing systems and documents.

A statement of what the solution must do, expressed as behavior, inputs, processing, and outputs that a user or system can observe.

A constraint on how well the solution performs, covering qualities such as availability, response time, scalability, security, accessibility, and maintainability.

The specific, testable conditions a deliverable must satisfy before the customer or product owner will accept it as complete.

Uncontrolled expansion of project scope through small, unapproved additions that accumulate and erode schedule, budget, and quality margins.

The approved scope statement, work breakdown structure, and dictionary that together define what is in and out of the project.

A hierarchical decomposition of the total project scope into manageable deliverables and work packages that can be estimated, assigned, and tracked.

A short document capturing a significant design decision, the context that forced it, the alternatives considered, and the consequences accepted.

The overall structure of a system: its components, their responsibilities, the interfaces between them, and the principles guiding their evolution.

The specification of how systems exchange data and invoke each other, including protocols, message formats, sequencing, error handling, and retry behavior.

An agreed definition of the inputs, outputs, data types, and failure responses that two components or teams commit to honor across a boundary.

The future cost of rework created by choosing a quick or simpler design now instead of a more robust one that would take longer.

The longest sequence of dependent activities through the schedule; any delay on it pushes the project completion date by the same amount.

The amount of time an activity can slip without delaying the project finish date or violating a constraint on a successor.

A relationship in which one activity, team, or deliverable must be complete or available before another can start or finish as planned.

The smallest release that delivers real value to users and generates feedback, allowing learning before further investment is committed.

A fixed, short timebox in which a cross-functional team completes a selected set of work and produces a potentially usable increment.

A shared checklist stating what completed work must include, such as reviewed code, passing tests, and updated documentation, before it counts as finished.

Confirmation that a work product was built correctly against its specification, typically through reviews, inspections, and static analysis.

Confirmation that the delivered solution meets the real user need and intended use, typically through acceptance testing and user feedback.

Testing performed by or with real users against agreed acceptance criteria to confirm the solution supports their actual tasks before go-live.

Re-running selected existing tests after a change to confirm that previously working behavior has not been broken.

Restructuring existing code or design without changing its external behavior, to reduce complexity and pay down accumulated technical debt.

A living log of identified risks, each with its cause, potential impact, likelihood, owner, response strategy, and current status.

The chosen strategy for handling a risk: avoid, mitigate, transfer, or accept, with concrete actions, an owner, and a trigger condition.

Time or money set aside in the approved baseline to cover known risks that have been identified and assessed but not yet occurred.

Budget held outside the approved baseline for unanticipated work arising from unknown risks, released only through formal change control.

A record of problems that have already occurred, tracking owner, severity, actions taken, and resolution date until each is closed.

The group authorized to review change requests, assess impact on scope, schedule, cost, and quality, and approve, defer, or reject them.

A formal proposal to modify an approved baseline, product, or document, submitted with rationale and impact analysis before a decision is made.

The agreed sequence of people to contact, with timeframes, when a decision or problem exceeds the authority of the current level.

A chart assigning each activity a Responsible doer, an Accountable owner, Consulted contributors, and Informed recipients to prevent ownership gaps.

Identifying everyone affected by or able to influence the project, then mapping their interest, influence, and preferred communication approach.

The agreed schedule and format of information sharing: who receives what, how often, through which channel, and who owns each message.

Structured capture of what worked and what did not during a project, recorded so future teams can reuse the insight rather than repeat mistakes.