Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

Requirements Engineering > IREB_CPRE_Glossary > Flashcards

IREB_CPRE_Glossary Flashcards

1
Q

Acceptance

A

The process of assessing whether a system satisfies all its requirements

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

Acceptance test

A

A test that assesses whether a system satisfies all its requirements.

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

Activity diagram

A

A diagram type in UML which models the flow of actions in a system or in a component including data flows and areas of responsibility where necessary.

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

Actor

A
  1. Generally in RE: A person, a system or a technical device in the context of a system that interacts with the system.
  2. Especially in goal-oriented RE: a person, a system or a technical device that may act and process information in order to achieve some goals.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Adequacy (of a requirement)

A

The degree to which a requirement expresses the stakeholders’ true desires and needs (i.e., those they had actually in mind when stating the requirement).

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

Application domain

A

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

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

Artifact

A

An intermediate or final result of system development; for example, a requirements specification.

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

Attribute

A

A characteristic property of an entity.

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

Baseline

A

A stable, change-controlled configuration of artifacts.
Baselines serve for release planning and release definition as well as for project management purposes such as effort estimation.

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

Behavior model

A

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

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

Bug

A

A spot in an artifact that is incorrectly described or crafted. Synonyms: for Defect, Fault.

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

Cardinality

A
  1. In modeling: The minimum and maximum number of objects in a relationship. In UML, the term multiplicity is used for cardinality.
  2. In mathematics: The number of elements in a set.
    Synonym: Multiplicity
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Change control board

A

A committee of client and supplier representatives that decides on change requests.
Abbreviation: CCB

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

Change request

A

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

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

Changeability (of an artifact)

A

The degree to which an artifact enables a required modification of the artifact.

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

Checking (requirements)

A

Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.
Note that some sources define validation broader and consider the terms checking and validation to be synonyms.

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

Class

A

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

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

Class diagram

A

A diagrammatic representation of a class model.

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

Class model

A

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

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

Completeness (of requirements)

A
  1. For a single requirement: The degree to which a requirement contains all necessary information
  2. For a requirements specification: The degree to which the specification contains all information which is necessary for developing a system that satisfies the stakeholders’ desires and needs.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Compliance

A

The capability of an artifact to adhere to standards, regulations, laws, or other formally imposed documents.

Systems frequently need to comply with standards, regulations, and laws constraining the domain where the system is deployed. Such compliance can only be ensured systematically if compliance checking already starts with the requirements.

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

Component

A
  1. In general: A delimitable part of a system.
  2. In software architecture: An encapsulated set of coherent objects or classes that jointly provide a service.
    Note: When viewed in isolation, a component is a system by itself.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Configuration

A

A consistent set of logically coherent units. The units are individually identifiable artifacts or parts of artifacts (e.g., requirements) in at most one version per unit.

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

Conformity (of requirements)

A

The degree to which a requirements specification conforms to regulations given in some standard.

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

Consistency (of requirements)

A

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

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

Constraint

A

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

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

Context

A
  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 in the second meaning is also called the system context.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q

Context boundary

A

Boundary between the context of a system and those parts of the application domain that are irrelevant for the system and its requirements.
The context boundary separates the relevant part of the environment of a system to be developed from the irrelevant part, i.e., the part that does not influence the system to be developed and, thus, does not have to be considered during requirements engineering.

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

Context diagram

A
  1. A diagrammatic representation of a context model.

2. In Structured Analysis, the context diagram is the root of the dataflow diagram hierarchy.

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

Context model

A

A model describing a system in its context.

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

Correctness

A

The degree to which the information contained in an artifact is provably true.
In RE, correctness is frequently used as a synonym for adequacy.

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

Customer

A

A person or organization who receives a product or service.

Also see stakeholder.

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

Customer requirements specification

A

A coarse description of the required capabilities of a system from the customer’s perspective.
Usually supplied by the customer.

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

Dataflow diagram

A

