Test your basic knowledge |

CPRE: Certified Professional Requirements Engineering

Subjects : certifications, cpre, it-skills

Instructions:

Answer 50 questions in 15 minutes.
If you are not ready to take this test, you can study here.
Match each statement with the correct term.
Don't refresh. All questions and answers are randomly picked and ordered every time you load a test.

This is a study tool. The 3 wrong answers for each question are randomly chosen from answers to other questions. So, you might find at times the answers obvious, but you will see it re-enforces your understanding as you take the test each time.

1. Verifiability (of requirements)
Multiple occurrence of the same information or resource.
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
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 mea
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.

2. View
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.
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 de
A configuration that has been released for installation and use by customers.
An excerpt from an artifact - containing only those parts one is currently interested in. A view can abstract or aggregate parts of the artifact.

3. Requirement (original IEEE definition)
A model consisting of a set of classes and relationships between them.
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 viewpoi
A desired state of affairs (that a stakeholder wants to achieve). Goals describe intentions of stakeholders. They may conflict with one another.
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 i

4. Error
A requirements specification pertaining to a software system. Abbreviation: SRS
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. In colloquial English - there is sometimes no distinction between the
A coarse description of the required capabilities of a system from the customer's perspective. Usually supplied by the customer.
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.

5. Requirements source
The source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.
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
An intermediate or final result of system development; for example - a requirements specification.
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.

6. Multiplicity
The process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).
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
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.
Cardinality.

7. Model
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.
An abstract representation of an existing reality or a reality to be created.
A graphic representation of an entity-relationship model. Abbreviation: ERD
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. In colloquial English - there is sometimes no distinction between the

8. Validation (of requirements)

9. Phrase template
A template for the syntactic structure of a phrase that expresses an individual requirement in natural language
Requirements elicitation.
A diagrammatic representation of a class model.
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.

10. Fault tolerance
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.
Requirements elicitation.
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.
A requirement pertaining to a system or to a component of a system.

11. Requirements baseline
A formally organized endeavor for checking an artifact by a group of experts. Checking may be performed with respect to both contents and conformance.
A baseline for a set of requirements.
The degree to which a set of requirements is free of contradicting statements.
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.

12. Prototype
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
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 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 s
A person or organization who receives a product or service. Also see stakeholder.

13. Bug
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.
Defect
A requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).
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

14. Customer requirements specification

15. Class diagram
A person who uses the functionality provided by a system. Also called end user.
A diagrammatic representation of a class model.
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.
A state machine having states that are hierarchically and/or orthogonally decomposed.

16. State charts
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.
State machines having states that are hierarchically and/or orthogonally decomposed.
A tabular - systematic representation of a complex decision that depends on multiple criteria.
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 characteri

17. Use case

18. Class
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 i
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.
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.
1. Analysis of elicited requirements in order to understand and document them. 2. Synonym for requirements engineering.

19. Entity-relationship model
A state machine having states that are hierarchically and/or orthogonally decomposed.
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
The capabilities of a system as stated by its functional requirements.
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

20. Requirements templates
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 requir
A blueprint for the syntactic structure of individual requirements.A phrase template is a specific requirements template for requirements written in natural language.
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.
A requirement pertaining to a system or to a component of a system.

21. Context model
The process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).
A tabular - systematic representation of a complex decision that depends on multiple criteria.
A model describing a system in its context.
A coarse description of the required capabilities of a system from the customer's perspective. Usually supplied by the customer.

22. Kind of requirement
A state machine having states that are hierarchically and/or orthogonally decomposed.
Cardinality.
Requirements elicitation
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 requir

23. Language
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 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.
A tabular - systematic representation of a complex decision that depends on multiple criteria.
1. A diagrammatic representation of a context model. 2. In Structured Analysis - the context diagram is the root of the data flow diagram hierarchy.

24. Class model
A model consisting of a set of classes and relationships between them.
A baseline for a set of requirements.
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.
A diagrammatic representation of a state machine.

25. Redundancy
1. A diagrammatic representation of a context model. 2. In Structured Analysis - the context diagram is the root of the data flow diagram hierarchy.
Multiple occurrence of the same information or resource.
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.
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.

