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. Quality
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 uniform regulation for perceiving - manufacturing or executing something.
A range of relevant things (for some given matter); for example - an application domain.
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.

2. Change control board
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
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 committee that supervises a project.
A committee of client and supplier representatives that decides on change requests. Abbreviation: CCB

3. Requirements discovery
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 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
Requirements elicitation
A model consisting of a set of classes and relationships between them.

4. Semantics
The meaning of a sign or a set of signs in a language.
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 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
Requirements elicitation.

5. Error
A requirement pertaining to a system or to a component of a system.
The capabilities of a system as stated by its functional requirements.
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 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.

6. Artifact
An intermediate or final result of system development; for example - a requirements specification.
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.
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 test that assesses whether a system satisfies all its requirements.

7. Pre-RS traceability
State machines having states that are hierarchically and/or orthogonally decomposed.
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 structured set of signs for expressing and communicating information. Signs are elements that are used for communication: expressions in a language - symbols - gestures - etc.
Traceability of a requirement back to its origin.

8. System requirements specification
The capabilities of a system as stated by its functional requirements.
Those parts of the real world that are relevant for determining the context of a system.
A range of relevant things (for some given matter); for example - an application domain.
A requirements specification pertaining to a system. Frequently considered to be a synonym for requirements specification.

9. User
A model consisting of a set of classes and relationships between them.
Traceability of a requirement back to its origin.
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 person who uses the functionality provided by a system. Also called end user.

10. Maintainability
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 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
A diagrammatic representation of a class model.
A test that assesses whether a system satisfies all its requirements.

11. Entity-relationship diagram
An artificial language that has been created for expressing specifications.
A graphic representation of an entity-relationship model. Abbreviation: ERD
A systematically represented collection of requirements - typically for a system or component - that satisfies given criteria. In some situations we distinguish between a customer requirements specification (typically written by the customer) and a s
A test that assesses whether a system satisfies all its requirements.

12. Kind of requirement
A coarse description of the required capabilities of a system from the customer's perspective. Usually supplied by the customer.
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 degree to which a requirement expresses the stakeholders' true desires and needs (i.e. - those they had actually in mind when stating the requirement).
1. A diagrammatic representation of a context model. 2. In Structured Analysis - the context diagram is the root of the data flow diagram hierarchy.

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

14. Important facets of RE
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.
A diagram type in UML which models the flow of actions in a system or in a component including data flows and areas of responsibility where necessary.
1. 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
A test that assesses whether a system satisfies all its requirements.

15. Version (of an entity)
A model describing the behavior of a system or component - e.g. - by a state machine.
A state machine having states that are hierarchically and/or orthogonally decomposed.
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 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.

16. Glossary
The process of checking whether documented requirements match the stakeholders' needs.
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
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 collection of definitions of terms that are relevant in some domain. Frequently - a glossary also contains cross-references - synonyms - homonyms - acronyms - and abbreviations.

17. 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.
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 (software) system that helps develop - operate and maintain systems. In RE - tools support requirements management as well as modeling - documenting - and validating requirements.

18. Changeability (of an artifact)
In RE: A well-argued request for changing one or more baselined requirements.
The capabilities of a system as stated by its functional requirements.
A graphic representation of an entity-relationship model. Abbreviation: ERD
The degree to which an artifact enables a required modification of the artifact.

19. Traceability (of requirements)
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
A structured set of signs for expressing and communicating information. Signs are elements that are used for communication: expressions in a language - symbols - gestures - etc.
A model describing the behavior of a system or component - e.g. - by a state machine.
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.

20. Reliability
A template for the syntactic structure of a phrase that expresses an individual requirement in natural language
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 set of requirements is free of contradicting statements.
A tabular - systematic representation of a complex decision that depends on multiple criteria.

21. Behavior Model
A requirements specification pertaining to a system. Frequently considered to be a synonym for requirements specification.
A model describing the behavior of a system or component - e.g. - by a state machine.
A language for expressing models of a certain kind. May be textual - graphic - symbolic or some combination thereof.
A model consisting of a set of classes and relationships between them.