A diagram modeling the functionality of a system or component by processes (also called activities), data stores and data flows. Incoming data flows trigger processes which then consume the received data, transform them, read/write persistent data held in data stores and then produce new data flows which may be intermediate results that trigger other processes or final results that leave the system.

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

Decision table

A

A tabular, systematic representation of a complex decision that depends on multiple criteria.

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

Defect

A

A spot in an artifact that is incorrectly described or crafted.
Synonym: fault, bug

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

Domain

A

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

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

Effectiveness

A

The degree to which something actually happens in the way it ought to happen.
In RE, typically the degree to which a system actually enables its users to achieve their goals as stated in the system’s requirements.

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

Efficiency

A

The degree to which a result is achieved with minimum consumption of resources.

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

Elicitation (of requirements)

A

The process of seeking, capturing and consolidating requirements from available requirements sources. May include the re-construction or creation of requirements.
Synonym: Requirements discovery, Requirements elicitation

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

End user

A

A person who uses the functionality provided by a system.

Synonym: User.

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

Entity

A
  1. In general: an element or set of elements that may stand for any conceivable item, e.g., a system, a part of reality, a thing, an organization, a process, etc.
  2. In entity-relationship-modeling: an individual object which has an identity and does not depend on another object.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
43
Q

Entity-relationship diagram

A

A graphic representation of an entity-relationship model.

Abbreviation: ERD

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

Entity-relationship model

A

A model of data that are relevant for a ?system, or of the data of an ?application domain. An ERM consists of a set of entity types that are each characterized by attributes and linked by relationships.
Abbreviation: ERM, ER Model

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

Error

A

A discrepancy between an observed behavior or result and the specified behavior or result.
An error typically is a symptom for the existence of a fault or defect in some artifact.

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

Fault

A

A spot in an artifact that is incorrectly described or crafted.
Synonym: Bug, Defect

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

Fault Tolerance

A

The capability of a system to continue normal operation despite the presence of (hardware or software) faults.
Fault tolerance may be stated as a quality requirement.

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

Feature

A

A delimitable characteristic of a system that provides value for stakeholders.
Normally comprises several requirements and is used for communicating with stakeholders on a higher level of abstraction and for expressing variable or optional characteristics.

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

Functional requirement

A

A requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).

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

Functionality

A

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

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

Glossary

A

A collection of definitions of terms that are relevant in some domain. Frequently, a glossary also contains cross-references, ?synonyms, homonyms, acronyms, and abbreviations.

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

Goal

A

A desired state of affairs (that a stakeholder wants to achieve).
Goals describe intentions of stakeholders. They may conflict with one another.

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

Goal model

A

A model that represents the goals of something as an ordered structure of sub-goals.

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

Homonym

A

A term looking identical to another term, but having a different meaning.
For example, bill as a bank note and bill as a list (of materials) are homonyms.

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

Inspection

A

A kind of review where the artifact under review is inspected by a group of experts according to given criteria. The experts’ findings are then collected and consolidated.

56
Q

Kind of requirement

A

There are several kinds of requirements. Requirements Engineering is primarily concerned with system requirements. Beyond that, there are project requirements and process requirements.
Requirements are typically sub-classified into functional requirements, quality requirements and constraints. The latter two are also called non-functional requirements.

57
Q

Language

A

A structured set of signs for expressing and communicating information. Signs are elements that are used for communication: expressions in a language, symbols, gestures, etc.

58
Q

Maintainability

A

The ease with which a software system can be modified to correct faults or adapt the system to changing needs.
Maintainability may be stated as a quality requirement.

59
Q

Model

A

An abstract representation of an existing reality or a reality to be created.
This definition covers the most frequent case in requirements engineering, but is a bit narrow. More generally speaking, a model is an abstract representation of an existing entity or an entity to be created, where entity denotes any part of reality or any other conceivable set of elements or phenomena, including other models. With respect to a model, the entity is called the original.
In Requirements Engineering, requirements can be specified by models.
Note that entity in this definition is used in its general meaning which is different from the one used in Entity-relationship models.

60
Q

Modeling language

A

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

61
Q

