CPN CPE Software Engineering key terms

A table mapping each requirement to its sources, design elements, code modules, and test cases, so that coverage and the impact of any change can be verified in both directions.

A constraint on how a system performs its functions, such as response time, availability, security, portability, or usability, rather than a description of a behavior the system must exhibit.

A structured description of interactions between an actor and a system that yields an observable result of value, typically capturing main flow, alternate flows, and preconditions and postconditions.

A short, conversation-oriented statement of a need written from the user's perspective, usually with acceptance criteria, intended to be refined through discussion rather than to serve as a complete specification.

The conditions a work item must satisfy to be accepted by the customer or product owner, expressed concretely enough that a tester can decide unambiguously whether each condition is met.

The activity of discovering what stakeholders actually need through techniques such as interviews, workshops, observation, document analysis, and prototyping, before those needs are written down as requirements.

A measurable property of a system such as performance, modifiability, security, or testability, usually expressed in scenarios that state stimulus, response, and measurable response criteria.

A structure in which components are organized into horizontal layers, each using only the layer below through a defined interface, which isolates concerns but can add pass-through overhead and complicate cross-cutting changes.

The degree of interdependence between software modules, ranging from tight coupling through shared global state to loose coupling through narrow, stable interfaces; lower coupling usually improves modifiability and testability.

How strongly the responsibilities inside a single module belong together; high cohesion means a module has one focused purpose, which makes it easier to understand, test, and change independently.

A named, reusable solution to a recurring design problem in a specific context, describing participating roles, collaborations, and consequences rather than providing code that can be copied directly.

A structured scenario-based evaluation in which stakeholders and architects examine how an architecture supports prioritized quality attributes and where competing attributes force tradeoffs.

A design guideline stating that high-level modules should not depend on low-level modules and that both should depend on abstractions, so that policy code is insulated from implementation details.

A design guideline stating that clients should not be forced to depend on methods they do not use, so broad interfaces are split into smaller role-specific ones to reduce coupling and ripple effects.

A design guideline stating that a module should have one reason to change, meaning its responsibilities should be aligned with a single actor or stakeholder concern.

A disciplined sequence of small behavior-preserving code transformations that improves internal structure, performed under test coverage so that external behavior is demonstrably unchanged.

The accumulated cost of shortcuts and deferred design work in a codebase, which manifests later as higher change effort, defects, and reduced velocity unless deliberately repaid.

A surface indication in source code, such as duplicated logic, long methods, or excessive parameters, that often signals a deeper design problem and warrants inspection rather than automatic rewriting.

A practice in which developers merge small changes into a shared mainline frequently, with each merge triggering an automated build and test run to expose integration problems early.

An automated sequence of stages, such as compile, static analysis, unit test, and package, that takes source changes to a verified artifact and reports failure at the earliest failing stage.

A practice that keeps software in a deployable state at all times through automated build, test, and release steps, so that deployment to production is a routine, low-risk business decision.

Any artifact placed under configuration control, such as source files, requirements documents, build scripts, or test data, identified and versioned so that changes can be tracked and audited.

A formally reviewed and approved configuration state that serves as a fixed reference for further development, so that subsequent changes must go through change control.

A group authorized to evaluate change requests against cost, risk, and schedule, and to approve, defer, or reject them, providing traceable decisions for scope and configuration changes.

The assessment of what a proposed change will affect, including requirements, design, code, tests, interfaces, data, and documentation, used to estimate effort and risk before approval.

Re-execution of selected existing tests after a change to confirm that previously working behavior still works and that no unintended side effects were introduced.

An automated test that exercises a single small unit of behavior in isolation, typically with dependencies replaced by test doubles, and runs fast enough for frequent execution.

A stand-in object used in place of a real dependency during testing, such as a stub returning canned data, a mock verifying interactions, or a fake with a lightweight implementation.

Testing in which two or more components or subsystems are combined and exercised together to expose defects in their interfaces, data contracts, sequencing, and error propagation.

Testing of the complete, integrated system against its specified requirements in an environment representative of its intended use, including functional and quality-attribute behavior.

Testing performed to determine whether a system satisfies business needs and agreed acceptance criteria, typically executed by customers or users or by testers acting on their behalf.

A measure of the proportion of code elements, such as statements, branches, or conditions, executed by a test suite, used to find untested areas rather than to prove correctness.

A maintained collection of tests that run without manual intervention, are deterministic and independently repeatable, and report pass or fail results suitable for gating a build.

A collaborative approach in which examples of desired behavior are written in structured natural language, agreed by business and technical stakeholders, and then automated as executable acceptance tests.

An existing system that is still vital to the business but is hard to change safely because of obsolete technology, missing tests, undocumented behavior, or accumulated technical debt.

A set of related systems built from a shared core of common assets and managed variation points, allowing systematic reuse while still serving distinct market or customer needs.

A project control technique that compares planned value, earned value, and actual cost to compute schedule and cost performance indices and forecasts of final cost.

A scheduling technique that models task dependencies as a network and identifies the longest path through it, which determines the minimum project duration and the tasks with zero slack.

A hierarchical decomposition of project scope into deliverable-oriented work packages that can be estimated, assigned, scheduled, and tracked as the basis for planning and control.

A named family of system structures, such as layered, pipe-and-filter, event-driven, or microservices, that prescribes component types and interaction rules along with typical strengths and liabilities.