28964721
Description
Flashcards by Georg Benhöfer, updated more than 1 year ago
|
Created by Georg Benhöfer
about 3 years ago
|
|
| Question | Answer |
| Acceptance criteria, Abnahmekriterien, auch: Akzeptanzkriterien | In agile: Criteria that the implementation of a ↑user story must satisfy in order to be accepted by the ↑stakeholders. Note: Acceptance criteria may also be written for ↑backlog items other than user stories. |
| Requirements negotiation, Abstimmung von Anforderungen (auch: Verhandlung von Anforderungen) | A ↑process where ↑stakeholders are working toward reaching an agreement to resolve ↑requirements conflicts. |
| Adequacy | The degree to which a ↑requirement expresses the ↑stakeholders' true and agreed desires and needs (i.e., those they had actually in mind when stating the requirement). |
| Agile | 1. In general: (a) Able to move quickly and easily. (b) Quick, smart, and clever. 2. In software development: A development approach which builds a product ↑incrementally by dividing work into ↑iterations of fixed duration (↑timeboxes). Note: Agile development is characterized by focusing on delivering a working product in each iteration, collaboration with ↑stakeholders with frequent feedback and adaptation of plans after each iteration based on feedback and changed ↑requirements. |
| Actor | A person in some ↑role, a ↑system or a technical device in the context of a subject under consideration that interacts with that subject. Note: In RE, the subject under consideration typically is a ↑system. In testing, it may be a test ↑object. |
| Activity diagram | A diagram type in ↑UML which models the flow of actions in some part of a ↑system, including ↑data flows and areas of responsibility where necessary. |
| Activity model | A ↑model of the flow of actions in some part of a ↑system. |
| Modifiability | The degree to which a ↑work product or ↑system can be modified without degrading its ↑quality. |
| Change request | In RE: A well-argued request for changing one or more ↑baselined ↑requirements. |
| Change control board | A committee of ↑customer and ↑supplier representatives that decides on ↑change requests. Abbreviation: CCB Note: The Change control board should not be confused with a change advisory board, which is a committee that evaluates change requests for a ↑system in operation and typically has no decision power. |
| Change management | A controlled way to effect or deny a requested change of a ↑work product. |
| Requirement | 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. |
| Kind of requirement | A classification of requirements according to their kind into ↑system requirements (consisting of ↑functional requirements, ↑quality requirements and ↑constraints), project requirements, and process requirements. Notes: 1. RE is primarily concerned with system requirements. 2. Quality requirements and constraints are also called ↑non-functional requirements. |
| Requirements document | A document consisting of a ↑requirements specification. Note: Requirements document is frequently used as a synonym for requirements specification. |
| Requirements elicitation, Anforderungsermittlung | The process of seeking, capturing and consolidating ↑requirements from available ↑sources, potentially including the re-construction or creation of requirements. |
| Requirements conflict | 1. A situation where two or more ↑requirements cannot be satisfied together. 2. A situation where two or more ↑stakeholders disagree about certain ↑requirements. Note: Requirements conflicts have to be solved by ↑requirements negotiation. |
| Requirements management | The process of managing existing ↑requirements and requirements-related ↑work products, including the storing, changing and tracing of requirements (↑traceability). |
| Requirements source | The source from which a ↑requirement has been derived. Note: Typical sources are ↑stakeholders, documents, existing ↑systems and observations. |
| Requirements specification | A systematically represented collection of ↑requirements, typically for a ↑system, that satisfies given criteria. Notes: 1. In some situations we distinguish between a ↑customer requirements specification (typically written by the ↑customer) and a ↑system requirements specification or ↑software requirements specification (written by the supplier). 2. Requirements specification may also denote the ↑process of specifying (↑eliciting, documenting and ↑validating) requirements. |
| Requirements template | A template for specifying ↑requirements. Note: In RE, several forms of templates are used. ↑Phrase templates are used for specifying individual ↑requirements or ↑user stories. ↑Form templates can be used to specify ↑use cases or ↑quality requirements. ↑Document templates provide a predefined structure for ↑requirements documents. |
Want to create your own Flashcards for free with GoConqr? Learn more.