Multiplicity

A

In UML, the term multiplicity is used for cardinality.: The minimum and maximum number of objects in a relationship.
Synonym: Cardinality

62
Q

Non-functional requirement

A

A quality requirement or a constraint.
Performance requirements may be regarded as another category of non-functional requirements. In this glossary, performance requirements are considered to be a sub-category of quality requirements.
Synonym: Extra-functional requirement

63
Q

Performance requirement

A

A requirement describing a performance characteristic (timing, speed, volume, capacity, throughput…).
Is regarded in this glossary as a sub-category of quality requirements, but can also be considered as a non-functional requirements category of its own.

64
Q

Phrase template

A

A template for the syntactic structure of a phrase that expresses an individual requirement in natural language.
Example: ‘As a [user], I want [function], so that [value]’

65
Q

Portability

A

The ease with which a system can be transferred to another platform (while preserving its functionality).
Portability may be stated as a quality requirement.

66
Q

Priority (of a requirement)

A

Documents the importance of a requirement in comparison to other requirements according to given criteria.

67
Q

Process verb

A

A verb characterizing the required action in a requirement written in natural language.

68
Q

Prototype

A
  1. In manufacturing: a piece which is built prior to the start of mass production.
  2. In software engineering: An executable piece of software that implements critical parts of a system in advance.
    In Requirements Engineering, prototypes are used as a means for requirements elicitation and validation.
69
Q

Quality

A

The degree to which a set of inherent characteristics of an entity fulfills requirements.
The entity may be a system, service, product, artifact, process, person, organization, etc. An inherent characteristic is a distinguishing feature of or property of an entity which is inherent to the entity and has not been assigned explicitly.
This is the notion of quality that is generally used in industry. Note that quality in this definition just means fitness for intended use, as stated in the requirements. This is in contrast to the colloquial notion of quality which is typically connoted with goodness or excellence.

70
Q

Quality requirement

A

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

71
Q

Redundancy

A

Multiple occurrence of the same information or resource.

72
Q

Release

A

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

73
Q

Reliability

A

The capability of a system to maintain a specified level of functionality and performance when used under specified conditions.
Reliability may be stated as a quality requirement.

74
Q

Requirement

A
  1. A condition or capability needed by a user to solve a problem or achieve an objective.
  2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents.
  3. A documented representation of a condition or capability as in (1) or (2).
    Note: The definition above is the classic one from IEEE Std 610.12 of 1990.

Alternatively, we also give a more modern definition:

  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.
75
Q

Requirements analysis

A
  1. Analysis of elicited requirements in order to understand and document them.
  2. Synonym for requirements engineering.
76
Q

Requirements baseline

A

A baseline for a set of requirements.

77
Q

Requirements discovery

A

The process of seeking, capturing and consolidating requirements from available requirements sources. May include the re-construction or creation of requirements.
Synonym: Requirements elicitation.

78
Q

Requirements document

A

A document consisting of a requirements specification.

Frequently used as a synonym for requirements specification.

79
Q

Requirements elicitation

A

The process of seeking, capturing and consolidating requirements from available requirements sources. May include the re-construction or creation of requirements.
Synonym: Requirements discovery

80
Q

Requirements engineer

A

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

81
Q

Requirements Engineering

A

A systematic and disciplined approach to the specification and management of requirements with the following goals:

(1) Knowing the relevant requirements, achieving a consensus among the stakeholders about these requirements, documenting them according to given standards, and managing them systematically,
(2) Understanding and documenting the stakeholders’ desires and needs,
(3) Specifying and managing requirements to minimize the risk of delivering a system that does not meet the stakeholders’ desires and needs.

Abbreviation: RE
Note: All three goals address important facets of RE: (1) process-orientation, (2) stakeholder focus, and (3) importance of risk and value considerations.

82
Q

Requirements management

A

The process of managing existing requirements and requirements related artifacts. Includes particularly storing, changing and tracing of requirements (traceability).

83
Q

Requirements model

A

A model that has been created with the purpose of specifying requirements.

