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. Configuration
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 ease with which a system can be transferred to another platform (while preserving its functionality). Portability may be stated as a quality requirement.
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.
The capability of a system to protect (a) its data and resources against unauthorized use and (b) its legitimate users against denial of service.

2. Risk
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 process of assessing whether a system satisfies all its requirements.
A model consisting of a set of classes and relationships between them.
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

3. Customer requirements specification

4. Class
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
1. A diagrammatic representation of a context model. 2. In Structured Analysis - the context diagram is the root of the data flow diagram hierarchy.
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.
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

5. Completeness (of requirements)
Defect
A person or organization who delivers a product or service to a customer.
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.
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

6. Bug
A committee that supervises a project.
Defect
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.
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.

7. Safety
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
Requirements elicitation.
A requirement that pertains to a quality concern that is not covered by functional requirements.
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

8. Checking (requirements)
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 state machine with atomic states.
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
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.

9. Maintainability
A requirement that limits the solution space beyond what is necessary for meeting the given functional requirements and quality requirements.
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
The capabilities of a system as stated by its functional 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.

10. Quality requirement
A requirement that pertains to a quality concern that is not covered by functional requirements.
A model describing a system in its context.
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.
Documents the importance of a requirement in comparison to other requirements according to given criteria.

11. Entity-relationship diagram
A characteristic property of an entity.
A model describing a system in its context.
A graphic representation of an entity-relationship model. Abbreviation: ERD
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

12. Fault
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 baseline for a set of requirements.
A requirements specification pertaining to a system. Frequently considered to be a synonym for requirements specification.
Defect.

13. Model
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.
An abstract representation of an existing reality or a reality to be created.
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. 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
The process of seeking - capturing and consolidating requirements from available requirements sources. May include the re-construction or creation of requirements. Aka Requirements discovery
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. 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

15. Multiplicity
Cardinality.
A requirements specification pertaining to a software system. Abbreviation: SRS
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 requirement that pertains to a quality concern that is not covered by functional requirements.

16. Context

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

18. Efficiency
A model describing a system in its context.
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 person or organization who receives a product or service. Also see stakeholder.
The degree to which a result is achieved with minimum consumption of resources.

19. Prototype
A model describing the behavior of a system or component - e.g. - by a state machine.
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
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 person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.

20. Functional requirement
A collection of definitions of terms that are relevant in some domain. Frequently - a glossary also contains cross-references - synonyms - homonyms - acronyms - and abbreviations.
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.
A requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).
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.

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

22. Actor
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
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 state machine having states that are hierarchically and/or orthogonally decomposed.
State machines having states that are hierarchically and/or orthogonally decomposed.

23. End user
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.
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.
User.
The degree to which a requirement is expressed such that it cannot be understood differently by different people.

24. Activity diagram
A requirement that limits the solution space beyond what is necessary for meeting the given functional requirements and quality requirements.
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.
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 degree to which a result is achieved with minimum consumption of resources.

25. Requirements discovery
The degree to which an artifact enables a required modification of the artifact.
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 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
Requirements elicitation

26. Priority (of a requirement)
Documents the importance of a requirement in comparison to other requirements according to given criteria.
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 process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).
The meaning of a sign or a set of signs in a language.

27. Entity-relationship model
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 language for expressing models of a certain kind. May be textual - graphic - symbolic or some combination thereof.
A spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
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

28. 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 configuration that has been released for installation and use by customers.
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
Documents the importance of a requirement in comparison to other requirements according to given criteria.

29. Kind of requirement
There are several kinds of requirements. Requirements Engineering is primarily concerned with system requirements. Beyond that - there are project requirements and process requirements. Requirements are typically sub-classified into functional requir
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
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 diagrammatic representation of a state machine.

30. Redundancy
The range of things that can be shaped and designed when developing a system.
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
Multiple occurrence of the same information or resource.

31. Modeling language
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.
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.
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. Verifiability (of requirements)
The degree to which an artifact enables a required modification of the artifact.
The degree to which a requirement is expressed such that it cannot be understood differently by different people.
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 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.

33. Important facets of RE
A requirements specification pertaining to a software system. Abbreviation: SRS
An artificial language that has been created for expressing specifications.
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.
A committee of client and supplier representatives that decides on change requests. Abbreviation: CCB

34. Adequacy (of a requirement)

35. Usability
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.
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.
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.
Requirements elicitation.

36. Scenario
1. A description of a potential sequence of events that lead to a desired (or unwanted) result. 2. An ordered sequence of interactions between partners - in particular between a system and external actors. May be a concrete sequence (instance scenari
A requirement 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
Documents the importance of a requirement in comparison to other requirements according to given criteria.
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

37. Requirements templates
An intermediate or final result of system development; for example - a requirements specification.
User.
A blueprint for the syntactic structure of individual requirements.A phrase template is a specific requirements template for requirements written in natural language.
A desired state of affairs (that a stakeholder wants to achieve). Goals describe intentions of stakeholders. They may conflict with one another.

38. Correctness
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
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.
In RE: A well-argued request for changing one or more baselined requirements.
The degree to which the information contained in an artifact is probably true. In RE - correctness is frequently used as a synonym for adequacy.

39. State machine
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 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
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 requirement pertaining to a system or to a component of a system.

40. Validation (of requirements)

41. Version (of an entity)
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.
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
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 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.

42. Process verb
A verb characterizing the required action in a requirement 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
Cardinality.
A requirement that pertains to a quality concern that is not covered by functional requirements.

43. Software requirements specification
A requirements specification pertaining to a software system. Abbreviation: SRS
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 be understood - learned - used - and liked by its users. Usability (or parts thereof) may be stated as quality 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

44. Performance requirement
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 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
Multiple occurrence of the same information or resource.
A range of relevant things (for some given matter); for example - an application domain.

45. Scope (of a system)
A state machine having states that are hierarchically and/or orthogonally decomposed.
The degree to which a requirements specification conforms to regulations given in some standard.
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 range of things that can be shaped and designed when developing a system.

46. Requirements baseline
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 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 diagrammatic representation of a state machine.

47. State-transition diagram
The part of a system's environment that is relevant for the definition as well as the understanding of the requirements of a system to be developed.
A diagrammatic representation of a state machine.
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 document consisting of a requirements specification. Frequently used as a synonym for requirements specification.

48. Constraint
An abstract representation of an existing reality or a reality to be created.
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 result is achieved with minimum consumption of resources.
A desired state of affairs (that a stakeholder wants to achieve). Goals describe intentions of stakeholders. They may conflict with one another.

49. Functionality
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 model that represents the goals of something as an ordered structure of sub-goals.
The capabilities of a system as stated by its functional requirements.
The range of things that can be shaped and designed when developing a system.

50. Customer
A diagrammatic representation of a class model.
Defect
A committee of client and supplier representatives that decides on change requests. Abbreviation: CCB
A person or organization who receives a product or service. Also see stakeholder.