CPRE Foundation Level Glossary: Def→Name Flashcards
Guess the CPRE Foundation Level Glossary term name by looking at its definition. (132 cards)
1
Q
Abbreviation for Unified Modeling Language, a standardized language
for modeling problems or solutions.
A
UML
2
Q
A desired state of affairs (that a ↑stakeholder wants to achieve).
A
Goal
3
Q
A possible event that threatens the success of an endeavor.
A
Risk
4
Q
- A part played by a person in a given context.
- In ↑UML ↑class models: The parts played by the linked ↑objects in an
↑association.
A
Role
5
Q
A (software) ↑system that helps develop, operate and maintain systems.
A
Tool
in software engineering
6
Q
A person who uses the ↑functionality provided by a ↑system.
A
User
7
Q
An excerpt from a ↑work product, containing only those parts one is
currently interested in.
A
View
8
Q
A person in some ↑role, a ↑system or a technical device in the context of
a subject under consideration that interacts with that subject.
A
Actor
9
Q
- In general:
(a) Able to move quickly and easily.
(b) Quick, smart, and clever. - In software development: A development approach which builds a
product ↑incrementally by dividing work into ↑iterations of fixed
duration (↑timeboxes).
A
Agile
10
Q
A representation of a set of ↑objects of the same kind by describing the
structure of the objects, the ways they can be manipulated and how they
behave.
A
Class
11
Q
- A human action that produces an incorrect result.
- A discrepancy between an observed ↑behavior or result and the
specified behavior or result.
A
Error
12
Q
→ Defect
A
Fault
13
Q
An abstract representation of an existing part of reality or a part of
reality to be created.
A
Model
14
Q
The range of things that can be shaped and designed when developing a
↑system.
A
Scope
of a system development
15
Q
An imperfection or deficiency in a ↑work product that impairs its
intended use.
Synonyms: bug, fault
A
Defect
16
Q
- A plan or drawing produced to show how something will look,
function or be structured before it is made. - The activity of creating a design.
- A decorative pattern [This meaning does not apply in the software
engineering ↑domain].
A
Design
17
Q
A range of relevant things (for some given matter); for example, an
↑application domain.
A
Domain
18
Q
- In general: Anything which is perceivable or conceivable (→ item).
- In software engineering: an individual ↑item which has an identity,
is characterized by the values of its ↑attributes and does not depend
on another item (→ entity).
A
Object
19
Q
An evaluation of a ↑work product by an individual or a group in order to
find problems or suggest improvements.
A
Review
20
Q
The capability of a ↑system to achieve an acceptable level of probability
that the system, under defined conditions, will not reach a state in which
human life, health, property, or the environment is endangered.
A
Safety
21
Q
An ↑iteration in ↑agile development, particularly when using ↑Scrum.
A
Sprint
22
Q
The rules for constructing structured signs in a ↑language.
A
Syntax
23
Q
- In general: A principle for ordering and structuring.
- In engineering: A coherent, delimitable set of elements that – by
coordinated action – achieve some purpose.
A
System
24
Q
A conceptual imagination of a future ↑system or ↑product, describing its
key characteristics and how it will create value for its ↑users.
A
Vision
for a system or product
25
1. In general: The network of thoughts and meanings needed for
understanding phenomena or utterances.
2. Especially in RE: The part of a ↑system’s environment being relevant
for understanding the system and its ↑requirements.
Context
26
A distinguishing characteristic of a ↑system that provides value for
↑stakeholders.
Feature
27
A medium-fidelity ↑prototype that demonstrates characteristics of a
user interface without implementing any real ↑functionality.
Mock-up
| of a digital system
28
A fictitious character representing a group of ↑users with similar needs,
values and habits who are expected to use a ↑system in a similar way.
Persona
29
A set of interrelated ↑activities performed in a given order to process
information or materials.
Process
30
A software-based ↑system or a ↑service provided by a system which is
developed and marketed by a ↑supplier and used by ↑customers.
Product
| in the context of software
31
1. In general: The degree to which a set of inherent characteristics of
an item fulfills ↑requirements.
2. In systems and software engineering: The degree to which a ↑system
satisfies stated and implied needs of its ↑stakeholders.
Quality
32
A ↑configuration that has been released for installation and use by
↑customers.
Release
33
The provision of some ↑functionality to a human or a ↑system by a
provider (a system, organization, group or individual) that delivers
value to the receiver.
Service
34
A word having the same meaning as another word.
Synonym
35
An occurrence of an ↑item which exists in multiple, time-ordered
occurrences where each occurrence has been created by modifying one
of its previous occurrences.
Version
36
The degree to which a ↑requirement expresses the ↑stakeholders’ true
and agreed desires and needs (i.e., those they had actually in mind when
stating the requirement).
Adequacy
| of a requirement
37
A stable, change-controlled ↑configuration of ↑work products.
Baseline
38
The way in which a ↑system reacts to stimuli, changes its state and
produces observable results.
Behavior
39
A person or organization who receives a ↑system, a ↑product or a
↑service.
Also see ↑stakeholder.
Customer
40
A collection of definitions of terms that are relevant in some ↑domain.
Glossary
41
The level of importance assigned to an ↑item, e.g., a ↑requirement or a
↑defect, according to certain criteria.
Priority
42
The degree to which a ↑system protects its data and resources against
unauthorized access or use and secures unobstructed access and use for
its legitimate ↑users.
Security
43
A formal, possibly mandatory set of regulations for how to interpret,
develop, manufacture, or execute something.
Standard
44
A set of possible interactions between external ↑actors and a ↑system
that provide a benefit for the actor(s) involved.
Use case
45
A characteristic property of an ↑entity or an ↑object.
Attribute
46
1. In general: A delimitable part of a ↑system.
2. In software architecture: An encapsulated set of coherent ↑objects or
↑classes that jointly achieve some purpose.
3. In testing: A part of a ↑system that can be tested in isolation.
Component
47
An addition to a ↑system under development that extends, enhances or
refactors (↑refactoring) the existing parts of the system.
Increment
| in software development
48
1. In general: The repetition of something, for example, a procedure, a
process or a piece of program code.
2. In agile development: A ↑timeboxed unit of work in which a
development team implements an ↑increment to the ↑system under
development.
Iteration
49
The degree to which an individual ↑requirement is a necessary part of
the ↑requirements specification of a ↑system.
Necessity
| of a requirement
50
1. In manufacturing: A piece which is built prior to the start of mass
production.
2. In software and systems engineering: A preliminary, partial
realization of certain characteristics of a ↑system.
3. In design: A preliminary, partial instance of a design solution.
Prototype
51
The meaning of a sign or a set of signs in a ↑language.
Semantics
52
The degree to which a ↑system can be used by specified ↑users to
achieve specified ↑goals in a specified context of use.
Usability
53
A low-fidelity ↑prototype built with simple materials that primarily
serves for discussing and validating requirements, design ideas or user
interface concepts.
Wireframe
54
The adherence of a ↑work product to ↑standards, conventions,
| regulations, laws, or similar prescriptions.
Compliance
55
The degree to which a ↑work product conforms to regulations given in
some ↑standard.
Conformity
56
A ↑requirement that limits the solution space beyond what is necessary
for meeting the given ↑functional requirements and ↑quality
requirements.
Constraint
| in RE
57
The degree to which resources are expended in relation to results
achieved.
Efficiency
58
A ↑model representing a set ↑goals, sub-goals and the relationships
between them.
Goal model
59
A formal ↑review of a ↑work product by a group of experts according to
given criteria, following a defined procedure.
Inspection
60
Multiple occurrence of the same information or resource.
Redundancy
61
A ↑state machine having states that are hierarchically and/or
orthogonally decomposed.
Statechart
62
A description of a need from a ↑user’s perspective together with the
expected benefit when this need is satisfied.
User story
63
The ↑process of confirming that an ↑item (a ↑system, a ↑work product or
a part thereof) matches its ↑stakeholders’ needs.
Validation
64
A model consisting of a set of ↑classes and relationships between them.
Class model
65
The degree to which a set of ↑requirements is free of contradicting
statements.
Consistency
| of requirements
66
An umbrella term for requirements ↑elicitation, ↑negotiation and
↑validation.
Elaboration
| of requirements
67
→ Requirements elicitation
Elicitation
| of requirements
68
The degree to which a ↑system performs specified functions under
specified conditions for a specified period of time.
Reliability
69
1. A need perceived by a ↑stakeholder.
2. A capability or property that a ↑system shall have.
3. A documented representation of a need, capability or property.
Requirement
70
A person or organization who influences a ↑system’s ↑requirements or
who is impacted by that system.
Stakeholder
71
The degree to which a ↑requirement is expressed such that it cannot be
understood differently by different people.
Unambiguity
| of requirements
72
A ↑review in which the author of a ↑work product leads the reviewers
systematically through the work product and the reviewers ask
questions and make comments about possible issues.
Walkthrough
73
1. For a single ↑requirement: The degree to which the specification of a
requirement is self-contained.
2. For a ↑work product covering multiple requirements: The degree to
which the work product contains all known requirements that are
relevant in the scope of this work product.
Completeness
| of requirements
74
A ↑model describing phenomena in an ↑application domain.
Domain model
75
A ↑model describing a set of ↑objects and relationships between them.
Object model
76
1. In general: The ability to establish explicit relationships between
related ↑work products or ↑items within work products.
2. In RE: The ability to trace a ↑requirement
(a) back to its origins,
(b) forward to its implementation in design and code and its
associated tests,
(c) to requirements it depends on (and vice-versa).
Traceability
77
A recorded, intermediate or final result generated in a work ↑process.
Work product
78
A diagrammatic representation of a ↑class model.
Class diagram
79
A consistent set of logically coherent ↑items. The items are individually
identifiable ↑work products or parts of work products in at most one
↑version per item.
Configuration
80
A ↑model describing a ↑system in its ↑context.
Context model
81
The degree to which an ↑item produces the intended results.
Effectiveness
82
The capabilities of a ↑system as stated by its ↑functional requirements.
Functionality
83
The degree to which a ↑work product or ↑system can be modified
without degrading its ↑quality.
Modifiability
84
A ↑model describing a ↑process or a set of related processes.
Process model
85
1. As a work product: A systematically represented description of the
properties of an ↑item (a ↑system, a device, etc.) that satisfies given
criteria.
2. As a process: the process of specifying (↑eliciting, documenting and
↑validating) the properties of an ↑item.
Specification
86
A ↑model describing the behavior of a ↑system by a finite set of states
and state transitions. State transitions are triggered by events and can in
turn trigger actions and new events.
State machine
87
The degree to which the fulfillment of a ↑requirement by an
| implemented ↑system can be verified.
Verifiability
| of requirements
88
A ↑model of the flow of actions in some part of a ↑system.
Activity model
89
A ↑model describing the ↑behavior of a ↑system, e.g., by a ↑state
machine.
Behavior model
90
In RE: A well-argued request for changing one or more ↑baselined
↑requirements.
Change request
91
1. A diagrammatic representation of a ↑context model.
3. In ↑Structured Analysis, the context diagram is the root of the
↑dataflow diagram hierarchy.
Context diagram
92
The capability of a ↑system to operate as intended despite the presence
of (hardware or software) ↑faults.
Fault tolerance
93
An ordered, typically prioritized collection of work items that a
development team has to work on when developing or evolving a
↑system.
Product backlog
94
The boundary between a ↑system and its surrounding ↑context.
System boundary
95
A diagram type in ↑UML which models the flow of actions in some part
of a ↑system, including ↑data flows and areas of responsibility where
necessary.
Activity diagram
96
The boundary between the ↑context of a ↑system and those parts of the
↑application domain that are irrelevant for the ↑system and its
↑requirements.
Context boundary
97
A high-fidelity ↑prototype that implements critical parts of a ↑system to
an extent that ↑stakeholders can use the prototype to see whether the
prototyped part of the system will work and behave as expected.
Native prototype
98
A ↑language that people use for speaking and writing in everyday life.
Natural language
99
A diagram type in ↑UML which models the interactions between a
selected set of ↑objects and/or ↑actors in the sequential order in which
those interactions occur.
Sequence diagram
100
A diagram type in ↑UML that models the ↑actors and the ↑use cases of a
↑system.
Use case diagram
101
A ↑requirement expressing a ↑user need.
User requirement
102
A controlled way to effect or deny a requested change of a ↑work
product.
Change management
103
A ↑language for expressing ↑models of a certain kind. May be textual,
graphic, symbolic or some combination thereof.
Modeling language
104
The degree to which an ↑item is comprehensible to its intended users.
Understandability
105
Those parts of the real world that are relevant for determining the
↑context of a ↑system.
Application domain
106
A ↑domain property in the ↑context of a ↑system that is required to hold.
Domain requirement
107
A ↑requirement pertaining to a ↑system.
System requirement
108
In agile: Criteria that the implementation of a ↑user story must satisfy in order to be accepted by the ↑stakeholders.
Acceptance criteria
109
A classification of requirements according to their kind into ↑system
requirements (consisting of ↑functional requirements, ↑quality
requirements and ↑constraints), project requirements, and process
requirements.
Kind of requirement
110
A ↑requirement that pertains to a quality concern that is not covered by
↑functional requirements.
Quality requirement
111
The source from which a ↑requirement has been derived.
Requirements source
112
A ↑requirement stating a business ↑goal, objective or need of an
organization.
Business requirement
113
A committee of ↑customer and ↑supplier representatives that decides on
↑change requests.
Change control board
114
A throwaway ↑prototype used to create shared understanding, clarify
↑requirements or validate requirements.
Exploratory prototype
115
1. A situation where two or more ↑requirements cannot be satisfied
together.
2. A situation where two or more ↑stakeholders disagree about certain
↑requirements.
Requirements conflict
116
A document consisting of a ↑requirements specification.
Requirements document
117
A person who – in collaboration with ↑stakeholders – elicits, documents,
validates, and manages ↑requirements.
Requirements Engineer
118
A template for specifying ↑requirements.
Requirements template
119
A diagrammatic representation of a ↑state machine.
State machine diagram
120
A pilot system forming the core of a ↑system to be developed.
Evolutionary prototype
121
A ↑requirement concerning a result or ↑behavior that shall be provided
by a function of a ↑system.
Functional requirement
122
A ↑requirement expressing a ↑stakeholder desire or need.
Stakeholder requirement
123
A ↑requirement describing a performance characteristic (timing, speed,
volume, capacity, throughput, ...).
Performance
| requirement
124
The process of seeking, capturing and consolidating ↑requirements from
available ↑sources, potentially including the re-construction or creation
of requirements.
Requirements elicitation
125
The process of managing existing ↑requirements and requirements related
↑work products, including the storing, changing and tracing of
requirements (↑traceability).
Requirements
| management
126
The systematic and disciplined approach to the ↑specification and
management of ↑requirements with the goal of understanding the
↑stakeholders’ desires and needs and minimizing the risk of delivering a
↑system that does not meet these desires and needs.
Requirements
| Engineering
127
A ↑process where ↑stakeholders are working toward reaching an
agreement to resolve ↑requirements conflicts.
Requirements
| negotiation
128
A ↑quality requirement or a ↑constraint.
Non-functional
| requirement
129
A systematically represented collection of ↑requirements, typically for a
↑system, that satisfies given criteria.
Requirements
| specification
130
A ↑requirements specification pertaining to a ↑system.
System requirements
| specification
131
A coarse description of the required capabilities of a ↑system from the
↑customer’s perspective.
Customer requirements
| specification
132
A ↑requirements specification pertaining to a software ↑system.
Software requirements
| specification
