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. User
A requirements specification pertaining to a system. Frequently considered to be a synonym for requirements specification.
A person who uses the functionality provided by a system. Also called end user.
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.
Abbreviation for Unified Modeling Language - a standardized language for modeling problems or solutions.

2. Constraint
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 requirement that limits the solution space beyond what is necessary for meeting the given functional requirements and quality requirements.
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 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.

3. Application domain
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.
Those parts of the real world that are relevant for determining the context of a system.
A diagrammatic representation of a class model.
The source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.

4. Specification
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 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.
The source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.

5. Change request
In RE: A well-argued request for changing one or more baselined requirements.
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
Multiple occurrence of the same information or resource.
Cardinality.

6. Class model
A model that has been created with the purpose of specifying requirements.
A model consisting of a set of classes and relationships between them.
A coarse description of the required capabilities of a system from the customer's perspective. Usually supplied by the customer.
Cardinality.

7. Finite state automaton
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 committee that supervises a project.
A model describing the behavior of a system or component - e.g. - by a state machine.
A state machine with atomic states.

8. Acceptance test
A test that assesses whether a system satisfies all its requirements.
An intermediate or final result of system development; for example - a requirements specification.
A blueprint for the syntactic structure of individual requirements.A phrase template is a specific requirements template for requirements written in natural language.
Requirements elicitation.

9. Requirements engineering (RE)
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 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
State machines having states that are hierarchically and/or orthogonally decomposed.
The degree to which a result is achieved with minimum consumption of resources.

10. UML
Abbreviation for Unified Modeling Language - a standardized language for modeling problems or solutions.
Those parts of the real world that are relevant for determining the context of a system.
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.
The degree to which a requirements specification conforms to regulations given in some standard.

11. Functionality
A person or organization who receives a product or service. Also see stakeholder.
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. 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 capabilities of a system as stated by its functional requirements.

12. Requirements templates
A tabular - systematic representation of a complex decision that depends on multiple criteria.
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 capability of an artifact to adhere to standards - regulations - laws - or other formally imposed documents. Systems frequently need to comply with standards - regulations - and laws constraining the domain where the system is deployed. Such com
A blueprint for the syntactic structure of individual requirements.A phrase template is a specific requirements template for requirements written in natural language.

13. System boundary
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 configuration that has been released for installation and use by customers.
A committee of client and supplier representatives that decides on change requests. Abbreviation: CCB
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

14. Requirements source
The degree to which a result is achieved with minimum consumption of resources.
The source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.
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.
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.

15. Requirements document
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 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
Traceability of a requirement forward to its implementation in design and code - RS stands for requirements specification.
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.

16. Semantics
A committee of client and supplier representatives that decides on change requests. Abbreviation: CCB
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.
A test that assesses whether a system satisfies all its requirements.

17. Data flow diagram
A person or organization that has a (direct or indirect) influence on a system's requirements. Indirect influence also includes situations where a person or organization is impacted by the system.
The process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).
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 maintain a specified level of functionality and performance when used under specified conditions. Reliability may be stated as a quality requirement.

18. Effectiveness

19. Completeness (of requirements)
A template for the syntactic structure of a phrase that expresses an individual requirement in natural language
A requirements specification pertaining to a software system. Abbreviation: SRS
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 requirements specification pertaining to a system. Frequently considered to be a synonym for requirements specification.

20. Usability
A template for the syntactic structure of a phrase that expresses an individual requirement in natural language
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.
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
The process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).

21. State charts
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 state machine with atomic states.
State machines having states that are hierarchically and/or orthogonally decomposed.
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.

22. Change control board
State machines having states that are hierarchically and/or orthogonally decomposed.
A requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).
A committee of client and supplier representatives that decides on change requests. Abbreviation: CCB
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.

23. Verifiability (of requirements)
The capability of an artifact to adhere to standards - regulations - laws - or other formally imposed documents. Systems frequently need to comply with standards - regulations - and laws constraining the domain where the system is deployed. Such com
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 artificial language that has been created for expressing specifications.
The degree to which a result is achieved with minimum consumption of resources.

