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


2. Checking (requirements)
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
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.
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
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


3. 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
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 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
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.


4. Viewpoint

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


5. Walkthrough

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


6. 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 range of relevant things (for some given matter); for example - an application domain.
A test that assesses whether a system satisfies all its requirements.
The meaning of a sign or a set of signs in a language.


7. Requirements management
The process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).
A person who uses the functionality provided by a system. Also called end user.
A diagrammatic representation of a state machine.
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


8. Goal
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.
An intermediate or final result of system development; for example - a requirements specification.
A desired state of affairs (that a stakeholder wants to achieve). Goals describe intentions of stakeholders. They may conflict with one another.
A uniform regulation for perceiving - manufacturing or executing something.


9. System context

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


10. Redundancy
A spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
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.
Multiple occurrence of the same information or resource.
The rules for constructing structured signs in a language.


11. Feature
A baseline for a set of requirements.
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 requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).
Requirements elicitation.


12. Multiplicity
Cardinality.
A requirement describing a performance characteristic (timing - speed - volume - capacity - throughput...). Is regarded in this glossary as a sub-category of quality requirements - but can also be considered as a non-functional requirements category
The 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 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


13. Semantics
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 meaning of a sign or a set of signs in a language.
A requirement that limits the solution space beyond what is necessary for meeting the given functional requirements and quality requirements.
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.


14. Conformity (of requirements)
The degree to which a requirements specification conforms to regulations given in some standard.
The degree to which the information contained in an artifact is probably true. In RE - correctness is frequently used as a synonym for adequacy.
Defect
The process of checking whether documented requirements match the stakeholders' needs.


15. 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
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.
Those parts of the real world that are relevant for determining the context of a system.
A requirement describing a performance characteristic (timing - speed - volume - capacity - throughput...). Is regarded in this glossary as a sub-category of quality requirements - but can also be considered as a non-functional requirements category


16. Functional requirement
A requirement pertaining to a system or to a component of a system.
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).
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. Sequence diagram
A range of relevant things (for some given matter); for example - an application domain.
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.
The capabilities of a system as stated by its functional requirements.
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


18. Syntax
The rules for constructing structured signs in a language.
The degree to which a result is achieved with minimum consumption of resources.
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
Cardinality.


19. Consistency (of requirements)
The degree to which a set of requirements is free of contradicting statements.
A consistent set of logically coherent units. The units are individually identifiable artifacts or parts of artifacts (e.g. - requirements) in at most one version per unit.
A person or organization who receives a product or service. Also see stakeholder.
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.


20. Bug
Cardinality.
A verb characterizing the required action in a requirement written in natural language.
User.
Defect


21. Pre-RS traceability
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 assessing whether a system satisfies all its requirements.
Traceability of a requirement back to its origin.
Requirements elicitation


22. End user
Defect
User.
The degree to which a requirements specification conforms to regulations given in some standard.
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


23. Requirements source
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
The source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.
The capability of a system to protect (a) its data and resources against unauthorized use and (b) its legitimate users against denial of service.
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


24. Application domain
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 tabular - systematic representation of a complex decision that depends on multiple criteria.
An artificial language that has been created for expressing specifications.
Those parts of the real world that are relevant for determining the context of a system.


25. Performance requirement
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 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
A person or organization who receives a product or service. Also see stakeholder.
The range of things that can be shaped and designed when developing a system.


26. Cardinality
A graphic representation of an entity-relationship model. Abbreviation: ERD
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 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 diagrammatic representation of a context model. 2. In Structured Analysis - the context diagram is the root of the data flow diagram hierarchy.


27. Error
A diagrammatic representation of a state machine.
The process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).
A language for expressing models of a certain kind. May be textual - graphic - symbolic or some combination thereof.
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


28. Risk
A committee that supervises a project.
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
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.
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.


29. Requirements model
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).
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 model that has been created with the purpose of specifying 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


30. Decision table
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 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.
A tabular - systematic representation of a complex decision that depends on multiple criteria.
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


31. Correctness
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 degree to which the information contained in an artifact is probably true. In RE - correctness is frequently used as a synonym for adequacy.
A desired state of affairs (that a stakeholder wants to achieve). Goals describe intentions of stakeholders. They may conflict with one another.
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.


32. UML
A language for expressing models of a certain kind. May be textual - graphic - symbolic or some combination thereof.
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.
Abbreviation for Unified Modeling Language - a standardized language for modeling problems or solutions.
A template for the syntactic structure of a phrase that expresses an individual requirement in natural language


33. Efficiency
A requirements specification pertaining to a system. Frequently considered to be a synonym for requirements specification.
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
The degree to which a result is achieved with minimum consumption of resources.
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


34. Specification language
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).
An abstract representation of an existing reality or a reality to be created.
An artificial language that has been created for expressing specifications.
A desired state of affairs (that a stakeholder wants to achieve). Goals describe intentions of stakeholders. They may conflict with one another.


35. Non-functional requirement
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.
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 state machine having states that are hierarchically and/or orthogonally decomposed.
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


36. Class diagram
A requirement pertaining to a system or to a component of a system.
A diagrammatic representation of a class model.
A model describing a system in its context.
Those parts of the real world that are relevant for determining the context of a system.


37. 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
The process of checking whether documented requirements match the stakeholders' needs.
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
An abstract representation of an existing reality or a reality to be created.


38. Structured analysis
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 uniform regulation for perceiving - manufacturing or executing something.
The process of assessing whether a system satisfies all its requirements.
An approach for specifying the functionality of a system based on a hierarchy of dataflow diagrams. Data flows as well as persistent data are defined in a data dictionary. A context diagram models the sources of incoming and the destinations of outgo


39. Requirements specification
A consistent set of logically coherent units. The units are individually identifiable artifacts or parts of artifacts (e.g. - requirements) in at most one version per unit.
A desired state of affairs (that a stakeholder wants to achieve). Goals describe intentions of stakeholders. They may conflict with one another.
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.


40. Context model
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 model describing a system in its context.
A range of relevant things (for some given matter); for example - an application domain.
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


41. Requirement (modern definition)
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 collection of definitions of terms that are relevant in some domain. Frequently - a glossary also contains cross-references - synonyms - homonyms - acronyms - and abbreviations.
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 baseline for a set of requirements.


42. Phrase template
A template for the syntactic structure of a phrase that expresses an individual requirement in natural language
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
The part of a system's environment that is relevant for the definition as well as the understanding of the requirements of a system to be developed.
A committee that supervises a project.


43. Validation (of requirements)

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


44. Attribute
A person or organization who receives a product or service. Also see stakeholder.
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 characteristic property of an entity.
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.


45. System requirement
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.
A person or organization who receives a product or service. Also see stakeholder.
Multiple occurrence of the same information or resource.
A requirement pertaining to a system or to a component of a system.


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


47. Use case

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


48. Finite state automaton
The degree to which a set of requirements is free of contradicting statements.
A state machine with atomic states.
A committee that supervises a project.
A uniform regulation for perceiving - manufacturing or executing something.


49. View
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 meaning of a sign or a set of signs in a language.
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 tabular - systematic representation of a complex decision that depends on multiple criteria.


50. Reliability
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 model describing the behavior of a system or component - e.g. - by 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 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.