26. Attribute
A diagrammatic representation of a state machine.
The range of things that can be shaped and designed when developing a system.
Traceability of a requirement forward to its implementation in design and code - RS stands for requirements specification.
A characteristic property of an entity.

27. Stakeholder

28. Entity
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.
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 a
A characteristic property of an entity.
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 s

29. Checking (requirements)
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.
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.
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.
User.

30. Behavior Model
A model describing the behavior of a system or component - e.g. - by a state machine.
A verb characterizing the required action in a requirement written in natural language.
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.
Cardinality.

31. Standard
A uniform regulation for perceiving - manufacturing or executing something.
The degree to which a result is achieved with minimum consumption of resources.
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.
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.

32. Requirements model
A model that has been created with the purpose of specifying requirements.
The process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).
A person who uses the functionality provided by a system. Also called end user.
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

33. Tool (in software engineering)
A (software) system that helps develop - operate and maintain systems. In RE - tools support requirements management as well as modeling - documenting - and validating requirements.
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 a
A model that represents the goals of something as an ordered structure of sub-goals.
An intermediate or final result of system development; for example - a requirements specification.

34. Functional requirement
A requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).
Requirements elicitation.
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 s
Documents the importance of a requirement in comparison to other requirements according to given criteria.

35. Activity diagram
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.
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.
A state machine having states that are hierarchically and/or orthogonally decomposed.
A desired state of affairs (that a stakeholder wants to achieve). Goals describe intentions of stakeholders. They may conflict with one another.

36. System
1. A diagrammatic representation of a context model. 2. In Structured Analysis - the context diagram is the root of the data flow diagram hierarchy.
A blueprint for the syntactic structure of individual requirements.A phrase template is a specific requirements template for requirements written in natural language.
A person or organization who delivers a product or service to a customer.
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

37. Requirements document
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
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.
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 re
A characteristic property of an entity.

38. Maintainability
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
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
A state machine having states that are hierarchically and/or orthogonally decomposed.
The process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).

39. Requirements analysis
A model describing the behavior of a system or component - e.g. - by a state machine.
1. Analysis of elicited requirements in order to understand and document them. 2. Synonym for requirements engineering.
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
A configuration that has been released for installation and use by customers.

40. Homonym
Boundary between the context of a system and those parts of the application domain that are irrelevant for the system and its requirements. It separates the relevant part of the environment of a system to be developed from the irrelevant part - i.e.
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.
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.
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

41. System boundary
The boundary between a system and its surrounding context.It 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 environ
A description of the interactions possible between actors and a system that - when executed - provide added value. They specify a system from a user's (or other external actor's) perspective: every use case describes some functionality that the syste
A committee that supervises a project.
When viewed in isolation - a component is a system by itself. 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.

42. Important facets of RE
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.
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.
A range of relevant things (for some given matter); for example - an application domain.
A state machine having states that are hierarchically and/or orthogonally decomposed.

43. Source (of a requirement)
A model that has been created with the purpose of specifying requirements.
A requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).
A graphic representation of an entity-relationship model. Abbreviation: ERD
Requirements source

44. Syntax
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 s
Requirements source
The degree to which an artifact enables a required modification of the artifact.
The rules for constructing structured signs in a language.

45. Walkthrough

46. Requirements engineering (RE)
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
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 requir
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 accor
A template for the syntactic structure of a phrase that expresses an individual requirement in natural language

47. Completeness (of requirements)
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
1. For a single requirement: The degree to which a requirementcontains 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 sati
A spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
An excerpt from an artifact - containing only those parts one is currently interested in. A view can abstract or aggregate parts of the artifact.

48. Specification
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 graphic representation of an entity-relationship model. Abbreviation: ERD
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
The capability of a system to protect (a) its data and resources against unauthorized use and (b) its legitimate users against denial of service.

49. Safety
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.
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 re
Cardinality.
A requirements specification pertaining to a system. Frequently considered to be a synonym for requirements specification.

50. Functionality
The capabilities of a system as stated by its functional requirements.
The ease with which a system can be transferred to another platform (while preserving its functionality). Portability may be stated as a quality requirement.
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 re
The degree to which a set of requirements is free of contradicting statements.