Projektmanagement & Requirements Engineering

Synthese

Zweck der Synthese ist die Sammlung und Ausarbeitung von Lösungsalternativen. Die Synthese von Lösungen ist ein kreativer, aufbauend-konstruktiver Schritt, welcher auf den Resultaten der Situationsanalyse (Situationskenntnis, Problemverständnis, Zielformulierungen, Anforderungskatalog) aufbaut -> Kreativitätstechniken

Analyse

Zweck der Analyse ist es, grundsätzlich die Machbarkeit einer Lösungsalternative zu verifizieren - ohne diese bereits zu werten oder mit weiteren Alternativen zu vergleichen - dies erfolgt später in der Auswahlphase. Die Analyse ist ein kritischer, analytisch-destruktiver Schritt. Erfüllt eine Lösungsalternative die Ansprüche nicht, so kann sie entweder verworfen werden oder muss überarbeitet werden.

Bewertung

• Es müssen mindestens 2 echte Lösungsalternativen existieren,
• Es müssen Bewertungskriterien - bezogen auf die Zielformulierung(en) - definiert sein,
• Die "Bewerter" müssen über die Fähigkeit verfügen, die Alternativen hinsichtlich der Bewertungskriterien beurteilen zu können.

Entscheid

• Basierend auf den Bewertungsergebnissen eine Entscheidung treffen.

Es kann wohl sein, dass der PLZ keine zufriedenstellende Variante hervorbringt oder es sich herausstellt, dass das Problem mit den verfügbaren Mitteln (Personal, Finanzen, Material) nicht realisieren lässt. In diesem Fall sind folgende Schlussfolgerungen möglich:

• Projektabbruch
• Sistierung der Zusammenarbeit mit Systementwicklern
• Zielreduktion
• Auf höhere Systemebene zurück, um eventuell auf anderen Wegen zum Ziel zu kommen
• Das Problem wird neu umschrieben/definiert

Das Ziel der Architekturgestaltung ist es, eine Architektur zu entwickeln, die einen zuvor definierten Wert bzw. Zweck/Ziel/Funktion erfüllt.

Die Konzeptgestaltung (nebst der Architekturgestaltung) folgt der Logik des oben erläuterten PLZ. In einer Konzeptgestaltung geht es darum, eine gewählte Architektur konkret und detailliert auszugestalten. Dazu wird in einem Top-Down-Ansatz der PLZ mehrmals durchlaufen.

Ziel dieses Teilprozesses ist es, eine erste unternehmerische Rechtfertigung des Vorhabens sowie Entscheidungsgrundlagen für ein GO/NO-GO vorliegen zu haben.

Resultat/Lieferobjekt -> Mini-Business Case

• Welches Problem genau soll adressiert werden?
• Welche grundlegenden Ziele(Grobziele) muss eine zukünftige Problemlösung erfüllen?
• Eventuell auch bereits: Welche grundlegenden Anforderungen muss die Lösung erfüllen (-> Systemanforderungen)?
• Welchen Nutzen soll und welche Kosten (einmalige wie auch wiederkehrende) darf die zukünftige Lösung aufweisen?
• Bis wann soll die Lösung verfügbar sein?
• Eventuell auch bereits: Welche grundlegenden Architekturvarianten (grobe Lösungsvarianten) stehen im Vordergrund?

Wenn diese Fragen beantwortet sind kann ein Projektantrag erstellt werden, welcher das Lieferobjekt deises Schrittes ergibt. Anhand dieses Projektantrag können die Planungsaktivitäten im nächsten Schritt gestartet weden.

Zielen kommt eine entscheidende Bedeutung zu; Ziele sollen die Lösungssuche steuern und nicht umgekehrt eine Lösung nachträglich rechtfertigen. Ziele müssen ausformuliert, verabschiedet und allen Beteiligten kommuniziert sein. Ziele dienen zur Erfolgsbestimmung eines Projektes.

(Muss-Ziele, Soll-Ziele, Wunsch-Ziele)

Abwicklungsziele

• Leistungsziele, was muss geliefert werden?
• Qualitätsziele, in welchem Zustand?
• Zeit-/Terminziele, bis wann?
• Kostenziele, zu welchen Kosten?

