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. Usability
A requirement that pertains to a quality concern that is not covered by functional requirements.
Defect.
A model describing the behavior of a system or component - e.g. - by a state machine.
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.

2. Standard
A uniform regulation for perceiving - manufacturing or executing something.
1. Analysis of elicited requirements in order to understand and document them. 2. Synonym for requirements engineering.
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
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

3. Domain
A range of relevant things (for some given matter); for example - an application domain.
A requirements specification pertaining to a system. Frequently considered to be a synonym for requirements specification.
The source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.
A diagrammatic representation of a class model.

4. Quality requirement
User.
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 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 requirement that pertains to a quality concern that is not covered by functional requirements.

5. Artifact
A model that has been created with the purpose of specifying 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.
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

6. Sequence diagram
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.
A model consisting of a set of classes and relationships between them.
1. A diagrammatic representation of a context model. 2. In Structured Analysis - the context diagram is the root of the data flow diagram hierarchy.

7. Model
A state machine with atomic states.
An abstract representation of an existing reality or a reality to be created.
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 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.

8. Context model
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 diagrammatic representation of a class model.
Cardinality.
A model describing a system in its context.

9. Defect
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 committee that supervises a project.
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 spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.

10. State machine
The rules for constructing structured signs in a language.
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
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.
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.

11. Validation (of requirements)

12. User
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 person who uses the functionality provided by a system. Also called end user.
An artificial language that has been created for expressing specifications.
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

13. Verifiability (of requirements)
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 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 process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).
Traceability of a requirement back to its origin.

14. Phrase template
A template for the syntactic structure of a phrase that expresses an individual requirement in natural language
A diagrammatic representation of a state machine.
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 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

15. Requirements engineering (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.
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 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 person or organization who receives a product or service. Also see stakeholder.

16. Statechart
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 range of things that can be shaped and designed when developing a system.
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 state machine having states that are hierarchically and/or orthogonally decomposed.

17. Requirement (original IEEE definition)
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 person who uses the functionality provided by a system. Also called end user.
Those parts of the real world that are relevant for determining the context of a system.
A requirements specification pertaining to a system. Frequently considered to be a synonym for requirements specification.

18. Customer
A configuration that has been released for installation and use by customers.
A person or organization who receives a product or service. Also see stakeholder.
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.
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).

19. State charts
Traceability of a requirement forward to its implementation in design and code - RS stands for requirements specification.
The meaning of a sign or a set of signs in a language.
State machines having states that are hierarchically and/or orthogonally decomposed.
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.

20. 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
Documents the importance of a requirement in comparison to other requirements according to given criteria.
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
The process of assessing whether a system satisfies all its requirements.

21. Tool (in software engineering)
Documents the importance of a requirement in comparison to other requirements according to given criteria.
A range of relevant things (for some given matter); for example - an application domain.
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 a requirement is expressed such that it cannot be understood differently by different people.

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

23. System context

24. Requirements engineer
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 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

25. Requirements management
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 document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
The process of checking whether documented requirements match the stakeholders' needs.
The process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).

26. Post-RS traceability
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
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
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

27. Requirements document
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 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 document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
An intermediate or final result of system development; for example - a requirements specification.

28. Fault
Defect.
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
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 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

29. View
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.
Requirements elicitation.
A test that assesses whether a system satisfies all its requirements.
An excerpt from an artifact - containing only those parts one is currently interested in. A view can abstract or aggregate parts of the artifact.

30. Change request
A model consisting of a set of classes and relationships between them.
In RE: A well-argued request for changing one or more baselined requirements.
A baseline for a set of requirements.
State machines having states that are hierarchically and/or orthogonally decomposed.

31. Multiplicity
Cardinality.
A verb characterizing the required action in a requirement written in natural language.
A range of relevant things (for some given matter); for example - an application domain.
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.

32. Customer requirements specification

33. Performance requirement
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 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 continue normal operation despite the presence of (hardware or software) faults. Fault tolerance may be stated as a quality requirement.
Requirements elicitation

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

35. Context diagram
A characteristic property of an 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
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 (software) system that helps develop - operate and maintain systems. In RE - tools support requirements management as well as modeling - documenting - and validating requirements.

36. Supplier
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 person or organization who delivers a product or service to a customer.
The process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).
State machines having states that are hierarchically and/or orthogonally decomposed.

37. Modeling language
User.
A language for expressing models of a certain kind. May be textual - graphic - symbolic or some combination thereof.
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 baseline for a set of requirements.

38. Goal model
A baseline for a set of requirements.
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.
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 model that represents the goals of something as an ordered structure of sub-goals.

39. 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.
Requirements elicitation
User.
A requirements specification pertaining to a software system. Abbreviation: SRS

40. Kind of requirement
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
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
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
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.

41. Viewpoint

42. UML
Cardinality.
Abbreviation for Unified Modeling Language - a standardized language for modeling problems or solutions.
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 that represents the goals of something as an ordered structure of sub-goals.

43. Priority (of a requirement)
A model describing the behavior of a system or component - e.g. - by a state machine.
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 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.
Documents the importance of a requirement in comparison to other requirements according to given criteria.

44. Version (of an entity)
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
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. A diagrammatic representation of a context model. 2. In Structured Analysis - the context diagram is the root of the data flow diagram hierarchy.
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

45. Process verb
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 test that assesses whether a system satisfies all its requirements.
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 verb characterizing the required action in a requirement written in natural language.

46. Scope (of a system)
The range of things that can be shaped and designed when developing a system.
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 requirement that limits the solution space beyond what is necessary for meeting the given functional requirements and quality 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.

47. Behavior Model
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 rules for constructing structured signs in a language.
A model describing the behavior of a system or component - e.g. - by a state machine.
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.

48. Class diagram
Traceability of a requirement back to its origin.
A model describing a system in its context.
Requirements source
A diagrammatic representation of a class model.

49. End 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.
User.
Requirements elicitation
A language for expressing models of a certain kind. May be textual - graphic - symbolic or some combination thereof.

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