ACM-SW key terms

The activity of discovering what stakeholders actually need from a system, using interviews, workshops, observation, and document study, before any of it is written down as a formal requirement.

A statement describing a behavior or service the system must provide, such as computing a total or sending a notification, expressed so that a test can confirm whether it is satisfied.

A constraint on how well the system performs its functions, covering qualities such as response time, availability, security, usability, or portability, rather than a specific behavior.

Any person or group affected by or interested in a system, including users, customers, operators, regulators, and maintainers, whose concerns must be identified and reconciled during requirements work.

Concrete, checkable conditions that a work item must meet to be accepted by the customer, written before development so that both sides agree on what done means.

A description of a sequence of interactions between an actor and a system that produces a result of value to that actor, typically covering a main success path and alternative paths.

A role played by a person, device, or external system that interacts with the system under design, defined by what it does rather than by a specific individual.

A short, plain-language statement of a need from a user's perspective, often written as a role, a goal, and a benefit, intended to prompt conversation rather than replace detailed specification.

The ability to follow the life of a requirement in both directions, linking it to its source and to the design elements, code, and tests that realize and verify it.

A measurable property of a system such as performance, modifiability, or security, often expressed through scenarios that state a stimulus, the system's response, and a measurable outcome.

The fundamental organization of a system embodied in its components, their relationships to each other and the environment, and the principles guiding its design and evolution.

A named, reusable solution to a recurring design problem in a given context, describing the roles of participating elements and how they collaborate rather than providing finished code.

The degree to which the responsibilities inside a single module belong together and serve one purpose; high cohesion makes a module easier to understand, test, and change.

The degree of interdependence between modules, measured by how much one must know about another; low coupling limits the ripple effect of changes across a system.

The property of a system built from parts that can be understood, changed, and tested somewhat independently, achieved by careful separation of concerns and well-defined interfaces.

A defined boundary through which two components interact, specifying the operations, inputs, outputs, and constraints one side exposes while hiding its internal implementation.

A disciplined change to the internal structure of code that improves readability or design without altering observable behavior, usually performed in small steps backed by automated tests.

The accumulated cost of shortcuts and expedient choices in a codebase that make future changes harder, analogous to interest paid until the debt is deliberately repaid.

A systematic examination of source changes by people other than the author, aimed at finding defects, checking standards, and spreading knowledge before the change is merged.

A surface symptom in source code, such as long methods or duplicated logic, that suggests a deeper design problem and often signals where refactoring is worthwhile.

An agreed set of rules for naming, formatting, and structuring source code within a project, which reduces friction in reading and reviewing code and can be partly automated.

Examination of source or compiled code by tooling without executing it, used to detect defects, style violations, and risky constructs early and cheaply.

An automated test that exercises a single small piece of production code in isolation, typically with dependencies replaced by test doubles, and runs fast enough to be run often.

A test that exercises two or more real components together to verify that their interactions, data exchange, and interfaces work as intended.

A stand-in object substituted for a real dependency during testing, such as a stub returning canned data or a mock recording calls, to isolate the code under test.

Re-running a chosen set of existing tests after a change to confirm that previously working behavior still works and that nothing unintended broke.

Confirmation by examination and testing that a work product meets the requirements and standards specified for it, answering the question of whether the product was built right.

Confirmation that the product actually fulfills its intended use and stakeholder needs in its real environment, answering the question of whether the right product was built.

A black-box test design technique that selects inputs at and just around the edges of valid input ranges, where defects are statistically most likely to appear.

A black-box test design technique that divides input space into classes expected to be handled alike, then tests one representative value from each class to reduce redundant cases.

A documented set of preconditions, inputs, and expected results assembled to verify a specific behavior or requirement, reusable for regression runs.

A system that records changes to files over time, allowing authors to retrieve earlier versions, work on parallel branches, and merge contributions with a traceable history.

A formally approved and fixed version of a configuration item or set of items that serves as the reference point for further development and can be changed only through change control.

The formal process by which proposed changes to a baselined product are recorded, evaluated for impact, approved or rejected, and then implemented and verified.

The discipline of identifying configuration items, controlling their changes, recording their status, and auditing them so that the exact composition of a product is known at all times.

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 quickly.

A simplified representation of the activities, artifacts, roles, and sequencing used to develop software, such as waterfall, iterative, or incremental approaches.

The full span of a product from concept and requirements through design, construction, testing, release, maintenance, and eventual retirement, each phase with its own activities and outputs.

An approach that favors short iterations, frequent delivery of working software, close collaboration with customers, and responsiveness to change over comprehensive up-front documentation.

The work of modifying software after release to correct faults, adapt to new environments, improve performance, or add features, which typically consumes most of a system's total cost.

A quantitative measure of some attribute of a product or process, such as cyclomatic complexity or defect density, used to understand, compare, or predict software quality.

The planned and systematic activities, including process definition, reviews, audits, and measurement, intended to give confidence that quality objectives are being met.

A published set of principles, such as those from ACM or IEEE, that guides practitioners to act in the public interest, honor confidentiality, and disclose conflicts or unsafe products.

A situation in which a practitioner's personal, financial, or other interest could improperly influence professional judgment, which must be disclosed or avoided.

Legally protected rights in creations of the mind, such as copyright, patents, and trade secrets, which constrain how software, code, and documentation may be used or redistributed.