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

2. Change control board
A requirements specification pertaining to a system. Frequently considered to be a synonym for requirements specification.
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 committee of client and supplier representatives that decides on change requests. Abbreviation: CCB
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

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

4. Constraint
A blueprint for the syntactic structure of individual requirements.A phrase template is a specific requirements template for requirements written in natural language.
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 coarse description of the required capabilities of a system from the customer's perspective. Usually supplied by the customer.
A requirement that limits the solution space beyond what is necessary for meeting the given functional requirements and quality requirements.

5. Defect
User.
Those parts of the real world that are relevant for determining the context of a system.
A state machine having states that are hierarchically and/or orthogonally decomposed.
A spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.

6. Context boundary
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.
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 model consisting of a set of classes and relationships between them.
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.

7. Prototype
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
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
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.
The process of seeking - capturing and consolidating requirements from available requirements sources. May include the re-construction or creation of requirements. Aka Requirements discovery

8. Inspection

9. Statechart
A state machine having states that are hierarchically and/or orthogonally decomposed.
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.
Traceability of a requirement back to its origin.
The process of seeking - capturing and consolidating requirements from available requirements sources. May include the re-construction or creation of requirements. Aka Requirements discovery

10. Effectiveness

11. Goal model
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
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 model that represents the goals of something as an ordered structure of sub-goals.
Traceability of a requirement back to its origin.

12. Change request
A model that has been created with the purpose of specifying requirements.
In RE: A well-argued request for changing one or more baselined requirements.
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.
A requirement pertaining to a system or to a component of a system.

13. Attribute
A characteristic property of an entity.
Traceability of a requirement forward to its implementation in design and code - RS stands for requirements specification.
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 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.

14. Safety
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 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 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
A desired state of affairs (that a stakeholder wants to achieve). Goals describe intentions of stakeholders. They may conflict with one another.

15. 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.
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.
A requirements specification pertaining to a software system. Abbreviation: SRS
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.

16. Requirements analysis
1. Analysis of elicited requirements in order to understand and document them. 2. Synonym for requirements engineering.
A requirements specification pertaining to a system. Frequently considered to be a synonym for requirements specification.
In RE: A well-argued request for changing one or more baselined 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.

17. End user
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
User.
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.
A diagrammatic representation of a class model.

18. Multiplicity
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.
Cardinality.
A characteristic property of an entity.
A model that has been created with the purpose of specifying requirements.

19. Stakeholder

20. Checking (requirements)
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.
A state machine 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.
A desired state of affairs (that a stakeholder wants to achieve). Goals describe intentions of stakeholders. They may conflict with one another.

21. Risk
Traceability of a requirement forward to its implementation in design and code - RS stands for requirements specification.
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 range of relevant things (for some given matter); for example - an application domain.
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

22. Scenario
A configuration that has been released for installation and use by customers.
The degree to which a result is achieved with minimum consumption of resources.
A model consisting of a set of classes and relationships between them.
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

23. System
Cardinality.
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 diagrammatic representation of a class model.
A template for the syntactic structure of a phrase that expresses an individual requirement in natural language

24. Decision table
A configuration that has been released for installation and use by customers.
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 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 tabular - systematic representation of a complex decision that depends on multiple criteria.

25. Application domain
Those parts of the real world that are relevant for determining the context of a system.
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 meaning of a sign or a set of signs in a language.
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

26. Standard
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 uniform regulation for perceiving - manufacturing or executing something.
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 blueprint for the syntactic structure of individual requirements.A phrase template is a specific requirements template for requirements written in natural language.

27. Walkthrough

28. Requirements document
The range of things that can be shaped and designed when developing a system.
A collection of definitions of terms that are relevant in some domain. Frequently - a glossary also contains cross-references - synonyms - homonyms - acronyms - and abbreviations.
Requirements elicitation.
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.

29. Fault
Abbreviation for Unified Modeling Language - a standardized language for modeling problems or solutions.
Defect.
A requirement that limits the solution space beyond what is necessary for meeting the given functional requirements and quality requirements.
A person or organization who delivers a product or service to a customer.

30. Requirements discovery
A committee that supervises a project.
Requirements elicitation
The process of assessing whether a system satisfies all its requirements.
An event that threatens the success of an endeavor - e.g. - of developing or operating a system. A risk is typically assessed in terms of its probability and potential damage.

31. Tool (in software engineering)
A template for the syntactic structure of a phrase that expresses an individual requirement in natural language
A consistent set of logically coherent units. The units are individually identifiable artifacts or parts of artifacts (e.g. - requirements) in at most one version per unit.
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 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

32. Usability
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 an artifact enables a required modification of the artifact.
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.
The degree to which a set of requirements is free of contradicting statements.

33. Configuration
The process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).
A characteristic property of an entity.
State machines having states that are hierarchically and/or orthogonally decomposed.
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.

34. Model
A characteristic property of an entity.
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 abstract representation of an existing reality or a reality to be created.
A diagrammatic representation of a class model.

35. Requirement (modern definition)
A person or organization who receives a product or service. Also see stakeholder.
The capabilities of a system as stated by its functional 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
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.

36. Compliance
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).
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
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 model that represents the goals of something as an ordered structure of sub-goals.

37. Class
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.
A requirement that limits the solution space beyond what is necessary for meeting the given functional requirements and quality 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
A coarse description of the required capabilities of a system from the customer's perspective. Usually supplied by the customer.

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

39. Viewpoint

40. Functional requirement
User.
The degree to which a requirement is expressed such that it cannot be understood differently by different people.
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 requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).

41. Priority (of a requirement)
Documents the importance of a requirement in comparison to other requirements according to given criteria.
A requirement that limits the solution space beyond what is necessary for meeting the given functional requirements and quality requirements.
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 state machine with atomic states.

42. Use case diagram
An event that threatens the success of an endeavor - e.g. - of developing or operating a system. A risk is typically assessed in terms of its probability and potential damage.
The degree to which a 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
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 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.

43. Requirements model
A model that has been created with the purpose of specifying requirements.
The source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.
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

44. 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
User.
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.

45. Sequence diagram
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 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.
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 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.

46. Context diagram
The process of checking whether documented requirements match the stakeholders' needs.
State machines having states that are hierarchically and/or orthogonally decomposed.
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
1. A diagrammatic representation of a context model. 2. In Structured Analysis - the context diagram is the root of the data flow diagram hierarchy.

47. Requirements elicitation
Requirements source
The process of seeking - capturing and consolidating requirements from available requirements sources. May include the re-construction or creation of requirements. Aka Requirements discovery
1. 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 source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.

48. Pre-RS traceability
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
Traceability of a requirement back to its origin.
A person who uses the functionality provided by a system. Also called end user.
A committee of client and supplier representatives that decides on change requests. Abbreviation: CCB

49. Post-RS traceability
Traceability of a requirement forward to its implementation in design and code - RS stands for requirements specification.
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 blueprint for the syntactic structure of individual requirements.A phrase template is a specific requirements template for requirements written in natural language.
An intermediate or final result of system development; for example - a requirements specification.

50. Quality
A range of relevant things (for some given matter); for example - an application domain.
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
The process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).
1. A diagrammatic representation of a context model. 2. In Structured Analysis - the context diagram is the root of the data flow diagram hierarchy.