84
Q

Requirements source

A

The source from which a requirement has been derived. Typical sources are stakeholders, documents, existing systems and observations.
Synonym: Source (of a Requirement)

85
Q

Requirements specification

A

A systematically represented collection of requirements, typically for a system or component, that satisfies given criteria.
In some situations we distinguish between a customer requirements specification (typically written by the customer) and a system requirements specification or software requirements specification (written by the supplier).
Requirements specification may also denote the activity of specifying requirements.

86
Q

Requirements template

A

A blueprint for the syntactic structure of individual requirements.
A phrase template is a specific requirements template for requirements written in natural language.

87
Q

Review

A

A formally organized endeavor for checking an artifact by a group of experts.
Checking may be performed with respect to both contents and conformance.

88
Q

Risk

A

An event that threatens the success of an endeavor, e.g., of developing or operating a system. A risk is typically assessed in terms of its probability and potential damage.

89
Q

Safety

A

The capability of a system to achieve an acceptable level of probability that operating the system will not result in harming people, property or the environment.
Safety requirements may be stated as quality requirements or in terms of functional requirements.

90
Q

Scenario

A
  1. A description of a potential sequence of events that lead to a desired (or unwanted) result.
  2. An ordered sequence of interactions between partners, in particular between a system and external actors. May be a concrete sequence (instance scenario) or a set of potential sequences (type scenario, use case).
  3. In UML: An execution trace of a use case.
91
Q

Scope (of a system)

A

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

92
Q

Security

A

The capability of a system to protect (a) its data and resources against unauthorized use and (b) its legitimate users against denial of service.

93
Q

Semantics

A

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

94
Q

Semi-formal

A

Something which is formal to some extent, but not completely.
An artifact is called semi-formal if it contains formal parts, but isn’t formalized totally. Typically, a semi-formal artifact has a defined syntax, while the semantics is partially defined only.

95
Q

Sequence diagram

A

A diagram type in UML which models the interactions between a selected set of objects and/or actors in the sequential order that those interactions occur.

96
Q

Software requirements specification

A

A requirements specification pertaining to a software system.
Abbreviation: SRS

97
Q

Source (of a requirement)

A

The source from which a requirement has been derived. Typical sources are stakeholders, documents, existing systems and observations.
Synonym: Requirements source

98
Q

Specification

A

A systematically represented description of the properties of an entity (a system, a device, etc.) that satisfies given criteria.
It may be about required properties (requirements specification) or implemented properties (e.g., a technical product specification).

99
Q

Specification language

A

An artificial language that has been created for expressing specifications.

100
Q

Stakeholder

A

A person or organization that has a (direct or indirect) influence on a system’s requirements.
Indirect influence also includes situations where a person or organization is impacted by the system.

101
Q

Standard

A

A uniform regulation for perceiving, manufacturing or executing something.

102
Q

State machine

A

A model describing the behavior of a system or component by a finite set of states and state transitions. State transitions are triggered by events and can in turn trigger actions and new events.
Related terms:
- A state machine with atomic states is called a finite state automaton.
- State machines having states that are hierarchically and/or orthogonally decomposed are called statecharts.

103
Q

State-transition diagram

A

A diagrammatic representation of a state machine.

104
Q

Statechart

A

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

105
Q

Steering committee

A

A committee that supervises a project.

106
Q

Structured Analysis

A

An approach for specifying the functionality of a system based on a hierarchy of dataflow diagrams. Data flows as well as persistent data are defined in a data dictionary. A context diagram models the sources of incoming and the destinations of outgoing data flows.

107
Q

Supplier

A

A person or organization who delivers a product or service to a customer.

108
Q

Synonym

A

A word having the same meaning as another word.

109
Q

Syntax

A

The rules for constructing structured signs in a language.

110
Q

System

A
  1. In general: A principle for ordering and structuring.
  2. In Informatics: A coherent, delimitable set of ?components that – by coordinated action – provides services.
    Requirements Engineering is concerned with the specification of requirements for systems consisting of software components, technical elements (computing hardware, devices, sensors,…) and organizational elements (persons, positions, business processes,…).
    Note that a system may comprise other systems. Therefore, components or services of a system are also considered to be systems.
