CPRE Foundation Level Glossary: Def→Name Flashcards

Guess the CPRE Foundation Level Glossary term name by looking at its definition.

1
Q

Abbreviation for Unified Modeling Language, a standardized language
for modeling problems or solutions.

A

UML

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

A desired state of affairs (that a ↑stakeholder wants to achieve).

A

Goal

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

A possible event that threatens the success of an endeavor.

A

Risk

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q
  1. A part played by a person in a given context.
  2. In ↑UML ↑class models: The parts played by the linked ↑objects in an
    ↑association.
A

Role

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

A (software) ↑system that helps develop, operate and maintain systems.

A

Tool

in software engineering

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

A person who uses the ↑functionality provided by a ↑system.

A

User

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

An excerpt from a ↑work product, containing only those parts one is
currently interested in.

A

View

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q
  1. In general:
    (a) Able to move quickly and easily.
    (b) Quick, smart, and clever.
  2. In software development: A development approach which builds a
    product ↑incrementally by dividing work into ↑iterations of fixed
    duration (↑timeboxes).
A

Agile

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q
  1. A human action that produces an incorrect result.
  2. A discrepancy between an observed ↑behavior or result and the
    specified behavior or result.
A

Error

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

→ Defect

A

Fault

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

An abstract representation of an existing part of reality or a part of
reality to be created.

A

Model

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

The range of things that can be shaped and designed when developing a
↑system.

A

Scope

of a system development

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

An imperfection or deficiency in a ↑work product that impairs its
intended use.
Synonyms: bug, fault

A

Defect

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q
  1. A plan or drawing produced to show how something will look,
    function or be structured before it is made.
  2. The activity of creating a design.
  3. A decorative pattern [This meaning does not apply in the software
    engineering ↑domain].
A

Design

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

A range of relevant things (for some given matter); for example, an
↑application domain.

A

Domain

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q
  1. In general: Anything which is perceivable or conceivable (→ item).
  2. 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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

An evaluation of a ↑work product by an individual or a group in order to
find problems or suggest improvements.

A

Review

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

An ↑iteration in ↑agile development, particularly when using ↑Scrum.

A

Sprint

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

The rules for constructing structured signs in a ↑language.

A

Syntax

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q
  1. In general: A principle for ordering and structuring.
  2. In engineering: A coherent, delimitable set of elements that – by
    coordinated action – achieve some purpose.
A

System

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q
  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.
A

Context

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

A distinguishing characteristic of a ↑system that provides value for
↑stakeholders.

A

Feature

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q

A medium-fidelity ↑prototype that demonstrates characteristics of a
user interface without implementing any real ↑functionality.

A

Mock-up

of a digital system

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q

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.

A

Persona

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
29
Q

A set of interrelated ↑activities performed in a given order to process
information or materials.

A

Process

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
30
Q

A software-based ↑system or a ↑service provided by a system which is
developed and marketed by a ↑supplier and used by ↑customers.

A

Product

in the context of software

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
31
Q
  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.
A

Quality

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
32
Q

A ↑configuration that has been released for installation and use by
↑customers.

A

Release

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
33
Q

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.

A

Service

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
34
Q

A word having the same meaning as another word.

A

Synonym

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
35
Q

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.

A

Version

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
36
Q

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).

A

Adequacy

of a requirement

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
37
Q

A stable, change-controlled ↑configuration of ↑work products.

A

Baseline

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
38
Q

The way in which a ↑system reacts to stimuli, changes its state and
produces observable results.

A

Behavior

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
39
Q

A person or organization who receives a ↑system, a ↑product or a
↑service.
Also see ↑stakeholder.

A

Customer

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
40
Q

A collection of definitions of terms that are relevant in some ↑domain.

A

Glossary

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
41
Q

The level of importance assigned to an ↑item, e.g., a ↑requirement or a
↑defect, according to certain criteria.

A

Priority

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
42
Q

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.

A

Security

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
43
Q

A formal, possibly mandatory set of regulations for how to interpret,
develop, manufacture, or execute something.

A

Standard

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
44
Q

A set of possible interactions between external ↑actors and a ↑system
that provide a benefit for the actor(s) involved.

A

Use case

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
45
Q

A characteristic property of an ↑entity or an ↑object.

A

Attribute

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
46
Q
  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.
A

Component

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
47
Q

An addition to a ↑system under development that extends, enhances or
refactors (↑refactoring) the existing parts of the system.

