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. Change request
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.
The degree to which a requirement is expressed such that it cannot be understood differently by different people.
The degree to which an artifact enables a required modification of the artifact.
In RE: A well-argued request for changing one or more baselined requirements.

2. Specification language
An artificial language that has been created for expressing specifications.
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 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.

3. Functional requirement
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
The process of assessing whether a system satisfies all its requirements.
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
A requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).

4. Reliability
An intermediate or final result of system development; for example - a requirements specification.
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.
The process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).
The degree to which the information contained in an artifact is probably true. In RE - correctness is frequently used as a synonym for adequacy.

5. Artifact
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 desired state of affairs (that a stakeholder wants to achieve). Goals describe intentions of stakeholders. They may conflict with one another.
An intermediate or final result of system development; for example - a requirements specification.
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 com

6. Requirements engineering (RE)
The process of seeking - capturing and consolidating requirements from available requirements sources. May include the re-construction or creation of requirements. Aka Requirements discovery
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
An artificial language that has been created for expressing specifications.
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.

7. Requirements engineer
Requirements elicitation
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.
An abstract representation of an existing reality or a reality to be created.
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.

8. State machine
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.
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.
Those parts of the real world that are relevant for determining the context of a system.
A model consisting of a set of classes and relationships between them.

9. Changeability (of an artifact)
A characteristic property of an entity.
The degree to which an artifact enables a required modification of the artifact.
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
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

10. Semi-formal

11. Traceability (of requirements)
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. Sometimes - traceabilit
A tabular - systematic representation of a complex decision that depends on multiple criteria.
A person or organization who delivers a product or service to a customer.
A committee that supervises a project.

12. Configuration
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.
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
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.
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.

13. Application domain
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 ach
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
Those parts of the real world that are relevant for determining the context of a system.
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.