24. Entity-relationship model
A requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).
A template for the syntactic structure of a phrase that expresses an individual requirement in natural language
An excerpt from an artifact - containing only those parts one is currently interested in. A view can abstract or aggregate parts of the artifact.
A model 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

25. Version (of an entity)
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.
Traceability of a requirement forward to its implementation in design and code - RS stands for requirements specification.
The degree to which a requirements specification conforms to regulations given in some standard.
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.

26. Important facets of RE
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
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.
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
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.

27. Decision table
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 tabular - systematic representation of a complex decision that depends on multiple criteria.
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 meaning of a sign or a set of signs in a language.

28. 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. 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 capability of a system to protect (a) its data and resources against unauthorized use and (b) its legitimate users against denial of service.
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

29. Walkthrough

30. Validation (of requirements)

31. Error
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
State machines having states that are hierarchically and/or orthogonally decomposed.
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.
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

32. Process verb
Requirements elicitation
A characteristic property of an entity.
A requirement that limits the solution space beyond what is necessary for meeting the given functional requirements and quality requirements.
A verb characterizing the required action in a requirement written in natural language.

33. Unambiguity (of 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
The degree to which a requirement is expressed such that it cannot be understood differently by different people.
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 (software) system that helps develop - operate and maintain systems. In RE - tools support requirements management as well as modeling - documenting - and validating requirements.

34. Goal
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 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.
Those parts of the real world that are relevant for determining the context of a system.
A desired state of affairs (that a stakeholder wants to achieve). Goals describe intentions of stakeholders. They may conflict with one another.

35. Requirements model
Traceability of a requirement back to its origin.
A model that has been created with the purpose of specifying requirements.
A model consisting of a set of classes and relationships between them.
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

36. Elicitation (of requirements)
Requirements elicitation.
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 collection of definitions of terms that are relevant in some domain. Frequently - a glossary also contains cross-references - synonyms - homonyms - acronyms - and abbreviations.
The degree to which a result is achieved with minimum consumption of resources.

37. Security
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 model describing a system in its context.
A spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
The capability of a system to protect (a) its data and resources against unauthorized use and (b) its legitimate users against denial of service.

38. Activity diagram
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.
Requirements elicitation.
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

39. Reliability
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
The capability of a system to maintain a specified level of functionality and performance when used under specified conditions. Reliability may be stated as a quality requirement.
A state machine having states that are hierarchically and/or orthogonally decomposed.
A range of relevant things (for some given matter); for example - an application domain.

40. Class diagram
An abstract representation of an existing reality or a reality to be created.
A diagrammatic representation of a class model.
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
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.

41. Context boundary
Requirements source
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.
The degree to which a requirement is expressed such that it cannot be understood differently by different people.
The source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.

42. Requirements engineer
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.
An event that threatens the success of an endeavor - e.g. - of developing or operating a system. A risk is typically assessed in terms of its probability and potential damage.
A 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 requirement pertaining to a system or to a component of a system.

43. State machine
Requirements source
1. In manufacturing: a piece which is built prior to the start of mass production. 2. In software engineering: An executable piece of software that implements critical parts of a system in advance. In Requirements Engineering - prototypes are used as
A model 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 managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).

44. Feature
A requirements specification pertaining to a system. Frequently considered to be a synonym for requirements specification.
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.
An artificial language that has been created for expressing specifications.
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

45. Post-RS traceability
Traceability of a requirement forward to its implementation in design and code - RS stands for requirements specification.
Abbreviation for Unified Modeling Language - a standardized language for modeling problems or solutions.
Requirements elicitation
A formally organized endeavor for checking an artifact by a group of experts. Checking may be performed with respect to both contents and conformance.

46. Domain
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
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 range of relevant things (for some given matter); for example - an application domain.
A state machine having states that are hierarchically and/or orthogonally decomposed.

47. Checking (requirements)
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.
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.
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.

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

49. Review
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 formally organized endeavor for checking an artifact by a group of experts. Checking may be performed with respect to both contents and conformance.
The meaning of a sign or a set of signs in a language.
The degree to which an artifact enables a required modification of the artifact.

50. View
An abstract representation of an existing reality or a reality to be created.
An excerpt from an artifact - containing only those parts one is currently interested in. A view can abstract or aggregate parts of the artifact.
A 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 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