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
6 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.
  • 1.1.1 Figures and Facts from Ordinary Projects

  • What are reasons for inadequate requirements engineering?
    1. The assumption that most requirements are self-evident and do not need to be stated explicitly.
    2. communication problems due to differences in experience and knowledge. (VB KG of LBS gebruiken)
    3. Project pressure to deliver results (to) rapidly. (snel starten zonder exact weten wat er gemaakt moet worden)
    4. Not spending enough time on RE. (Terwijl RE tijd bespaard)(Helpt ook bij reuse)
    5. Lack of skills with the Requirements Engineer in the field of for example elicition.
    6. Using a bad template with too little detail or the lack of a template.
  • Symptoms of poor requirements engineering
    1. Unused system
    2. User dissatisfaction with developed system
    3. Unmet stakeholder requirements
    4. Unwanted features gettingimplemented
    5. Work executed through workarounds
    6. Unclear incomplete or wrong requirements lead to development of wrong solutions.
    7. Costs of fixing errors increase exponentially with each project phase.
  • 1.1.2 Requirements Engineering - What Is It?

  • What is a requirement
    1. A condition or 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).
    4. A requirement may be unstated, implied by or derived from other requirements, or directly stated and managed.
    5. Requirements describe, but not limited to, past, present and future conditions or capabilities in an enterprise, organizational structures, roles, processes, policies, rules and information systems.
  • Four core activities of requirements engineering
    1. Elicitation (Obtain requirements form stakeholders)
    2. Documentation (elicited requirements are described adequately)
    3. Validation & Negotiation (guarantee that predefined quality criteria are met, documented requirements must be validated and negotiated)
    4. Management
  • Requirements engineering consists of two parts, which?
    1. Requirements development (gericht op identificeren, verzamelen en ontwikkelen van requirements van de stakeholder)
    2. Requirements management (beheren van de requirment van creatie tot uitfaseren)
  • What are the different levels of requirements?
    • Business - VB: Wat heeft het bedrijf nodig, een CRM systeem
    • Stakeholders - VB: Wat zijn de wensen van de stakeholders; tester/ gebruiker etc.
    • Solution - VB: Functioneel / Non-Functioneel
    • Transition
  • 1.3 Characteristics of a requirements Engineer

  • What is the role of a 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.
  • Skills of the requirements engineer
    1. Communication skills (verbal and written)
    2. Knowledge of documentation and presentation tools
    3. Knowledge of modeling tools and techniques
    4. Analytical thinking
    5. Empathy
    6. Conflict resolution
    7. Facilitation and Moderation
    8. Self-confidence
    9. Ability to convince
  • Requirements engineer responsibilities
    1. Understand business domains as well as technology domains
    2. Act as the connecting links between business stakeholders and technology implementation stakeholders
    3. Plan requirements engineering activities in collaboration with stakeholders
    4. Speak the language of the stakeholders
    5. Be able to communicate requirements (e.g. by means of diagrams and graphs)
    6. Create requirements documents
    7. Maintain respectful relationships with stakeholders
    8. Present ideas and alternatives as well as their realizations •Make systems user-friendly and simple
    9. Ensure systems satisfy functional and non-functional requirements
    10. Plan and organize requirements communications
    11. Take additional responsibilities towards Domain SME Project Manager and Tester if needed
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.