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. Scope (of a system)
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.
Documents the importance of a requirement in comparison to other requirements according to given criteria.
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 range of things that can be shaped and designed when developing a system.


2. Class diagram
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.
Those parts of the real world that are relevant for determining the context of a system.
A diagrammatic representation of a class model.
An intermediate or final result of system development; for example - a requirements specification.


3. Class model
The capabilities of a system as stated by its functional requirements.
A desired state of affairs (that a stakeholder wants to achieve). Goals describe intentions of stakeholders. They may conflict with one another.
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.
A model consisting of a set of classes and relationships between them.


4. Risk
Multiple occurrence of the same information or resource.
A state machine having states that are hierarchically and/or orthogonally decomposed.
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.
An intermediate or final result of system development; for example - a requirements specification.


5. Entity-relationship diagram
The process of checking whether documented requirements match the stakeholders' needs.
A graphic representation of an entity-relationship model. Abbreviation: ERD
A language for expressing models of a certain kind. May be textual - graphic - symbolic or some combination thereof.
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.


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


7. Viewpoint

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


8. Data flow diagram
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 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.
Traceability of a requirement forward to its implementation in design and code - RS stands for requirements specification.
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.


9. Semi-formal

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


10. Customer
A person or organization who receives a product or service. Also see stakeholder.
The degree to which a requirement is expressed such that it cannot be understood differently by different people.
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
User.


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


12. Maintainability
The ease with which a software system can be modified to correct faults or adapt the system to changing needs. Maintainability may be stated as a quality requirement
A graphic representation of an entity-relationship model. Abbreviation: ERD
A state machine with atomic states.
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


13. State charts
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 person or organization who delivers a product or service to a customer.
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.


14. Requirements document
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 document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
The degree to which a requirements specification conforms to regulations given in some standard.
A blueprint for the syntactic structure of individual requirements.A phrase template is a specific requirements template for requirements written in natural language.


15. Homonym
An intermediate or final result of system development; for example - a requirements specification.
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages 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 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.


16. Requirements elicitation
A uniform regulation for perceiving - manufacturing or executing something.
A graphic representation of an entity-relationship model. Abbreviation: ERD
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.
The process of seeking - capturing and consolidating requirements from available requirements sources. May include the re-construction or creation of requirements. Aka Requirements discovery


17. Requirements discovery
Requirements elicitation
A model describing the behavior of a system or component - e.g. - by a state machine.
Documents the importance of a requirement in comparison to other requirements according to given criteria.
Cardinality.


18. State-transition diagram
A diagrammatic representation of a state machine.
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.
The degree to which a result is achieved with minimum consumption of resources.
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.


19. Effectiveness

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


20. System context

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


21. Constraint
A requirement that limits the solution space beyond what is necessary for meeting the given functional requirements and quality requirements.
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.
Traceability of a requirement back to its origin.
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


22. Use case

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


23. Requirements baseline
A baseline for a set of requirements.
A coarse description of the required capabilities of a system from the customer's perspective. Usually supplied by the customer.
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 the information contained in an artifact is probably true. In RE - correctness is frequently used as a synonym for adequacy.


24. Requirements templates
1. A condition or capability needed by a user to solve a problem or achieve an objective 2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract - standard - specification - or other formally i
The source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.
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 blueprint for the syntactic structure of individual requirements.A phrase template is a specific requirements template for requirements written in natural language.


25. Context

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


26. Attribute
The ease with which a software system can be modified to correct faults or adapt the system to changing needs. Maintainability may be stated as a quality requirement
A characteristic property of an entity.
The source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.
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


27. Cardinality
Defect
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 who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.
An excerpt from an artifact - containing only those parts one is currently interested in. A view can abstract or aggregate parts of the artifact.


28. Version (of an entity)
A requirements specification pertaining to a system. Frequently considered to be a synonym for requirements specification.
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 (software) system that helps develop - operate and maintain systems. In RE - tools support requirements management as well as modeling - documenting - and validating requirements.
An intermediate or final result of system development; for example - a requirements specification.


