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. Cardinality
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
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 a system to continue normal operation despite the presence of (hardware or software) faults. Fault tolerance may be stated as a quality requirement.
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. Checking (requirements)
A committee of client and supplier representatives that decides on change requests. Abbreviation: CCB
A coarse description of the required capabilities of a system from the customer's perspective. Usually supplied by the customer.
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.
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.

3. Requirements discovery
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 tabular - systematic representation of a complex decision that depends on multiple criteria.
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.
Requirements elicitation

4. Attribute
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.
A characteristic property of an entity.
A state machine with atomic states.
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.

5. Requirements document
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
The meaning of a sign or a set of signs in a language.
A person or organization who receives a product or service. Also see stakeholder.
A requirements specification pertaining to a software system. Abbreviation: SRS

6. Correctness
The degree to which the information contained in an artifact is probably true. In RE - correctness is frequently used as a synonym for adequacy.
Requirements elicitation
A range of relevant things (for some given matter); for example - an application domain.
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

7. Acceptance test
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 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 test that assesses whether a system satisfies all its 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.

8. Requirement (modern definition)
A quality requirement or a constraint. Performance requirements may be regarded as another category of non-functional requirements. In this glossary - performance requirements are considered to be a sub-category of quality requirements. Synonym: Extr
A graphic representation of an entity-relationship model. Abbreviation: ERD
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 structured set of signs for expressing and communicating information. Signs are elements that are used for communication: expressions in a language - symbols - gestures - etc.

9. Validation (of requirements)

10. Requirements source
The source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.
A baseline for a set of requirements.
The meaning of a sign or a set of signs in a language.
A state machine having states that are hierarchically and/or orthogonally decomposed.

11. Component
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
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 model that has been created with the purpose of specifying requirements.
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.

12. Fault
1. A diagrammatic representation of a context model. 2. In Structured Analysis - the context diagram is the root of the data flow diagram hierarchy.
Defect.
A coarse description of the required capabilities of a system from the customer's perspective. Usually supplied by the customer.
A state machine having states that are hierarchically and/or orthogonally decomposed.

13. Requirements elicitation
A requirements specification pertaining to a software system. Abbreviation: SRS
A configuration that has been released for installation and use by customers.
A tabular - systematic representation of a complex decision that depends on multiple criteria.
The process of seeking - capturing and consolidating requirements from available requirements sources. May include the re-construction or creation of requirements. Aka Requirements discovery

14. Requirement (original IEEE definition)
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.
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
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.
Documents the importance of a requirement in comparison to other requirements according to given criteria.

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

16. Requirements specification
A model that has been created with the purpose of specifying requirements.
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 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 an artifact enables a required modification of the artifact.

17. Goal model
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.
A model that represents the goals of something as an ordered structure of sub-goals.
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 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.

18. Language
Traceability of a requirement forward to its implementation in design and code - RS stands for requirements specification.
A requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).
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. 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

19. Safety
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
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 language for expressing models of a certain kind. May be textual - graphic - symbolic or some combination thereof.
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.

20. Scenario
A model that represents the goals of something as an ordered structure of sub-goals.
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
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
The process of seeking - capturing and consolidating requirements from available requirements sources. May include the re-construction or creation of requirements. Aka Requirements discovery

21. Data flow diagram
A requirement that pertains to a quality concern that is not covered by functional requirements.
The process of assessing whether a system satisfies all its requirements.
The range of things that can be shaped and designed when developing a system.
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

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

23. Homonym
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.
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 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 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.

24. Artifact
An intermediate or final result of system development; for example - a requirements specification.
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. A diagrammatic representation of a context model. 2. In Structured Analysis - the context diagram is the root of the data flow diagram hierarchy.
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

25. Review
A diagrammatic representation of a class model.
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 formally organized endeavor for checking an artifact by a group of experts. Checking may be performed with respect to both contents and conformance.
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

26. Decision table
Requirements elicitation
A tabular - systematic representation of a complex decision that depends on multiple criteria.
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 characteristic property of an entity.

