CPRE: Certified Professional Requirements Engineering

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 baseline
A spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
A baseline for a set of requirements.
A uniform regulation for perceiving - manufacturing or executing something.
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


2. Pre-RS traceability
Traceability of a requirement back to its origin.
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 person or organization that has a (direct or indirect) influence on a system's requirements. Indirect influence also includes situations where a person or organization is impacted by the system.
The degree to which a set of requirements is free of contradicting statements.


3. Entity-relationship model
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 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 process of assessing whether a system satisfies all its requirements.
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.


4. Error
A person who uses the functionality provided by a system. Also called end user.
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 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
Documents the importance of a requirement in comparison to other requirements according to given criteria.


5. Correctness
User.
Abbreviation for Unified Modeling Language - a standardized language for modeling problems or solutions.
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 coarse description of the required capabilities of a system from the customer's perspective. Usually supplied by the customer.


6. State-transition diagram
Multiple occurrence of the same information or resource.
A spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
A diagrammatic representation of a state machine.
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


7. Entity-relationship diagram
A graphic representation of an entity-relationship model. Abbreviation: ERD
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 rules for constructing structured signs in a language.
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


8. Review
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 person who uses the functionality provided by a system. Also called end user.
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.
A formally organized endeavor for checking an artifact by a group of experts. Checking may be performed with respect to both contents and conformance.


9. Customer
A person or organization who receives a product or service. Also see stakeholder.
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 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
Requirements source


10. Fault
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.
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.
Defect.
The degree to which the information contained in an artifact is probably true. In RE - correctness is frequently used as a synonym for adequacy.


11. Consistency (of requirements)
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 a set of requirements is free of contradicting statements.
A uniform regulation for perceiving - manufacturing or executing something.
Defect.


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


13. Completeness (of requirements)
User.
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
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 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


14. User
In RE: A well-argued request for changing one or more baselined requirements.
A person who uses the functionality provided by a system. Also called end 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 person or organization who delivers a product or service to a customer.


15. Requirements document
The process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
The rules for constructing structured signs in a 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


16. Viewpoint


17. Usability
The process of checking whether documented requirements match the stakeholders' needs.
The range of things that can be shaped and designed when developing a system.
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 model that represents the goals of something as an ordered structure of sub-goals.


18. Component
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
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.
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.
Requirements source


19. Requirements templates
A requirement that pertains to a quality concern that is not covered by functional 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.
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 blueprint for the syntactic structure of individual requirements.A phrase template is a specific requirements template for requirements written in natural language.


20. Changeability (of an artifact)
The degree to which an artifact enables a required modification of the artifact.
A model that has been created with the purpose of specifying requirements.
The process of assessing whether a system satisfies all its requirements.
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.


21. Customer requirements specification


22. Non-functional 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
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 characteristic property of an entity.
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


23. Elicitation (of requirements)
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.
Requirements elicitation.
Requirements elicitation
A diagrammatic representation of a state machine.


24. UML
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.
Requirements elicitation.
Documents the importance of a requirement in comparison to other requirements according to given criteria.
Abbreviation for Unified Modeling Language - a standardized language for modeling problems or solutions.


25. 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 requirements specification pertaining to a software system. Abbreviation: SRS
Abbreviation for Unified Modeling Language - a standardized language for modeling problems or solutions.
The ease with which a system can be transferred to another platform (while preserving its functionality). Portability may be stated as a quality requirement.


26. Functionality
The capabilities of a system as stated by its functional 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.
A uniform regulation for perceiving - manufacturing or executing something.
Defect


27. 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 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 capabilities of a system as stated by its functional requirements.
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.


28. Requirements discovery
The capabilities of a system as stated by its functional requirements.
A person or organization who receives a product or service. Also see stakeholder.
Requirements elicitation
A model describing a system in its context.


29. Semantics
Documents the importance of a requirement in comparison to other requirements according to given criteria.
The meaning of a sign or a set of signs in a language.
Those parts of the real world that are relevant for determining the context of a system.
The capability of a system to protect (a) its data and resources against unauthorized use and (b) its legitimate users against denial of service.


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


31. Supplier
A model that represents the goals of something as an ordered structure of sub-goals.
A person or organization who delivers a product or service to a customer.
The degree to which a requirements specification conforms to regulations given in some standard.
The ease with which a system can be transferred to another platform (while preserving its functionality). Portability may be stated as a quality requirement.


32. Requirements model
A model that has been created with the purpose of specifying requirements.
The meaning of a sign or a set of signs in a language.
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
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


33. Quality requirement
The process of checking whether documented requirements match the stakeholders' needs.
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 requirement that pertains to a quality concern that is not covered by functional 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


34. System context


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


36. Priority (of a requirement)
The process of seeking - capturing and consolidating requirements from available requirements sources. May include the re-construction or creation of requirements. Aka Requirements discovery
1. A diagrammatic representation of a context model. 2. In Structured Analysis - the context diagram is the root of the data flow diagram hierarchy.
Documents the importance of a requirement in comparison to other requirements according to given criteria.
A characteristic property of an entity.


37. Verifiability (of requirements)
The meaning of a sign or a set of signs in a language.
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 model that has been created with the purpose of specifying requirements.
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.


38. 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.
The process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.
A template for the syntactic structure of a phrase that expresses an individual requirement in natural language


39. Requirements analysis
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 model describing a system in its context.
1. Analysis of elicited requirements in order to understand and document them. 2. Synonym for requirements engineering.
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


40. Goal model
In RE: A well-argued request for changing one or more baselined requirements.
Requirements source
The range of things that can be shaped and designed when developing a system.
A model that represents the goals of something as an ordered structure of sub-goals.


41. Cardinality
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 diagram type in UML which models the interactions between a selected set of objects and/or actors in the sequential order that those interactions occur.
An artificial language that has been created for expressing specifications.
A state machine with atomic states.


42. System boundary
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
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
Documents the importance of a requirement in comparison to other requirements according to given criteria.
1. Analysis of elicited requirements in order to understand and document them. 2. Synonym for requirements engineering.


43. Validation (of requirements)


44. Constraint
A state machine having states that are hierarchically and/or orthogonally decomposed.
A diagram type in UML which models the flow of actions in a system or in a component including data flows and areas of responsibility where necessary.
A requirement that limits the solution space beyond what is necessary for meeting the given functional requirements and quality requirements.
A model that represents the goals of something as an ordered structure of sub-goals.


45. Scope (of a system)
A person or organization that has a (direct or indirect) influence on a system's requirements. Indirect influence also includes situations where a person or organization is impacted by the system.
The range of things that can be shaped and designed when developing a system.
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
The degree to which an artifact enables a required modification of the artifact.


46. System requirement
A baseline for a set of requirements.
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.
A requirement that pertains to a quality concern that is not covered by functional requirements.
A requirement pertaining to a system or to a component of a system.


47. Bug
Defect
A model describing the behavior of a system or component - e.g. - by a state machine.
The rules for constructing structured signs in a language.
In RE: A well-argued request for changing one or more baselined requirements.


48. Acceptance
A requirements specification pertaining to a system. Frequently considered to be a synonym for requirements specification.
The process of assessing whether a system satisfies all its requirements.
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 coarse description of the required capabilities of a system from the customer's perspective. Usually supplied by the customer.


49. Conformity (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 ease with which a system can be transferred to another platform (while preserving its functionality). Portability may be stated as a quality requirement.
The degree to which a requirements specification conforms to regulations given in some standard.
A state machine with atomic states.


50. State machine
Defect.
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.
A model describing a system in its context.
A requirements specification pertaining to a software system. Abbreviation: SRS