22. Semi-formal

23. Specification
An excerpt from an artifact - containing only those parts one is currently interested in. A view can abstract or aggregate parts of the artifact.
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 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 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

24. Standard
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.
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 uniform regulation for perceiving - manufacturing or executing something.
An intermediate or final result of system development; for example - a requirements specification.

25. Structured analysis
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
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 range of relevant things (for some given matter); for example - an application domain.
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.

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

27. Walkthrough

28. System boundary
A language for expressing models of a certain kind. May be textual - graphic - symbolic or some combination thereof.
The degree to which a result is achieved with minimum consumption of resources.
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
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

29. Adequacy (of a requirement)

30. End user
The source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.
User.
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 configuration that has been released for installation and use by customers.

31. State charts
A requirement that limits the solution space beyond what is necessary for meeting the given functional requirements and quality requirements.
Requirements source
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
State machines having states that are hierarchically and/or orthogonally decomposed.

32. Finite state automaton
When viewed in isolation - a component is a system by itself. 1. In general: A delimitable part of a system. 2. In software architecture: An encapsulated set of coherent objects or classes that jointly provide a service.
A requirement pertaining to a system or to a component of a system.
A requirement that pertains to a quality concern that is not covered by functional requirements.
A state machine with atomic states.

33. Requirements templates
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 blueprint for the syntactic structure of individual requirements.A phrase template is a specific requirements template for requirements written in natural language.
A baseline for a set of requirements.
Defect.

34. Requirements analysis
Requirements elicitation.
A requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).
1. Analysis of elicited requirements in order to understand and document them. 2. Synonym for requirements engineering.
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

35. Fault tolerance
A person or organization who receives a product or service. Also see stakeholder.
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
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 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

36. Class
Those parts of the real world that are relevant for determining the context of 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.
A committee of client and supplier representatives that decides on change requests. Abbreviation: CCB
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

37. Effectiveness

38. Requirements engineer
The degree to which a requirement is expressed such that it cannot be understood differently by different people.
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
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 person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.

39. Class diagram
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 diagrammatic representation of a class model.
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

40. Goal model
A model that represents the goals of something as an ordered structure of sub-goals.
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 model consisting of a set of classes and relationships between them.
Cardinality.

41. Validation (of requirements)

42. Checking (requirements)
An intermediate or final result of system development; for example - a requirements specification.
A spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.
A committee that supervises a project.

43. Entity
A uniform regulation for perceiving - manufacturing or executing something.
A blueprint for the syntactic structure of individual requirements.A phrase template is a specific requirements template for requirements written in natural 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
State machines having states that are hierarchically and/or orthogonally decomposed.

44. Risk
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
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 person who - in collaboration with stakeholders - elicits - documents - validates - and manages 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

45. Acceptance
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.
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.
Multiple occurrence of the same information or resource.
The process of assessing whether a system satisfies all its requirements.

46. Unambiguity (of requirements)
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 is expressed such that it cannot be understood differently by different people.
A state machine having states that are hierarchically and/or orthogonally decomposed.
A model describing a system in its context.

47. Requirements specification
A person or organization who receives a product or service. Also see stakeholder.
A person or organization who delivers a product or service to a customer.
A systematically represented collection of requirements - typically for a system or component - that satisfies given criteria. In some situations we distinguish between a customer requirements specification (typically written by the customer) and a s
A model describing the behavior of a system or component - e.g. - by a state machine.

48. View
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
Cardinality.
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.
An excerpt from an artifact - containing only those parts one is currently interested in. A view can abstract or aggregate parts of the artifact.

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

50. Security
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
Requirements elicitation
A systematically represented description of the properties of an entity (a system - a device - etc.) that satisfies given criteria. It may be about required properties (requirements specification) or implemented properties (e.g. - a technical product
The capability of a system to protect (a) its data and resources against unauthorized use and (b) its legitimate users against denial of service.