14. Completeness (of 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
A requirement pertaining to a system or to a component of a system.
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
Documents the importance of a requirement in comparison to other requirements according to given criteria.

15. Acceptance
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.
Cardinality.
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.
The process of assessing whether a system satisfies all its requirements.

16. Behavior Model
Defect.
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.
A model describing the behavior of a system or component - e.g. - by a state machine.
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.

17. Security
An excerpt from an artifact - containing only those parts one is currently interested in. A view can abstract or aggregate parts of the artifact.
The capability of a system to protect (a) its data and resources against unauthorized use and (b) its legitimate users against denial of service.
A model that has been created with the purpose of specifying requirements.
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.

18. Use case

19. Adequacy (of a requirement)

20. Context boundary
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.
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.
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.
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.

21. Statechart
A state machine having states that are hierarchically and/or orthogonally decomposed.
A requirements specification pertaining to a software system. Abbreviation: SRS
A model describing the behavior of a system or component - e.g. - by a state machine.
A coarse description of the required capabilities of a system from the customer's perspective. Usually supplied by the customer.

22. Compliance
The degree to which an artifact enables a required modification of the artifact.
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
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 com
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 ach

23. Domain
A model describing the behavior of a system or component - e.g. - by a state machine.
A desired state of affairs (that a stakeholder wants to achieve). Goals describe intentions of stakeholders. They may conflict with one another.
A range of relevant things (for some given matter); for example - an application domain.
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 com

24. Version (of an entity)
Traceability of a requirement forward to its implementation in design and code - RS stands for requirements specification.
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 outgo
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 degree to which the information contained in an artifact is probably true. In RE - correctness is frequently used as a synonym for adequacy.

25. Multiplicity
Cardinality.
A committee of client and supplier representatives that decides on change requests. Abbreviation: CCB
Traceability of a requirement back to its origin.
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.

26. State-transition diagram
User.
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
A diagrammatic representation of a state machine.
A language for expressing models of a certain kind. May be textual - graphic - symbolic or some combination thereof.

27. Requirement (original IEEE definition)
The source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.
A committee of client and supplier representatives that decides on change requests. Abbreviation: CCB
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
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.

28. Defect
A spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
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 ach
A model that has been created with the purpose of specifying requirements.

29. Steering committee
A committee of client and supplier representatives that decides on change requests. Abbreviation: CCB
A committee that supervises a project.
Traceability of a requirement forward to its implementation in design and code - RS stands for requirements specification.
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.

30. Review
A formally organized endeavor for checking an artifact by a group of experts. Checking may be performed with respect to both contents and conformance.
The degree to which the information contained in an artifact is probably true. In RE - correctness is frequently used as a synonym for adequacy.
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.
A state machine having states that are hierarchically and/or orthogonally decomposed.

31. User
The ease with which a system can be transferred to another platform (while preserving its functionality). Portability may be stated as a quality requirement.
A person who uses the functionality provided by a system. Also called end user.
A baseline for a set of requirements.
A coarse description of the required capabilities of a system from the customer's perspective. Usually supplied by the customer.

32. System requirements specification
Requirements elicitation.
The capabilities of a system as stated by its functional requirements.
A requirements specification pertaining to a system. Frequently considered to be a synonym for requirements specification.
Defect.

33. Acceptance test
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 scenari
A requirement pertaining to a system or to a component of a system.
A test that assesses whether a system satisfies all its requirements.
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

34. Supplier
A person or organization who delivers a product or service to a customer.
An intermediate or final result of system development; for example - a requirements specification.
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
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 com

35. State charts
State machines having states that are hierarchically and/or orthogonally decomposed.
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 process of seeking - capturing and consolidating requirements from available requirements sources. May include the re-construction or creation of requirements. Aka Requirements discovery
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

36. Effectiveness

37. Consistency (of requirements)
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
The degree to which an artifact enables a required modification of the artifact.
A range of relevant things (for some given matter); for example - an application domain.
The degree to which a set of requirements is free of contradicting statements.

38. Validation (of requirements)

39. Semantics
A verb characterizing the required action in a requirement written in natural language.
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 meaning of a sign or a set of signs in a language.
The capabilities of a system as stated by its functional requirements.

40. Source (of a requirement)
A range of relevant things (for some given matter); for example - an application domain.
Requirements source
A requirement pertaining to a system or to a component of a system.
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

41. Release
A configuration that has been released for installation and use by customers.
A requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).
The source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.
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.

42. Cardinality
Multiple occurrence of the same information or resource.
Traceability of a requirement back to its origin.
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.
A requirements specification pertaining to a software system. Abbreviation: SRS

43. Requirements source
The capability of a system to protect (a) its data and resources against unauthorized use and (b) its legitimate users against denial of service.
1. A diagrammatic representation of a context model. 2. In Structured Analysis - the context diagram is the root of the data flow diagram hierarchy.
The capabilities of a system as stated by its functional requirements.
The source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.

44. Baseline
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.
The process of checking whether documented requirements match the stakeholders' needs.
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
A uniform regulation for perceiving - manufacturing or executing something.

45. Entity-relationship model
A state machine with atomic states.
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 graphic representation of an entity-relationship model. Abbreviation: ERD

46. Checking (requirements)
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.
The degree to which an artifact enables a required modification of the artifact.
The source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.
A template for the syntactic structure of a phrase that expresses an individual requirement in natural language

47. Software requirements specification
Those parts of the real world that are relevant for determining the context of a system.
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
A requirements specification pertaining to a software system. Abbreviation: SRS
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.

48. Specification
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 com
The source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.
Traceability of a requirement forward to its implementation in design and code - RS stands for requirements specification.
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

49. Safety
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
Traceability of a requirement back to its origin.
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 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

50. 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
The process of seeking - capturing and consolidating requirements from available requirements sources. May include the re-construction or creation of requirements. Aka Requirements discovery
A person who uses the functionality provided by a system. Also called end user.
1. Analysis of elicited requirements in order to understand and document them. 2. Synonym for requirements engineering.