A

Increment

in software development

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
48
Q
  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.
A

Iteration

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
49
Q

The degree to which an individual ↑requirement is a necessary part of
the ↑requirements specification of a ↑system.

A

Necessity

of a requirement

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
50
Q
  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.
A

Prototype

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
51
Q

The meaning of a sign or a set of signs in a ↑language.

A

Semantics

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
52
Q

The degree to which a ↑system can be used by specified ↑users to
achieve specified ↑goals in a specified context of use.

A

Usability

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
53
Q

A low-fidelity ↑prototype built with simple materials that primarily
serves for discussing and validating requirements, design ideas or user
interface concepts.

A

Wireframe

54
Q

The adherence of a ↑work product to ↑standards, conventions,

regulations, laws, or similar prescriptions.

A

Compliance

55
Q

The degree to which a ↑work product conforms to regulations given in
some ↑standard.

A

Conformity

56
Q

A ↑requirement that limits the solution space beyond what is necessary
for meeting the given ↑functional requirements and ↑quality
requirements.

A

Constraint

in RE

57
Q

The degree to which resources are expended in relation to results
achieved.

A

Efficiency

58
Q

A ↑model representing a set ↑goals, sub-goals and the relationships
between them.

A

Goal model

59
Q

A formal ↑review of a ↑work product by a group of experts according to
given criteria, following a defined procedure.

A

Inspection

60
Q

Multiple occurrence of the same information or resource.

A

Redundancy

61
Q

A ↑state machine having states that are hierarchically and/or
orthogonally decomposed.

A

Statechart

62
Q

A description of a need from a ↑user’s perspective together with the
expected benefit when this need is satisfied.

A

User story

63
Q

The ↑process of confirming that an ↑item (a ↑system, a ↑work product or
a part thereof) matches its ↑stakeholders’ needs.

A

Validation

64
Q

A model consisting of a set of ↑classes and relationships between them.

A

Class model

65
Q

The degree to which a set of ↑requirements is free of contradicting
statements.

A

Consistency

of requirements

66
Q

An umbrella term for requirements ↑elicitation, ↑negotiation and
↑validation.

A

Elaboration

of requirements

67
Q

→ Requirements elicitation

A

Elicitation

of requirements

68
Q

The degree to which a ↑system performs specified functions under
specified conditions for a specified period of time.

A

Reliability

69
Q
  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.
A

Requirement

70
Q

A person or organization who influences a ↑system’s ↑requirements or
who is impacted by that system.

A

Stakeholder

71
Q

The degree to which a ↑requirement is expressed such that it cannot be
understood differently by different people.

A

Unambiguity

of requirements

72
Q

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.

A

Walkthrough

73
Q
  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.
A

Completeness

of requirements

74
Q

A ↑model describing phenomena in an ↑application domain.

A

Domain model

75
Q

A ↑model describing a set of ↑objects and relationships between them.

A

Object model

76
Q
  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).
A

Traceability

77
Q

A recorded, intermediate or final result generated in a work ↑process.

A

Work product

78
Q

A diagrammatic representation of a ↑class model.

A

Class diagram

79
Q

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.

A

Configuration

80
Q

A ↑model describing a ↑system in its ↑context.

A

Context model

81
Q

The degree to which an ↑item produces the intended results.

A

Effectiveness

82
Q

The capabilities of a ↑system as stated by its ↑functional requirements.

A

Functionality

83
Q

The degree to which a ↑work product or ↑system can be modified
without degrading its ↑quality.

A

Modifiability

84
Q

A ↑model describing a ↑process or a set of related processes.

A

Process model

85
Q
  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.
A

Specification

86
Q

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.

A

State machine

87
Q

The degree to which the fulfillment of a ↑requirement by an

implemented ↑system can be verified.

A

Verifiability

of requirements

88
Q

A ↑model of the flow of actions in some part of a ↑system.

A

Activity model

89
Q

A ↑model describing the ↑behavior of a ↑system, e.g., by a ↑state
machine.

A

Behavior model

90
Q

In RE: A well-argued request for changing one or more ↑baselined
↑requirements.

A

Change request

91
Q
  1. A diagrammatic representation of a ↑context model.
  2. In ↑Structured Analysis, the context diagram is the root of the
    ↑dataflow diagram hierarchy.
A

Context diagram

92
Q

The capability of a ↑system to operate as intended despite the presence
of (hardware or software) ↑faults.

