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. Supplier
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 test that assesses whether a system satisfies all its requirements.
Multiple occurrence of the same information or resource.
A person or organization who delivers a product or service to a customer.


2. State machine
A model that represents the goals of something as an ordered structure of sub-goals.
A diagram modeling the functionality of a system or component by processes (also called activities) - data stores and data flows. Incoming data flows trigger processes which then consume the received data - transform them - read/write persistent data
A 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 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.


3. Requirements specification
A systematically represented collection of requirements - typically for a system or component - that satisfies given criteria. In some situations we distinguish between a customer requirements specification (typically written by the customer) and a s
A coarse description of the required capabilities of a system from the customer's perspective. Usually supplied by the customer.
A diagrammatic representation of a class model.
1. A description of a potential sequence of events that lead to a desired (or unwanted) result. 2. An ordered sequence of interactions between partners - in particular between a system and external actors. May be a concrete sequence (instance scenari


4. Requirements document
The capabilities of a system as stated by its functional requirements.
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
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 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.


5. Application domain
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 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 verb characterizing the required action in a requirement written in natural language.
Those parts of the real world that are relevant for determining the context of a system.


6. Component
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 document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
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 tabular - systematic representation of a complex decision that depends on multiple criteria.


7. Effectiveness

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


8. Customer requirements specification

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


9. Language
Requirements source
Defect
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


10. Functionality
The capabilities of a system as stated by its functional 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 continue normal operation despite the presence of (hardware or software) faults. Fault tolerance may be stated as a quality requirement.
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


11. Reliability
A requirements specification pertaining to a software system. Abbreviation: SRS
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.
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 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.


12. Context

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


13. Constraint
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.
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.
A requirement that limits the solution space beyond what is necessary for meeting the given functional requirements and quality requirements.
A formally organized endeavor for checking an artifact by a group of experts. Checking may be performed with respect to both contents and conformance.


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


15. Entity
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.
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 describing a system in its context.


16. Customer
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 requirement that limits the solution space beyond what is necessary for meeting the given functional requirements and quality requirements.
A person or organization who receives a product or service. Also see stakeholder.
A (software) system that helps develop - operate and maintain systems. In RE - tools support requirements management as well as modeling - documenting - and validating requirements.


17. Attribute
A characteristic property of an entity.
Defect.
The meaning of a sign or a set of signs in a language.
User.


18. Consistency (of requirements)
The rules for constructing structured signs in a language.
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
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
The degree to which a set of requirements is free of contradicting statements.


19. Kind of requirement
A model that has been created with the purpose of specifying requirements.
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 language for expressing models of a certain kind. May be textual - graphic - symbolic or some combination thereof.
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.


20. Requirements baseline
A baseline for a set of requirements.
A person or organization that has a (direct or indirect) influence on a system's requirements. Indirect influence also includes situations where a person or organization is impacted by the system.
Those parts of the real world that are relevant for determining the context of a system.
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


21. Context boundary
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 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
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.
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


22. Correctness
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).
Requirements elicitation.
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 formally organized endeavor for checking an artifact by a group of experts. Checking may be performed with respect to both contents and conformance.


23. Entity-relationship model
1. In manufacturing: a piece which is built prior to the start of mass production. 2. In software engineering: An executable piece of software that implements critical parts of a system in advance. In Requirements Engineering - prototypes are used as
A committee that supervises a project.
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 collection of definitions of terms that are relevant in some domain. Frequently - a glossary also contains cross-references - synonyms - homonyms - acronyms - and abbreviations.


24. Adequacy (of a requirement)

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


25. Conformity (of requirements)
The degree to which a requirements specification conforms to regulations given in some standard.
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.
Documents the importance of a requirement in comparison to other requirements according to given criteria.
A test that assesses whether a system satisfies all its requirements.


26. Structured analysis
A language for expressing models of a certain kind. May be textual - graphic - symbolic or some combination thereof.
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
An artificial language that has been created for expressing specifications.
A desired state of affairs (that a stakeholder wants to achieve). Goals describe intentions of stakeholders. They may conflict with one another.


27. Goal model
The degree to which an artifact enables a required modification of the artifact.
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 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.


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


29. Inspection

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


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


31. Semantics
The meaning of a sign or a set of 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
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 verb characterizing the required action in a requirement written in natural language.


32. State charts
A range of relevant things (for some given matter); for example - an application domain.
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. 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
State machines having states that are hierarchically and/or orthogonally decomposed.


33. Priority (of a requirement)
Documents the importance of a requirement in comparison to other requirements according to given criteria.
A document consisting of a requirements specification. Frequently used as a synonym 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).
Those parts of the real world that are relevant for determining the context of a system.


34. Configuration
A consistent set of logically coherent units. The units are individually identifiable artifacts or parts of artifacts (e.g. - requirements) in at most one version per unit.
A test that assesses whether a system satisfies all its 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.
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


35. Safety
Requirements elicitation.
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 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 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


36. Requirements discovery
Requirements elicitation
A diagrammatic representation of a class model.
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
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.


37. Validation (of requirements)

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


38. Steering committee
An event that threatens the success of an endeavor - e.g. - of developing or operating a system. A risk is typically assessed in terms of its probability and potential damage.
A committee that supervises a project.
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
The degree to which a requirements specification conforms to regulations given in some standard.


39. Entity-relationship diagram
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.
The degree to which a result is achieved with minimum consumption of resources.
A person who uses the functionality provided by a system. Also called end user.
A graphic representation of an entity-relationship model. Abbreviation: ERD


40. Changeability (of an artifact)
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
The degree to which an artifact enables a required modification of the artifact.
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 capability of a system to be understood - learned - used - and liked by its users. Usability (or parts thereof) may be stated as quality requirements.


41. Requirements elicitation
A model consisting of a set of classes and relationships between them.
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 process of seeking - capturing and consolidating requirements from available requirements sources. May include the re-construction or creation of requirements. Aka Requirements discovery
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


42. Model
A verb characterizing the required action in a requirement written in natural language.
Requirements source
An abstract representation of an existing reality or a reality to be created.
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


43. 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 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 template for the syntactic structure of a phrase that expresses an individual requirement in natural language
The range of things that can be shaped and designed when developing a system.


44. Efficiency
The degree to which a result is achieved with minimum consumption of resources.
A spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
The capabilities of a system as stated by its functional 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.


45. Goal
Requirements elicitation
A desired state of affairs (that a stakeholder wants to achieve). Goals describe intentions of stakeholders. They may conflict with one another.
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 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


46. Requirements engineering (RE)
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
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.
Requirements elicitation
A systematic and disciplined approach to the specification and management of requirements with the following goals: (1) Knowing the relevant requirements - achieving a consensus among the stakeholders about these requirements - documenting them accor


47. Important facets of RE
The degree to which a set of requirements is free of contradicting statements.
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.
A range of relevant things (for some given matter); for example - an application domain.
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.


48. Non-functional requirement
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 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
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.
In RE: A well-argued request for changing one or more baselined requirements.


49. Fault
A model describing a system in its context.
Defect.
A test that assesses whether a system satisfies all its requirements.
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


50. Tool (in software engineering)
State machines having states that are hierarchically and/or orthogonally decomposed.
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.
The process of assessing whether a system satisfies all its requirements.
A (software) system that helps develop - operate and maintain systems. In RE - tools support requirements management as well as modeling - documenting - and validating requirements.