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. 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 formally organized endeavor for checking an artifact by a group of experts. Checking may be performed with respect to both contents and conformance.
A person or organization who receives a product or service. Also see stakeholder.
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.

2. Goal
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).
A desired state of affairs (that a stakeholder wants to achieve). Goals describe intentions of stakeholders. They may conflict with one another.
A blueprint for the syntactic structure of individual requirements.A phrase template is a specific requirements template for requirements written in natural language.
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

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

4. Requirements management
Abbreviation for Unified Modeling Language - a standardized language for modeling problems or solutions.
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 managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).
A model describing the behavior of a system or component - e.g. - by a state machine.

5. Acceptance test
A test that assesses whether a system satisfies all its requirements.
A configuration that has been released for installation and use by customers.
An intermediate or final result of system development; for example - a requirements specification.
Those parts of the real world that are relevant for determining the context of a system.

6. Acceptance
The process of assessing whether a system satisfies all its requirements.
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
A requirements specification pertaining to a system. Frequently considered to be a synonym for requirements specification.
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

7. Verifiability (of requirements)
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.
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 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: Extr
A formally organized endeavor for checking an artifact by a group of experts. Checking may be performed with respect to both contents and conformance.

8. Consistency (of requirements)
The degree to which a set of requirements is free of contradicting statements.
A committee that supervises a project.
A diagrammatic representation of a class model.
State machines having states that are hierarchically and/or orthogonally decomposed.

9. Version (of an entity)
A graphic representation of an entity-relationship model. Abbreviation: ERD
An intermediate or final result of system development; for example - a 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 degree to which a requirement is expressed such that it cannot be understood differently by different people.

10. Validation (of requirements)

11. Requirement (modern definition)
A person or organization who delivers a product or service to a customer.
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 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.
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

12. Activity diagram
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
Requirements source
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 requirement pertaining to a system or to a component of a system.

13. Finite state automaton
Defect
The degree to which a requirements specification conforms to regulations given in some standard.
A state machine with atomic states.
A requirement that limits the solution space beyond what is necessary for meeting the given functional requirements and quality requirements.

14. Requirements document
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.
A state machine having states that are hierarchically and/or orthogonally decomposed.
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 document consisting of a requirements specification. Frequently used as a synonym for requirements specification.

15. Performance requirement
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
An artificial language that has been created for expressing specifications.
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.
The degree to which a set of requirements is free of contradicting statements.

16. Decision table
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 tabular - systematic representation of a complex decision that depends on multiple criteria.
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.
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

