PASC flashcards

36 cards. Read the term and the definition here. The deck at the top of this page is optional.

Functional requirement

A statement of a service or behavior the system must provide, describing what the software shall do in response to given inputs or events.

Non-functional requirement

A constraint on how the system performs its functions, such as performance, security, usability, reliability, or maintainability targets, often expressed as measurable quality attributes.

MoSCoW prioritization

A requirements prioritization scheme classifying items as Must have, Should have, Could have, and Won't have for a specific delivery, helping scope releases under fixed constraints.

Requirements traceability matrix

A table linking each requirement to its source, design elements, code modules, and test cases, used to detect uncovered requirements and orphaned artifacts.

Use case

A description of a sequence of interactions between an actor and a system that yields an observable result of value to the actor, including main and alternate flows.

Coupling and cohesion

Coupling measures interdependence between modules and should be low; cohesion measures relatedness of responsibilities within a module and should be high.

Single responsibility principle

A SOLID principle stating that a class should have only one reason to change, meaning it should encapsulate one cohesive set of responsibilities.

Dependency inversion principle

A SOLID principle stating that high-level modules should not depend on low-level modules; both should depend on abstractions, and abstractions should not depend on details.

Layered architecture

An architectural style organizing components into layers where each layer provides services to the layer above and depends only on layers below, promoting replaceability and separation.

Observer pattern

A behavioral design pattern defining a one-to-many dependency so that when a subject changes state, all registered observers are notified and updated automatically.

MVC architecture

A pattern separating an application into model (data and logic), view (presentation), and controller (input handling), allowing independent evolution of user interface and core logic.

Code smell

A surface symptom in source code, such as long methods, duplicated logic, or large classes, that suggests a deeper design problem warranting refactoring.

Refactoring

A disciplined restructuring of code that improves internal structure without changing external behavior, typically safeguarded by automated regression tests.

DRY principle

The principle that every piece of knowledge or logic should have a single authoritative representation, avoiding duplicated code that can diverge and cause inconsistent behavior.

Defensive programming

A construction practice that validates inputs and handles error conditions explicitly, so code remains correct even when callers violate expected preconditions.

Static analysis

Automated examination of source code without executing it, detecting issues such as null dereferences, unused variables, and style or security violations.

Boundary value analysis

A black-box test technique selecting inputs at the edges of valid ranges (minimum, maximum, just inside and outside), where defects most often cluster.

Equivalence partitioning

A black-box technique dividing inputs into classes treated identically by the software, so one representative value per class is sufficient for testing.

Regression testing

Re-execution of existing test suites after changes to confirm that previously working functionality remains intact and no new defects were introduced.

Statement versus branch coverage

Statement coverage measures executed statements; branch coverage measures executed decision outcomes. Branch coverage subsumes statement coverage and is generally stronger.

Test oracle

The mechanism or source of expected results used to determine whether an observed test outcome passes or fails, such as a specification or reference implementation.

Configuration item

Any artifact placed under configuration control, including source code, build scripts, requirements documents, and test data, each versioned and tracked.

Baseline

A formally approved and fixed configuration of one or more configuration items that serves as a reference point for subsequent development and change control.

Semantic versioning

A versioning scheme MAJOR.MINOR.PATCH where MAJOR signals incompatible changes, MINOR adds backward-compatible features, and PATCH delivers backward-compatible fixes.

Continuous delivery

A practice keeping software in a continuously deployable state through automated build, test, and release pipelines, with deployment to production requiring a manual decision.

Critical path

The longest sequence of dependent project tasks, determining the minimum possible project duration; tasks on it have zero float or slack.

Earned value CPI and SPI

Cost performance index equals earned value divided by actual cost; schedule performance index equals earned value divided by planned value. Values below 1 indicate overrun or delay.

Brooks's law

The observation that adding manpower to a late software project makes it later, due to communication overhead and ramp-up time for new team members.

Risk exposure

A risk metric computed as the probability of the risk occurring multiplied by the impact if it occurs, used to prioritize risk responses.

Corrective maintenance

Maintenance performed to diagnose and fix defects discovered after release, restoring the software to its intended correct behavior.

Software entropy

The tendency of a software system's complexity and disorder to increase over time as changes accumulate without corresponding refactoring or restructuring.

Impact analysis

An assessment identifying which components, interfaces, and tests are affected by a proposed change, guiding effort estimation and regression test selection.

Technical debt

The implied future cost of choosing an expedient implementation over a better one, which must eventually be repaid through refactoring or rework.

Whistleblowing justification

Disclosure of serious harm from software is justified when public safety is at risk and internal reporting channels have been exhausted without remedy.

Conflict of interest disclosure

A professional obligation to reveal relationships, gifts, or interests that could improperly influence technical judgment, so stakeholders can assess objectivity.

Software Engineering Code of Ethics

The ACM/IEEE-CS code articulating eight principles, including public interest, client and employer, product quality, judgment, management, profession, colleagues, and self.