Samenvatting
Summary (Midterm) - Requirements Engineering (INFOMRE)
- Instelling
- Universiteit Utrecht (UU)
Summary of everything for the midterm exam. Including leture notes, literature summaries and screenshots of slides/ images.
[Meer zien]Voorbeeld 4 van de 39 pagina's
Voorbeeld 4 van de 39 pagina's
In winkelwagengesponsord bericht van onze partner
Voorbeeld van de inhoud
Requirements EngineeringLecture 1 – Introduction
Terminology
• Requirement (IEEE):
1. A condition or capability needed by a user to solve a problem or achieve an objective
2. A condition or capability that must be met or possessed by a system or system
component to satisfy a contract, standard, specification, or other formally imposed
documents
3. A documented representation of a condition or capability as in 1 or 2
• Requirement (IREB):
1. 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
• Requirements engineer: A person who — in collaboration with stakeholders — elicits,
documents, validates, and manages requirements.
• Requirements engineering: 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,
3. Specifying and managing requirements to minimize the risk of delivering a system
that does not meet the stakeholders’ desires and needs.
Pohl’s three dimensions of RE
• Specification
o Deals with the degree of requirements understanding
o From vague / opaque requirements . . .
o To a specification that is unambiguous, complete, verifiable, etc.
o To classified requirements (functional vs. non-functional, vital vs. desirable, etc.)
o The page should be faster → The profile page shall be loaded on any Android
v7+ device within 10ms
1
, • Representation
o Deals with how the knowledge about the system is expressed:
▪ Informal (e.g., natural language): easy to read, inherently ambiguous
▪ Semi-formal (e.g., class diagrams): provide a good overview, weak
semantics
▪ Formal (e.g., first-order logic): precise, but more system-oriented
• Agreement
o Deals with the degree of agreement reached on a specification
o From personal views on the system, to a common system spec
▪ Do the same terms mean the same concept to all stakeholders?
▪ Do the stakeholders agree on the functions to deliver?
Lecture summary
• RE is the key to software quality
• Poor RE may result in failure
Lecture 2 – Fundamentals and Processes
Fundamentals of RE
• What is RE?
o To make sure that a software solution correctly solves a given problem, we
must first correctly understand and define the problem to solve.
• RE is about… Discover, understand, formulate, analyze and agree on:
o what problem should be solved
o why such a problem needs to be solved
o who should be involved in the responsibility of solving that problem
• Problems and solutions
o RE focuses on the problem, not the solution
▪ Problem space: where the problem exists
▪ Solution space: build software
o The world: things that have an effect on our life
o The machine: solution space (payment record, as customer you don’t care, it has
no effect on their life)
o Shared phenomena: relevant both to world and machine
o RE is concerned with the machine’s effect on the surrounding world and the
assumptions we make about that world
o RE is solely concerned with world phenomena, including shared ones
▪ RE focuses on requirements and assumptions
▪ Software design focuses on machine phenomena
o E.g. assumptions are like physics laws/ that the courier will deliver the item →
not specified in system, just assume it is like this.
2
,• Systems
o A system is a set of components interacting with each other to satisfy some
global objectives
▪ intrinsically composite
▪ can be seen as a whole through the global properties emerging from
component interactions
▪ e.g. Marktplaats:
• Components: sellers, buyers, shipping companies, payment
subsystem, e-mail systems, the software for managing items and
bids, etc.
• Global properties: satisfaction of buyers getting access to items,
auction rules regulating the system, trustworthiness,
relationships
o The task of requirements engineers is to investigate the problem world:
▪ System-as-is, which exists before the machine is built;
▪ System-to-be, when the machine will be built and operated
o When we do RE, there is always a system-as-is (not always technical)
o Example (e-auction):The system-as-is is a standard auction system with no
support for electronic bidding. The system-to-be is intended to make items
biddable from anywhere at any time through Internet auctions
• The software-to-be (part of system-to-be)
o The system-to-be consists of two sub-components:
1. Software-to-be: the machine to be built
2. Environment that surrounds the software-to-be, and includes
• People and business units
• Physical devices
• Legacy software (cannot easily be changed)
• Defining RE
o Requirements Engineering: A coordinated set of activities for exploring,
evaluating, documenting, consolidating, revising and adapting the objectives,
capabilities, qualities, constraints and assumptions that the system-to-be should
meet based on
▪ problems raised by the system-as-is
▪ and opportunities provided by new technologies (generative AI, when
you want to include large language models )
• Three dimensions of RE
3
, o Why
▪ All these “whats” are there for a reason.
▪ Identify, analyze, refine the system-to-be’s objectives
• to address analyzed deficiencies of the system-as-is
• in alignment with business objectives
• taking advantage of technology opportunities
▪ Challenges:
• Acquire domain knowledge
• Evaluate alternative options (don’t commit too prematurely to
one solution)
• Evaluate technology opportunities
• Handling conflicts
▪ Example: Train control: Alternatives for satisfying avoid train collisions
→ ensure that there will never be two trains on the same block; ensure
that trains on the same block will always be separated by some worst-
case stopping distance
o What
▪ Services, constraints, assumptions about system-to-be
▪ Identify & define the system-to-be’s functional services (features)
• to satisfy the identified objectives
• according to quality constraints: security, performance, . . .
• based on realistic assumptions about the environment
▪ Challenges:
• Identify the right set of features
• Specify these precisely for understanding by all parties
• Ensure backward traceability to system objectives
▪ When you define a what, it is not just a statement of “the system should
do this”. It should also consider how well and how the functions should
be delivered.
▪ Example: library management: One key function for a library
management software is a query service. The definition of such a
function should
• be comprehensible both by library staff and by the students
• provide evidence that the objectives of increased coverage,
information accuracy and wider accessibility will be met
4
Voordelen van het kopen van samenvattingen bij Stuvia op een rij:
Verzekerd van kwaliteit door reviews
Stuvia-klanten hebben meer dan 700.000 samenvattingen beoordeeld. Zo weet je zeker dat je de beste documenten koopt!
Snel en makkelijk kopen
Je betaalt supersnel en eenmalig met iDeal, creditcard of Stuvia-tegoed voor de samenvatting. Zonder lidmaatschap.
Focus op de essentie
Samenvattingen worden geschreven voor en door anderen. Daarom zijn de samenvattingen altijd betrouwbaar en actueel. Zo kom je snel tot de kern!
Veelgestelde vragen
Wat krijg ik als ik dit document koop?
Je krijgt een PDF, die direct beschikbaar is na je aankoop. Het gekochte document is altijd, overal en oneindig toegankelijk via je profiel.
Tevredenheidsgarantie: hoe werkt dat?
Onze tevredenheidsgarantie zorgt ervoor dat je altijd een studiedocument vindt dat goed bij je past. Je vult een formulier in en onze klantenservice regelt de rest.
Van wie koop ik deze samenvatting?
Stuvia is een marktplaats, je koop dit document dus niet van ons, maar van verkoper IsabelleU. Stuvia faciliteert de betaling aan de verkoper.
Zit ik meteen vast aan een abonnement?
Nee, je koopt alleen deze samenvatting voor €6,49. Je zit daarna nergens aan vast.
Is Stuvia te vertrouwen?
4,6 sterren op Google & Trustpilot (+1000 reviews)
Afgelopen 30 dagen zijn er 73918 samenvattingen verkocht
Opgericht in 2010, al 14 jaar dé plek om samenvattingen te kopen