PE Software key terms

A written document that records what a software system must do, including functional behaviour, performance limits, interfaces, and constraints. It serves as the shared reference for developers, testers, and clients during design and acceptance.

A statement describing a specific behaviour or service the system must provide, such as computing a result, storing a record, or responding to a user action. It defines what the software does rather than how well it does it.

A constraint on how the system performs its functions, covering qualities such as response time, throughput, availability, security, usability, and portability. These requirements shape architecture and are often verified through measurement rather than inspection.

A description of a sequence of interactions between an actor and a system that produces a measurable result of value. It captures goal-oriented behaviour and is often documented with preconditions, main flow, and alternate flows.

A person, external system, or device that interacts with the software being built. Actors are drawn outside the system boundary and represent roles rather than specific individuals, so one person may fill several roles.

The ability to link each requirement forward to design elements, code, and test cases, and backward to its source. Traceability supports impact analysis when requirements change and helps demonstrate that every requirement has been verified.

The set of high-level design decisions that define a system's major components, their responsibilities, and the rules governing their interaction. Architecture captures the choices that are costly to change later, such as deployment topology and technology stack.

The degree to which a system is composed of discrete, replaceable units with well-defined interfaces. Higher modularity generally improves maintainability and testability because changes stay local to a module instead of rippling across the codebase.

A measure of how strongly related and focused the responsibilities inside a single module are. High cohesion is desirable: a module whose parts all serve one purpose is easier to understand, test, and reuse.

The degree of interdependence between modules, expressed through shared data, call sequences, or knowledge of each other's internals. Low coupling is generally preferred because it reduces the blast radius of changes and simplifies independent testing.

A design principle in which each module conceals internal decisions, such as data structures or algorithms, behind a stable interface. Callers depend only on the published contract, so internals can be revised without breaking other modules.

The bundling of data with the operations that act on it, while restricting direct access to the data from outside. In object-oriented code this is typically achieved with private fields and public methods that enforce invariants.

A named, reusable solution to a recurring design problem within a given context, such as Observer for change notification or Factory for object creation. Patterns communicate intent and trade-offs rather than providing ready-to-paste code.

A structural style in which components are organised into horizontal layers, each providing services to the layer above and consuming services from the layer below. Strict layering limits dependencies but can add pass-through overhead.

A defined contract specifying the operations a component offers, including names, parameters, return values, and error behaviour, without prescribing implementation. Well-designed interfaces are stable and hide the details behind them.

A test that exercises a single small unit of code, such as a function or class, in isolation from external systems. Unit tests run fast and are typically automated and executed frequently during development.

A test that verifies the interaction between two or more components, or between a component and an external system such as a database or message broker. It targets interface defects that isolated unit tests cannot reveal.

Testing of the complete, integrated system against its specified requirements, often in an environment resembling production. It focuses on end-to-end behaviour, interfaces with external systems, and non-functional qualities.

A test that determines whether the delivered software satisfies business needs and is fit for purpose, often derived from user stories or requirements. Customers or their representatives frequently participate in defining and approving these tests.

A stand-in object used in place of a real dependency during testing, including stubs, mocks, fakes, and spies. Doubles make tests deterministic and fast by removing reliance on databases, networks, or clocks.

A test double that records calls made to it and can be programmed to return expected values or raise errors. Tests then assert that the unit under test interacted with its collaborator in the expected way.

A metric describing how much of the code, branches, or requirements a test suite exercises. High coverage can reveal untested areas but does not by itself prove correctness, since tests may lack meaningful assertions.

A test re-run after changes to confirm that previously working behaviour still works. Regression suites guard against unintended side effects of fixes, refactoring, or new features and are usually automated.

A black-box test design technique that divides input data into classes expected to be processed the same way, then tests one representative value per class. It reduces the number of cases while preserving defect-finding power.

A test design technique that selects values at, just below, and just above the edges of input ranges, where defects concentrate. It complements equivalence partitioning by targeting off-by-one and limit-handling errors.

Testing based on specifications and observable behaviour without knowledge of internal code structure. It validates that the software meets its contract and is well suited to independent test teams and acceptance testing.

Testing that uses knowledge of the program's internal structure, such as control flow and data flow, to design cases. Techniques include statement and branch coverage, and the approach often reveals unreachable or dead code.

A tool that records changes to files over time so that specific versions can be retrieved, compared, and merged. Modern distributed systems such as Git give every developer a full repository copy with local history.

An independent line of development within a version control repository, allowing work to proceed without disturbing the mainline. Branches are later integrated through merging or rebasing, and their lifespan affects integration risk.

A situation where two branches change the same part of a file in incompatible ways, so the version control system cannot combine them automatically. A developer must resolve the conflict manually and commit the resolution.

A practice in which developers frequently merge changes into a shared mainline, with each merge triggering an automated build and test run. It surfaces integration defects early and keeps the codebase in a releasable state.

A practice that keeps software in a state where it can be released to production at any time, with automated build, test, and deployment pipelines. Release remains a deliberate business decision rather than a technical bottleneck.

An automated sequence of build, test, and deployment stages that moves code from commit to production. Each stage acts as a quality gate, and failures stop promotion so defects are caught before release.

The disciplined restructuring of existing code to improve readability, design, or performance without changing observable behaviour. It is normally protected by automated tests and applied in small, reversible steps.

The accumulated cost of shortcuts and design compromises that make future changes slower or riskier. Like financial debt, it incurs ongoing interest in the form of extra maintenance effort until it is deliberately repaid.

A systematic examination of source code by peers before it is merged, aiming to find defects, improve design, and share knowledge. Effective reviews are small in scope, timely, and focused on substance rather than style preferences.

The structured set of phases through which software is conceived, built, deployed, and maintained, typically including requirements, design, implementation, testing, and operation. Models such as waterfall, iterative, and agile organise these phases differently.

An iterative, incremental approach that delivers working software in short cycles and welcomes changing requirements. It emphasises collaboration, feedback, and small cross-functional teams over extensive up-front documentation.

An agile framework built around fixed-length sprints, defined roles such as Product Owner and Scrum Master, and artefacts including the product backlog. Daily stand-ups and sprint reviews provide short feedback loops and transparency.

A fixed timebox, commonly one to four weeks, during which an agile team builds a potentially shippable product increment. Scope is agreed at the start and protected from uncontrolled change until the sprint review.