SUBJECTS
|
BROWSE
|
CAREER CENTER
|
POPULAR
|
JOIN
|
LOGIN
Business Skills
|
Soft Skills
|
Basic Literacy
|
Certifications
About
|
Help
|
Privacy
|
Terms
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. Conformity (of requirements)
A blueprint for the syntactic structure of individual requirements.A phrase template is a specific requirements template for requirements written in natural language.
The degree to which a requirements specification conforms to regulations given in some standard.
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.
Defect
2. Non-functional requirement
A spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
A coarse description of the required capabilities of a system from the customer's perspective. Usually supplied by the customer.
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 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
3. Goal
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
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 desired state of affairs (that a stakeholder wants to achieve). Goals describe intentions of stakeholders. They may conflict with one another.
A test that assesses whether a system satisfies all its requirements.
4. Change control board
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 diagrammatic representation of a class model.
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 committee of client and supplier representatives that decides on change requests. Abbreviation: CCB
5. Goal model
A model that represents the goals of something as an ordered structure of sub-goals.
A uniform regulation for perceiving - manufacturing or executing something.
A requirement pertaining to a system or to a component of a system.
A requirements specification pertaining to a software system. Abbreviation: SRS
6. Requirement (modern definition)
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.
An intermediate or final result of system development; for example - a requirements specification.
Requirements source
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
7. Requirements templates
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 blueprint for the syntactic structure of individual requirements.A phrase template is a specific requirements template for requirements written in natural language.
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 person or organization who delivers a product or service to a customer.
8. Structured analysis
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.
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
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.
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.
9. Standard
A desired state of affairs (that a stakeholder wants to achieve). Goals describe intentions of stakeholders. They may conflict with one another.
A characteristic property of an entity.
A model consisting of a set of classes and relationships between them.
A uniform regulation for perceiving - manufacturing or executing something.
10. Behavior Model
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 model describing the behavior of a system or component - e.g. - by a state machine.
User.
Defect.
11. Important facets of RE
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.
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 author of an artifact under review walks a group of experts systematically through the artifact. The experts' findings are then collected and consolidated.
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
12. Homonym
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 blueprint for the syntactic structure of individual requirements.A phrase template is a specific requirements template for requirements written in natural language.
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 uniform regulation for perceiving - manufacturing or executing something.
13. Statechart
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 committee of client and supplier representatives that decides on change requests. Abbreviation: CCB
A person or organization who delivers a product or service to a customer.
A state machine having states that are hierarchically and/or orthogonally decomposed.
14. System
The degree to which a set of requirements is free of contradicting statements.
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. 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 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
15. Checking (requirements)
A verb characterizing the required action in a requirement written in natural language.
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
A requirement that limits the solution space beyond what is necessary for meeting the given functional requirements and quality requirements.
16. Requirements management
A requirement that pertains to a quality concern that is not covered by functional requirements.
A verb characterizing the required action in a requirement written in natural language.
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. Functionality
A characteristic property of an entity.
The capabilities of a system as stated by its functional requirements.
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
The degree to which a requirement is expressed such that it cannot be understood differently by different people.
18. Pre-RS traceability
Traceability of a requirement back to its origin.
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.
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 state machine with atomic states.
19. Portability
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 requirement expresses the stakeholders' true desires and needs (i.e. - those they had actually in mind when stating the requirement).
The degree to which a set of requirements is free of contradicting statements.
The ease with which a system can be transferred to another platform (while preserving its functionality). Portability may be stated as a quality requirement.
20. Context diagram
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 desired state of affairs (that a stakeholder wants to achieve). Goals describe intentions of stakeholders. They may conflict with one another.
State machines having states that are hierarchically and/or orthogonally decomposed.
A model describing the behavior of a system or component - e.g. - by a state machine.
21. Quality requirement
A requirement that pertains to a quality concern that is not covered by functional requirements.
A requirement describing a performance characteristic (timing - speed - volume - capacity - throughput...). Is regarded in this glossary as a sub-category of quality requirements - but can also be considered as a non-functional requirements category
The rules for constructing structured signs in a language.
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
22. Correctness
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 capabilities of a system as stated by its functional requirements.
Cardinality.
The degree to which a requirements specification conforms to regulations given in some standard.
23. Version (of an entity)
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 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.
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 committee of client and supplier representatives that decides on change requests. Abbreviation: CCB
24. Change request
A person or organization who delivers a product or service to a customer.
A requirements specification pertaining to a system. Frequently considered to be a synonym for requirements specification.
In RE: A well-argued request for changing one or more baselined requirements.
A state machine having states that are hierarchically and/or orthogonally decomposed.
25. Use case
26. Requirements source
The source from which a requirement has been derived. Typical sources are stakeholders - documents - existing systems and observations.
A desired state of affairs (that a stakeholder wants to achieve). Goals describe intentions of stakeholders. They may conflict with one another.
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.
27. Domain
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 range of relevant things (for some given matter); for example - an application domain.
A state machine having states that are hierarchically and/or orthogonally decomposed.
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
28. Finite state automaton
A state machine with atomic states.
An abstract representation of an existing reality or a reality to be created.
Something which is formal to some extent - but not completely. An artifact is called semi-formal if it contains formal parts - but isn't formalized totally. Typically - a semi-formal artifact has a defined syntax - while the semantics is partially de
The 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
29. Requirement (original IEEE definition)
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 formally organized endeavor for checking an artifact by a group of experts. Checking may be performed with respect to both contents and conformance.
1. A condition or capability needed by a user to solve a problem or achieve an objective 2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract - standard - specification - or other formally i
1. In general: an element or set of elements that may stand for any conceivable item - e.g. - a system - a part of reality - a thing - an organization - a process - etc. 2. In entity-relationship-modeling: an individual object which has an identity a
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.
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.
The degree to which a result is achieved with minimum consumption of resources.
1. Analysis of elicited requirements in order to understand and document them. 2. Synonym for requirements engineering.
31. End user
User.
A collection of definitions of terms that are relevant in some domain. Frequently - a glossary also contains cross-references - synonyms - homonyms - acronyms - and abbreviations.
The degree to which a result is achieved with minimum consumption of resources.
A test that assesses whether a system satisfies all its requirements.
32. Maintainability
An intermediate or final result of system development; for example - a requirements specification.
Requirements source
Cardinality.
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
33. Software requirements specification
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 requirements specification pertaining to a software system. Abbreviation: SRS
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
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).
34. Error
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 model that represents the goals of something as an ordered structure of sub-goals.
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 degree to which a requirement is expressed such that it cannot be understood differently by different people.
35. Fault
A template for the syntactic structure of a phrase that expresses an individual requirement in natural language
Defect.
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
A range of relevant things (for some given matter); for example - an application domain.
36. Redundancy
A model describing a system in its context.
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.
Multiple occurrence of the same information or resource.
The rules for constructing structured signs in a language.
37. UML
The process of seeking - capturing and consolidating requirements from available requirements sources. May include the re-construction or creation of requirements. Aka Requirements discovery
The process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).
Those parts of the real world that are relevant for determining the context of a system.
Abbreviation for Unified Modeling Language - a standardized language for modeling problems or solutions.
38. Risk
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 language for expressing models of a certain kind. May be textual - graphic - symbolic or some combination thereof.
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 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
39. Context
40. Efficiency
A baseline for a set of requirements.
The process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).
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 degree to which a result is achieved with minimum consumption of resources.
41. Requirements model
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 model that has been created with the purpose of specifying requirements.
In RE: A well-argued request for changing one or more baselined 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
42. Entity-relationship model
Cardinality.
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
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.
User.
43. Reliability
A template for the syntactic structure of a phrase that expresses an individual requirement in natural language
An abstract representation of an existing reality or a reality to be created.
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 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.
44. Verifiability (of requirements)
The degree to which the fulfillment of a requirement by an implemented system can be checked - e.g. - by defining acceptance test cases - measurements or inspection procedures.
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
Requirements elicitation.
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
45. Artifact
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
1. A diagrammatic representation of a context model. 2. In Structured Analysis - the context diagram is the root of the data flow diagram hierarchy.
An intermediate or final result of system development; for example - a requirements specification.
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
46. Process verb
A verb characterizing the required action in a requirement written in natural language.
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 committee of client and supplier representatives that decides on change requests. Abbreviation: CCB
A baseline for a set of requirements.
47. Requirements engineer
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 person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.
The process of seeking - capturing and consolidating requirements from available requirements sources. May include the re-construction or creation of requirements. Aka Requirements discovery
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.
48. Application domain
A requirement pertaining to a system or to a component of a system.
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.
Those parts of the real world that are relevant for determining the context of a system.
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.
49. Inspection
50. Multiplicity
A graphic representation of an entity-relationship model. Abbreviation: ERD
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 configuration that has been released for installation and use by customers.
Cardinality.