A

Fault tolerance

93
Q

An ordered, typically prioritized collection of work items that a
development team has to work on when developing or evolving a
↑system.

A

Product backlog

94
Q

The boundary between a ↑system and its surrounding ↑context.

A

System boundary

95
Q

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.

A

Activity diagram

96
Q

The boundary between the ↑context of a ↑system and those parts of the
↑application domain that are irrelevant for the ↑system and its
↑requirements.

A

Context boundary

97
Q

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.

A

Native prototype

98
Q

A ↑language that people use for speaking and writing in everyday life.

A

Natural language

99
Q

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.

A

Sequence diagram

100
Q

A diagram type in ↑UML that models the ↑actors and the ↑use cases of a
↑system.

A

Use case diagram

101
Q

A ↑requirement expressing a ↑user need.

A

User requirement

102
Q

A controlled way to effect or deny a requested change of a ↑work
product.

A

Change management

103
Q

A ↑language for expressing ↑models of a certain kind. May be textual,
graphic, symbolic or some combination thereof.

A

Modeling language

104
Q

The degree to which an ↑item is comprehensible to its intended users.

A

Understandability

105
Q

Those parts of the real world that are relevant for determining the
↑context of a ↑system.

A

Application domain

106
Q

A ↑domain property in the ↑context of a ↑system that is required to hold.

A

Domain requirement

107
Q

A ↑requirement pertaining to a ↑system.

A

System requirement

108
Q

In agile: Criteria that the implementation of a ↑user story must satisfy in order to be accepted by the ↑stakeholders.

A

Acceptance criteria

109
Q

A classification of requirements according to their kind into ↑system
requirements (consisting of ↑functional requirements, ↑quality
requirements and ↑constraints), project requirements, and process
requirements.

A

Kind of requirement

110
Q

A ↑requirement that pertains to a quality concern that is not covered by
↑functional requirements.

A

Quality requirement

111
Q

The source from which a ↑requirement has been derived.

A

Requirements source

112
Q

A ↑requirement stating a business ↑goal, objective or need of an
organization.

A

Business requirement

113
Q

A committee of ↑customer and ↑supplier representatives that decides on
↑change requests.

A

Change control board

114
Q

A throwaway ↑prototype used to create shared understanding, clarify
↑requirements or validate requirements.

A

Exploratory prototype

115
Q
  1. A situation where two or more ↑requirements cannot be satisfied
    together.
  2. A situation where two or more ↑stakeholders disagree about certain
    ↑requirements.
A

Requirements conflict

116
Q

A document consisting of a ↑requirements specification.

A

Requirements document

117
Q

A person who – in collaboration with ↑stakeholders – elicits, documents,
validates, and manages ↑requirements.

A

Requirements Engineer

118
Q

A template for specifying ↑requirements.

A

Requirements template

119
Q

A diagrammatic representation of a ↑state machine.

A

State machine diagram

120
Q

A pilot system forming the core of a ↑system to be developed.

A

Evolutionary prototype

121
Q

A ↑requirement concerning a result or ↑behavior that shall be provided
by a function of a ↑system.

A

Functional requirement

122
Q

A ↑requirement expressing a ↑stakeholder desire or need.

A

Stakeholder requirement

123
Q

A ↑requirement describing a performance characteristic (timing, speed,
volume, capacity, throughput, …).

A

Performance

requirement

124
Q

The process of seeking, capturing and consolidating ↑requirements from
available ↑sources, potentially including the re-construction or creation
of requirements.

A

Requirements elicitation

125
Q

The process of managing existing ↑requirements and requirements related
↑work products, including the storing, changing and tracing of
requirements (↑traceability).

A

Requirements

management

126
Q

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.

A

Requirements

Engineering

127
Q

A ↑process where ↑stakeholders are working toward reaching an
agreement to resolve ↑requirements conflicts.

A

Requirements

negotiation

128
Q

A ↑quality requirement or a ↑constraint.

A

Non-functional

requirement

129
Q

A systematically represented collection of ↑requirements, typically for a
↑system, that satisfies given criteria.

A

Requirements

specification

130
Q

A ↑requirements specification pertaining to a ↑system.

A

System requirements

specification

131
Q

A coarse description of the required capabilities of a ↑system from the
↑customer’s perspective.

A

Customer requirements

specification

132
Q

A ↑requirements specification pertaining to a software ↑system.

A

Software requirements

specification