PASC cheat sheet

Functional requirements state what the system shall do; non-functional requirements constrain how it does it (performance, security, usability).

MoSCoW prioritization classifies requirements as Must have, Should have, Could have, and Won't have for a given release.

A use case describes actor-system interaction toward a goal; it includes main flow, alternate flows, and pre/postconditions.

INVEST criteria for a good user story: Independent, Negotiable, Valuable, Estimable, Small, Testable.

Requirements traceability matrix maps each requirement to design elements, code, and test cases to detect gaps and orphans.

Ambiguity indicators in requirements include weak words (fast, user-friendly, etc.), passive voice, and unquantified adjectives.

Elicitation techniques include interviews, workshops, observation, document analysis, prototyping, and questionnaires.

A requirements baseline is a formally approved, version-controlled set of requirements that changes only via change control.

Verification asks whether requirements are written correctly; validation asks whether they describe the right system for stakeholders.

Coupling measures interdependence between modules (aim low); cohesion measures relatedness within a module (aim high).

The SOLID principles: Single responsibility, Open-closed, Liskov substitution, Interface segregation, Dependency inversion.

Layered architecture organizes components into tiers where each layer depends only on the layer beneath it.

MVC separates model (data/logic), view (presentation), and controller (input handling) to isolate concerns.

A design pattern names a reusable solution to a recurring problem; it is not code but a template for structuring code.

Architectural quality attributes (performance, availability, modifiability, security) are realized through tactics and trade-offs.

UML class diagrams show classes, attributes, operations, and relationships: association, generalization, aggregation, composition.

The observer pattern defines a one-to-many dependency so dependents are notified automatically when the subject changes.

Separation of concerns assigns distinct responsibilities to distinct modules to reduce ripple effects of change.

Defensive programming validates inputs and handles error conditions rather than assuming preconditions hold.

A code smell is a surface indicator of a deeper design problem (e.g., long method, duplicated code, god class).

Refactoring restructures code without changing external behavior; it is typically paired with automated tests as a safety net.

The DRY principle: every piece of knowledge should have a single, authoritative representation in the system.

Exception handling separates error-handling code from normal flow; catch blocks should handle, log, or rethrow, not silently swallow.

Pair programming and code review are construction practices that catch defects early and spread knowledge.

Immutability and pure functions reduce side effects and make code easier to reason about and test.

Static analysis tools detect defects (null dereferences, unused variables, style violations) without executing the program.

Continuous integration merges and builds changes frequently to surface integration defects early.

Black-box testing derives cases from specifications without knowledge of internals; white-box testing uses code structure.

Boundary value analysis tests at and around the edges of input ranges, where defects cluster.

Equivalence partitioning divides inputs into classes treated identically; one representative per class suffices.

Statement coverage executes every statement; branch coverage executes every branch outcome; higher coverage does not guarantee correctness.

Levels of testing: unit, integration, system, and acceptance, each with distinct objectives and scope.

Regression testing re-runs existing tests after changes to confirm nothing previously working has broken.

A test oracle is the mechanism (expected result) used to judge whether an observed outcome passes.

Defect severity measures impact on the system; priority measures urgency of fixing; they are assigned independently.

Static testing (reviews, inspections) finds defects without executing code and can catch issues early in the lifecycle.

A configuration item is any artifact placed under version control (source, documents, build scripts, test data).

A baseline is a fixed, approved configuration that serves as a reference point for further development.

Version control branching strategies include trunk-based development and feature-branch workflows, differing in integration frequency.

A build is reproducible when identical inputs and toolchain produce identical outputs, ideally verified by hashing artifacts.

Semantic versioning uses MAJOR.MINOR.PATCH: breaking changes, backward-compatible features, and backward-compatible fixes.

Change control records, evaluates, approves, and tracks changes to baselined items to preserve integrity.

Release notes document new features, fixed defects, and known issues for a given version.

Continuous delivery keeps software in a deployable state at all times; continuous deployment additionally releases automatically.

The iron triangle (scope, time, cost, and quality) shows that adjusting one constraint affects the others.

Critical path is the longest chain of dependent tasks; it determines the minimum project duration and has zero float.

Earned value: CV = EV − AC; SV = EV − PV; CPI = EV/AC; SPI = EV/PV.

A sprint retrospective inspects process and team practices after a sprint to identify improvements.

Scrum roles are Product Owner, Scrum Master, and Developers; artifacts are product backlog, sprint backlog, and increment.

Risk exposure = probability of occurrence × impact; risk response options include avoid, mitigate, transfer, and accept.

COCOMO is an algorithmic cost model estimating effort from size (e.g., KLOC) and cost drivers.

A Gantt chart displays tasks against a calendar timeline and shows dependencies and overlaps.

Brooks's law states that adding people to a late software project makes it later.

Maintenance categories: corrective (fixing defects), adaptive (new environments), perfective (improvements), preventive (future-proofing).

Software entropy describes increasing disorder in a system as it is modified without refactoring.

Legacy systems are often maintained because of business value and embedded knowledge despite obsolete technology.

Reverse engineering derives design or requirements information from existing code; reengineering restructures it afterward.

Impact analysis identifies the components and tests affected by a proposed change before it is made.

The boy scout rule: leave code cleaner than you found it, applied incrementally during maintenance.

Technical debt is the implied future cost of choosing an expedient solution over a better one.

Regression risk grows with coupling; changes in highly coupled modules require broader retesting.

The ACM/IEEE-CS Software Engineering Code of Ethics has eight principles, including public, client and employer, product, and profession.

The public interest is the primary obligation; professional duties to clients and employers are subordinate to public safety.

Competence: engineers should accept work only within their competence and disclose relevant limitations.

Conflicts of interest must be disclosed; gifts or favors that could influence judgment should be refused or revealed.

Confidentiality obligations persist beyond the employment relationship unless disclosure is required by law or public safety.

Whistleblowing is justified when a product poses serious public harm and internal channels have been exhausted.

Intellectual property: using licensed or open-source code requires honoring its license terms and attribution.

Data privacy principles include collecting only necessary data, limiting use, and protecting it from unauthorized access.

Professionals should not misrepresent the state of software or conceal known defects that endanger users.