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. Use case diagram
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
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
User.
A diagram type in UML that models the actors and the use cases of a system. The boundary between the actors and the use cases constitutes the system boundary.


2. Important facets of RE
Abbreviation for Unified Modeling Language - a standardized language for modeling problems or solutions.
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.
The degree to which a requirement is expressed such that it cannot be understood differently by different people.
Requirements source


3. Statechart
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
Traceability of a requirement forward to its implementation in design and code - RS stands for requirements specification.
A state machine having states that are hierarchically and/or orthogonally decomposed.
A model that represents the goals of something as an ordered structure of sub-goals.


4. Acceptance
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 collection of definitions of terms that are relevant in some domain. Frequently - a glossary also contains cross-references - synonyms - homonyms - acronyms - and abbreviations.
The process of assessing whether a system satisfies all its 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.


5. Conformity (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 committee of client and supplier representatives that decides on change requests. Abbreviation: CCB
The degree to which a requirements specification conforms to regulations given in some standard.
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


6. Non-functional requirement
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 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
A requirements specification pertaining to a software system. Abbreviation: SRS


7. Standard
A uniform regulation for perceiving - manufacturing or executing something.
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
In RE: A well-argued request for changing one or more baselined requirements.
The degree to which an artifact enables a required modification of the artifact.


8. Goal
A baseline for a set of requirements.
A desired state of affairs (that a stakeholder wants to achieve). Goals describe intentions of stakeholders. They may conflict with one another.
A model describing a system in its context.
Multiple occurrence of the same information or resource.


9. Context

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


10. Feature
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
An artificial language that has been created for expressing specifications.
A template for the syntactic structure of a phrase that expresses an individual requirement in natural language
Multiple occurrence of the same information or resource.


11. Decision table
A tabular - systematic representation of a complex decision that depends on multiple criteria.
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
Requirements elicitation.
Traceability of a requirement back to its origin.


12. Validation (of requirements)

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


13. Component
The degree to which an artifact enables a required modification of the artifact.
The range of things that can be shaped and designed when developing a system.
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.
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.


14. Correctness
A desired state of affairs (that a stakeholder wants to achieve). Goals describe intentions of stakeholders. They may conflict with one another.
The degree to which the information contained in an artifact is probably true. In RE - correctness is frequently used as a synonym for adequacy.
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.
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. Domain
Traceability of a requirement back to its origin.
A range of relevant things (for some given matter); for example - an application domain.
In RE: A well-argued request for changing one or more baselined 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


16. Verifiability (of 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.
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.
Multiple occurrence of the same information or resource.
A characteristic property of an entity.


17. Modeling language
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 concerning a result of behavior that shall be provided by a function of a system (or of a component or service).
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.


18. Risk
Requirements elicitation
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.
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.


19. View
A configuration that has been released for installation and use by customers.
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 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
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


20. Kind of requirement
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 template for the syntactic structure of a phrase that expresses an individual requirement in natural language
Those parts of the real world that are relevant for determining the context of a system.
1. In general: A principle for ordering and structuring. 2. In Informatics: A coherent - delimitable set of components that - by coordinated action - provides services. Requirements Engineering is concerned with the specification of requirements for


21. Elicitation (of requirements)
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
The ease with which a system can be transferred to another platform (while preserving its functionality). Portability may be stated as a quality requirement.
Requirements elicitation.
State machines having states that are hierarchically and/or orthogonally decomposed.


22. Finite state automaton
A verb characterizing the required action in a requirement written in natural language.
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 state machine with atomic states.
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


23. Acceptance test
A test that assesses whether a system satisfies all its requirements.
A model describing the behavior of a system or component - e.g. - by a state machine.
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 checking whether documented requirements match the stakeholders' needs.


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


25. Requirements analysis
1. Analysis of elicited requirements in order to understand and document them. 2. Synonym for requirements engineering.
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.
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 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


26. Efficiency
The degree to which a result is achieved with minimum consumption of resources.
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.
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 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


27. 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
User.
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
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


28. Glossary
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
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.
A collection of definitions of terms that are relevant in some domain. Frequently - a glossary also contains cross-references - synonyms - homonyms - acronyms - and abbreviations.
Abbreviation for Unified Modeling Language - a standardized language for modeling problems or solutions.


29. State-transition diagram
A diagrammatic representation of a state machine.
The degree to which a requirement is expressed such that it cannot be understood differently by different people.
A spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
A diagram type in UML that models the actors and the use cases of a system. The boundary between the actors and the use cases constitutes the system boundary.


30. Class model
Traceability of a requirement forward to its implementation in design and code - RS stands for requirements specification.
A model consisting of a set of classes and relationships between them.
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


31. Safety
The boundary between a system and its surrounding context.It separates the system to be developed from its environment; i.e. - it separates the part of the reality that can be modified or altered by the development process from aspects of the environ
The capability of a system to achieve an acceptable level of probability that operating the system will not result in harming people - property or the environment. Safety requirements may be stated as quality requirements or in terms of functional re
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
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


32. System context

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


33. Requirements engineer
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.
A requirements specification pertaining to a software system. Abbreviation: SRS
1. Analysis of elicited requirements in order to understand and document them. 2. Synonym for requirements engineering.
Requirements source


34. Version (of an entity)
A uniform regulation for perceiving - manufacturing or executing something.
Documents the importance of a requirement in comparison to other requirements according to given criteria.
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 artifact under review is inspected by a group of experts according to given criteria. The experts' findings are then collected and consolidated.


35. Homonym
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 term looking identical to another term - but having a different meaning. For example - bill as a bank note and bill as a list (of materials) are homonyms.
A tabular - systematic representation of a complex decision that depends on multiple criteria.
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.


36. Artifact
A committee of client and supplier representatives that decides on change requests. Abbreviation: CCB
An intermediate or final result of system development; for example - a requirements specification.
A model consisting of a set of classes and relationships between them.
The meaning of a sign or a set of signs in a language.


37. Baseline
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.
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 stable - change-controlled configuration of artifacts. Baselines serve for release planning and release definition as well as for project management purposes such as effort estimation.
The degree to which a set of requirements is free of contradicting statements.


38. Context boundary
A model describing the behavior of a system or component - e.g. - by a state machine.
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 diagram type in UML that models the actors and the use cases of a system. The boundary between the actors and the use cases constitutes the system boundary.
An excerpt from an artifact - containing only those parts one is currently interested in. A view can abstract or aggregate parts of the artifact.


39. State charts
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
State machines having states that are hierarchically and/or orthogonally decomposed.
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.
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.


40. Requirements elicitation
A diagrammatic representation of a class model.
The process of seeking - capturing and consolidating requirements from available requirements sources. May include the re-construction or creation of requirements. Aka Requirements discovery
The capability of a system to protect (a) its data and resources against unauthorized use and (b) its legitimate users against denial of service.
The range of things that can be shaped and designed when developing a system.


41. Context 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.
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 committee of client and supplier representatives that decides on change requests. Abbreviation: CCB
Abbreviation for Unified Modeling Language - a standardized language for modeling problems or solutions.


42. Changeability (of an artifact)
The degree to which an artifact enables a required modification of the artifact.
Multiple occurrence of the same information or resource.
1. A description of a potential sequence of events that lead to a desired (or unwanted) result. 2. An ordered sequence of interactions between partners - in particular between a system and external actors. May be a concrete sequence (instance scenari
Those parts of the real world that are relevant for determining the context of a system.


43. Adequacy (of a requirement)

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


44. Phrase template
A requirement that limits the solution space beyond what is necessary for meeting the given functional requirements and quality requirements.
A template for the syntactic structure of a phrase that expresses an individual requirement in natural language
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 uniform regulation for perceiving - manufacturing or executing something.


45. Requirements engineering (RE)
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 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 characteristic property of an entity.
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


46. Fault
Defect.
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
Traceability of a requirement back to its origin.
The capabilities of a system as stated by its functional requirements.


47. Pre-RS traceability
Traceability of a requirement back to its origin.
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 represents the goals of something as an ordered structure of sub-goals.
A state machine having states that are hierarchically and/or orthogonally decomposed.


48. Requirements templates
A systematically represented description of the properties of an entity (a system - a device - etc.) that satisfies given criteria. It may be about required properties (requirements specification) or implemented properties (e.g. - a technical product
A requirement pertaining to a system or to a component of a system.
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: 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


49. Inspection

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


50. User
The range of things that can be shaped and designed when developing a system.
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.
A person who uses the functionality provided by a system. Also called end user.
A committee that supervises a project.