27. Changeability (of an artifact)
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.
A requirements specification pertaining to a system. Frequently considered to be a synonym for requirements specification.
The degree to which an artifact enables a required modification of the artifact.
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

28. Fault tolerance
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 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 test that assesses whether a system satisfies all its requirements.
The degree to which a requirements specification conforms to regulations given in some standard.

29. Context

30. Domain
A range of relevant things (for some given matter); for example - an application domain.
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
Requirements elicitation.
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

31. 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
A committee that supervises a project.
An intermediate or final result of system development; for example - a requirements specification.
A committee of client and supplier representatives that decides on change requests. Abbreviation: CCB

32. System
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.
The capabilities of a system as stated by its functional requirements.
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
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

33. 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.
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.
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 requirements specification pertaining to a system. Frequently considered to be a synonym for requirements specification.

34. Conformity (of requirements)
A person or organization who delivers a product or service to a customer.
A person or organization who receives a product or service. Also see stakeholder.
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 a requirements specification conforms to regulations given in some standard.

35. Sequence diagram
A blueprint for the syntactic structure of individual requirements.A phrase template is a specific requirements template for requirements written in natural language.
A diagram type in UML which models the interactions between a selected set of objects and/or actors in the sequential order that those interactions occur.
Requirements source
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

36. Activity diagram
A characteristic property of an entity.
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.
(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.

37. Stakeholder

38. End user
Requirements elicitation.
User.
1. In general: an element or set of elements that may stand for any conceivable item - e.g. - a system - a part of reality - a thing - an organization - a process - etc. 2. In entity-relationship-modeling: an individual object which has an identity a
A model that represents the goals of something as an ordered structure of sub-goals.

39. Release
A configuration that has been released for installation and use by customers.
A characteristic property of an entity.
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 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.

40. Acceptance
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
The process of assessing whether a system satisfies all its requirements.
A requirement pertaining to a system or to a component of a system.
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.

41. Class model
A model consisting of a set of classes and relationships between them.
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 verb characterizing the required action in a requirement written in natural language.
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

42. Context diagram
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 graphic representation of an entity-relationship model. Abbreviation: ERD
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.
1. A diagrammatic representation of a context model. 2. In Structured Analysis - the context diagram is the root of the data flow diagram hierarchy.

43. Walkthrough

44. Requirements baseline
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.
A baseline for a set of requirements.
In RE: A well-argued request for changing one or more baselined requirements.
A template for the syntactic structure of a phrase that expresses an individual requirement in natural language

45. View
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 requirement that limits the solution space beyond what is necessary for meeting the given functional requirements and quality requirements.
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
Those parts of the real world that are relevant for determining the context of a system.

46. Non-functional requirement
A formally organized endeavor for checking an artifact by a group of experts. Checking may be performed with respect to both contents and conformance.
1. Analysis of elicited requirements in order to understand and document them. 2. Synonym for requirements engineering.
A quality requirement or a constraint. Performance requirements may be regarded as another category of non-functional requirements. In this glossary - performance requirements are considered to be a sub-category of quality requirements. Synonym: Extr
A requirements specification pertaining to a system. Frequently considered to be a synonym for requirements specification.

47. Actor
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.
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 degree to which a result is achieved with minimum consumption of resources.
Abbreviation for Unified Modeling Language - a standardized language for modeling problems or solutions.

48. Model
An abstract representation of an existing reality or a reality to be created.
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
The range of things that can be shaped and designed when developing a system.
Documents the importance of a requirement in comparison to other requirements according to given criteria.

49. Completeness (of 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.
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 collection of definitions of terms that are relevant in some domain. Frequently - a glossary also contains cross-references - synonyms - homonyms - acronyms - and abbreviations.
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.

50. Glossary
A collection of definitions of terms that are relevant in some domain. Frequently - a glossary also contains cross-references - synonyms - homonyms - acronyms - and abbreviations.
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.
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 range of relevant things (for some given matter); for example - an application domain.