Samenvatting Requirements Engineering Fundamentals A Study Guide for the Certified Professional for Requirements Engineering Exam - Foundation Level - IREB compliant

ISBN-10 1457111926 ISBN-13 9781457111921
114 Flashcards en notities
4 Studenten
  • Deze samenvatting

  • +380.000 andere samenvattingen

  • Een unieke studietool

  • Een oefentool voor deze samenvatting

  • Studiecoaching met filmpjes

Onthoud sneller, leer beter. Wetenschappelijk bewezen.

Dit is de samenvatting van het boek "Requirements Engineering Fundamentals A Study Guide for the Certified Professional for Requirements Engineering Exam - Foundation Level - IREB compliant". De auteur(s) van het boek is/zijn Klaus Pohl Chris Rupp. Het ISBN van dit boek is 9781457111921 of 1457111926. Deze samenvatting is geschreven door studenten die effectief studeren met de studietool van Study Smart With Chris.

Samenvatting - Requirements Engineering Fundamentals A Study Guide for the Certified Professional for Requirements Engineering Exam - Foundation Level - IREB compliant

  • 1 Introduction and Foundations

  • Woordenlijst
    Adequacy = toereikendheid (v.e. requirement)
    Artifact = (tussen-)product, artefact
    Cardinality = Kardinaliteit (bet.: minimum and maximum number of objects in a relationship (In UML multiplicity).
    Compliance = naleving
    Conformity = conformiteit (bet.: the degree to which a req. spec. conforms to regulatios given in some standard;
    Homonym = homoniem (bet: 1 woord, meer betekenissen);
    Phrase template = Zin-sjabloon
    Portability = portabiliteit (bet.: The ease in which a system can be transferred to another platform (while preserving its functionality) Portability may be stated as a quality requirement;
    Process verb = proceswerkwoord (bet.: A verb characterizing the required action in a requirement written in natural language);
    Redundancy = Redundantie (bet.: mutiple occurrence of the same information or resource;
    Semantics = semantiek (bet.: the meaning of a sign or a set of signs in a language;
    Synonym = symoniem (bet.: a word having the same meaning as another word);
    Unambiguity = eenduidigheid (bet.: the degree to which a req. is expressed such that it cannot be understood differently by different people;
    Verifiability = verifieerbaarheid.
  • Begrippen
    Adequacy = Toereikendheid (v.e. requirement voor de stakeholders);
    Adjective = bijv.nmw.;
    Adverb = bijwoord;
    Alter = veranderen;
    Apprenticing = meelopen (bv stage);
    Applicable = toepasbaar;
    Artifact = Artefarct, (tussen-)product (bet.: an intermediate or final result of system development;
    Ascertain = vaststellen;
    Assumption = aanname;
    Abbreviation = afkorting;
    Acronym = letterwoord;
    Biases = vooringenomenheden;
    Cardinality = Kardinaliteit (bet.: the minimum and maximum number of objects in a relationship. (in UML multiplicity);
    Collateral = onderpand;
    Compliance = naleving (van formele regels, wetten);
    Comply = voldoen;
    Conformity = Conformiteit (bet.: the degree to which a requirement specification conforms to regulations given in some standard;
    Correctness = correctheid (bet.: in R.E. frequently use as a synonym for adequacy;
    Delineate = omlijnen;
    Depict = afbeelden;
    Elaborate = uitwijden;
    Elucidate = verduidelijken;
    Extensibility = uitbreidbaarheid;
    Homonym = homoniem (1 woord met meerdere betekenissen);
    Impose = forceren, opdringen;
    Mandatory = nodig, verplicht;
    Moderate = matigen;
    Modify = wijzigen, modificeren;
    Noun = zelfst.nmw.;
    Obligatory = verplicht;
    Pertain = passen, geschikt zijn;
    Phrase template = Zin-sjabloon;
    Pitfall = valkuil;
    Portability = portabiliteit (bet.: The ease with which a system can be transferred to another platform (quality req.);
    Process verb = proceswerkwoord (bet.: a verb characterizing the required action in a requirement written in natural language;
    Reconcile = harmoniseren, verzoenen;
    Redundancy = redundantie (bet.: multiple occurrence of the same information or resource);
    Semantics = semantiek (bet.: the meaning of a sign or a set of signs in a language);
    Spatial = ruimtelijk;
    Synonym = synoniem (bet.: a word having the same meaning as another word);
    Syntactic = syntactisch (volgens de regels van de grammatica);
    Unambiguity = eenduidigheid;
    Unbiased = onbevooroordeeld;
    Verifiability = verifieerbaarheid (the degree to which the fulfillment of a requirement by an implemented system can be checked);
    Viewpoint = gezichtspunt, perspectief.
  • What is a requirement
    1. A condition of capability needed by a user to solve a problem or achieve an objective;
    2. A condition of capability that must be met or possessed by a system component to satisfy a contract, standard, specification or other formally imposed documents;
    3. A documented representation of a condition of capability as in 1) or 2).
    (IEEE Std...)
  • @ Types of requirements?
    1. Functional requirements (What)
    2. Quality Requirements (How)
    3. Constraints (imposed on the system by the environment)

    2. and 3. are non-functional requirements

  • What are functional requirements?
    • A Functional Requirement is a requirement concerning a result or behaviour that shall be provided by a function of the system;
    • Functional requirements define what the system does to deliver the desired services to the user.

  • What are quality requirements?
    1. A quality requirement is a requirement that pertains to a quality concern that is not covered by functional requirements
    2. @ The desired qualities of the system, e.g. (ISO 25010):
    • Detailing functionalities (securaty, accurateness)
    • Reliability
    • Useability
    • Efficiency
    • Changeability
    • Portability
  • @ Characteristics of quality requirements
    Quality requirements are:
    • Mostly documented using natural language;
    • To be kept seperated from functional requirements;
    • Relation to other statements traceble;
    • Validation ensured by quantitative assertions;
    • Often made operational by transfermation into additional functionality
  • What is a constraint
    A constraint is a requirement that limits the solution space beyond what is necessary for meeting the given functional requirements and quality requirements.
  • @ Characteristics of constraints
    • Cannot be influenced by the stakeholders;
    • Imposed by the environment;
    • Not implemented but adhered to;
    • Limit the solution space during development;
    •  - the system to be developed;
    •  - the development itself

  • What is Requirement Engineering
    Requirements engineering is 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 according to given standards and managing them systematically;
    2. understanding and documenting the stakeholders desires and needs, then specifying and managing the requirements to minimize the risk of delivering a system that does not meet these desires and needs.
  • Why requirements engineering?
    Facts and figures from studies about software projects:
    • 60% of all errors originate during the phase of requirements engineering;
    • unclear, incomplete or missing requirements lead to systems that fail to fulfil the needs of the user;
    • Most of the requirement defects are discovered in late project phases or during deployment
    • the later a defect is corrected, the higher the costs of fixing.

    Good requirements engineering is the basis for succesful development of systems that meet the needs of the client.

    Inadequate requirements engineering leads to unclear, imprecise or missing requirements.

    @ Reasons for inadequate requirements engineering:

    • The assumption that most requirements are self-evident and do not need to be stated explicitly;
    • communication problems due to differences in experience and knowledge;
    • Project pressure to deliver results (to) rapidly.
  • @ Activities of RE
    1. Elicitation;
    2. Documentation;
    3. Validation & Negotiation
    4. Management:
    • Prioritising;
    • Tracebility
    • Changes;
    • Versioning.
  • Characteristics of stakeholders
    • They are the most important source of requirements;
    • They often interact with the system;
    • They may have an other interest in the system;
    • They may influence the system from the outside (legal entities, institutions).
  • What is a stakeholders
    A stakeholder of a system is a person or an organisation that has an (direct or indirect) influence on the requirements of the system.
  • The requirements engineer
    The requirements engineer has a central role in the development project for a system and is the primary contact for stakeholders, architects and developers.
  • Characteristics of the requirements engineer
    The requirements engineer must have: domain knoledge, process knowledge, IT know-how;
    Above all, good communication skills are essential: verbal, in writing.
    Additionally, the requirements engineer must possess certain soft skills: analytical thinking, empathy, conflict resolution, moderation, self-confidence, ability to convince.
  • Communication fundamentals
    • Requirements are shared between stakeholders, architects and developers;
    • Communication involves transformation of concepts into data by the sender and of data to concepts by the sender (philosophy IREB);
    • This transformation process comprises, in particular, focussing and simplification (philosophy IREB);
    • In this process, information may be lost or distorted, resulted in a different interpretation of concepts;

    Communication about requirements is done by using natural language, and/or formal conceptual models. The communication medium plays an important role in the accuracy of the communication. Verbal communication relies heavily on redundancy. Written communication must take additional measures to avoid misunderstandings. An agreement about a common terminology can minimize misunderstandings (glossary). Use of a formal discriptive language (UML) and defining rules for focussing, simplification and interpretation further reduce noise and transmission errors in communication of requirements.

Lees volledige samenvatting
Deze samenvatting. +380.000 andere samenvattingen. Een unieke studietool. Een oefentool voor deze samenvatting. Studiecoaching met filmpjes.