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. Customer
A person who uses the functionality provided by a system. Also called end user.
A requirement that pertains to a quality concern that is not covered by functional requirements.
The degree to which a result is achieved with minimum consumption of resources.
A person or organization who receives a product or service. Also see stakeholder.

2. Requirement (original IEEE definition)
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 requirements specification conforms to regulations given in some standard.
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
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.

3. Model
An abstract representation of an existing reality or a reality to be created.
The process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).
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
The ease with which a system can be transferred to another platform (while preserving its functionality). Portability may be stated as a quality requirement.

4. Requirements templates
A diagrammatic representation of a class model.
A blueprint for the syntactic structure of individual requirements.A phrase template is a specific requirements template for requirements written in natural language.
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 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.

5. Software requirements specification
If an entity exists in multiple - time-ordered occurrences - where each occurrence has been created by modifying one of its predecessors - every occurrence is a version of that entity.
A 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
A requirements specification pertaining to a software system. Abbreviation: SRS
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.

6. Modeling language
A language for expressing models of a certain kind. May be textual - graphic - symbolic or some combination thereof.
A configuration that has been released for installation and use by customers.
The capabilities of a system as stated by its functional requirements.
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

7. Release
A configuration that has been released for installation and use by customers.
Requirements elicitation.
A requirement that pertains to a quality concern that is not covered by functional requirements.
The rules for constructing structured signs in a language.

8. Changeability (of an artifact)
The source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.
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 degree to which an artifact enables a required modification of the artifact.
A requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).

9. Security
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 process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).
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 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. Specification
A uniform regulation for perceiving - manufacturing or executing something.
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 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
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

11. Conformity (of requirements)
The degree to which a requirements specification conforms to regulations given in some standard.
The degree to which a result is achieved with minimum consumption of resources.
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
In RE: A well-argued request for changing one or more baselined requirements.

12. Quality requirement
Traceability of a requirement back to its origin.
A state machine with atomic states.
A requirement that pertains to a quality concern that is not covered by functional requirements.
The range of things that can be shaped and designed when developing a system.

13. Performance 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
State machines having states that are hierarchically and/or orthogonally decomposed.
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 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

14. Bug
A range of relevant things (for some given matter); for example - an application domain.
Cardinality.
Defect
Those parts of the real world that are relevant for determining the context of a system.

15. Validation (of requirements)

16. Fault
Defect.
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.
1. A diagrammatic representation of a context model. 2. In Structured Analysis - the context diagram is the root of the data flow diagram hierarchy.
The process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).

17. System context

18. Process verb
Traceability of a requirement back to its origin.
A verb characterizing the required action in a requirement written in natural language.
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 model that has been created with the purpose of specifying requirements.

19. Scope (of a system)
A requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).
An artificial language that has been created for expressing specifications.
A model describing the behavior of a system or component - e.g. - by a state machine.
The range of things that can be shaped and designed when developing a system.

20. Homonym
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 spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
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.
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.

21. Multiplicity
A requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).
Cardinality.
The part of a system's environment that is relevant for the definition as well as the understanding of the requirements of a system to be developed.
The range of things that can be shaped and designed when developing a system.

22. Language
Defect.
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.
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 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

23. Attribute
A characteristic property of an entity.
A baseline for a set of requirements.
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 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

24. Entity-relationship diagram
A graphic representation of an entity-relationship model. Abbreviation: ERD
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.
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 process of checking whether documented requirements match the stakeholders' needs.

25. Application domain
Those parts of the real world that are relevant for determining the context of a system.
The degree to which a result is achieved with minimum consumption of resources.
The degree to which a requirements specification conforms to regulations given in some standard.
A model consisting of a set of classes and relationships between them.

26. Scenario
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 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 source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.
The degree to which a set of requirements is free of contradicting statements.

27. Behavior Model
A model describing the behavior of a system or component - e.g. - by a state machine.
A committee that supervises a project.
A spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
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.

28. Functional requirement
A requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).
A person or organization who delivers a product or service to a customer.
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 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. Requirements engineering (RE)
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 degree to which a requirement is expressed such that it cannot be understood differently by different people.
An intermediate or final result of system development; for example - a requirements specification.
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

30. State machine
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
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 set of requirements is free of contradicting statements.
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.

31. Change control board
The degree to which a set of requirements is free of contradicting statements.
A committee of client and supplier representatives that decides on change requests. Abbreviation: CCB
A configuration that has been released for installation and use by customers.
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.

32. Class model
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.
In RE: A well-argued request for changing one or more baselined requirements.
A model consisting of a set of classes and relationships between them.
A committee of client and supplier representatives that decides on change requests. Abbreviation: CCB

33. Verifiability (of requirements)
Defect.
The process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).
An abstract representation of an existing reality or a reality to be created.
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.

34. Use case diagram
The process of checking whether documented requirements match the stakeholders' needs.
State machines having states that are hierarchically and/or orthogonally decomposed.
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.
Defect.

35. Checking (requirements)
The process of checking whether documented requirements match the stakeholders' needs.
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.
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 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.

36. Requirements engineer
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.
A blueprint for the syntactic structure of individual requirements.A phrase template is a specific requirements template for requirements written in natural language.
An abstract representation of an existing reality or a reality to be created.
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

37. View
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
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 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
An excerpt from an artifact - containing only those parts one is currently interested in. A view can abstract or aggregate parts of the artifact.

38. Class diagram
The capabilities of a system as stated by its functional requirements.
If an entity exists in multiple - time-ordered occurrences - where each occurrence has been created by modifying one of its predecessors - every occurrence is a version of that entity.
The process of checking whether documented requirements match the stakeholders' needs.
A diagrammatic representation of a class model.

39. Defect
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
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 model that has been created with the purpose of specifying requirements.
A spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.

40. Safety
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 uniform regulation for perceiving - manufacturing or executing something.
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.
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

41. Sequence diagram
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.
Defect
A tabular - systematic representation of a complex decision that depends on multiple criteria.
The range of things that can be shaped and designed when developing a system.

42. Redundancy
Multiple occurrence of the same information or resource.
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 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.
1. Analysis of elicited requirements in order to understand and document them. 2. Synonym for requirements engineering.

43. Portability
The source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.
A template for the syntactic structure of a phrase that expresses an individual requirement in natural language
The ease with which a system can be transferred to another platform (while preserving its functionality). Portability may be stated as a quality requirement.
An intermediate or final result of system development; for example - a requirements specification.

44. Fault tolerance
A model that represents the goals of something as an ordered structure of sub-goals.
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 test that assesses whether a system satisfies all its requirements.
The degree to which a set of inherent characteristics of an entity fulfills requirements. The entity may be a system - service - product - artifact - process - person - organization - etc. An inherent characteristic is a distinguishing feature of or

45. Entity
The source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.
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 document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
A model that represents the goals of something as an ordered structure of sub-goals.

46. Inspection

47. Important facets of RE
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
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.
A diagram type in UML which models the flow of actions in a system or in a component including data flows and areas of responsibility where necessary.
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.

48. Completeness (of 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.
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
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 test that assesses whether a system satisfies all its requirements.

49. System boundary
1. Analysis of elicited requirements in order to understand and document them. 2. Synonym for requirements engineering.
The boundary between a system and its surrounding context.It separates the system to be developed from its environment; i.e. - it separates the part of the reality that can be modified or altered by the development process from aspects of the environ
A requirement 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.

50. Structured analysis
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 language for expressing models of a certain kind. May be textual - graphic - symbolic or some combination thereof.
A spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
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