SUBJECTS
|
BROWSE
|
CAREER CENTER
|
POPULAR
|
JOIN
|
LOGIN
Business Skills
|
Soft Skills
|
Basic Literacy
|
Certifications
About
|
Help
|
Privacy
|
Terms
|
Email
Search
Test your basic knowledge |
CPRE: Certified Professional Requirements Engineering
Start Test
Study First
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. Quality
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
A uniform regulation for perceiving - manufacturing or executing something.
A range of relevant things (for some given matter); for example - an application domain.
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.
2. Change control board
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 maintain a specified level of functionality and performance when used under specified conditions. Reliability may be stated as a quality requirement.
A committee that supervises a project.
A committee of client and supplier representatives that decides on change requests. Abbreviation: CCB
3. 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.
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
Requirements elicitation
A model consisting of a set of classes and relationships between them.
4. Semantics
The meaning of a sign or a set of signs in a 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.
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
Requirements elicitation.
5. Error
A requirement pertaining to a system or to a component of a system.
The capabilities of a system as stated by its 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
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.
6. Artifact
An intermediate or final result of system development; for example - a requirements specification.
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.
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 test that assesses whether a system satisfies all its requirements.
7. Pre-RS traceability
State machines having states that are hierarchically and/or orthogonally decomposed.
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
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.
Traceability of a requirement back to its origin.
8. System requirements specification
The capabilities of a system as stated by its functional requirements.
Those parts of the real world that are relevant for determining the context of a system.
A range of relevant things (for some given matter); for example - an application domain.
A requirements specification pertaining to a system. Frequently considered to be a synonym for requirements specification.
9. User
A model consisting of a set of classes and relationships between them.
Traceability of a requirement back to its origin.
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 person who uses the functionality provided by a system. Also called end user.
10. Maintainability
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 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 diagrammatic representation of a class model.
A test that assesses whether a system satisfies all its requirements.
11. Entity-relationship diagram
An artificial language that has been created for expressing specifications.
A graphic representation of an entity-relationship model. Abbreviation: ERD
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 test that assesses whether a system satisfies all its requirements.
12. Kind of requirement
A coarse description of the required capabilities of a system from the customer's perspective. Usually supplied by the customer.
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).
1. A diagrammatic representation of a context model. 2. In Structured Analysis - the context diagram is the root of the data flow diagram hierarchy.
13. 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).
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 requirement that limits the solution space beyond what is necessary for meeting the given functional requirements and quality requirements.
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.
14. Important facets of RE
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.
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. In general: The network of thoughts and meanings needed for understanding phenomena or utterances. 2. Especially in RE: The part of a system's environment being relevant for understanding the system and its requirements. Context in the second mea
A test that assesses whether a system satisfies all its requirements.
15. Version (of an entity)
A model describing the behavior of a system or component - e.g. - by a state machine.
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.
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.
16. Glossary
The process of checking whether documented requirements match the stakeholders' needs.
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 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 collection of definitions of terms that are relevant in some domain. Frequently - a glossary also contains cross-references - synonyms - homonyms - acronyms - and abbreviations.
17. Application domain
Those parts of the real world that are relevant for determining the context of a system.
The part of a system's environment that is relevant for the definition as well as the understanding of the requirements of a system to be developed.
A 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 (software) system that helps develop - operate and maintain systems. In RE - tools support requirements management as well as modeling - documenting - and validating requirements.
18. Changeability (of an artifact)
In RE: A well-argued request for changing one or more baselined requirements.
The capabilities of a system as stated by its functional requirements.
A graphic representation of an entity-relationship model. Abbreviation: ERD
The degree to which an artifact enables a required modification of the artifact.
19. Traceability (of requirements)
The ability to trace a requirement (1) back to its origins - (2) forward to its implementation in design and code - (3) to requirements it depends on (and vice-versa). Origins may be stakeholders - documents - rationale - etc. Sometimes - traceabilit
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 model describing the behavior of a system or component - e.g. - by a state machine.
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.
20. Reliability
A template for the syntactic structure of a phrase that expresses an individual requirement in natural language
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.
The degree to which a set of requirements is free of contradicting statements.
A tabular - systematic representation of a complex decision that depends on multiple criteria.
21. Behavior Model
A requirements specification pertaining to a system. Frequently considered to be a synonym for requirements specification.
A model describing the behavior of a system or component - e.g. - by a state machine.
A language for expressing models of a certain kind. May be textual - graphic - symbolic or some combination thereof.
A model consisting of a set of classes and relationships between them.
22. Semi-formal
23. Specification
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 information contained in an artifact is probably true. In RE - correctness is frequently used as a synonym for adequacy.
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 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
24. 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.
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 uniform regulation for perceiving - manufacturing or executing something.
An intermediate or final result of system development; for example - a requirements specification.
25. Structured analysis
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
There are several kinds of requirements. Requirements Engineering is primarily concerned with system requirements. Beyond that - there are project requirements and process requirements. Requirements are typically sub-classified into functional requir
A range of relevant things (for some given matter); for example - an application domain.
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
26. Prototype
A model describing the behavior of a system or component - e.g. - by a state machine.
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 spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
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
27. Walkthrough
28. System boundary
A language for expressing models of a certain kind. May be textual - graphic - symbolic or some combination thereof.
The degree to which a result is achieved with minimum consumption of resources.
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 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
29. Adequacy (of a requirement)
30. End user
The source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.
User.
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 configuration that has been released for installation and use by customers.
31. State charts
A requirement that limits the solution space beyond what is necessary for meeting the given functional requirements and quality requirements.
Requirements source
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
State machines having states that are hierarchically and/or orthogonally decomposed.
32. Finite state automaton
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 requirement pertaining to a system or to a component of a system.
A requirement that pertains to a quality concern that is not covered by functional requirements.
A state machine with atomic states.
33. Requirements templates
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 blueprint for the syntactic structure of individual requirements.A phrase template is a specific requirements template for requirements written in natural language.
A baseline for a set of requirements.
Defect.
34. Requirements analysis
Requirements elicitation.
A requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).
1. Analysis of elicited requirements in order to understand and document them. 2. Synonym for requirements engineering.
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
35. Fault tolerance
A person or organization who receives a product or service. Also see stakeholder.
1. In general: A principle for ordering and structuring. 2. In Informatics: A coherent - delimitable set of components that - by coordinated action - provides services. Requirements Engineering is concerned with the specification of requirements for
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 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
36. Class
Those parts of the real world that are relevant for determining the context of a system.
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 committee of client and supplier representatives that decides on change requests. Abbreviation: CCB
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
37. Effectiveness
38. Requirements engineer
The degree to which a requirement is expressed such that it cannot be understood differently by different people.
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 excerpt from an artifact - containing only those parts one is currently interested in. A view can abstract or aggregate parts of the artifact.
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.
39. Class diagram
The degree to which the information contained in an artifact is probably true. In RE - correctness is frequently used as a synonym for adequacy.
A diagrammatic representation of a class model.
The process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).
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
40. Goal model
A model that represents the goals of something as an ordered structure of sub-goals.
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 model consisting of a set of classes and relationships between them.
Cardinality.
41. Validation (of requirements)
42. Checking (requirements)
An intermediate or final result of system development; for example - a requirements specification.
A spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.
A committee that supervises a project.
43. Entity
A uniform regulation for perceiving - manufacturing or executing something.
A blueprint for the syntactic structure of individual requirements.A phrase template is a specific requirements template for requirements 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
State machines having states that are hierarchically and/or orthogonally decomposed.
44. Risk
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
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 person who - in collaboration with stakeholders - elicits - documents - validates - and manages 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. Acceptance
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.
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.
Multiple occurrence of the same information or resource.
The process of assessing whether a system satisfies all its requirements.
46. Unambiguity (of 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
The degree to which a requirement is expressed such that it cannot be understood differently by different people.
A state machine having states that are hierarchically and/or orthogonally decomposed.
A model describing a system in its context.
47. Requirements specification
A person or organization who receives a product or service. Also see stakeholder.
A person or organization who delivers a product or service to a customer.
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 model describing the behavior of a system or component - e.g. - by a state machine.
48. View
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
Cardinality.
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.
An excerpt from an artifact - containing only those parts one is currently interested in. A view can abstract or aggregate parts of the artifact.
49. Statechart
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 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 state machine having states that are hierarchically and/or orthogonally decomposed.
State machines having states that are hierarchically and/or orthogonally decomposed.
50. Security
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
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 capability of a system to protect (a) its data and resources against unauthorized use and (b) its legitimate users against denial of service.