+380.000 andere samenvattingen
Een unieke studietool
Een oefentool voor deze samenvatting
Studiecoaching met filmpjes
Onthoud sneller, leer beter. Wetenschappelijk bewezen.
Samenvatting - Requirements Engineering Fundamentals A Study Guide for the Certified Professional for Requirements Engineering Exam - Foundation Level - IREB compliant
1 Introduction and Foundations
WoordenlijstAdequacy = 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.
BegrippenAdequacy = 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
- A condition of capability needed by a user to solve a problem or achieve an objective;
- 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;
- A documented representation of a condition of capability as in 1) or 2).
@ Types of requirements?
- Functional requirements (What)
- Quality Requirements (How)
- 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?
- A quality requirement is a requirement that pertains to a quality concern that is not covered by functional requirements
- @ The desired qualities of the system, e.g. (ISO 25010):
- Detailing functionalities (securaty, accurateness)
@ Characteristics of quality requirementsQuality 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 constraintA constraint is a requirement that limits the solution space beyond what is necessary for meeting the given functional requirements and quality requirements.
@ Characteristics of constraintsConstraints:
- 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 EngineeringRequirements engineering is a systematic and disciplined approach to the specification and management of requirements with the following goals:
- knowing the relevant requirements, achieving a consensus among the stakeholders about these requirements, documenting them according to given standards and managing them systematically;
- 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
- Validation & Negotiation
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 stakeholdersA 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 engineerThe 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 engineerThe 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.
- 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.