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. System boundary
The boundary between a system and its surrounding context.It separates the system to be developed from its environment; i.e. - it separates the part of the reality that can be modified or altered by the development process from aspects of the environ
A 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.
Traceability of a requirement back to its origin.
A diagrammatic representation of a class model.

2. Change control board
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 committee of client and supplier representatives that decides on change requests. Abbreviation: CCB
A diagrammatic representation of a class model.
A collection of definitions of terms that are relevant in some domain. Frequently - a glossary also contains cross-references - synonyms - homonyms - acronyms - and abbreviations.

3. Review
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 blueprint for the syntactic structure of individual requirements.A phrase template is a specific requirements template for requirements written in natural language.
A formally organized endeavor for checking an artifact by a group of experts. Checking may be performed with respect to both contents and conformance.
Documents the importance of a requirement in comparison to other requirements according to given criteria.

4. Requirements management
The process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).
A (software) system that helps develop - operate and maintain systems. In RE - tools support requirements management as well as modeling - documenting - and validating requirements.
Those parts of the real world that are relevant for determining the context of a system.
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

5. View
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 requirement pertaining to a system or to a component of a system.
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.
An excerpt from an artifact - containing only those parts one is currently interested in. A view can abstract or aggregate parts of the artifact.

6. Customer requirements specification

7. Requirements document
A tabular - systematic representation of a complex decision that depends on multiple criteria.
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 document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
A model describing the behavior of a system or component - e.g. - by a state machine.

8. UML
A graphic representation of an entity-relationship model. Abbreviation: ERD
A test that assesses whether a system satisfies all its requirements.
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
Abbreviation for Unified Modeling Language - a standardized language for modeling problems or solutions.

9. Actor
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 blueprint for the syntactic structure of individual requirements.A phrase template is a specific requirements template for requirements written in natural language.
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 template for the syntactic structure of a phrase that expresses an individual requirement in natural language

10. Entity-relationship model
Traceability of a requirement back to its origin.
There are several kinds of requirements. Requirements Engineering is primarily concerned with system requirements. Beyond that - there are project requirements and process requirements. Requirements are typically sub-classified into functional requir
A baseline for a set of 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

11. Error
A desired state of affairs (that a stakeholder wants to achieve). Goals describe intentions of stakeholders. They may conflict with one another.
The source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.
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
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.

12. Entity-relationship diagram
A graphic representation of an entity-relationship model. Abbreviation: ERD
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 spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
The process of seeking - capturing and consolidating requirements from available requirements sources. May include the re-construction or creation of requirements. Aka Requirements discovery

13. Homonym
User.
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 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.
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

14. Defect
Defect
A spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
User.
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

15. Usability
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 range of relevant things (for some given matter); for example - an application domain.
The source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.
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.

16. Requirements templates
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 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 blueprint for the syntactic structure of individual requirements.A phrase template is a specific requirements template for requirements written in natural language.
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

17. Redundancy
The source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.
A requirements specification pertaining to a software system. Abbreviation: SRS
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.
Multiple occurrence of the same information or resource.

18. Correctness
A language for expressing models of a certain kind. May be textual - graphic - symbolic or some combination thereof.
A model that has been created with the purpose of specifying requirements.
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 the information contained in an artifact is probably true. In RE - correctness is frequently used as a synonym for adequacy.

19. Adequacy (of a requirement)

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

21. Fault
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.
Defect.
Defect
An intermediate or final result of system development; for example - a requirements specification.

22. Priority (of a requirement)
The degree to which a requirement is expressed such that it cannot be understood differently by different people.
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.
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.

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

24. Requirements analysis
The degree to which a set of requirements is free of contradicting statements.
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.
1. Analysis of elicited requirements in order to understand and document them. 2. Synonym for requirements engineering.
A systematically represented description of the properties of an entity (a system - a device - etc.) that satisfies given criteria. It may be about required properties (requirements specification) or implemented properties (e.g. - a technical product

25. Bug
A state machine with atomic states.
Defect
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
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.

26. Domain
A range of relevant things (for some given matter); for example - an application domain.
State machines having states that are hierarchically and/or orthogonally decomposed.
1. In general: The network of thoughts and meanings needed for understanding phenomena or utterances. 2. Especially in RE: The part of a system's environment being relevant for understanding the system and its requirements. Context in the second mea
The degree to which a requirement is expressed such that it cannot be understood differently by different people.

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

28. System
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.
The degree to which a requirement is expressed such that it cannot be understood differently by different people.
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
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

29. Sequence diagram
A configuration that has been released for installation and use by customers.
A model consisting of a set of classes and relationships between them.
A spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
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.

30. Semi-formal

31. State machine
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 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 process of assessing whether a system satisfies all its requirements.
The meaning of a sign or a set of signs in a language.

32. Use case

33. Requirements engineer
A person or organization who delivers a product or service to a customer.
A committee of client and supplier representatives that decides on change requests. Abbreviation: CCB
The process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.

34. Language
A requirement that pertains to a quality concern that is not covered by functional 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.
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 coarse description of the required capabilities of a system from the customer's perspective. Usually supplied by the customer.

35. System 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 requirements specification pertaining to a system. Frequently considered to be a synonym for requirements specification.
A requirements specification pertaining to a software system. Abbreviation: SRS
The process of seeking - capturing and consolidating requirements from available requirements sources. May include the re-construction or creation of requirements. Aka Requirements discovery

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

37. Model
An abstract representation of an existing reality or a reality to be created.
A configuration that has been released for installation and use by customers.
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
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

38. Change request
A tabular - systematic representation of a complex decision that depends on multiple criteria.
A graphic representation of an entity-relationship model. Abbreviation: ERD
In RE: A well-argued request for changing one or more baselined requirements.
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

39. Validation (of requirements)

40. Artifact
A formally organized endeavor for checking an artifact by a group of experts. Checking may be performed with respect to both contents and conformance.
An intermediate or final result of system development; for example - a requirements specification.
A requirement that pertains to a quality concern that is not covered by functional requirements.
The ease with which a system can be transferred to another platform (while preserving its functionality). Portability may be stated as a quality requirement.

41. Requirements baseline
A uniform regulation for perceiving - manufacturing or executing something.
An artificial language that has been created for expressing specifications.
A baseline for a set of requirements.
The degree to which a requirements specification conforms to regulations given in some standard.

42. Non-functional requirement
A test that assesses whether a system satisfies all its requirements.
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 spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
State machines having states that are hierarchically and/or orthogonally decomposed.

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

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

45. Semantics
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.
The meaning of a sign or a set of signs in a language.
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.
Those parts of the real world that are relevant for determining the context of a system.

46. System context

47. Tool (in software engineering)
An abstract representation of an existing reality or a reality to be created.
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. 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 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.

48. Completeness (of requirements)
A spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
Documents the importance of a requirement in comparison to other requirements according to given criteria.
1. For a single requirement: The degree to which a requirementcontains all necessary information. 2. For a requirements specification: The degree to which the specification contains all information which is necessary for developing a system that sati
A 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

49. Phrase template
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 uniform regulation for perceiving - manufacturing or executing something.
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 template for the syntactic structure of a phrase that expresses an individual requirement in natural language

50. Compliance
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 desired state of affairs (that a stakeholder wants to achieve). Goals describe intentions of stakeholders. They may conflict with one another.
1. A condition or capability needed by a user to solve a problem or achieve an objective 2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract - standard - specification - or other formally i
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