29. Actor
A requirement that limits the solution space beyond what is necessary for meeting the given functional requirements and quality 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
A diagrammatic representation of a state machine.
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


30. Requirement (original IEEE definition)
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 range of relevant things (for some given matter); for example - an application domain.
Abbreviation for Unified Modeling Language - a standardized language for modeling problems or solutions.
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


31. Stakeholder

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


32. Redundancy
A configuration that has been released for installation and use by customers.
The degree to which a set of requirements is free of contradicting statements.
Multiple occurrence of the same information or resource.
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.


33. Security
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 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.
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 range of relevant things (for some given matter); for example - an application domain.


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


35. Activity diagram
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 degree to which a requirement expresses the stakeholders' true desires and needs (i.e. - those they had actually in mind when stating the requirement).
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 describing a system in its context.


36. Pre-RS traceability
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 that represents the goals of something as an ordered structure of sub-goals.
Traceability of a requirement back to its origin.
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


37. Non-functional requirement
A committee that supervises a project.
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.
A verb characterizing the required action in a requirement written in natural language.
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


38. Supplier
A model that represents the goals of something as an ordered structure of sub-goals.
The degree to which a result is achieved with minimum consumption of resources.
1. A diagrammatic representation of a context model. 2. In Structured Analysis - the context diagram is the root of the data flow diagram hierarchy.
A person or organization who delivers a product or service to a customer.


39. Functional requirement
The degree to which a set of inherent characteristics of an entity fulfills requirements. The entity may be a system - service - product - artifact - process - person - organization - etc. An inherent characteristic is a distinguishing feature of or
A uniform regulation for perceiving - manufacturing or executing something.
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.
A requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).


40. Requirements management
The process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).
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 requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).
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.


41. State machine
A configuration that has been released for installation and use by customers.
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 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 system. Frequently considered to be a synonym for requirements specification.


42. Compliance
In RE: A well-argued request for changing one or more baselined requirements.
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 coarse description of the required capabilities of a system from the customer's perspective. Usually supplied by the customer.
The degree to which an artifact enables a required modification of the artifact.


43. Requirements analysis
Documents the importance of a requirement in comparison to other requirements according to given criteria.
State machines having states that are hierarchically and/or orthogonally decomposed.
A graphic representation of an entity-relationship model. Abbreviation: ERD
1. Analysis of elicited requirements in order to understand and document them. 2. Synonym for requirements engineering.


44. Multiplicity
The process of assessing whether a system satisfies all its requirements.
A discrepancy between an observed behavior or result and the specified behavior or result. An error typically is a symptom for the existence of a fault or defect in some artifact. In colloquial English - there is sometimes no distinction between the
State machines having states that are hierarchically and/or orthogonally decomposed.
Cardinality.


45. Goal model
A model that represents the goals of something as an ordered structure of sub-goals.
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 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
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.


46. Context model
A model describing the behavior of a system or component - e.g. - by a state machine.
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
In RE: A well-argued request for changing one or more baselined requirements.
A model describing a system in its context.


47. Specification
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.
Traceability of a requirement back to its origin.
A desired state of affairs (that a stakeholder wants to achieve). Goals describe intentions of stakeholders. They may conflict with one another.
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


48. Requirements engineer
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 capability of a system to maintain a specified level of functionality and performance when used under specified conditions. Reliability may be stated as a quality requirement.
A 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 person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.


49. Change request
1. Analysis of elicited requirements in order to understand and document them. 2. Synonym for requirements engineering.
A test that assesses whether a system satisfies all its requirements.
In RE: A well-argued request for changing one or more baselined requirements.
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.


50. Finite state automaton
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 state machine with atomic states.
An intermediate or final result of system development; for example - a requirements specification.
A graphic representation of an entity-relationship model. Abbreviation: ERD