GoConqr has a new look! Let us know what you think.

Flashcards

IREB Glossar

Deleted user User has deleted their subject information English 20 cards

Cards in this deck (20)

  1. 1Acceptance criteria, Abnahmekriterien, auch: AkzeptanzkriterienIn 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.
  2. 2Requirements negotiation, Abstimmung von Anforderungen (auch: Verhandlung von Anforderungen)A ↑process where ↑stakeholders are working toward reaching an agreement to resolve ↑requirements conflicts.
  3. 3AdequacyThe 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).
  4. 4Agile1. 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.
  5. 5ActorA 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.
  6. 6Activity diagramA 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.
  7. 7Activity modelA ↑model of the flow of actions in some part of a ↑system.
  8. 8ModifiabilityThe degree to which a ↑work product or ↑system can be modified without degrading its ↑quality.
  9. 9Change requestIn RE: A well-argued request for changing one or more ↑baselined ↑requirements.
  10. 10Change control boardA 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.
  11. 11Change managementA controlled way to effect or deny a requested change of a ↑work product.
  12. 12Requirement1. 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.
  13. 13Kind of requirementA 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.
  14. 14Requirements documentA document consisting of a ↑requirements specification.
    Note: Requirements document is frequently used as a synonym for requirements specification.
  15. 15Requirements elicitation, AnforderungsermittlungThe process of seeking, capturing and consolidating ↑requirements from available ↑sources, potentially including the re-construction or creation of requirements.
  16. 16Requirements conflict1. 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.
  17. 17Requirements managementThe process of managing existing ↑requirements and requirements-related ↑work products, including the storing, changing and tracing of requirements (↑traceability).
  18. 18Requirements sourceThe source from which a ↑requirement has been derived.
    Note: Typical sources are ↑stakeholders, documents, existing ↑systems and observations.
  19. 19Requirements specificationA 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.
  20. 20Requirements templateA 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.

Information

Description
User has deleted their subject information Flashcards on IREB Glossar, created by Deleted user on 23/02/2021.
Created by
Deleted user · Feb 2021
Updated
Feb 23, 2021
Views
11
Tags
ireb
History
  • Created by Georg Benhöfer · Feb 22, 2021
  • Copied by Georg Benhöfer · Feb 23, 2021
Rating

Feedback

What is it about?

What do you think of the new look?

How do you like it?