PE Software flashcards

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

Functional requirement

A statement of a behavior or service the system must perform, expressed as input-to-output transformation, described with measurable acceptance criteria so it can be verified by testing.

Non-functional requirement

A quality attribute or constraint on how the system performs its functions, such as response time, availability, security, maintainability, or portability, rather than a specific behavior.

MoSCoW prioritization

A requirement prioritization scheme classifying items as Must have, Should have, Could have, or Won't have this time; the Won't category records deliberate scope exclusions.

Requirements traceability matrix

A table linking each requirement to design elements, source code, and test cases in both directions, enabling impact analysis when a requirement is added, changed, or removed.

INVEST criteria

A checklist for good user stories: Independent, Negotiable, Valuable to users, Estimable, Small enough for one iteration, and Testable with clear acceptance criteria.

V-model

A lifecycle model where each development phase has a matching verification phase: requirements map to acceptance tests, architectural design to integration tests, detailed design to unit tests.

Scope creep

Uncontrolled expansion of project scope through unapproved additions to requirements, typically without corresponding adjustments to schedule, budget, or resources.

Single Responsibility Principle

The SOLID principle that a class should have one reason to change, meaning it should serve one actor or cohesive responsibility rather than mixing unrelated concerns.

Liskov Substitution Principle

Subtypes must be usable wherever their base type is expected without breaking correctness, so overrides may not strengthen preconditions or weaken postconditions.

Dependency Inversion Principle

High-level modules should not depend on low-level modules; both should depend on abstractions, and abstractions should not depend on implementation details.

Coupling and cohesion

Coupling is the degree of interdependence between modules; cohesion is the degree to which a module's internal responsibilities belong together. Good design minimizes coupling and maximizes cohesion.

Strategy pattern

A behavioral pattern that defines a family of interchangeable algorithms behind a common interface and lets a client select one at runtime without conditional logic.

Observer pattern

A behavioral pattern establishing a one-to-many dependency so that when a subject changes state, all registered observers are notified automatically, forming the basis of publish-subscribe.

Architecture decision record

A short document recording the context, the decision made, alternatives considered, and resulting consequences; records are superseded rather than rewritten when decisions change.

Equivalence partitioning

A black-box test design technique dividing inputs into classes expected to be processed identically, so one representative value per class is tested instead of every possible input.

Boundary value analysis

A black-box technique testing values at, immediately below, and immediately above the edges of each input or output range, because defects cluster at boundaries.

Branch coverage

A white-box metric requiring every decision outcome (true and false) to be exercised at least once; achieving full branch coverage guarantees full statement coverage but not full path coverage.

Test double

A stand-in object replacing a real dependency in a test; variants include stubs returning canned answers, spies recording calls, mocks verifying expectations, and fakes with working simplified logic.

Regression testing

Re-executing a selected subset of existing tests after a change to confirm that previously working behavior still works and that no defects were reintroduced.

Static analysis

Examination of source code or models without executing the program, detecting issues such as style violations, type errors, unreachable code, and potential null dereferences.

Continuous integration

A practice where every commit triggers an automated build and test pipeline, keeping the mainline integration-ready and detecting integration defects quickly.

Continuous delivery

A practice keeping the main branch always in a releasable state with automated testing and deployment pipelines, where releasing to production still requires a human decision.

Semantic versioning

A versioning convention MAJOR.MINOR.PATCH where MAJOR signals incompatible API changes, MINOR signals backward-compatible features, and PATCH signals backward-compatible bug fixes.

Git merge versus rebase

Merge combines histories with a commit having two parents and preserves original commits; rebase replays commits onto a new base, producing a linear history with rewritten commit hashes.

Configuration baseline

An approved and fixed configuration of one or more configuration items that serves as a reference for further development and can be changed only through formal change control.

Technical debt

The future cost implied by choosing an expedient design or implementation now instead of a better approach, repaid later through refactoring and tracked deliberately.

Function point analysis

A functional sizing method counting external inputs, outputs, inquiries, internal logical files, and external interface files, then adjusting for complexity and general system characteristics.

Brooks's law

The observation that adding personnel to a late software project delays it further, because onboarding and communication overhead grow faster than productive capacity.

Risk exposure

The product of a risk's probability of occurrence and its impact if it occurs, used to rank risks and decide which to mitigate or accept.

Critical path

The longest chain of dependent activities in a project schedule; it determines the minimum project duration and its activities have zero float.

Cost performance index

Earned value metric CPI = Earned Value / Actual Cost; a value below 1.0 indicates the project is spending more than the work earned justifies.

Professional code of ethics

A statement of obligations such as acting in the public interest, maintaining competence, preserving confidentiality, and disclosing conflicts, which governs engineering practice beyond employer instructions.