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. Statechart
A state machine having states that are hierarchically and/or orthogonally decomposed.
A range of relevant things (for some given matter); for example - an application domain.
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
Requirements source
2. Scenario
Documents the importance of a requirement in comparison to other requirements according to given criteria.
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
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.
The degree to which a requirements specification conforms to regulations given in some standard.
3. Entity-relationship model
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 process of checking whether documented requirements match the stakeholders' needs.
User.
A model that represents the goals of something as an ordered structure of sub-goals.
4. Fault
Defect.
The degree to which a requirements specification conforms to regulations given in some 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.
A committee of client and supplier representatives that decides on change requests. Abbreviation: CCB
5. Model
A verb characterizing the required action in a requirement written in natural language.
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 requirements specification conforms to regulations given in some standard.
An abstract representation of an existing reality or a reality to be created.
6. State charts
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 baseline for a set of requirements.
Defect.
State machines having states that are hierarchically and/or orthogonally decomposed.
7. Attribute
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 process of assessing whether a system satisfies all its requirements.
A characteristic property of an entity.
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
8. Effectiveness
9. Class model
A model consisting of a set of classes and relationships between them.
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 committee that supervises a project.
The boundary between a system and its surrounding context.It separates the system to be developed from its environment; i.e. - it separates the part of the reality that can be modified or altered by the development process from aspects of the environ
10. Kind of requirement
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.
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).
The process of checking whether documented requirements match the stakeholders' needs.
11. Redundancy
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
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
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.
Multiple occurrence of the same information or resource.
12. Defect
A spot in an artifact that is incorrectly described or crafted. Synonym: fault - bug.
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 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
Documents the importance of a requirement in comparison to other requirements according to given criteria.
13. Priority (of a requirement)
Documents the importance of a requirement in comparison to other requirements according to given criteria.
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 degree to which a requirement is expressed such that it cannot be understood differently by different people.
Requirements elicitation
14. Sequence diagram
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 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 receives a product or service. Also see stakeholder.
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
15. System boundary
The boundary between a system and its surrounding context.It separates the system to be developed from its environment; i.e. - it separates the part of the reality that can be modified or altered by the development process from aspects of the environ
The 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
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.
16. Checking (requirements)
A characteristic property of an entity.
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.
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
Comprises requirements validation and checking requirements for qualities such as unambiguity or comprehensibility.
17. Customer
A person or organization who receives a product or service. Also see stakeholder.
A coarse description of the required capabilities of a system from the customer's perspective. Usually supplied by the customer.
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 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.
18. Class
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.
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 state machine with atomic states.
A desired state of affairs (that a stakeholder wants to achieve). Goals describe intentions of stakeholders. They may conflict with one another.
19. Stakeholder
20. Context model
A committee of client and supplier representatives that decides on change requests. Abbreviation: CCB
In RE: A well-argued request for changing one or more baselined requirements.
A model describing a system in its context.
A state machine having states that are hierarchically and/or orthogonally decomposed.
21. Entity
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
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 degree to which a requirement expresses the stakeholders' true desires and needs (i.e. - those they had actually in mind when stating the requirement).
22. Requirements specification
A uniform regulation for perceiving - manufacturing or executing something.
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 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 requirement pertaining to a system or to a component of a system.
23. 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.
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 range of things that can be shaped and designed when developing a system.
The degree to which a result is achieved with minimum consumption of resources.
24. Semantics
The meaning of a sign or a set of signs in a language.
A template for the syntactic structure of a phrase that expresses an individual requirement in natural language
A state machine with atomic states.
A person or organization who receives a product or service. Also see stakeholder.
25. Conformity (of requirements)
A model describing the behavior of a system or component - e.g. - by a state machine.
The degree to which a requirements specification conforms to regulations given in some standard.
Defect
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.
26. Language
The process of managing existing requirements and requirements related artifacts. Includes particularly storing - changing and tracing of requirements traceability).
A requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service).
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.
Abbreviation for Unified Modeling Language - a standardized language for modeling problems or solutions.
27. Quality requirement
A formally organized endeavor for checking an artifact by a group of experts. Checking may be performed with respect to both contents and conformance.
A person who - in collaboration with stakeholders - elicits - documents - validates - and manages requirements.
A requirement that pertains to a quality concern that is not covered by functional requirements.
State machines having states that are hierarchically and/or orthogonally decomposed.
28. Requirements engineering (RE)
An intermediate or final result of system development; for example - a requirements specification.
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 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
Requirements elicitation.
29. Requirement (original IEEE definition)
The rules for constructing structured signs in a language.
A collection of definitions of terms that are relevant in some domain. Frequently - a glossary also contains cross-references - synonyms - homonyms - acronyms - and abbreviations.
A characteristic property of an entity.
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
30. Acceptance
A requirement that limits the solution space beyond what is necessary for meeting the given functional requirements and quality requirements.
The capability of a system to be understood - learned - used - and liked by its users. Usability (or parts thereof) may be stated as quality requirements.
The process of assessing whether a system satisfies all its requirements.
A range of relevant things (for some given matter); for example - an application domain.
31. Review
A requirements specification pertaining to a software system. Abbreviation: SRS
A diagrammatic representation of a class model.
A requirement that limits the solution space beyond what is necessary for meeting the given functional requirements and quality requirements.
A formally organized endeavor for checking an artifact by a group of experts. Checking may be performed with respect to both contents and conformance.
32. Use case diagram
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 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.
The range of things that can be shaped and designed when developing a system.
Abbreviation for Unified Modeling Language - a standardized language for modeling problems or solutions.
33. Prototype
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.
The degree to which an artifact enables a required modification of the artifact.
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. Specification language
An artificial language that has been created for expressing specifications.
Requirements elicitation
A model describing a system in its context.
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
35. Requirements discovery
A uniform regulation for perceiving - manufacturing or executing something.
Requirements elicitation
A graphic representation of an entity-relationship model. Abbreviation: ERD
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.
36. Requirements analysis
A requirement that pertains to a quality concern that is not covered by 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
1. Analysis of elicited requirements in order to understand and document them. 2. Synonym for requirements engineering.
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
37. Context boundary
Boundary between the context of a system and those parts of the application domain that are irrelevant for the system and its requirements. It separates the relevant part of the environment of a system to be developed from the irrelevant part - i.e.
A model consisting of a set of classes and relationships between them.
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 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.
38. Safety
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 graphic representation of an entity-relationship model. Abbreviation: ERD
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 ease with which a system can be transferred to another platform (while preserving its functionality). Portability may be stated as a quality requirement.
39. Domain
A range of relevant things (for some given matter); for example - an application domain.
A requirement pertaining to a system or to a component of 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
The capability of a system to protect (a) its data and resources against unauthorized use and (b) its legitimate users against denial of service.
40. Finite state automaton
A model that has been created with the purpose of specifying requirements.
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 configuration that has been released for installation and use by customers.
A state machine with atomic states.
41. Version (of an entity)
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 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 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.
42. Goal
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.
A desired state of affairs (that a stakeholder wants to achieve). Goals describe intentions of stakeholders. They may conflict with one another.
A uniform regulation for perceiving - manufacturing or executing something.
The process of seeking - capturing and consolidating requirements from available requirements sources. May include the re-construction or creation of requirements. Aka Requirements discovery
43. Requirements elicitation
A person or organization who receives a product or service. Also see stakeholder.
A document consisting of a requirements specification. Frequently used as a synonym for requirements specification.
The process of seeking - capturing and consolidating requirements from available requirements sources. May include the re-construction or creation of requirements. Aka Requirements discovery
An excerpt from an artifact - containing only those parts one is currently interested in. A view can abstract or aggregate parts of the artifact.
44. Scope (of a system)
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.
The range of things that can be shaped and designed when developing a system.
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 person or organization who receives a product or service. Also see stakeholder.
45. Class diagram
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 result is achieved with minimum consumption of resources.
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 diagrammatic representation of a class model.
46. 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 process of seeking - capturing and consolidating requirements from available requirements sources. May include the re-construction or creation of requirements. Aka Requirements discovery
(1) process- orientation - (2) stakeholder focus - and (3) importance of risk and value considerations.
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
47. Component
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 tabular - systematic representation of a complex decision that depends on multiple criteria.
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.
An artificial language that has been created for expressing specifications.
48. Change request
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.
In RE: A well-argued request for changing one or more baselined requirements.
A model that represents the goals of something as an ordered structure of sub-goals.
Abbreviation for Unified Modeling Language - a standardized language for modeling problems or solutions.
49. Behavior Model
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.
1. In manufacturing: a piece which is built prior to the start of mass production. 2. In software engineering: An executable piece of software that implements critical parts of a system in advance. In Requirements Engineering - prototypes are used as
The capabilities of a system as stated by its functional requirements.
50. Artifact
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.
A language for expressing models of a certain kind. May be textual - graphic - symbolic or some combination thereof.
A model describing the behavior of a system or component - e.g. - by a state machine.