Test your basic knowledge |

CPRE: Certified Professional Requirements Engineering

Subjects : certifications, cpre, it-skills

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

2. Scenario
Documents the importance of a requirement in comparison to other requirements according to given criteria.
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
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.
The degree to which a requirements specification conforms to regulations given in some standard.

3. Entity-relationship model
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
The process of checking whether documented requirements match the stakeholders' needs.
User.
A model that represents the goals of something as an ordered structure of sub-goals.

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

5. Model
A verb characterizing the required action in a requirement written in natural language.
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 degree to which a requirements specification conforms to regulations given in some standard.
An abstract representation of an existing reality or a reality to be created.

6. State charts
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 baseline for a set of requirements.
Defect.
State machines having states that are hierarchically and/or orthogonally decomposed.

7. Attribute
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
The process of assessing whether a system satisfies all its requirements.
A characteristic property of an entity.
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

8. Effectiveness

9. Class model
A model consisting of a set of classes and relationships between them.
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 committee that supervises a project.
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

10. Kind of requirement
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.
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
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 process of checking whether documented requirements match the stakeholders' needs.

11. Redundancy
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
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
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.
Multiple occurrence of the same information or resource.

12. Defect
A spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
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 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
Documents the importance of a requirement in comparison to other requirements according to given criteria.

13. Priority (of a requirement)
Documents the importance of a requirement in comparison to other requirements according to given criteria.
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 a requirement is expressed such that it cannot be understood differently by different people.
Requirements elicitation

14. Sequence diagram
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 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 person or organization who receives a product or service. Also see stakeholder.
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

15. System boundary
The boundary between a system and its surrounding context.It separates the system to be developed from its environment; i.e. - it separates the part of the reality that can be modified or altered by the development process from aspects of the environ
The 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 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
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.

16. Checking (requirements)
A characteristic property of an 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.
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
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.

17. Customer
A person or organization who receives a product or service. Also see stakeholder.
A coarse description of the required capabilities of a system from the customer's perspective. Usually supplied by the customer.
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.
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.

18. Class
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.
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 state machine with atomic states.
A desired state of affairs (that a stakeholder wants to achieve). Goals describe intentions of stakeholders. They may conflict with one another.

19. Stakeholder

20. Context model
A committee of client and supplier representatives that decides on change requests. Abbreviation: CCB
In RE: A well-argued request for changing one or more baselined requirements.
A model describing a system in its context.
A state machine having states that are hierarchically and/or orthogonally decomposed.

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

22. Requirements specification
A uniform regulation for perceiving - manufacturing or executing something.
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 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 requirement pertaining to a system or to a component of a system.

23. 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.
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.
The range of things that can be shaped and designed when developing a system.
The degree to which a result is achieved with minimum consumption of resources.

24. Semantics
The meaning of a sign or a set of signs in a language.
A template for the syntactic structure of a phrase that expresses an individual requirement in natural language
A state machine with atomic states.
A person or organization who receives a product or service. Also see stakeholder.

25. Conformity (of requirements)
A model describing the behavior of a system or component - e.g. - by a state machine.
The degree to which a requirements specification conforms to regulations given in some standard.
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.

26. Language
The process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).
A requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).
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.
Abbreviation for Unified Modeling Language - a standardized language for modeling problems or solutions.

27. Quality requirement
A formally organized endeavor for checking an artifact by a group of experts. Checking may be performed with respect to both contents and conformance.
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.
A requirement that pertains to a quality concern that is not covered by functional requirements.
State machines having states that are hierarchically and/or orthogonally decomposed.

28. Requirements engineering (RE)
An intermediate or final result of system development; for example - a requirements specification.
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 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
Requirements elicitation.

29. Requirement (original IEEE definition)
The rules for constructing structured signs in a language.
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 characteristic property of an 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

30. Acceptance
A requirement that limits the solution space beyond what is necessary for meeting the given functional requirements and quality requirements.
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.
The process of assessing whether a system satisfies all its requirements.
A range of relevant things (for some given matter); for example - an application domain.

31. Review
A requirements specification pertaining to a software system. Abbreviation: SRS
A diagrammatic representation of a class model.
A requirement that limits the solution space beyond what is necessary for meeting the given functional requirements and quality 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.

32. Use case diagram
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 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 range of things that can be shaped and designed when developing a system.
Abbreviation for Unified Modeling Language - a standardized language for modeling problems or solutions.

33. Prototype
A requirements specification pertaining to a system. Frequently considered to be a synonym for 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.
The degree to which an artifact enables a required modification of the artifact.
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

34. Specification language
An artificial language that has been created for expressing specifications.
Requirements elicitation
A model describing a system in its context.
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

35. Requirements discovery
A uniform regulation for perceiving - manufacturing or executing something.
Requirements elicitation
A graphic representation of an entity-relationship model. Abbreviation: ERD
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.

36. Requirements analysis
A requirement that pertains to a quality concern that is not covered by functional 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
1. Analysis of elicited requirements in order to understand and document them. 2. Synonym for requirements engineering.
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

37. Context boundary
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 model consisting of a set of classes and relationships between them.
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 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.

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

39. Domain
A range of relevant things (for some given matter); for example - an application domain.
A requirement pertaining to a system or to a component of a system.
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 capability of a system to protect (a) its data and resources against unauthorized use and (b) its legitimate users against denial of service.

40. Finite state automaton
A model that has been created with the purpose of specifying requirements.
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 configuration that has been released for installation and use by customers.
A state machine with atomic states.

41. Version (of an entity)
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 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 state machine having states that are hierarchically and/or orthogonally decomposed.
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.

42. Goal
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.
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.
The process of seeking - capturing and consolidating requirements from available requirements sources. May include the re-construction or creation of requirements. Aka Requirements discovery

43. Requirements elicitation
A person or organization who receives a product or service. Also see stakeholder.
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
The process of seeking - capturing and consolidating requirements from available requirements sources. May include the re-construction or creation of requirements. Aka Requirements discovery
An excerpt from an artifact - containing only those parts one is currently interested in. A view can abstract or aggregate parts of the artifact.

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

45. Class diagram
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 result is achieved with minimum consumption of resources.
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 diagrammatic representation of a class model.

46. Baseline
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 seeking - capturing and consolidating requirements from available requirements sources. May include the re-construction or creation of requirements. Aka Requirements discovery
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.
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

47. Component
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 tabular - systematic representation of a complex decision that depends on multiple criteria.
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.
An artificial language that has been created for expressing specifications.

48. Change request
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.
In RE: A well-argued request for changing one or more baselined requirements.
A model that represents the goals of something as an ordered structure of sub-goals.
Abbreviation for Unified Modeling Language - a standardized language for modeling problems or solutions.

49. Behavior Model
A model describing the behavior of a system or component - e.g. - by a state machine.
A requirement pertaining to a system or to a component of a system.
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 capabilities of a system as stated by its functional requirements.

50. Artifact
An intermediate or final result of system development; for example - a requirements specification.
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.
A model describing the behavior of a system or component - e.g. - by a state machine.