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. Requirements management
The process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).
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
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 capabilities of a system as stated by its functional requirements.

2. Priority (of a requirement)
Documents the importance of a requirement in comparison to other requirements according to given criteria.
A requirements specification pertaining to a software system. Abbreviation: SRS
Those parts of the real world that are relevant for determining the context of a system.
The degree to which the information contained in an artifact is probably true. In RE - correctness is frequently used as a synonym for adequacy.

3. Finite state automaton
Defect
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 state machine with atomic states.
A tabular - systematic representation of a complex decision that depends on multiple criteria.

4. Kind of requirement
An intermediate or final result of system development; for example - a requirements specification.
Cardinality.
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 requirements specification pertaining to a software system. Abbreviation: SRS

5. Source (of a requirement)
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.
Requirements source
Requirements elicitation
The capabilities of a system as stated by its functional requirements.

6. Specification language
A spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
The degree to which a set of requirements is free of contradicting statements.
An artificial language that has been created for expressing specifications.
A template for the syntactic structure of a phrase that expresses an individual requirement in natural language

7. Baseline
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.
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.
A diagrammatic representation of a class model.

8. Acceptance
The process of assessing whether a system satisfies all its requirements.
Traceability of a requirement back to its origin.
1. Analysis of elicited requirements in order to understand and document them. 2. Synonym for requirements engineering.
A uniform regulation for perceiving - manufacturing or executing something.

9. Semi-formal

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

11. Reliability
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
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 maintain a specified level of functionality and performance when used under specified conditions. Reliability may be stated as a quality requirement.
A characteristic property of an entity.

12. Entity-relationship diagram
A graphic representation of an entity-relationship model. Abbreviation: ERD
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.
The range of things that can be shaped and designed when developing a system.
A requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).

13. Homonym
A blueprint for the syntactic structure of individual requirements.A phrase template is a specific requirements template for requirements written in natural language.
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 requirement that pertains to a quality concern that is not covered by functional requirements.
The degree to which a requirements specification conforms to regulations given in some standard.

14. Steering committee
A diagrammatic representation of a state machine.
A committee that supervises a project.
State machines having states that are hierarchically and/or orthogonally decomposed.
A state machine with atomic states.

15. Context 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 model that represents the goals of something as an ordered structure of sub-goals.
A model describing a system in its context.
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.

16. View
A requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).
A verb characterizing the required action in a requirement written 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 graphic representation of an entity-relationship model. Abbreviation: ERD

17. Fault
Defect.
A requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).
A test that assesses whether a system satisfies all its requirements.
A requirements specification pertaining to a software system. Abbreviation: SRS

18. Adequacy (of a requirement)

19. Important facets of RE
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
Those parts of the real world that are relevant for determining the context of a system.
1. Analysis of elicited requirements in order to understand and document them. 2. Synonym for requirements engineering.
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.

20. Modeling language
The degree to which a requirement is expressed such that it cannot be understood differently by different people.
A configuration that has been released for installation and use by customers.
Defect.
A language for expressing models of a certain kind. May be textual - graphic - symbolic or some combination thereof.

21. Class diagram
A spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
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 tabular - systematic representation of a complex decision that depends on multiple criteria.
A diagrammatic representation of a class model.

22. System
Those parts of the real world that are relevant for determining the context of a 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
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.
An intermediate or final result of system development; for example - a requirements specification.

23. Requirements baseline
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 spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
A tabular - systematic representation of a complex decision that depends on multiple criteria.

24. Effectiveness

25. State charts
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.
A person or organization who delivers a product or service to a customer.
State machines having states that are hierarchically and/or orthogonally decomposed.

26. System boundary
The process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.
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
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

27. Prototype
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
User.
Requirements elicitation.
The degree to which a result is achieved with minimum consumption of resources.

28. Syntax
A state machine with atomic states.
The process of assessing whether a system satisfies all its 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.
The rules for constructing structured signs in a language.

29. Changeability (of an artifact)
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
The range of things that can be shaped and designed when developing a system.
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.

30. Conformity (of requirements)
The process of checking whether documented requirements match the stakeholders' needs.
A (software) system that helps develop - operate and maintain systems. In RE - tools support requirements management as well as modeling - documenting - and validating 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.
The degree to which a requirements specification conforms to regulations given in some standard.

31. User
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.
A requirement pertaining to a system or to a component of a system.
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
A person who uses the functionality provided by a system. Also called end user.

32. Security
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 degree to which a requirement expresses the stakeholders' true desires and needs (i.e. - those they had actually in mind when stating the requirement).
Traceability of a requirement back to its origin.
A model describing the behavior of a system or component - e.g. - by a state machine.

33. Requirements document
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.
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
Defect.

34. Correctness
A coarse description of the required capabilities of a system from the customer's perspective. Usually supplied by the customer.
The degree to which the information contained in an artifact is probably true. In RE - correctness is frequently used as a synonym for adequacy.
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
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.

35. Multiplicity
A range of relevant things (for some given matter); for example - an application domain.
Cardinality.
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 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

36. Scope (of a system)
The range of things that can be shaped and designed when developing a 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.
The degree to which the information contained in an artifact is probably true. In RE - correctness is frequently used as a synonym for adequacy.
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.

37. Validation (of requirements)

38. Requirement (original IEEE definition)
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
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
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.

39. Supplier
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
A person or organization who delivers a product or service to a customer.
The ease with which a system can be transferred to another platform (while preserving its functionality). Portability may be stated as a quality requirement.
The process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).

40. Component
The range of things that can be shaped and designed when developing a system.
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 model describing the behavior of a system or component - e.g. - by a state machine.
The degree to which a requirement expresses the stakeholders' true desires and needs (i.e. - those they had actually in mind when stating the requirement).

41. Statechart
The process of seeking - capturing and consolidating requirements from available requirements sources. May include the re-construction or creation of requirements. Aka Requirements discovery
The source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.
A state machine having states that are hierarchically and/or orthogonally decomposed.
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

42. 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.
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 person who uses the functionality provided by a system. Also called end user.
Requirements source

43. System requirement
The degree to which the information contained in an artifact is probably true. In RE - correctness is frequently used as a synonym for adequacy.
A requirement pertaining to a system or to a component of a system.
A state machine with atomic states.
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

44. Functional requirement
A requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).
The part of a system's environment that is relevant for the definition as well as the understanding of the requirements of a system to be developed.
A spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
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.

45. Post-RS traceability
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.
Traceability of a requirement forward to its implementation in design and code - RS stands for requirements specification.
The degree to which the information contained in an artifact is probably true. In RE - correctness is frequently used as a synonym for adequacy.
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

46. Requirements source
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.
Requirements source
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.

47. Class
A model that has been created with the purpose of specifying requirements.
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
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 structured set of signs for expressing and communicating information. Signs are elements that are used for communication: expressions in a language - symbols - gestures - etc.

48. Customer requirements specification

49. Compliance
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 meaning of a sign or a set of signs in a language.
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
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

50. 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
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 requirement that pertains to a quality concern that is not covered by functional requirements.
A graphic representation of an entity-relationship model. Abbreviation: ERD