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. Walkthrough

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

2. Requirements specification
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 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.
A range of relevant things (for some given matter); for example - an application domain.

3. Requirements engineering (RE)
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 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
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 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

4. Software requirements specification
A requirements specification pertaining to a software system. Abbreviation: SRS
A diagrammatic representation of a state machine.
1. A diagrammatic representation of a context model. 2. In Structured Analysis - the context diagram is the root of the data flow diagram hierarchy.
In RE: A well-argued request for changing one or more baselined requirements.

5. Sequence diagram
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 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 rules for constructing structured signs in a language.
A requirements specification pertaining to a software system. Abbreviation: SRS

6. Requirements management
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.
The process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).
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) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.

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

8. Statechart
The process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).
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.
A state machine having states that are hierarchically and/or orthogonally decomposed.
User.

9. Requirements source
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.
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 source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.

10. Customer requirements specification

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

11. Elicitation (of requirements)
A diagrammatic representation of a state machine.
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 degree to which a requirement expresses the stakeholders' true desires and needs (i.e. - those they had actually in mind when stating the requirement).
Requirements elicitation.

12. Requirements elicitation
A spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
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 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 assessing whether a system satisfies all its requirements.

13. Change control board
The source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.
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 committee of client and supplier representatives that decides on change requests. Abbreviation: CCB
1. A diagrammatic representation of a context model. 2. In Structured Analysis - the context diagram is the root of the data flow diagram hierarchy.

14. Consistency (of requirements)
The degree to which a requirement is expressed such that it cannot be understood differently by different people.
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 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 set of requirements is free of contradicting statements.

15. Security
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.
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 degree to which the information contained in an artifact is probably true. In RE - correctness is frequently used as a synonym for adequacy.
The capability of a system to protect (a) its data and resources against unauthorized use and (b) its legitimate users against denial of service.

16. Specification language
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. 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
An artificial language that has been created for expressing specifications.
A requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).

17. Source (of a requirement)
A requirements specification pertaining to a software system. Abbreviation: SRS
Requirements source
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 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

18. Goal model
Documents the importance of a requirement in comparison to other requirements according to given criteria.
A model that represents the goals of something as an ordered structure of sub-goals.
User.
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

19. Stakeholder

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

20. Bug
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 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 requirements specification pertaining to a software system. Abbreviation: SRS

21. UML
The capability of a system to protect (a) its data and resources against unauthorized use and (b) its legitimate users against denial of service.
Abbreviation for Unified Modeling Language - a standardized language for modeling problems or solutions.
Something which is formal to some extent - but not completely. An artifact is called semi-formal if it contains formal parts - but isn't formalized totally. Typically - a semi-formal artifact has a defined syntax - while the semantics is partially de
An abstract representation of an existing reality or a reality to be created.

22. Redundancy
An excerpt from an artifact - containing only those parts one is currently interested in. A view can abstract or aggregate parts of the artifact.
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
Multiple occurrence of the same information or resource.

23. Requirements document
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
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.
In RE: A well-argued request for changing one or more baselined requirements.
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.

24. Model
An abstract representation of an existing reality or a reality to be created.
A uniform regulation for perceiving - manufacturing or executing something.
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.
Cardinality.

25. Activity diagram
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 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 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.
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.

26. Steering committee
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.
A characteristic property of an entity.
A committee that supervises a project.
The rules for constructing structured signs in a language.

27. 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.
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 who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.
A collection of definitions of terms that are relevant in some domain. Frequently - a glossary also contains cross-references - synonyms - homonyms - acronyms - and abbreviations.

28. Defect
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 meaning of a sign or a set of signs in a language.
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 spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.

29. Requirements analysis
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.
1. Analysis of elicited requirements in order to understand and document them. 2. Synonym for requirements engineering.
An excerpt from an artifact - containing only those parts one is currently interested in. A view can abstract or aggregate parts of the artifact.

30. Requirement (modern definition)
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.
Requirements elicitation
A model describing the behavior of a system or component - e.g. - by a state machine.
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.

31. Context model
The process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).
The rules for constructing structured signs in a language.
The degree to which the fulfillment of a requirement by an implemented system can be checked - e.g. - by defining acceptance test cases - measurements or inspection procedures.
A model describing a system in its context.

32. Language
A committee that supervises a project.
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 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.
Cardinality.

33. Artifact
An intermediate or final result of system development; for example - a requirements specification.
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 ease with which a system can be transferred to another platform (while preserving its functionality). Portability may be stated as a quality requirement.
A verb characterizing the required action in a requirement written in natural language.

34. Verifiability (of requirements)
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 be understood - learned - used - and liked by its users. Usability (or parts thereof) may be stated as quality requirements.
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
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.

35. Change request
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.
When viewed in isolation - a component is a system by itself. 1. In general: A delimitable part of a system. 2. In software architecture: An encapsulated set of coherent objects or classes that jointly provide a service.
A 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.
In RE: A well-argued request for changing one or more baselined requirements.

36. Post-RS traceability
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 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 forward to its implementation in design and code - RS stands for requirements specification.
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

37. Version (of an entity)
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 person or organization who receives a product or service. Also see stakeholder.
A uniform regulation for perceiving - manufacturing or executing something.
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

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

39. Semantics
Defect
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.
Multiple occurrence of the same information or resource.
The meaning of a sign or a set of signs in a language.

40. Standard
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 uniform regulation for perceiving - manufacturing or executing something.
A configuration that has been released for installation and use by customers.
The process of assessing whether a system satisfies all its requirements.

41. State machine
A diagrammatic representation of a class model.
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.
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

42. Class diagram
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 diagrammatic representation of a class model.
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.
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

43. Non-functional requirement
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 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
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
The process of assessing whether a system satisfies all its requirements.

44. Behavior Model
A range of relevant things (for some given matter); for example - an application domain.
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.
A committee of client and supplier representatives that decides on change requests. Abbreviation: CCB

45. Changeability (of an artifact)
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 model that represents the goals of something as an ordered structure of sub-goals.
The degree to which an artifact enables a required modification of the artifact.
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

46. State-transition diagram
When viewed in isolation - a component is a system by itself. 1. In general: A delimitable part of a system. 2. In software architecture: An encapsulated set of coherent objects or classes that jointly provide a service.
A diagrammatic representation of a state machine.
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.
Documents the importance of a requirement in comparison to other requirements according to given criteria.

47. Traceability (of requirements)
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 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 document consisting of a requirements specification. Frequently used as 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

48. Reliability
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.
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.
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.

49. Semi-formal

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

50. Scope (of a system)
A language for expressing models of a certain kind. May be textual - graphic - symbolic or some combination thereof.
The range of things that can be shaped and designed when developing a system.
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
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.