Systemziele

• Akzeptanz und
• Wirtschaftlichkeit

des im Projekt zu erstellenden Systems. Sie unterteilen sich hierarchisch in Globalziele, Gruppenziele und Detailziele.

Ziel:

• Ein zu erreichender Zustand
• Meist im umfassenden Sinn

Anforderung:

• Eine zu erreichende Eigenschaft
• Meist konkret

Bei einer Delphi-Befragung wird einer Expertengruppe ein Fragen- oder Thesenkatalog des betreffenden Fachgebiets vorgelegt. Die Befragten haben in zwei oder mehr sogenannten Runden die Möglichkeit, die Thesen einzuschätzen. Ab der zweiten Runde wird Feedback gegeben, wie andere Experten geantwortet haben, in der Regel anonym. Auf diese Weise wird versucht, der üblichen Gruppendynamik mit sehr dominanten Personen entgegenzuwirken.

Dauer[Tage] = Aufwand [PT] / Personen [P]

Termintreue [%] = (#eingehaltene Termine / #Termine) * 100

Fortschrittsgrad = (ISTaufwand * 100) / Planaufwand

Zeitlicher Fortschrittsgrad [%] = (Dauer [Wochen] / prognostizierte Gesamtdauer [Wochen]) * 100 -> zu einem Zeitpunkt x

zeitl . FGplan = ISTDauer / geplannte Dauer

zeitl. FGist = ISTDauer / voraussichtliche Dauer

EV = Fortschrittsgrad tx * plankosten

Burned Value = Differenz zwischen denk Plan Kosten und den effektiv angefallenen Kosten

Scheduled Performance Index = EV / PV

Cost Performance Index = EV / BV

Anforderungen entsprechen nicht dem Kundenwunsch, sind zu wenig detailiert beschrieben oder fehlen ganz -> System entspricht nich dem, was der Kunde/Nutzer wollte

Häufigster Fehler sind falsch Annahmen von Stakeholdern.

• Eine Bedingung oder Fähigkeit, die von einem Benutzer (Person oder System) zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird.
• Eine Bedingung oder Fähigkeit, die ein System oder Teilsystem erfüllen oder besitzen muss, um einen Vertrag, eine Norm, eine Spezifikation oder andere, formell vorgegebene Dokumente zu erfüllen.
• Eine dokumentierte Repräsentation einer Bedingung oder Eigenschaft.

Ein Stakeholder eines Systems ist eine Person oder Organisation, die (direkt oder indirekt) Einfluss auf die Anforderungen des betrachteten Systems hat.

Dem Requirements Engineering im Entwicklungsprozess kommt die Aufgabe zu, die Anforderungen der Stakeholder zu ermitteln, zweckmäßig zu dokumentieren, zu überprüfen und abzustimmen sowie die dokumentierten Anforderungen über den gesamten Lebenszyklus des Systems hinweg zu verwalten

Das Requirements Engineering ist ein systematischer und disziplinierter Ansatz zur Spezifikation und zum Management von Anforderungen mit den folgenden Zielen:

• Die relevanten Anforderungen zu kennen, Konsens unter den Stakeholdern über die Anforderungen herzustellen, die Anforderungen konform zu vorgegebenen Standards zu dokumentieren und die Anforderungen systematisch zu managen.
• Die Wünsche und Bedürfnisse der Stakeholder zu verstehen, zu dokumentieren sowie die Anforderungen zu spezifizieren und zu managen, um das Risiko zu minimieren, dass das System nicht den Wünschen und Bedürfnissen der Stakeholder entspricht.
• Kann als abgeschlossene Phase in Projekten vorkommen (Wasserfall) aber auch als begleitender Prozess.

• Glossar
• Formale Beschreibungssprache (UML ...)
• Art der Kommunikation (Gestik, Sprache...)

• Steht im Mittelpunkt des Geschehens
• Pflegt oft als einziger direkten Kontakt zu allen Stakeholdern
• Analytisches Denken
• Empathie
• Kommunikationsfähigkeit
• Konfliktlösungsfähigkeit
• Moderationsfähigkeit
• Selbstbewusstsein
• Überzeugungsfähigkeit

• Funktionale Anforderungen
  • Eine funktionale Anforderung ist eine Anforderung bezüglich des Ergebnisses eines Verhaltens, das von einer Funktion des Systems bereitgestellt werden soll.
• Qualitätsanforderung
  • Eine Qualitätsanforderung ist eine Anforderung, die sich auf ein Qualitätsmerkmal bezieht, das nicht durch funktionale Anforderungen abgedeckt wird.
  • Quantitative definieren, damit diese überprüft werden können
  • Stehen fast immer in Beziehung zu finktionalen Anforderungen und müssen zwingend so ausgewiesen werden
  • Performace
  • Sicherheit
  • Zuverlässigkeit
  • Bentzbarkeit
  • Änderbarkeit
  • Übertragbarkeit
• Randbedingung
  • 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.

von innen nach aussen 

System | Systemgrenze&Systemabgrenzung | Systemkontext | Kontextgrenze & Kontextabgrenzung | irrelevante Umgebung

Mögliche Elemente die im System eingezeichnet werden können:

• Personen
• Systeme
• Prozesse
• Ereignisse
• Dokumente

Die Systemgrenze separiert das geplante System von seiner Umgebung. Sie grenzt den im Rahmen des Entwicklungsprozesses gestaltbaren und veränderbaren Teil der Realität von Aspekten in der Umgebung ab, die durch den Entwicklungsprozess nicht verändert werden können.

Die Kontextgrenze separiert den relevanten Teil der Umgebung eines geplanten Systems vom irrelevanten Teil, d.h. dem Teil der Umgebung, der keinen Einfluss auf das geplante System und damit auch keinen Einfluss auf die Anforderungen dieses Systems hat.

Stakeholder (zur Überischt eine Stakeholderliste machen!)

Dokumente

Systeme die bereits in betrieb sind

Der RE...

• Spricht die Sprache der Stakeholder
• Arbeitet sich in das Fachgebiet gründlich ein
• Erstellt ein Anforderungsdokument
• Kann die Arbeitsergebnisse verständlich formulieren
• Pflegt einen respektvollen Umgang mit den Stakeholdern
• sorgt dafür, dass das spezifizierte System den funktionalen und qualitativen Ansprüchen der Stakeholder gerecht wird.
• organisiert die Planung und Koordination der Kommunikationswege sowie eine strukturierte Terminplanung für die durchzuführenden Requirements-Engineering-Aktivitäten mit den Stakeholdern.

Der Stakeholder...

• führt den Requirements Engineer in das Fachgebiet ein,
• versorgt den Requirements Engineer mit Anforderungen,
• formuliert die Anforderungen zielgerecht und gewissenhaft,
• trifft Entscheidungen zeitgerecht,
• priorisiert die Anforderungen,
• befolgt den vorgegebenen Änderungsprozess,

Mit dem Kano-Modell wird eine Anforderungskategorisierung gemacht. Es gibt drei Arten von Katgorien:

• Basisfaktoren (unterbewusstes Wissen)
  • Müssen zwingend erfüllt werden
  • Weden vorallem durch bereits vorhandene Systeme geprägt
  • Zur Ermittlung eignen sich Beobachtungstechniken und dokumentzentrierte Techniken
• Leistungsfaktoren (bewusstes Wissen)
  • Stakeholder fordern diese bewusst und explizit
  • Erfüllung erzeugt Stakeholderzufriedenheit
  • Zur Ermittlung eignen sich Befragungstechniken
• Begesiterungsfaktoren (unbeswusstes Wissen)
  • sind Systemmerkmale die der Stakeholder nicht kennt und erst während der Benutzung als angenehme und nützliche Überaschung entdeckt
  • Wird erst durch ausprobieren erkannt oder wenn vom RE vorgeschlagen
  • Zur Ermittlung eignen sich Kreativitätstechniken 

Das Kano-Modell sagt aus, dass mit der Ziet aus Begeisterungsfaktoren Leistungsfaktoren und schlussendlich Basisfaktoren werde, denn der Nutzer gewöhnt sich an Merkmale eines Systems.

[Grafik]