PE Software cheat sheet

Requirement types: functional (behavior), non-functional (quality attributes such as performance, security, usability), and constraint/pseudo-requirements imposed by standards, contracts, or platforms.

Requirements are verifiable when each statement has a measurable acceptance criterion; avoid unquantified words such as fast, robust, or user-friendly.

MoSCoW prioritization classifies requirements as Must have, Should have, Could have, and Won't have; the Won't category documents explicit scope exclusions.

Traceability matrices link requirements to design elements, code, and test cases; bidirectional links support impact analysis when a requirement changes.

A use case describes actor-system interaction toward a goal; it includes preconditions, main success scenario, alternate flows, and postconditions.

User stories follow the Connextra form (As a role, I want goal, so that benefit) and are commonly assessed with INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable.

The V-model pairs each development phase with a corresponding verification phase: requirements with acceptance testing, design with integration testing, detailed design with unit testing.

Change control records a change request, its impact analysis, approval decision, and implementation status; unapproved scope additions are scope creep.

SOLID: Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion; each principle names a specific class or interface design constraint.

Coupling measures interdependency between modules; cohesion measures how strongly related the responsibilities inside one module are. Good design targets low coupling and high cohesion.

Layered architecture restricts dependencies to adjacent layers; the dependency rule in clean/hexagonal architecture points inward toward domain logic, never outward to frameworks.

Design patterns fall into creational (Factory Method, Abstract Factory, Builder, Singleton, Prototype), structural (Adapter, Bridge, Composite, Decorator, Facade, Proxy), and behavioral (Observer, Strategy, Command, State, Template Method) groups.

The Strategy pattern swaps interchangeable algorithms behind a common interface; the State pattern changes behavior by delegating to state objects that model transitions.

The Observer pattern defines one-to-many dependency so subscribers are notified of publisher changes; it underlies event-driven and publish-subscribe designs.

An architecture decision record (ADR) captures context, decision, alternatives considered, and consequences; it is immutable and superseded rather than edited.

Separation of concerns and information hiding (Parnas) justify decomposing modules by likely change, not merely by execution sequence.

Test levels: unit (isolated component), integration (interfaces between components), system (end-to-end behavior), and acceptance (fitness for user needs).

Black-box techniques derive tests from specifications: equivalence partitioning, boundary value analysis, decision tables, and state transition testing.

White-box techniques derive tests from code structure: statement coverage, branch/decision coverage, and path coverage; 100% branch coverage implies 100% statement coverage, not the reverse.

Boundary value analysis tests values at, just below, and just above each boundary; defects cluster at boundaries of valid input ranges.

A unit test should be fast, deterministic, isolated, and self-validating; external dependencies are replaced with test doubles (stubs, spies, mocks, fakes).

Regression testing re-runs existing tests after a change to detect reintroduced defects; it is a selection strategy, not a distinct test level.

Static analysis inspects code without executing it (linting, type checking, data-flow analysis); dynamic analysis executes code, e.g., with sanitizers or profilers.

Code review and pair programming are static verification techniques; they find defects earlier and cheaper than testing, but do not replace execution-based testing.

Process models: waterfall (sequential, phase-gated), iterative/incremental, spiral (risk-driven with repeated risk analysis), and agile (short timeboxed iterations with working software each increment).

Scrum roles are Product Owner, Scrum Master, and Developers; artifacts are Product Backlog, Sprint Backlog, and Increment; the Sprint is a fixed-length timebox.

Kanban limits work in progress (WIP) per column to expose bottlenecks and applies pull-based flow; it prescribes no fixed iteration length.

Continuous integration requires every commit to trigger automated build and test; continuous delivery keeps the main branch always releasable, while continuous deployment also releases automatically.

Semantic versioning uses MAJOR.MINOR.PATCH: MAJOR for incompatible API changes, MINOR for backward-compatible features, PATCH for backward-compatible fixes.

Git branches are movable pointers to commits; a merge creates a commit with two parents, whereas rebase replays commits onto a new base and rewrites their hashes.

Configuration management identifies configuration items, controls changes, records status, and audits; a baseline is an approved, fixed configuration reference.

Technical debt is the implied future cost of choosing an expedient solution; it is tracked explicitly and repaid deliberately, not merely accumulated.

Function points size software from functional requirements (inputs, outputs, inquiries, internal and external files) independently of implementation language.

COCOMO-style models estimate effort as a function of size raised to an exponent adjusted by cost drivers; effort grows superlinearly with size.

Story points estimate relative size, not duration; velocity is completed story points per iteration and is used to forecast, not to compare teams.

Brooks's law: adding people to a late software project makes it later, because communication paths grow roughly as n(n-1)/2.

Risk exposure = probability of the risk occurring × impact if it occurs; mitigation reduces probability, contingency reduces impact.

The critical path is the longest sequence of dependent tasks in the schedule; it determines minimum project duration and has zero float.

Defect density = defects found / size (e.g., per KLOC); defect removal efficiency = defects found before release / total defects found.

Earned value: CV = EV − AC (cost variance), SV = EV − PV (schedule variance), CPI = EV/AC, SPI = EV/PV; negative variance indicates a problem.

Software engineering codes of ethics (e.g., ACM/IEEE-CS) obligate engineers to act in the public interest, hold client confidentiality, and report risks they are competent to judge.

Public safety takes precedence over employer or client instructions when software defects could cause harm; escalation is a documented professional duty.

Professional competence limits: an engineer should accept work only within their competence and disclose limitations rather than silently guess.

Licensure (PE) typically requires an accredited degree, passing the Fundamentals and Principles and Practice exams, and verified qualifying experience under supervision.

Intellectual property: copyright protects expression, patents protect novel and non-obvious inventions, trade secrets protect confidential information, and licenses define permitted use.

Data protection principles include purpose limitation, data minimization, accuracy, storage limitation, and confidentiality; personal data must be processed lawfully.

Safety-critical systems require documented hazard analysis (e.g., FMEA, fault tree analysis) and independent verification of safety requirements.

Conflict of interest and bribery: engineers must disclose financial interests that could bias technical judgment and must not accept improper inducements.