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. Glossary
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 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
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 collection of definitions of terms that are relevant in some domain. Frequently - a glossary also contains cross-references - synonyms - homonyms - acronyms - and abbreviations.

2. Class model
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
Requirements elicitation.
An approach for specifying the functionality of a system based on a hierarchy of dataflow diagrams. Data flows as well as persistent data are defined in a data dictionary. A context diagram models the sources of incoming and the destinations of outgo
A model consisting of a set of classes and relationships between them.

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

4. Fault
Defect.
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
A requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).
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

5. Actor
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
The process of assessing whether a system satisfies all its requirements.
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 baseline for a set of requirements.

6. System requirements specification
A requirement pertaining to a system or to a component of a system.
A requirements specification pertaining to a system. Frequently considered to be a synonym for requirements specification.
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 requirement that pertains to a quality concern that is not covered by functional requirements.

7. Functional requirement
1. Analysis of elicited requirements in order to understand and document them. 2. Synonym for requirements engineering.
A requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).
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 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.

8. System context

9. Important facets of RE
1. Analysis of elicited requirements in order to understand and document them. 2. Synonym for requirements engineering.
The range of things that can be shaped and designed when developing a system.
A test that assesses whether a system satisfies all its requirements.
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.

10. Artifact
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
An intermediate or final result of system development; for example - a requirements specification.
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.
The process of checking whether documented requirements match the stakeholders' needs.

11. Requirements engineer
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.
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 spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
Requirements elicitation

12. Multiplicity
Cardinality.
A baseline for a set of requirements.
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.
A model consisting of a set of classes and relationships between them.

13. Viewpoint

14. State-transition diagram
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
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 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 diagrammatic representation of a state machine.

15. Error
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 (software) system that helps develop - operate and maintain systems. In RE - tools support requirements management as well as modeling - documenting - and validating requirements.
1. Analysis of elicited requirements in order to understand and document them. 2. Synonym for requirements engineering.
An artificial language that has been created for expressing specifications.

16. Goal
In RE: A well-argued request for changing one or more baselined requirements.
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 protect (a) its data and resources against unauthorized use and (b) its legitimate users against denial of service.
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.

17. Requirements specification
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
Defect
Requirements elicitation
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.

18. Entity-relationship diagram
A graphic representation of an entity-relationship model. Abbreviation: ERD
A person who uses the functionality provided by a system. Also called end user.
Cardinality.
A characteristic property of an entity.

19. Feature
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 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 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
Documents the importance of a requirement in comparison to other requirements according to given criteria.

20. Unambiguity (of requirements)
The source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.
An excerpt from an artifact - containing only those parts one is currently interested in. A view can abstract or aggregate parts of the artifact.
An abstract representation of an existing reality or a reality to be created.
The degree to which a requirement is expressed such that it cannot be understood differently by different people.

21. UML
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 model describing a system in its context.
Abbreviation for Unified Modeling Language - a standardized language for modeling problems or solutions.
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.

22. Stakeholder

23. Checking (requirements)
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 requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.
A person or organization who delivers a product or service to a customer.

24. Class diagram
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.
A language for expressing models of a certain kind. May be textual - graphic - symbolic or some combination thereof.
A diagrammatic representation of a class model.
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

25. Changeability (of an artifact)
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.
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 degree to which an artifact enables a required modification of the artifact.
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.

26. Kind of requirement
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
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
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 committee of client and supplier representatives that decides on change requests. Abbreviation: CCB

27. Defect
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 spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
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 committee of client and supplier representatives that decides on change requests. Abbreviation: CCB

28. Specification language
An artificial language that has been created for expressing specifications.
A diagrammatic representation of a state machine.
Those parts of the real world that are relevant for determining the context of a system.
A model describing the behavior of a system or component - e.g. - by a state machine.

29. Requirements engineering (RE)
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 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
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 person or organization who receives a product or service. Also see stakeholder.

30. 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 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 range of things that can be shaped and designed when developing a system.
An abstract representation of an existing reality or a reality to be created.

31. Syntax
A requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).
A committee of client and supplier representatives that decides on change requests. Abbreviation: CCB
The rules for constructing structured signs in a language.
The range of things that can be shaped and designed when developing a system.

32. Attribute
A requirements specification pertaining to a software system. Abbreviation: SRS
A test that assesses whether a system satisfies all its requirements.
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.
A characteristic property of an entity.

33. Redundancy
A certain perspective on the requirements of a system. Typical viewpoints are perspectives that a stakeholder or stakeholder group has (for example - an end user's perspective or an operator's perspective). However - there can also be topical viewpoi
A blueprint for the syntactic structure of individual requirements.A phrase template is a specific requirements template for requirements written in natural language.
Multiple occurrence of the same information or resource.
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. Performance requirement
A committee of client and supplier representatives that decides on change requests. Abbreviation: CCB
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 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.
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.

35. Quality requirement
A requirement that pertains to a quality concern that is not covered by functional requirements.
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.
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 committee that supervises a project.

36. Efficiency
The degree to which a result is achieved with minimum consumption of resources.
A requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).
The source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.
Multiple occurrence of the same information or resource.

37. Inspection

38. Context boundary
A requirement that pertains to a quality concern that is not covered by functional requirements.
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.
In RE: A well-argued request for changing one or more baselined requirements.
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.

39. Standard
A discrepancy between an observed behavior or result and the specified behavior or result. An error typically is a symptom for the existence of a fault or defect in some artifact. In colloquial English - there is sometimes no distinction between the
The 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 uniform regulation for perceiving - manufacturing or executing something.
A model describing a system in its context.

40. State charts
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.
State machines having states that are hierarchically and/or orthogonally decomposed.
A tabular - systematic representation of a complex decision that depends on multiple criteria.
A spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.

41. System
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
Abbreviation for Unified Modeling Language - a standardized language for modeling problems or solutions.
A verb characterizing the required action in a requirement written in natural language.
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

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

43. Entity
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 state machine with atomic states.
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 a requirement expresses the stakeholders' true desires and needs (i.e. - those they had actually in mind when stating the requirement).

44. Application domain
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 (software) system that helps develop - operate and maintain systems. In RE - tools support requirements management as well as modeling - documenting - and validating requirements.
Those parts of the real world that are relevant for determining the context of a system.
A diagrammatic representation of a class model.

45. 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.
A person or organization who delivers a product or service to a customer.
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 the fulfillment of a requirement by an implemented system can be checked - e.g. - by defining acceptance test cases - measurements or inspection procedures.

46. Phrase template
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 model that represents the goals of something as an ordered structure of sub-goals.
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.
A template for the syntactic structure of a phrase that expresses an individual requirement in natural language

47. Supplier
A person or organization who delivers a product or service to a customer.
An intermediate or final result of system development; for example - a requirements specification.
Traceability of a requirement back to its origin.
Abbreviation for Unified Modeling Language - a standardized language for modeling problems or solutions.

48. Class
A model consisting of a set of classes and relationships between them.
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.
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

49. Use case

50. Completeness (of requirements)
The range of things that can be shaped and designed when developing 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
A configuration that has been released for installation and use by customers.
1. A diagrammatic representation of a context model. 2. In Structured Analysis - the context diagram is the root of the data flow diagram hierarchy.