EGATSU-SP cheat sheet

System: an integrated set of elements (hardware, software, people, procedures) that accomplishes a defined objective; a system boundary separates it from its environment.

Requirement: a statement that identifies a product or process operational, functional, or design characteristic that is unambiguous, testable, and necessary.

Verification: confirmation by examination and provision of objective evidence that specified requirements have been fulfilled; answers 'Did we build the product right?'

Validation: confirmation that the requirements for a specific intended use are fulfilled; answers 'Did we build the right product?'

Traceability: the ability to follow the life of a requirement in both forward and backward directions through the development lifecycle.

Interface: a shared boundary between two or more system elements across which information, material, or energy is exchanged; characterized by type (physical, logical, human).

Stakeholder: an individual or organization having a right, share, claim, or interest in a system or in its possession of characteristics that meet their needs and expectations.

Configuration item: an entity within a configuration that satisfies an end use function and can be uniquely identified at a given reference point.

Baseline: a formally reviewed and agreed-upon set of products or documents that serves as a reference for further development and against which progress is measured.

SMART criteria for requirements: Specific, Measurable, Achievable, Relevant, Time-bound; a requirement lacking any of these is a candidate for rejection.

Elicitation techniques: interviews, workshops, observation, document analysis, prototyping, and surveys; no single technique captures all stakeholder needs.

Requirements classification: functional (what the system does), non-functional (quality attributes such as performance, security, usability), and constraints (imposed design decisions).

MoSCoW prioritization: Must have, Should have, Could have, Won't have; Must-have items typically consume no more than 60% of effort.

Requirement traceability matrix (RTM) maps each requirement to its source, design element, implementation, and test case; gaps indicate coverage risk.

Use case: a sequence of actions a system performs that yields an observable result of value to an actor; includes preconditions, postconditions, and main/alternate flows.

Requirements analysis checks: completeness, consistency, feasibility, verifiability, necessity, and unambiguity; conflicts are resolved with stakeholders before baselining.

Planning baseline includes scope, schedule, cost, quality, risk, and communication plans; each plan has an owner and measurable acceptance criteria.

Earned Value Management: SPI = EV / PV and CPI = EV / AC; SPI or CPI below 1.0 signals schedule or cost performance issues.

Architecture viewpoints: logical, process, development, and physical; each viewpoint addresses a different set of stakeholder concerns.

Separation of concerns: divide a system into parts that overlap in functionality as little as possible; reduces coupling and increases maintainability.

Coupling and cohesion: aim for low coupling between modules and high cohesion within a module; coupling types range from content (worst) to data (best).

Design patterns are reusable solutions to recurring design problems; categories are creational, structural, and behavioral.

Interface Control Document (ICD): defines the physical, electrical, and logical characteristics of an interface between two system elements.

Architecture trade-off analysis: evaluate competing quality attributes (performance, security, modifiability, availability) using scenarios and sensitivity points.

Layered architecture: each layer provides services to the layer above and consumes services from the layer below; strict layering forbids upward or skip-layer calls.

Design review types: preliminary design review (PDR) confirms the allocated baseline; critical design review (CDR) confirms the product baseline is complete.

Configuration management activities: identification, control, status accounting, and audit; all four are required for a complete CM process.

Change control board (CCB): the authority that reviews, approves, or rejects proposed changes to a configuration baseline.

Version control branching strategies: trunk-based development favors short-lived branches; GitFlow uses long-lived develop and release branches.

Build automation: a repeatable build script produces identical artifacts from the same source revision; build reproducibility is a prerequisite for reliable testing.

Deployment environments: development, test, staging, and production; configuration differences between environments are a common source of defects.

Infrastructure as Code (IaC): provisioning and managing infrastructure through machine-readable definition files rather than manual processes.

Configuration audit: functional configuration audit (FCA) verifies performance against requirements; physical configuration audit (PCA) verifies the as-built configuration against documentation.

Rollback plan: a documented procedure to restore the previous known-good configuration if a deployment fails; must be tested before production use.

Test levels: unit, integration, system, and acceptance; each level has distinct objectives and entry/exit criteria.

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

White-box techniques: statement coverage, branch/decision coverage, and path coverage; they measure the degree to which code structure is exercised.

Boundary value analysis: test values at the lower and upper boundaries of an input domain and just inside/outside them; defects cluster at boundaries.

Defect severity vs. priority: severity measures impact on the system; priority measures urgency of fix; they are independent attributes.

Quality assurance vs. quality control: QA is process-oriented and preventive; QC is product-oriented and detective (testing is a QC activity).

Regression testing: re-execution of selected tests to confirm that changes have not introduced new defects; test selection is based on change impact analysis.

Entry criteria for system testing typically include: all components integrated, unit and integration tests passed, and the test environment verified.

Defect life cycle: new, assigned, open, fixed, retest, verified, closed; rejected and deferred are terminal or holding states.

Incident management priorities are typically P1 (critical) through P4 (low); P1 targets restoration first, root-cause analysis later.

Mean time to repair (MTTR) = total downtime / number of incidents; mean time between failures (MTBF) = total operating time / number of failures.

Availability = MTBF / (MTBF + MTTR); expressed as a percentage, it drives redundancy and maintenance strategy decisions.

Maintenance types: corrective (fix after failure), preventive (scheduled), predictive (condition-based), and adaptive (respond to environment changes).

Root cause analysis tools: 5 Whys, fishbone (Ishikawa) diagram, fault tree analysis, and Pareto analysis; select based on problem complexity and data availability.

Runbook: a documented set of procedures for routine operations and incident response; should be version-controlled and tested.

Monitoring categories: availability, performance, capacity, and security; alerts require defined thresholds and escalation paths.

Change management: standard, normal, and emergency changes; emergency changes still require retrospective review and documentation.

CIA triad: confidentiality (authorized access only), integrity (accuracy and completeness), and availability (timely access when needed).

Risk = likelihood × impact; risk response options are avoid, mitigate, transfer, and accept; residual risk remains after controls are applied.

Authentication vs. authorization: authentication verifies identity; authorization determines what an authenticated entity is permitted to do.

Least privilege: every user and process operates with only the permissions necessary to perform its function, for only the time required.

Defense in depth: multiple layered controls so that failure of one control does not compromise the system; layers include physical, network, host, application, and data.

Compliance frameworks: ISO/IEC 27001 (information security management), SOC 2 (trust services), PCI DSS (payment card data), GDPR (personal data protection).

Vulnerability vs. threat vs. risk: a vulnerability is a weakness, a threat is a potential cause of harm, and risk is the combination of threat exploiting vulnerability and resulting impact.

Incident response phases: preparation, detection and analysis, containment, eradication, recovery, and post-incident lessons learned.

Data classification tiers (e.g., public, internal, confidential, restricted) determine handling, encryption, and retention requirements.