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

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

3. Changeability (of an artifact)
A spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
The degree to which an artifact enables a required modification of the artifact.
Those parts of the real world that are relevant for determining the context of a system.
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

4. Semantics
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.
The meaning of a sign or a set of signs in a 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.
A coarse description of the required capabilities of a system from the customer's perspective. Usually supplied by the customer.

5. Phrase template
A model that has been created with the purpose of specifying 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 verb characterizing the required action in a requirement written in natural language.
A template for the syntactic structure of a phrase that expresses an individual requirement in natural language

6. Use case diagram
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 diagrammatic representation of a class model.
Requirements elicitation.
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.

7. User
A person who uses the functionality provided by a system. Also called end user.
A characteristic property of an 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.
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

8. Attribute
A characteristic property of an entity.
The degree to which a result is achieved with minimum consumption of resources.
The meaning of a sign or a set of signs in a language.
The degree to which a requirement is expressed such that it cannot be understood differently by different people.

9. Acceptance test
A test that assesses whether a system satisfies all its requirements.
Those parts of the real world that are relevant for determining the context of a system.
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 state machine with atomic states.

10. Context model
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 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 model describing a system in its context.
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

11. Bug
The degree to which a requirements specification conforms to regulations given in some 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 person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.
Defect

12. Use case

Warning: Invalid argument supplied for foreach() in /var/www/html/basicversity.com/show_quiz.php on line 183

13. Entity-relationship diagram
A language for expressing models of a certain kind. May be textual - graphic - symbolic or some combination thereof.
A graphic representation of an entity-relationship model. Abbreviation: ERD
1. A condition or capability needed by a user to solve a problem or achieve an objective 2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract - standard - specification - or other formally i
A person or organization who receives a product or service. Also see stakeholder.

14. Usability
Cardinality.
A person who uses the functionality provided by a system. Also called end user.
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 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.

15. Requirements engineering (RE)
An artificial language that has been created for expressing specifications.
A person or organization who receives a product or service. Also see stakeholder.
Defect
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

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

17. Validation (of requirements)

Warning: Invalid argument supplied for foreach() in /var/www/html/basicversity.com/show_quiz.php on line 183

18. Risk
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
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 committee of client and supplier representatives that decides on change requests. Abbreviation: CCB
A tabular - systematic representation of a complex decision that depends on multiple criteria.

19. Prototype
A graphic representation of an entity-relationship model. Abbreviation: ERD
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 committee that supervises a project.
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

20. Priority (of a requirement)
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
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.

21. State-transition diagram
Documents the importance of a requirement in comparison to other requirements according to given criteria.
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 diagrammatic representation of a state machine.
A requirement that pertains to a quality concern that is not covered by functional requirements.

22. Unambiguity (of requirements)
A graphic representation of an entity-relationship model. Abbreviation: ERD
The degree to which a requirement is expressed such that it cannot be understood differently by different people.
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. 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

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

24. Application domain
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 template for the syntactic structure of a phrase that expresses an individual requirement in natural language
Cardinality.
Those parts of the real world that are relevant for determining the context of a system.

25. Requirements templates
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
Abbreviation for Unified Modeling Language - a standardized language for modeling problems or solutions.
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 blueprint for the syntactic structure of individual requirements.A phrase template is a specific requirements template for requirements written in natural language.

26. Requirement (modern definition)
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
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.
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 spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.

27. Data flow diagram
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 requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).
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 process of seeking - capturing and consolidating requirements from available requirements sources. May include the re-construction or creation of requirements. Aka Requirements discovery

28. Syntax
Traceability of a requirement back to its origin.
A requirements specification pertaining to a system. Frequently considered to be a synonym for requirements specification.
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.
The rules for constructing structured signs in a language.

29. Feature
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 requirements specification conforms to regulations given in some standard.
Those parts of the real world that are relevant for determining the context of a system.
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

30. System requirement
The ease with which a system can be transferred to another platform (while preserving its functionality). Portability may be stated as a quality requirement.
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 collection of definitions of terms that are relevant in some domain. Frequently - a glossary also contains cross-references - synonyms - homonyms - acronyms - and abbreviations.
A requirement pertaining to a system or to a component of a system.

31. Multiplicity
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 systematically represented description of the properties of an entity (a system - a device - etc.) that satisfies given criteria. It may be about required properties (requirements specification) or implemented properties (e.g. - a technical product
A 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.
Cardinality.

32. Scope (of a system)
A model consisting of a set of classes and relationships between them.
1. Analysis of elicited requirements in order to understand and document them. 2. Synonym for requirements engineering.
The range of things that can be shaped and designed when developing a system.
A requirement pertaining to a system or to a component of a system.

33. Class model
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 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 model consisting of a set of classes and relationships between them.
A state machine having states that are hierarchically and/or orthogonally decomposed.

34. Effectiveness

Warning: Invalid argument supplied for foreach() in /var/www/html/basicversity.com/show_quiz.php on line 183

35. Process verb
An abstract representation of an existing reality or a reality to be created.
A verb characterizing the required action in a requirement written in natural language.
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.
The degree to which a result is achieved with minimum consumption of resources.

36. Finite state automaton
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages 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.
A model that represents the goals of something as an ordered structure of sub-goals.

37. Requirements specification
An intermediate or final result of system development; for example - a requirements specification.
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
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
An artificial language that has been created for expressing specifications.

38. System requirements specification
A requirements specification pertaining to a system. Frequently considered to be a synonym for requirements specification.
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
An abstract representation of an existing reality or a reality to be created.
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.

39. Elicitation (of requirements)
A requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).
The meaning of a sign or a set of signs in a language.
A graphic representation of an entity-relationship model. Abbreviation: ERD
Requirements elicitation.

40. Requirements management
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 process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).
A range of relevant things (for some given matter); for example - an application domain.
A desired state of affairs (that a stakeholder wants to achieve). Goals describe intentions of stakeholders. They may conflict with one another.

41. Goal
The degree to which an artifact enables a required modification of the artifact.
A state machine with atomic states.
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 desired state of affairs (that a stakeholder wants to achieve). Goals describe intentions of stakeholders. They may conflict with one another.

42. Context

Warning: Invalid argument supplied for foreach() in /var/www/html/basicversity.com/show_quiz.php on line 183

43. Verifiability (of 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.
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 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.

44. Requirements baseline
A baseline for a set of 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.
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 that has been created with the purpose of specifying requirements.

45. 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 characteristic property of an entity.
A model that has been created with the purpose of specifying requirements.
A person who uses the functionality provided by a system. Also called end user.

46. Class
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 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.
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 coarse description of the required capabilities of a system from the customer's perspective. Usually supplied by the customer.

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

48. Compliance
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
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 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 diagrammatic representation of a state machine.

49. Sequence diagram
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 ease with which a system can be transferred to another platform (while preserving its functionality). Portability may be stated as a quality requirement.
A committee that supervises a project.
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.

50. System
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
Requirements elicitation.
A committee of client and supplier representatives that decides on change requests. Abbreviation: CCB
A uniform regulation for perceiving - manufacturing or executing something.