PASC key terms

A statement describing a capability, characteristic, or constraint that a software system must satisfy. It can describe what users need, what the system must do, or a restriction on how it is built.

A requirement that specifies a behavior or function the system must perform, such as computing a total or authenticating a user. It describes what the software does in response to given inputs.

A requirement describing a quality attribute or constraint rather than a behavior, such as performance, security, usability, or availability. These shape how well the system performs its functions and are often harder to verify.

A description of a sequence of interactions between an actor and a system that yields an observable result of value. It captures a goal-oriented scenario and its alternate paths.

A person, role, or external system that interacts with the system under design to accomplish a goal. Actors are drawn from outside the system boundary and may be human or automated.

Concrete, testable conditions that a work item must satisfy to be accepted by the customer or product owner. They clarify intent and form the basis for verification tests.

The ability to link requirements forward to design elements, code, and tests, and backward to their sources. It supports impact analysis when requirements change and helps confirm coverage.

The activity of discovering stakeholder needs through techniques such as interviews, workshops, observation, and prototyping. Its goal is to surface both stated and unstated requirements before specification.

Any individual or group with an interest in the system or affected by its outcomes, including users, sponsors, operators, and regulators. Their needs and constraints inform requirements and priorities.

The set of fundamental structural choices of a system: its major components, their responsibilities, their interactions, and the principles and constraints guiding them. It captures decisions that are costly to change later.

A named family of system structures with characteristic components, connectors, and constraints, such as layered, client-server, or event-driven. Choosing a style sets broad trade-offs for qualities like scalability and modifiability.

A reusable, named solution to a recurring design problem in a particular context, describing collaborating roles and their responsibilities. Patterns communicate proven structures without prescribing exact code.

The degree to which software modules depend on one another. Low coupling is generally desirable because it limits the ripple effects of changes and makes modules easier to test and replace independently.

The degree to which the responsibilities inside a single module belong together and serve one purpose. High cohesion is generally desirable because focused modules are easier to understand, reuse, and maintain.

The property of a system built from discrete, replaceable units with well-defined interfaces. Good modularity localizes change and enables independent development and testing of parts.

A defined boundary through which a component exposes operations and data to other components while hiding its internal implementation. Clear interfaces allow substitution and reduce unintended dependencies.

A measurable property of a system such as performance, security, availability, or modifiability that shapes architectural decisions. Quality attributes are often expressed as scenarios with stimuli, responses, and measures.

A design guideline stating that a module or class should have one reason to change, meaning it should serve a single cohesive responsibility. It reduces coupling between unrelated concerns.

An application programming interface: the set of operations, data types, and conventions by which one software component invokes another. It forms a contract that callers rely on and providers must honor.

A disciplined change to the internal structure of code that improves readability or design without altering observable behavior. It is typically supported by automated tests that confirm behavior is preserved.

The accumulated cost of shortcuts and suboptimal design decisions that make future changes harder. Like financial debt, it incurs ongoing interest in the form of slower development and higher defect risk.

A systematic examination of source changes by peers before integration, checking correctness, style, security, and design. It catches defects early and spreads knowledge across the team.

Automated examination of source code without executing it to find defects, style violations, or security weaknesses. Tools flag patterns such as unused variables, null risks, or unsafe calls.

An automated test that exercises a single small unit of code, such as a function or class, in isolation from its dependencies. Unit tests run fast and pinpoint failures precisely.

A documented set of preconditions, inputs, steps, and expected results used to verify a specific behavior. Well-designed test cases cover both normal and exceptional paths.

A stand-in object substituted for a real dependency during testing, such as a stub, mock, or fake. Doubles isolate the unit under test and let testers control dependency behavior.

Re-running selected tests after changes to confirm that existing behavior still works and nothing previously working has broken. It is central to safe modification and release.

A measure of how much of the software a test suite exercises, expressed in terms such as statements, branches, or requirements covered. It indicates gaps but does not by itself prove correctness.

A system that records changes to files over time so that specific versions can be retrieved, compared, and merged. It enables collaboration, history tracking, and recovery from mistakes.

An independent line of development within a version control system that diverges from a common base. Branches let teams isolate work such as features or fixes before integrating it.

A situation where version control cannot automatically combine changes because two branches modified the same part of a file. A developer must resolve it manually before integration completes.

A practice where developers integrate changes into a shared mainline frequently, each integration triggering automated build and test. It surfaces integration defects early and keeps the codebase releasable.

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 timing remains a business decision.

The property that a new version of a system or API continues to support clients built against older versions. It protects existing users from breaking changes during upgrades.

A fixed-length iteration, common in agile methods, during which a team builds and verifies an increment of potentially shippable work. Scope is planned at the start and reviewed at the end.

An ordered list of desired work items, such as features, fixes, and improvements, maintained by the product owner. Items are refined and prioritized so the team always works on the highest value next.

A measure of how much backlog work a team completes per iteration, often in story points. It supports forecasting but should not be used to compare teams or pressure them to inflate estimates.

A visual chart showing remaining work versus time within an iteration or release. Its slope reveals whether the team is on track to finish the planned scope.

The process of identifying, assessing, prioritizing, and mitigating threats to project objectives. It includes contingency planning and ongoing monitoring so problems are addressed before they become crises.

A document describing scope, schedule, resources, milestones, risks, and quality approach for a project. It guides execution and is revised as conditions change.

The modification of software after delivery to correct faults, adapt to new environments, improve performance, or add features. It consumes a large share of total lifecycle cost.

An older system that remains in use and is often critical to operations but is hard to change due to outdated technology, poor documentation, or scarce knowledge. It poses special risks for evolution.

The study of what will be affected by a proposed change, including code, tests, documentation, and dependent systems. It estimates effort and risk before modification begins.

The process of analyzing an existing system to recover its design, behavior, or data structures when documentation is missing or outdated. It often precedes reengineering or maintenance work.

A published set of principles guiding practitioner conduct, such as honesty, competence, public safety, and avoidance of conflicts of interest. It helps engineers weigh obligations to employers, clients, and the public.

A situation where a professional's personal interests or outside relationships could improperly influence decisions made on behalf of an employer or client. It should be disclosed and managed.

Reporting a serious wrongdoing, such as a safety hazard or illegal practice, to an authority outside the organization when internal channels fail. It raises ethical tensions between loyalty and public welfare.

The dividing line between what is inside the system under design and the external actors, systems, and environment it interacts with. It scopes requirements and clarifies responsibilities.

A preliminary, often partial implementation built to explore requirements, validate design ideas, or gather feedback. Prototypes may be discarded or evolved into production code.

An automated sequence of build, test, and deployment stages that moves code from commit toward release. It enforces quality gates and makes releases repeatable and fast.

A replaceable, independently deployable unit of software with a defined contract and explicit dependencies. Components are the building blocks of architectural structures.