17. Tool (in software engineering)
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 (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 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 state machine having states that are hierarchically and/or orthogonally decomposed.

18. View
The process of checking whether documented requirements match the stakeholders' needs.
An excerpt from an artifact - containing only those parts one is currently interested in. A view can abstract or aggregate parts of the artifact.
A spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
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

19. Multiplicity
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.
Cardinality.
A tabular - systematic representation of a complex decision that depends on multiple criteria.
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.

20. Semantics
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 meaning of a sign or a set of signs in a language.
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 document consisting of a requirements specification. Frequently used as a synonym for requirements specification.

21. Requirements templates
A (software) system that helps develop - operate and maintain systems. In RE - tools support requirements management as well as modeling - documenting - and validating requirements.
A desired state of affairs (that a stakeholder wants to achieve). Goals describe intentions of stakeholders. They may conflict with one another.
Abbreviation for Unified Modeling Language - a standardized language for modeling problems or solutions.
A blueprint for the syntactic structure of individual requirements.A phrase template is a specific requirements template for requirements written in natural language.

22. Feature
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
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 model consisting of a set of classes and relationships between them.
The degree to which a requirements specification conforms to regulations given in some standard.

23. Defect
A spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
State machines having states that are hierarchically and/or orthogonally decomposed.
A state machine having states that are hierarchically and/or orthogonally decomposed.
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.

24. System
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
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.
A coarse description of the required capabilities of a system from the customer's perspective. Usually supplied by the customer.
Documents the importance of a requirement in comparison to other requirements according to given criteria.

25. Standard
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 language for expressing models of a certain kind. May be textual - graphic - symbolic or some combination thereof.
A uniform regulation for perceiving - manufacturing or executing something.
User.

26. Actor
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
An abstract representation of an existing reality or a reality to be created.
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
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.

27. Requirements source
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
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 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 source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.

28. Constraint
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: Extr
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.
In RE: A well-argued request for changing one or more baselined requirements.
A requirement that limits the solution space beyond what is necessary for meeting the given functional requirements and quality requirements.

29. Artifact
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.
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 configuration that has been released for installation and use by customers.
An intermediate or final result of system development; for example - a requirements specification.

30. Requirement (original IEEE definition)
The process of assessing whether a system satisfies all its requirements.
An abstract representation of an existing reality or a reality to be created.
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
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.

31. Scenario
A requirement that limits the solution space beyond what is necessary for meeting the given functional requirements and quality requirements.
The degree to which a requirement is expressed such that it cannot be understood differently by different people.
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 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

32. Elicitation (of requirements)
Documents the importance of a requirement in comparison to other requirements according to given criteria.
A requirement that pertains to a quality concern that is not covered by functional requirements.
Requirements elicitation.
Defect

33. Class diagram
A state machine having states that are hierarchically and/or orthogonally decomposed.
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.
User.
A diagrammatic representation of a class model.

34. Software requirements specification
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 requirements specification pertaining to a software system. Abbreviation: SRS
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 model that represents the goals of something as an ordered structure of sub-goals.

35. Entity-relationship diagram
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.
An abstract representation of an existing reality or a reality to be created.
A graphic representation of an entity-relationship model. Abbreviation: ERD
The source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.

36. Usability
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.
The process of checking whether documented requirements match the stakeholders' needs.
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.
The degree to which a result is achieved with minimum consumption of resources.

37. Homonym
The rules for constructing structured signs in a language.
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.
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.
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

38. Quality
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 person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.
The process of checking whether documented requirements match the stakeholders' needs.
The rules for constructing structured signs in a language.

39. Inspection

40. Steering committee
An abstract representation of an existing reality or a reality to be created.
The degree to which a requirement is expressed such that it cannot be understood differently by different people.
An artificial language that has been created for expressing specifications.
A committee that supervises a project.

41. Use case

42. Sequence diagram
An excerpt from an artifact - containing only those parts one is currently interested in. A view can abstract or aggregate parts of the artifact.
A model that represents the goals of something as an ordered structure of sub-goals.
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
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.

43. Source (of a requirement)
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.
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
Requirements source
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.

44. Unambiguity (of requirements)
The degree to which a requirement is expressed such that it cannot be understood differently by different people.
The rules for constructing structured signs in a language.
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.
In RE: A well-argued request for changing one or more baselined requirements.

45. Correctness
User.
The degree to which the information contained in an artifact is probably true. In RE - correctness is frequently used as a synonym for adequacy.
A requirement that pertains to a quality concern that is not covered by functional requirements.
Abbreviation for Unified Modeling Language - a standardized language for modeling problems or solutions.

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

47. Syntax
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
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.
A characteristic property of an entity.
The rules for constructing structured signs in a language.

48. Context model
A language for expressing models of a certain kind. May be textual - graphic - symbolic or some combination thereof.
A test that assesses whether a system satisfies all its requirements.
A model describing a system in its context.
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.

49. Process verb
A diagrammatic representation of a class model.
The degree to which the information contained in an artifact is probably true. In RE - correctness is frequently used as a synonym for adequacy.
A verb characterizing the required action in a requirement written in natural language.
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

50. Risk
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.
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.
A state machine having states that are hierarchically and/or orthogonally decomposed.
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.