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. Post-RS traceability
Multiple occurrence of the same information or resource.
Traceability of a requirement forward to its implementation in design and code - RS stands for requirements 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.
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.

2. Change request
The process of assessing whether a system satisfies all its requirements.
In RE: A well-argued request for changing one or more baselined requirements.
A committee that supervises a project.
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.

3. Configuration
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.
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 template for the syntactic structure of a phrase that expresses an individual requirement in natural language
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.

4. Baseline
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.
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. 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 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. Standard
A diagrammatic representation of a class model.
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 uniform regulation for perceiving - manufacturing or executing something.
A characteristic property of an entity.

6. Entity-relationship diagram
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 graphic representation of an entity-relationship model. Abbreviation: ERD
Cardinality.
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

7. Glossary
The capabilities of a system as stated by its functional requirements.
A collection of definitions of terms that are relevant in some domain. Frequently - a glossary also contains cross-references - synonyms - homonyms - acronyms - and abbreviations.
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
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.

8. Model
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 maintain a specified level of functionality and performance when used under specified conditions. Reliability may be stated as a quality requirement.
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.
An abstract representation of an existing reality or a reality to be created.

9. Correctness
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 degree to which the information contained in an artifact is probably true. In RE - correctness is frequently used as a synonym for adequacy.
The meaning of a sign or a set of signs in a language.
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.

10. Fault
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.
An excerpt from an artifact - containing only those parts one is currently interested in. A view can abstract or aggregate parts of the artifact.
Defect.
A formally organized endeavor for checking an artifact by a group of experts. Checking may be performed with respect to both contents and conformance.

11. Pre-RS traceability
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.
Traceability of a requirement back to its origin.
Traceability of a requirement forward to its implementation in design and code - RS stands for requirements specification.
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.

12. Validation (of requirements)

13. Performance requirement
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
A committee of client and supplier representatives that decides on change requests. Abbreviation: CCB
Requirements source
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

14. Completeness (of requirements)
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
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.
Abbreviation for Unified Modeling Language - a standardized language for modeling problems or solutions.
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

15. Security
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 verb characterizing the required action in a requirement written in natural language.
The degree to which a result is achieved with minimum consumption of resources.
A formally organized endeavor for checking an artifact by a group of experts. Checking may be performed with respect to both contents and conformance.

16. Traceability (of requirements)
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 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.
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
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

17. Defect
The range of things that can be shaped and designed when developing a system.
A spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
A (software) system that helps develop - operate and maintain systems. In RE - tools support requirements management as well as modeling - documenting - and validating requirements.
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.

18. Scope (of a system)
The rules for constructing structured signs in a language.
In RE: A well-argued request for changing one or more baselined requirements.
The range of things that can be shaped and designed when developing a system.
Cardinality.

19. Unambiguity (of requirements)
The degree to which a requirement is expressed such that it cannot be understood differently by different people.
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 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.
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.

20. Context diagram
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
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 graphic representation of an entity-relationship model. Abbreviation: ERD
1. A diagrammatic representation of a context model. 2. In Structured Analysis - the context diagram is the root of the data flow diagram hierarchy.

21. Conformity (of requirements)
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.
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 degree to which a requirements specification conforms to regulations given in some standard.

22. Scenario
A configuration that has been released for installation and use by customers.
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
The process of seeking - capturing and consolidating requirements from available requirements sources. May include the re-construction or creation of requirements. Aka Requirements discovery
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

23. Redundancy
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 spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
Multiple occurrence of the same information or resource.
Requirements elicitation.

24. Data flow diagram
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
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 degree to which a requirements specification conforms to regulations given in some standard.
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.

25. Changeability (of an artifact)
An abstract representation of an existing reality or a reality to be created.
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 process of assessing whether a system satisfies all its requirements.
The degree to which an artifact enables a required modification of the artifact.

26. Statechart
A verb characterizing the required action in a requirement written in natural language.
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 state machine having states that are hierarchically and/or orthogonally decomposed.
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.

27. Semantics
The meaning of a sign or a set of signs in a language.
Requirements elicitation
A person or organization who delivers a product or service to a customer.
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.

28. Requirements specification
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
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. 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
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. Artifact
A (software) system that helps develop - operate and maintain systems. In RE - tools support requirements management as well as modeling - documenting - and validating requirements.
An intermediate or final result of system development; for example - a requirements specification.
A configuration that has been released for installation and use by customers.
Requirements source

30. Behavior Model
A model describing the behavior of a system or component - e.g. - by a state machine.
Cardinality.
A coarse description of the required capabilities of a system from the customer's perspective. Usually supplied by the customer.
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

31. Supplier
A person or organization who delivers a product or service to a customer.
Documents the importance of a requirement in comparison to other requirements according to given criteria.
A model consisting of a set of classes and relationships between them.
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.

32. Homonym
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 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 state machine with atomic states.
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.

33. Activity diagram
A state machine with atomic states.
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 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 document consisting of a requirements specification. Frequently used as a synonym for requirements specification.

34. Acceptance test
The degree to which a set of requirements is free of contradicting statements.
A test that assesses whether a system satisfies all its requirements.
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 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.

35. Portability
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 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 test that assesses whether a system satisfies all its requirements.
Those parts of the real world that are relevant for determining the context of a system.

36. Entity-relationship model
A template for the syntactic structure of a phrase that expresses an individual requirement in natural language
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 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 range of relevant things (for some given matter); for example - an application domain.

37. End user
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages 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.
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.
User.

38. Usability
A model describing a system in its context.
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 language for expressing models of a certain kind. May be textual - graphic - symbolic or some combination thereof.
A model describing the behavior of a system or component - e.g. - by a state machine.

39. 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 person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.
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 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

40. Customer
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 test that assesses whether a system satisfies all its requirements.
A model that has been created with the purpose of specifying requirements.
A person or organization who receives a product or service. Also see stakeholder.

41. Source (of a requirement)
Requirements source
The process of checking whether documented requirements match the stakeholders' needs.
A desired state of affairs (that a stakeholder wants to achieve). Goals describe intentions of stakeholders. They may conflict with one another.
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

42. Process verb
A state machine having states that are hierarchically and/or orthogonally decomposed.
A verb characterizing the required action in a requirement written in natural language.
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.
Traceability of a requirement forward to its implementation in design and code - RS stands for requirements specification.

43. Acceptance
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 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.
The process of assessing whether a system satisfies all its requirements.
A person or organization who delivers a product or service to a customer.

44. Modeling language
A language for expressing models of a certain kind. May be textual - graphic - symbolic or some combination thereof.
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.
Abbreviation for Unified Modeling Language - a standardized language for modeling problems or solutions.
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

45. Multiplicity
A graphic representation of an entity-relationship model. Abbreviation: ERD
Cardinality.
A person or organization who receives a product or service. Also see stakeholder.
The degree to which the information contained in an artifact is probably true. In RE - correctness is frequently used as a synonym for adequacy.

46. State-transition diagram
A diagrammatic representation of a state machine.
An abstract representation of an existing reality or a reality to be created.
A spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
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

47. Component
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.
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.
Requirements source

48. Prototype
Requirements elicitation.
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 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 ease with which a system can be transferred to another platform (while preserving its functionality). Portability may be stated as a quality requirement.

49. Attribute
A characteristic property of an entity.
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 baseline for a set of requirements.
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.

50. Entity
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.
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 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.