Zusammenfassung
Zusammenfassung für die IREB CPRE Foundation Level Prüfung
- Hochschule
- IREB - CPRE Foundation Level
Meine Zusammenfassung, die ich für die erfolgreich abgeschlossene Prüfung IREB CPRE Foundation Level genutzt habe.
[ Mehr anzeigen ]vorschau 4 aus 49 Seiten
Vorschau 4 aus 49 Seiten
In den EinkaufswagenVerkäufer
Folgen
Inhaltsvorschau
1 Einleitung in GrundlagenDefinition: 1-1 Anforderung
Eine Anforderung ist:
- Ein notwendiges Bedürfnis eines Stakeholders
- Eine Fähigkeit oder Eigenschaft, die ein System erfüllen muss
- Eine dokumentierte Repräsentation eines Bedürfnisses, einer Fähigkeit oder Eigenschaft
Definition: 1-2 Stakeholder
Ein Stakeholder ist eine Person oder Organisation, die Einfluss auf die Anforderungen des Systems hat
oder auf die das System Auswirkungen hat
Ziel Requirements Engineering
Anforderungen der Stakeholder (dies ist ein Zyklus):
- Zu ermitteln
o Anforderungen der Stakeholder zu gewinnen
o Konflikte zw. Stakeholdern aufzulösen
- zu dokumentieren
o Beschreiben von erarbeiteten Anforderungen
- zu validieren (abstimmen + überprüfen)
o Prüfen ob dokumentierte Anforderungen gut sind
- zu verwalten
o Anforderungsverwaltung die parallel läuft
Definition: 1-4: Funktionale Anforderung
Eine Funktionale Anforderung ist eine Anforderung bezüglich des Ergebnisses oder des Verhaltens,
das von einer Funktion des Systems bereitgestellt werden soll
Definition 1-5: Qualitätsanforderungen
Eine Qualitätsanforderung ist eine Anforderung, die sich auf ein Qualitätsmerkmal bezieht,
Funktionale und Qualitätsanforderungen stehen oft in einer Beziehung. QA konkretisieren oder
beschreiben genauer die FA. Beide sollten aber getrennt spezifiziert werden
Definition 1-6: Randbedingungen
Eine Randbedingung ist eine Anforderung, die den Lösungsraum jenseits dessen einschränkt, was
notwendig ist, um die funktionalen Anforderungen und die Qualitätsanforderungen zu erfüllen.
z.b. mit Welchen tool die Software programmiert werden soll, wann es Live gehen soll. Organisatorische
oder technologische vorgabe, die die Lösungen für ein System einschränkt.
Mehrwert RE durch erfassen der Anforderungen:
- Geringeres Risiko falsches System zu entwickeln
- Besseres Verständnis des Problems
, - Grundlage für die Schätzung von Entwicklungsaufwand und Kosten
- Voraussetzung für das Testen des Systems
Gründe für fehlerhafte Anforderungen/RE:
- Beginn der Entwicklung ohne Verständnisgrundlage
- Kommunikationsprobleme
- Annahme, Anforderungen seien klar
- Unzureichende Fähigkeit des Requirements Engineers
Klassifikationen von Anforderungen
- Systemanforderung:
o Was soll das System leisten?
o Klassische Anforderungen
o Bsp: Erstellen von Bescheiden
- Stakeholder-Anforderung:
o Was möchten die Stakeholder erreichen
o Konsolidierung und ggf. Konfliktmanagement
o Bsp: System soll effizient der Sachbearbeiter verbessern
- Benutzeranforderung:
o Was der Benutzer mit dem System erreichen will
o Unterkategorie von Stakeholderanforderung
o Bsp: Filtermöglichkeit in Tabellen
- Domänenanforderung
o Anforderung aus dem Umfeld
o Oft Randbedingung
o Bsp: entwicklung in Java 8
- Geschäftsanforderung:
o Bezug zu geschäftlichen Zielen
o Vorgaben von der Orga
o Bsp: Go live in 2025
Tätigkeiten eines Requirement Engineers
- Anforderungen ermitteln, dokumentieren, validieren und verwalten
- Kenntnisse im Requirement Engineering verfügen und aktiv einbringen
- Lücke zwischen dem Problem und möglichen Lösungen überbrücken
Fähigkeiten eines Requirements Engineers:
- Analytisches Denken
- Empathie
- Kommunikationsfähigkeit
- Konfliktlösungsfähigkeit
- Moderationsfähigkeit
- Selbstbewusstsein
- Überzeugungsfähigkeit
,2 Grundlegende Prinzipien des Requirement
Engineering
Neun grundlegende Prinzipien
1. Wertorientierung
a. Anforderung sind Mittel zum Zweck, kein Selbstzweck
2. Stakeholder
a. Im RE geht es darum, die Wünsche und Bedürfnisse der Stakeholder zu befriedigen
b. Die richtigen und alle Stakeholder einbeziehen (Stakeholder können mehrere rollen
haben)
c. Zw. Stakeholdern kann es zu Konflikten kommen
3. Gemeinsames Verständnis
a. Erfolgreiche Systementwicklung ist ohne gemeinsame Basis nicht möglich
b. Explizites gemeinsames Verständnis: dokumentiertes
c. Implizites gemeinsames Verständnis: basiert auf Wissen aller (nicht dokumentiertes)
d. Beides wichtig und hat nachteile. Explz. Eher bei Wasserfall, Implz. Eher agile
4. Kontext
a. System können nicht isoliert verstanden werden
5. Problem – Anforderung – Lösung
6. Validierung
a. Nicht- validierte Anforderungen sind nutzlos/ müssen regelmäßig validiert werden
i. Die Anforderungen tatsächlich den Bedürfnissen der Stakeholder entspricht
ii. Anforderung ausreichend dokumentiert wurde, um dieses Verständnis an
Entwickler zu vermitteln
iii. Stakeholder sich über Anforderung einig sind (keine ungelösten Konflikte
existieren)
iv. Die Über den Kontext getroffenen Annahmen korrekt und während des Betriebs
des Systems gültig sind
7. Evolution
a. Sich ändernde Anforderungen sind kein Unfall, sondern ein Normalfall
b. Gründe: Ändernde Bedürfnisse, Geschäftsprozesse, Technologische Änderungen,
Gesetzesänderungen, Feedback von Stakeholdern
8. Innovation
a. Mehr vom Gleichen ist nicht genug
b. Stakeholder weiß selbst nicht immer alle Anforderungen (hat welche Unbewusst) –
versuchen rauszufinden
c. Inkrementelle Innovation: Stetige Verbesserung von Produkten/Technologien
d. Disruptive Innovation: Neuartige Technologie die alte ablöst
9. Systematische und disziplinierte Arbeit
a. Kein one fits all: Der Requirements Engineer muss für jedes neue Projekt systematisch
einen Requirements-Engineering-Prozess etablieren und die für die jeweilige Situation
passenden Requirements-Engineering-Praktiken auswählen
b. Systematisches und diszipliniertes Arbeiten im Requirements Engineering bedeutet,
dass der Requirements Engineer
• die verwendeten Prozesse und Praktiken an das jeweilige Problem, den gegebenen
Kontext und die vorhandene Arbeitsumgebung anpasst;
• nicht immer die gleichen Prozesse und Praktiken verwendet;
• erfolgreiche Prozesse und Praktiken aus vergangenen Projekten nicht unreflektiert
wiederverwendet.
, Definition 2-1: Wert einer Anforderung
Der Wert einer Anforderung ist gleich ihrem Nutzen abzüglich der Kosten für das Ermitteln,
Dokumentieren, Validieren und Verwalten der Anforderung.
Anforderungen nur erfassen, wenn sie Stakeholder Wünsche erfüllen (so viel wie nötig, aber nicht zu
wenig)
Definition 2-2: Systemkontext
Das Systemkontext ist der Teil der Umgebung eines Systems, der für die Definition und das
Verständnis der Anforderungen des zu entwickelnden Systems relevant ist
System und Systemkontext sind getrennt von der Systemgrenze
Systemkontext beschreibt relevanten Teil der Umgebung, der mit der Kontextgrenze vom irrelevanten Teil
der Umgebung abgegrenzt wird
- Alles was mit dem System zu tun hat muss identifiziert werden und ist teil des Kontext (und die
Beziehung zum System)
- Z.b. Personen, Systeme, Vorgängersysteme, Prozesse, Ereignisse, Dokumente
- Desto mehr Aspekte korrekt identifiziert werden, desto niedriger Wahrscheinlichkeit für falsche
Interpretation der Anforderungen
- Daher Dokumentation von Systemkontext wichtig
Definition 2-3: Systemgrenze
Systemgrenze separiert das geplante System von seinem Kontext
Aspekte (Objekte, Personen, Prozesse etc.) im „System“ (innerhalb der Systemgrenze) können während
der Entwicklung angepasst werden (Drucker darf ausgetaucht werden wenns im System liegt).
Aspekte im Kontext dürfen nicht verändert werden
Richtige Abgrenzung
RE hat bei jeder Anforderung zu prüfen ob:
- Sich die gesamte Anforderung auf das zu entwickelnde System bezieht, oder ob Teile der
Anforderung durch vorgegebene Kontextaspekte erfüllt werden
- Ob die Anforderung unnötig durch die aktuelle Systemabgrenzung eingeschränkt wird. Also
Dinge die dem Kontext zugeordnet sind, eigentlich gestaltbar sein sollten
2 Arten von Abgrenzung:
Systemabgrenzung: Bestimmen der Systemgrenze, die festlegt, welche Aspekte durch das geplante
System abgedeckt werden sollen und welche Aspekte Teil der Umgebung dieses Systems sind
- Quellen und Senken als Ausgangspunkt zur Abgrezung. Z.b. Stakeholder oder existierende
System
- Systemgrenze häufig erst am Ende klar, davor Grauzone (da nicht bekannt oder unvollständig)
Kontextabgrenzung: Grenze des Kontexts zur irrelevanten Umgebung hin bestimmt, indem analysiert
wird, welche Aspekte in der Umgebung eine Beziehung zu dem geplanten System haben
-
Durch beide wird der Systemkontext bestimmt.
Grenzen können sich verschieben
Alle Vorteile der Zusammenfassungen von Stuvia auf einen Blick:
Garantiert gute Qualität durch Reviews
Stuvia Verkäufer haben mehr als 700.000 Zusammenfassungen beurteilt. Deshalb weißt du dass du das beste Dokument kaufst.
Schnell und einfach kaufen
Man bezahlt schnell und einfach mit iDeal, Kreditkarte oder Stuvia-Kredit für die Zusammenfassungen. Man braucht keine Mitgliedschaft.
Konzentration auf den Kern der Sache
Deine Mitstudenten schreiben die Zusammenfassungen. Deshalb enthalten die Zusammenfassungen immer aktuelle, zuverlässige und up-to-date Informationen. Damit kommst du schnell zum Kern der Sache.
Häufig gestellte Fragen
Was bekomme ich, wenn ich dieses Dokument kaufe?
Du erhältst eine PDF-Datei, die sofort nach dem Kauf verfügbar ist. Das gekaufte Dokument ist jederzeit, überall und unbegrenzt über dein Profil zugänglich.
Zufriedenheitsgarantie: Wie funktioniert das?
Unsere Zufriedenheitsgarantie sorgt dafür, dass du immer eine Lernunterlage findest, die zu dir passt. Du füllst ein Formular aus und unser Kundendienstteam kümmert sich um den Rest.
Wem kaufe ich diese Zusammenfassung ab?
Stuvia ist ein Marktplatz, du kaufst dieses Dokument also nicht von uns, sondern vom Verkäufer majin123. Stuvia erleichtert die Zahlung an den Verkäufer.
Werde ich an ein Abonnement gebunden sein?
Nein, du kaufst diese Zusammenfassung nur für 15,49 €. Du bist nach deinem Kauf an nichts gebunden.
Kann man Stuvia trauen?
4.6 Sterne auf Google & Trustpilot (+1000 reviews)
45.681 Zusammenfassungen wurden in den letzten 30 Tagen verkauft
Gegründet 2010, seit 15 Jahren die erste Adresse für Zusammenfassungen