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

-
ISBN-10 1457111926 ISBN-13 9781457111921
310 Flashcards & Notes
4 Students
  • This summary

  • +380.000 other summaries

  • A unique study tool

  • A rehearsal system for this summary

  • Studycoaching with videos

Remember faster, study better. Scientifically proven.

This is the summary of the book "Requirements Engineering Fundamentals A Study Guide for the Certified Professional for Requirements Engineering Exam - Foundation Level - IREB compliant". The author(s) of the book is/are Klaus Pohl Chris Rupp. The ISBN of the book is 9781457111921 or 1457111926. This summary is written by students who study efficient with the Study Tool of Study Smart With Chris.

Summary - 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
    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.


Read the full summary
This summary. +380.000 other summaries. A unique study tool. A rehearsal system for this summary. Studycoaching with videos.

Latest added flashcards

What is a Exceptional requirement change?
With this type of change the change request is urgent and has to be implemented immediately. These types of changes can be a corrective or adaptive change request by nature
What is a adaptive requirement change
With this type of change, the change is typically required because a change is required to the current system because the system context and hence the business needs have changed.
What is a corrective requirement change?
With this type of change, the change is typically required to fix a problem or error with the current system or requirement.
Technique 8: Decision Matrix
This technique to resolve a requirements conflict comprises of a comparison matrix of all key criteria that needs to be considered against each solution alternative. By compiling this comparison information in a matrix format it often highlights which is the best solution to choose. This therefore resolves any conflicts with the collated information provided
Technique 7: Plus-­‐Minus-­‐Interesting or PMI
With this technique all the positive and negative repercussions of a solution alternative is being analyzed. Two categories, one for Plus and one for Minus are developed in order to list the Positives and Negatives. When a fact or factor is neither a positive nor a negative item, it is placed in the Interesting column.
Technique 6: Consider all facts (CAF)
This technique is about collecting all facts and influencing factors relating to the requirements that are in conflict. These facts and factors are then prioritized in readiness to be used as an input into the “Plus-­‐Minus-­‐Interesting” or PMI technique.
Technique 5: Overruling
This technique is aligned with the organizational hierarchy. The more senior stakeholder’s requirements or proposed solution is the one that will taken forward as the resolution.
Technique 3: Voting
This technique is simply to ask all stakeholders involved with the requirements and/or the conflict itself to vote on a set of alternative options for a solution. The solution with the most votes is accepted as the resolution for the conflict.
Technique 2: Compromise
This technique is about using alternative parts of various solutions to try and come up with a solution that could be a compromise for all stakeholders but an acceptable solution to go forward with.
Technique 1: Agreement
Agreement is when the stakeholders work together to negotiate a solution to the conflict. This involves discussion of each other’sviews in order to try to persuade people experiencing the conflict to agree a workable solution.