CPRE flashcards
CPRE · Build recall with a focused review session.
32 cards. Read the term and the definition here. The deck at the top of this page is optional.
- Requirement
- A statement describing a capability or property that a system must have, or a condition it must satisfy, derived from stakeholder needs and expressed so it can be verified.
- System requirement
- A requirement stating what the system under consideration must do or what property it must exhibit, as opposed to a process requirement about how development is performed.
- Process requirement
- A constraint on how the development work is carried out, such as mandated reviews, tooling, documentation standards, or legal procedures, rather than on system behavior.
- Non-functional requirement
- A requirement about a quality property or constraint of the system, such as performance, reliability, usability, security, or legal compliance, rather than a specific function.
- System boundary
- The defined line separating the system under consideration from its environment, including external actors and neighboring systems, which fixes what counts as in scope.
- Stakeholder
- Any person, group, or role affected by the system or able to influence its requirements, including indirect parties such as regulators, maintainers, and operators.
- Requirement specification
- A structured, agreed document or model that records requirements for a defined system boundary, serving as the reference for design, testing, and acceptance.
- Semi-structured interview
- An elicitation interview guided by a prepared question list but allowing follow-up questions and open discussion, balancing coverage with exploration.
- Observation
- An elicitation technique in which the analyst watches users perform real work in context, revealing tacit knowledge and workarounds that users cannot easily describe.
- Apprenticeship
- An elicitation form of observation where the analyst learns and performs the user's task hands-on, uncovering implicit steps and decision rules embedded in the work.
- Document analysis
- An elicitation technique that mines existing manuals, forms, standards, and legacy data for requirements; inexpensive but vulnerable to inheriting outdated or erroneous content.
- Prototyping
- Building a preliminary, often partial version of the system to elicit feedback; low-fidelity versions test understanding, high-fidelity versions test usability and behavior.
- Perspective-based reading
- A review technique assigning reviewers distinct viewpoints such as user, tester, or developer, so that different defect classes are detected by each perspective.
- Brainstorming
- A group elicitation technique generating many candidate ideas without early criticism, followed by clustering and evaluation, useful when requirements are still unknown.
- Requirement template
- A fixed sentence pattern requiring trigger, subject, response, and measurable criterion, which reduces ambiguity and omission in natural-language requirements.
- Use case
- A goal-oriented description of interactions between actors and the system, comprising preconditions, main success scenario, alternative flows, exceptions, and postconditions.
- Include relationship
- A UML use case relationship in which a base use case always incorporates the behavior of another use case, modeling mandatory shared behavior.
- Extend relationship
- A UML use case relationship in which optional behavior augments a base use case at a defined extension point only when its condition holds.
- Composition
- A whole-part association in which parts are exclusively owned by the whole and cannot exist independently, unlike aggregation where parts can be shared.
- State machine
- A model of one object's lifecycle using states, event-triggered transitions, guards, and effects, exposing unreachable states and forbidden transition sequences.
- Traceability
- Documented links between requirements and their sources, design elements, code, and tests, enabling impact analysis, coverage checks, and compliance evidence.
- Verifiable requirement
- A requirement for which a finite, cost-effective procedure can decide whether the delivered system satisfies it, typically because it contains a measurable criterion.
- Validation versus verification
- Validation checks that documented requirements match real stakeholder needs; verification checks that requirements are correctly and consistently documented per quality rules.
- Inspection
- A formal review with defined roles, entry criteria, a checklist, a logged defect list, and exit criteria, considered the most rigorous requirements review technique.
- Requirements negotiation
- A structured process for resolving conflicting stakeholder goals through interest-based trade-offs, producing agreed requirements with recorded rationale and priorities.
- Requirement smell
- A textual pattern signaling likely defects, such as passive voice hiding the actor, compound requirements, unquantified adjectives, or design decisions embedded in the requirement.
- Quality attribute scenario
- A specification of a quality requirement as stimulus, environment, system response, and response measure, making non-functional requirements objective and testable.
- Baseline
- A formally reviewed and agreed set of requirements that changes only through defined change control, anchoring release scope, contracts, and audit evidence.
- Impact analysis
- Assessment of which design elements, code, tests, and stakeholders are affected by a proposed requirement change, performed by following traceability links.
- MoSCoW
- A prioritization scheme classifying requirements as Must have, Should have, Could have, or Won't have for a given release, making scope trade-offs explicit.
- Requirement status
- An attribute tracking a requirement's lifecycle state, typically proposed, approved, implemented, verified, or obsolete, which must be updated from evidence.
- Definition of Ready
- An agile team agreement listing conditions a backlog item must meet before work starts, functioning as entry criteria analogous to review readiness in traditional RE.