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. Model
A coarse description of the required capabilities of a system from the customer's perspective. Usually supplied by the customer.
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 tabular - systematic representation of a complex decision that depends on multiple criteria.
An abstract representation of an existing reality or a reality to be created.


2. Goal model
Cardinality.
The degree to which a set of requirements is free of contradicting statements.
A model that represents the goals of something as an ordered structure of sub-goals.
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.


3. Use case

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


4. Non-functional requirement
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
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
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.


5. Supplier
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 concerning a result of behavior that shall be provided by a function of a system (or of a component or service).
A requirements specification pertaining to a system. Frequently considered to be a synonym for requirements specification.
A person or organization who delivers a product or service to a customer.


6. Acceptance
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 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.
The process of assessing whether a system satisfies all its requirements.
Traceability of a requirement forward to its implementation in design and code - RS stands for requirements specification.


7. Software requirements specification
The degree to which a requirements specification conforms to regulations given in some standard.
A requirements specification pertaining to a software system. Abbreviation: SRS
In RE: A well-argued request for changing one or more baselined requirements.
Defect.


8. Standard
A certain perspective on the requirements of a system. Typical viewpoints are perspectives that a stakeholder or stakeholder group has (for example - an end user's perspective or an operator's perspective). However - there can also be topical viewpoi
A diagrammatic representation of a state machine.
A uniform regulation for perceiving - manufacturing or executing something.
A person or organization who receives a product or service. Also see stakeholder.


9. Validation (of requirements)

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


10. Compliance
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
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.
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 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


11. Version (of an entity)
The process of checking whether documented requirements match the stakeholders' needs.
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 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.


12. Glossary
A requirement that pertains to a quality concern that is not covered by functional requirements.
An intermediate or final result of system development; for example - a requirements specification.
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
A collection of definitions of terms that are relevant in some domain. Frequently - a glossary also contains cross-references - synonyms - homonyms - acronyms - and abbreviations.


13. Behavior Model
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.
A model describing the behavior of a system or component - e.g. - by a state machine.
The source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.
Those parts of the real world that are relevant for determining the context of a system.


14. Decision table
A tabular - systematic representation of a complex decision that depends on multiple criteria.
Documents the importance of a requirement in comparison to other requirements according to given criteria.
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
Multiple occurrence of the same information or resource.


15. Requirements engineering (RE)
A requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).
A state machine with atomic states.
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 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


16. Semi-formal

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


17. Requirements baseline
A baseline for a set of requirements.
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 source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.
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


18. System requirements specification
A requirements specification pertaining to a system. Frequently considered to be a synonym for requirements specification.
A characteristic property of an entity.
User.
A collection of definitions of terms that are relevant in some domain. Frequently - a glossary also contains cross-references - synonyms - homonyms - acronyms - and abbreviations.


19. User
A person who uses the functionality provided by a system. Also called end user.
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 capabilities of a system as stated by its functional requirements.
The capability of a system to protect (a) its data and resources against unauthorized use and (b) its legitimate users against denial of service.


20. Efficiency
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 person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.
A model describing a system in its context.
The degree to which a result is achieved with minimum consumption of resources.


21. Scope (of a system)
State machines having states that are hierarchically and/or orthogonally decomposed.
The range of things that can be shaped and designed when developing a system.
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 diagrammatic representation of a state machine.


22. Post-RS traceability
A diagrammatic representation of a state machine.
An artificial language that has been created for expressing specifications.
A test that assesses whether a system satisfies all its requirements.
Traceability of a requirement forward to its implementation in design and code - RS stands for requirements specification.


23. State-transition diagram
A diagrammatic representation of a state machine.
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
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 protect (a) its data and resources against unauthorized use and (b) its legitimate users against denial of service.


24. Statechart
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 model that has been created with the purpose of specifying requirements.
A state machine having states that are hierarchically and/or orthogonally decomposed.
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.


25. Context diagram
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
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 graphic representation of an entity-relationship model. Abbreviation: ERD
The process of seeking - capturing and consolidating requirements from available requirements sources. May include the re-construction or creation of requirements. Aka Requirements discovery


26. 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 requirement pertaining to a system or to a component of a system.
A model consisting of a set of classes and relationships between them.
A state machine having states that are hierarchically and/or orthogonally decomposed.


27. Defect
The degree to which an artifact enables a required modification of the artifact.
1. Analysis of elicited requirements in order to understand and document them. 2. Synonym for requirements engineering.
A requirement that pertains to a quality concern that is not covered by functional requirements.
A spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.


28. Correctness
A model that has been created with the purpose of specifying requirements.
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. In general: The network of thoughts and meanings needed for understanding phenomena or utterances. 2. Especially in RE: The part of a system's environment being relevant for understanding the system and its requirements. Context in the second mea
A 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


29. Baseline
A committee that supervises a project.
A person or organization who receives a product or service. Also see stakeholder.
Multiple occurrence of the same information or resource.
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.


30. Functional requirement
A systematically represented collection of requirements - typically for a system or component - that satisfies given criteria. In some situations we distinguish between a customer requirements specification (typically written by the customer) and a s
The source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.
A baseline for a set 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).


31. Cardinality
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.
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 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 baseline for a set of requirements.


32. Risk
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
Traceability of a requirement back to its origin.
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.
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.


33. Structured analysis
Requirements elicitation.
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 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
Those parts of the real world that are relevant for determining the context of a system.


34. Review
A committee of client and supplier representatives that decides on change requests. Abbreviation: CCB
The process of assessing whether a system satisfies all its 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.
Requirements source


35. State charts
State machines having states that are hierarchically and/or orthogonally decomposed.
Those parts of the real world that are relevant for determining the context of a system.
The range of things that can be shaped and designed when developing a system.
An intermediate or final result of system development; for example - a requirements specification.


36. Semantics
The meaning of a sign or a set of signs in a language.
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 spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.


37. State machine
An intermediate or final result of system development; for example - a requirements specification.
An approach for specifying the functionality of a system based on a hierarchy of dataflow diagrams. Data flows as well as persistent data are defined in a data dictionary. A context diagram models the sources of incoming and the destinations of outgo
A 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 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.


38. Use case diagram
User.
Multiple occurrence of the same information or resource.
Requirements elicitation
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.


39. Constraint
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 requirement that limits the solution space beyond what is necessary for meeting the given functional requirements and quality 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
A (software) system that helps develop - operate and maintain systems. In RE - tools support requirements management as well as modeling - documenting - and validating requirements.


40. Prototype
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
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.
Traceability of a requirement forward to its implementation in design and code - RS stands for requirements specification.
The source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.


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


42. Homonym
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 degree to which something actually happens in the way it ought to happen. In RE - typically the degree to which a system actually enables its users to achieve their goals as stated in the system's requirements.
1. A diagrammatic representation of a context model. 2. In Structured Analysis - the context diagram is the root of the data flow diagram hierarchy.
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


43. System boundary
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
User.
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 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


44. Inspection

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


45. Requirements specification
The source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.
A requirements specification pertaining to a software system. Abbreviation: SRS
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
Traceability of a requirement back to its origin.


46. Completeness (of requirements)
A template for the syntactic structure of a phrase that expresses an individual requirement in natural language
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
Multiple occurrence of the same information or resource.
State machines having states that are hierarchically and/or orthogonally decomposed.


47. Customer
A diagrammatic representation of a state machine.
A person or organization who receives a product or service. Also see stakeholder.
A test that assesses whether a system satisfies all its requirements.
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.


48. Adequacy (of a requirement)

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


49. Acceptance test
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.
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


50. Change control board
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 result is achieved with minimum consumption of resources.
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 committee of client and supplier representatives that decides on change requests. Abbreviation: CCB