111
Q

System boundary

A

The boundary between a system and its surrounding context.
The system boundary separates the system to be developed from its environment; i.e., it separates the part of the reality that can be modified or altered by the development process from aspects of the environment that cannot be changed or modified by the development process.

112
Q

System context

A

The part of a system’s environment that is relevant for the definition as well as the understanding of the requirements of a system to be developed.

113
Q

System requirement

A

A requirement pertaining to a system or to a component of a system.

114
Q

System require-ments specification

A

A requirements specification pertaining to a system.

Frequently considered to be a synonym for requirements specification.

115
Q

Tool (in software engineering)

A

A (software) system that helps develop, operate and maintain systems.
In RE, tools support requirements management as well as modeling, documenting, and validating requirements.

116
Q

Traceability (of requirements)

A

The ability to trace a requirement (1) back to its origins, (2) forward to its implementation in design and code, (3) to requirements it depends on (and vice-versa). Origins may be stakeholders, documents, rationale, etc.
Traceability of a requirement back to its origin is also called pre-RS traceability. Conversely, traceability of a requirement forward to its implementation in design and code is also called post-RS traceability. RS stands for requirements specification.
Sometimes, traceability to the rationale of a requirement is considered to be a traceability category of its own.

117
Q

UML

A

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

118
Q

Unambiguity (of requirements)

A

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

119
Q

Usability

A

The capability of a system to be understood, learned, used, and liked by its users.
Usability (or parts thereof) may be stated as quality requirements.

120
Q

Use case

A

A description of the interactions possible between actors and a system that, when executed, provide added value.
Use cases specify a system from a user’s (or other external actor’s) perspective: every use case describes some functionality that the system must provide for the actors involved in the use case.

121
Q

Use case diagram

A

A diagram type in UML that models the actors and the use cases of a system.
The boundary between the actors and the use cases constitutes the system boundary.

122
Q

User

A

A person who uses the functionality provided by a system. Also called end user.

123
Q

Validation (of requirements)

A

The process of checking whether documented requirements match the stakeholders’ needs.
Note that some sources define requirements validation broader by also including checking requirements for qualities such as unambiguity or comprehensibility, thus considering the terms validation and checking to be synonyms.

124
Q

Verifiability (of requirements)

A

The degree to which the fulfillment of a requirement by an implemented system can be checked, e.g., by defining acceptance test cases, measurements or inspection procedures.

125
Q

Version (of an entity)

A

If an entity exists in multiple, time-ordered occurrences, where each occurrence has been created by modifying one of its predecessors, every occurrence is a version of that entity.

126
Q

View

A

An excerpt from an artifact, containing only those parts one is currently interested in.
A view can abstract or aggregate parts of the artifact.

127
Q

Viewpoint

A

A certain perspective on the requirements of a system.
Typical viewpoints are perspectives that a stakeholder or stakeholder group has (for example, an end user’s perspective or an operator’s perspective). However, there can also be topical viewpoints such as a security viewpoint.

Note that this definition is somewhat different from the definition of an architectural viewpoint in the international standard ISO/IEC42010: 2007 (IEEE Std 1471-2000).

128
Q

Walkthrough

A

A kind of review where the author of an artifact under review walks a group of experts systematically through the artifact. The experts’ findings are then collected and consolidated.

129
Q

CCB

A

Change Control Board

130
Q

CPRE

A

Certified Professional for Requirements Engineering

131
Q

ER

A

Entity-Relationship

132
Q

ERD

A

Entity-Relationship Diagram

133
Q

ERM

A

Entity-Relationship Model

134
Q

IREB

A

International Requirements Engineering Board

135
Q

RE

A

Requirements Engineering

136
Q

SRS

A

Software Requirements Specification

137
Q

UML

A

Unified Modeling Language

Requirements Engineering (1 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions