CPRE cheat sheet

Four core activities per IREB/CPRE framing: elicitation, documentation, validation and negotiation, and management (change plus traceability); each activity runs iteratively, not once in sequence.

Requirement types: a system requirement describes what the system must do or be; a process requirement constrains how development is performed (e.g., tooling, review gates, documentation standards).

Requirement categories: functional (behavior), non-functional/quality (performance, usability, reliability, security), and constraints (legal, technical, organizational, physical).

A requirement is a statement about a needed capability or property; a specification is a structured, agreed artifact that documents requirements for a defined system boundary.

Lifecycle models change RE shape: sequential models front-load a complete specification; iterative/agile models specify incrementally at the level of detail needed for the next iteration.

Stakeholder = any person or role affected by, or affecting, the system; stakeholder identification precedes elicitation and must include indirect parties (regulators, operators, maintainers).

System boundary and context define what is inside the system under consideration versus external actors and neighboring systems; ambiguity here is a leading source of scope defects.

Documentation forms: natural-language text (with templates), models (use case, data, state, activity), and formal specifications; each trades readability for precision and verifiability.

Quality of the RE process is judged by the quality of resulting artifacts plus effort, not by artifact volume; a large specification can still be incomplete or inconsistent.

Elicitation techniques split into survey-style (interview, questionnaire, observation, document analysis) and creative/group (brainstorming, workshops, prototyping, analogy).

Interview types: open (exploratory, no fixed script), semi-structured (guide with follow-ups), closed (fixed questions); choose by how much the interviewer already knows.

Observation variants: shadowing (follow the user), field observation (watch in context), and apprenticeship (learn the task hands-on); all reveal tacit knowledge users cannot verbalize.

Document analysis mines existing forms, manuals, standards, and legacy system data; it is cheap but inherits errors from obsolete sources.

Prototyping elicits feedback on concrete artifacts; low-fidelity prototypes test understanding, high-fidelity prototypes test usability and detailed behavior.

Perspective-based reading assigns distinct reviewer viewpoints (user, tester, developer, operator) to the same artifact; different perspectives surface different defect classes.

Conflict detection, not conflict avoidance, is the goal of group elicitation: divergent stakeholder goals must be surfaced and negotiated explicitly.

Elicitation is complete enough when further sources yield no new requirements and open questions are logged with owners, not when a template is filled.

Natural-language requirement quality criteria (ISO/IEC/IEEE 29148 style): necessary, unambiguous, complete, singular, feasible, verifiable, correct, and conforming to a template.

Use-case description elements: actor, preconditions, trigger, main success scenario, alternative and exception flows, postconditions; a use case is a goal-oriented interaction, not a function list.

UML use case diagram semantics: actors outside the boundary, associations to use cases, <> for mandatory shared behavior, <> for optional behavior at an extension point.

Class diagrams capture structural domain concepts: classes, attributes, operations, associations with multiplicities, generalization, aggregation versus composition (shared versus exclusive ownership).

State machines model lifecycle of a single object: states, transitions triggered by events, guards, effects; they expose forbidden or unreachable states that prose hides.

Activity diagrams express control and data flow with decisions, merges, forks, joins, and swimlanes; they suit business processes and complex algorithms.

Requirement templates (e.g., 'When , the shall within ') force explicit trigger, subject, and measurable criterion.

Traceability classes: to sources/stakeholders (backward) and to design, code, and tests (forward); bidirectional links enable impact analysis on change.

Modeling notation is secondary to semantics: the same requirement may be documented as text, model, or table, provided the chosen form makes it verifiable.

Validation asks 'did we build the right requirements?'; verification asks 'did we document them right?'. Both are distinct from testing the implemented system.

Validation techniques: review/inspection, walkthrough, prototyping, simulation, and test-case derivation from requirements before implementation.

Inspection is the most formal review: defined roles (moderator, author, reader, recorder, inspectors), entry criteria, checklist, defect log, and exit criteria.

Negotiation resolves conflicts through interest-based trade-offs; outcomes must be recorded as agreed requirements with rationale, not as verbal consensus.

Conflict resolution options: prioritize by value/risk, split into variants, defer to a later release, or reject with documented justification.

A requirement is verifiable only if a finite, cost-effective procedure can decide whether the delivered system meets it; vague quality words (fast, user-friendly) are unverifiable without measures.

Requirements smells: passive voice hiding the actor, compound requirements joined by 'and/or', negative requirements, design embedded in requirements, and unquantified adjectives.

Consistency checks look for contradictory requirements, conflicting terminology, and duplicate requirements across documents and models.

Quality attributes need scenario-based specification: stimulus, environment, response, and measure, so acceptance criteria are objective.

Requirement attributes to manage: unique identifier, version, status, priority, source, rationale, owner, and links to other artifacts.

Change control flow: request, impact analysis via traceability, decision (accept/reject/defer), implementation, and re-validation; every change is logged.

Baseline = a formally reviewed and agreed set of requirements that can only change through change control; baselines anchor release scope and contracts.

Traceability supports impact analysis, coverage analysis, and compliance evidence; missing links cause untested requirements and orphan code.

Prioritization schemes: MoSCoW (Must/Should/Could/Won't), ranking, and value-versus-cost or risk-based scoring; priority is a decision, not an attribute of the text.

Requirement volatility is managed by classifying stability and planning detail level per volatility; stable areas can be specified early, volatile ones late.

Status lifecycle typically runs proposed, approved, implemented, verified, and rejected/obsolete; status must reflect evidence, not intent.

Version management requires unique IDs plus version numbers; identifiers are never reused, even after a requirement is deleted, to preserve traceability history.

Configuration management of requirements covers identification, control, status accounting, and audit of requirement artifacts, mirroring software configuration management.

RE tool capabilities: repository with attributes, traceability links, versioning and baselines, workflow/status, review support, and reporting for coverage.

Tool selection criteria: integration with issue trackers, test management, and modeling tools; export formats; multi-user concurrency; and total cost of ownership.

In agile contexts the product backlog is the requirements repository; user stories plus acceptance criteria and examples replace a single up-front specification.

Definition of Ready and Definition of Done act as entry/exit criteria for backlog items, the agile analogue of review exit criteria.

Regulated domains (medical, automotive, aerospace) require bidirectional traceability and documented change rationale as audit evidence; tooling must produce that evidence.

Model-based RE stores requirements as model elements, enabling automated consistency checks and generation of documents or test skeletons.

Requirements reuse via domain glossaries, reference architectures, and requirement patterns reduces effort but requires adaptation checks against the new context.

Metrics for RE include requirement volatility rate, defect density found in review, traceability coverage, and rework effort attributable to requirement defects.