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. Maintainability
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
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 (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 that represents the goals of something as an ordered structure of sub-goals.


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


3. Functional requirement
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 configuration that has been released for installation and use by customers.
A requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).
1. A diagrammatic representation of a context model. 2. In Structured Analysis - the context diagram is the root of the data flow diagram hierarchy.


4. Quality
A graphic representation of an entity-relationship model. Abbreviation: ERD
A characteristic property of an entity.
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 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


5. Redundancy
Multiple occurrence of the same information or resource.
A model describing the behavior of a system or component - e.g. - by a state machine.
Requirements elicitation
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


6. Functionality
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.
Defect.
The capabilities of a system as stated by its functional 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


7. Constraint
A (software) system that helps develop - operate and maintain systems. In RE - tools support requirements management as well as modeling - documenting - and validating 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.
The degree to which a result is achieved with minimum consumption of resources.
A requirement that limits the solution space beyond what is necessary for meeting the given functional requirements and quality requirements.


8. System 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.
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.
The range of things that can be shaped and designed when developing a system.


9. Entity
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. 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 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 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


10. Statechart
The rules for constructing structured signs in a language.
A model that represents the goals of something as an ordered structure of sub-goals.
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 state machine having states that are hierarchically and/or orthogonally decomposed.


11. Performance requirement
The rules for constructing structured signs in a language.
The degree to which a result is achieved with minimum consumption of resources.
A configuration that has been released for installation and use by customers.
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. Modeling language
A language for expressing models of a certain kind. May be textual - graphic - symbolic or some combination thereof.
Requirements elicitation.
The process of assessing whether a system satisfies all its requirements.
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.


13. Standard
The rules for constructing structured signs in a language.
A uniform regulation for perceiving - manufacturing or executing something.
A requirements specification pertaining to a software system. Abbreviation: SRS
The meaning of a sign or a set of signs in a language.


14. Software requirements specification
A diagrammatic representation of a state machine.
A requirements specification pertaining to a software system. Abbreviation: SRS
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.


15. Requirements management
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 process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).
1. A need perceived by a stakeholder 2. A capability or property that a system shall have 3. A documented representation of a need - capability or property.
A range of relevant things (for some given matter); for example - an application domain.


16. Glossary
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 collection of definitions of terms that are relevant in some domain. Frequently - a glossary also contains cross-references - synonyms - homonyms - acronyms - and abbreviations.
Documents the importance of a requirement in comparison to other requirements according to given criteria.
A coarse description of the required capabilities of a system from the customer's perspective. Usually supplied by the customer.


17. Requirement (modern definition)
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
A baseline for a set of requirements.
State machines having states that are hierarchically and/or orthogonally decomposed.
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.


18. Error
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 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
In RE: A well-argued request for changing one or more baselined requirements.
A characteristic property of an entity.


19. System requirement
A requirement pertaining to a system or to a component of a system.
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.
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
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


20. Context diagram
A (software) system that helps develop - operate and maintain systems. In RE - tools support requirements management as well as modeling - documenting - and validating 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
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 that supervises a project.


21. 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.
A model that represents the goals of something as an ordered structure of sub-goals.
A spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
A coarse description of the required capabilities of a system from the customer's perspective. Usually supplied by the customer.


22. Requirements templates
Defect.
A blueprint for the syntactic structure of individual requirements.A phrase template is a specific requirements template for requirements written in natural language.
A model describing the behavior of a system or component - e.g. - by a state machine.
A certain perspective on the requirements of a system. Typical viewpoints are perspectives that a stakeholder or stakeholder group has (for example - an end user's perspective or an operator's perspective). However - there can also be topical viewpoi


23. Pre-RS traceability
1. Analysis of elicited requirements in order to understand and document them. 2. Synonym for requirements engineering.
Traceability of a requirement back to its origin.
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
The degree to which an artifact enables a required modification of the artifact.


24. Effectiveness

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


25. Specification language
The process of checking whether documented requirements match the stakeholders' needs.
Boundary between the context of a system and those parts of the application domain that are irrelevant for the system and its requirements. It separates the relevant part of the environment of a system to be developed from the irrelevant part - i.e.
An artificial language that has been created for expressing specifications.
A diagrammatic representation of a class model.


26. Unambiguity (of requirements)
The degree to which a requirement is expressed such that it cannot be understood differently by different people.
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).
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 committee of client and supplier representatives that decides on change requests. Abbreviation: CCB


27. Context

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


28. Model
An abstract representation of an existing reality or a reality to be created.
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. 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.


29. Quality requirement
Requirements elicitation
A uniform regulation for perceiving - manufacturing or executing something.
A requirements specification pertaining to a software system. Abbreviation: SRS
A requirement that pertains to a quality concern that is not covered by functional requirements.


30. Domain
A graphic representation of an entity-relationship model. Abbreviation: ERD
The process of checking whether documented requirements match the stakeholders' needs.
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 range of relevant things (for some given matter); for example - an application domain.


31. Requirements elicitation
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 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.
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 degree to which a requirement expresses the stakeholders' true desires and needs (i.e. - those they had actually in mind when stating the requirement).


32. Requirements engineer
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.
A model describing the behavior of a system or component - e.g. - by a state machine.
A spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
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.


33. Changeability (of an artifact)
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.
The degree to which a requirement is expressed such that it cannot be understood differently by different people.
Requirements source


34. Change control board
A model consisting of a set of classes and relationships between them.
The degree to which a requirement is expressed such that it cannot be understood differently by different people.
A committee of client and supplier representatives that decides on change requests. Abbreviation: CCB
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.


35. Requirements analysis
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 blueprint for the syntactic structure of individual requirements.A phrase template is a specific requirements template for requirements written in natural language.
1. Analysis of elicited requirements in order to understand and document them. 2. Synonym for requirements engineering.
A (software) system that helps develop - operate and maintain systems. In RE - tools support requirements management as well as modeling - documenting - and validating requirements.


36. Customer
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 degree to which a set of requirements is free of contradicting statements.
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 person or organization who receives a product or service. Also see stakeholder.


37. Acceptance
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 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 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 process of assessing whether a system satisfies all its requirements.


38. Semi-formal

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


39. Efficiency
The degree to which a requirement is expressed such that it cannot be understood differently by different people.
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.
The degree to which a result is achieved with minimum consumption of resources.


40. Portability
Traceability of a requirement back to its origin.
The ease with which a system can be transferred to another platform (while preserving its functionality). Portability may be stated as a quality requirement.
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


41. Phrase template
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
Defect.
A template for the syntactic structure of a phrase that expresses an individual requirement in natural language
The process of assessing whether a system satisfies all its requirements.


42. 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.
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 language for expressing models of a certain kind. May be textual - graphic - symbolic or some combination thereof.


43. Inspection

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


44. End user
User.
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 abstract representation of an existing reality or a reality to be created.
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.


45. Customer requirements specification

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


46. Entity-relationship diagram
A uniform regulation for perceiving - manufacturing or executing something.
A graphic representation of an entity-relationship model. Abbreviation: ERD
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 document consisting of a requirements specification. Frequently used as a synonym for requirements specification.


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


48. Requirements specification
The capabilities of a system as stated by its functional requirements.
A uniform regulation for perceiving - manufacturing or executing something.
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 degree to which a requirements specification conforms to regulations given in some standard.


49. Consistency (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.
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.
The degree to which a set of requirements is free of contradicting statements.
An artificial language that has been created for expressing specifications.


50. Scenario
Documents the importance of a requirement in comparison to other requirements according to given criteria.
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
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
An artificial language that has been created for expressing specifications.