Sie sind auf Seite 1von 3

Anforderungen:

Das Ziel einer Anforderungsspezifikation ist es also, Fehlerkosten zu senken und eine klare Grundlage für den Bau des künftigen Systems zu vereinbaren.

Die Eigenschaften einer guten Anforderungsspezifikation sind:

Adäquatheit

Hier wird beschrieben, was der Kunde wirklich will bzw. wirklich braucht

Vollständigkeit

Es wird alles aufgenommen und beschrieben was der Kunde gerne will bzw. braucht

Widerspruchsfrei

Die Spezifikation ist nur realisierbar, wenn sich Anforderungen nicht gegenseitig ausschliessen oder widersprechen. Daher muss die überprüft werden. Falls es tatsächlich zu Wiedersprüchen kommt, so müssen diese durch angepasst werden.

Verständlichkeit

Spezifikationen müssen so beschrieben werden dass alle beteiligten Parteien und Personen diese verstehen.

Eindeutigkeit

Alles wird so beschrieben, dass es eindeutig ist und keine Spekulationen zulässt.

Prüfbarkeit

Ziele müssen messbar und realistisch sein. Daher wird alles so formuliert und aufgeschrieben, dass die Anforderungen später auch überprüft werden können.

Ein guter Spezifikationsprozess ist gekennzeichnet durch:

  • Integration von Ermittlungen, Darstellung und Prüfung der Anforderungen;Kundenorientierung;Methodisches und zielgerichtetes Vorgehen;Einsatz geeigneter Mittel

Requirements Engineering (englisch für: Anforderungsspezifikationen) ist ein Prozess bei dem Benutzeranforderungen aufgenommen, verfeinert und präzise dargestellt werden.

  • Dieser Spezifikationsprozess kostet Geld, ohne dass diesen Kosten unmittelbar ein sichtbarer Erfolg gegenübersteht. Er ist nur wirtschaftlich, wenn dem Aufwand entsprechende

Kosteneinsparungen gegenüberstehen.

  • Als Ergebnis des Requirements Engineering sollte die Frage WAS? beantwortet werden können. Was muss ein System können? Was passiert, wenn eine bestimmte Aktion eintritt oder ein

Fehler auftritt? Bei diesem Abschnitt muss der Kunde stark einbezogen werden und sich nochmals genau überlegen, WAS? er nun genau will. Nur so können Fehler vermieden und im Endeffekt

Geld gespart werden.

  • Der Prozess, bei dem Benutzeranforderungen aufgenommen, verfeinert und präzise dargestellt werden, wird Requirements Engineering (RE) genannt

  • Ziel des RE ist eine korrekte und vollständige Spezifikation der Software-Anforderungen

Warum sind Anforderungen zu spezifizieren?

  • Kosteneinsparungen (durch vermeiden von Fehlerkosten und damit verbunden Folgekosten)

    • Merke: Je später falsche Entwicklungsentscheide entdeckt werden, desto teurer ist deren Korrektur, da diese Kosten exponentiell wachsen.

  • Konsensfindung und klare Grundlage Als Ergebnis von Requirements Engineering liegt eine vollständige, konsistente und eindeutige Anforderungsspezifikation vor.

Informationserhebung / Datenerhebung

Alle Informationsbeschaffungsmethoden haben zum Ziel, Informationen in der geforderten Qualität zu erheben. Mit Qualität ist in erster Linie Korrektheit, Vollständigkeit, Aktualität und die Aufgabenadäquatheit der Daten gemeint.

Vorbereitungen zur Erhebung von Daten werden am Anfang des Projekts (im Rahmen der Planungsphase) durchgeführt.

Welche Informationen werden benötigt und welche davon sind unerlässlich?

Wo und wie können die Informationen gefunden werden?

In welchem Genauigkeits- und Detaillierungsgrad müssen die Daten vorliegen?

Welche Methoden und Techniken werden eingesetzt?

Was darf die Erhebung kosten? Welcher Aufwand ist zulässig?

Wie können die Ergebnisse plausibilisiert und dokumentiert werden?

Erhebungstechniken (Methoden und Techniken der Informationserhebung):

 

Dokumentenstudium

 

Selbstaufschreibung

Checklisten

Interview

Delphi-Methode

Hochrechnungsprognose

Fragebogen

Datenbanken

Multimomentstudie

 

Gesprächsrunden

 

Interview:

 

Vorteile:

 

Nachteile:

 

Fördert aktuelle Ereignisse zu Tage

Aufwändige Erhebungstechnik (Vorbereitung, Durchführung, Nachbearbeitung)

 

Gezielte Erhebungstechnik. Bei Unklarheiten kann unverzüglich

Stellt hohe Anforderungen an Interviewer. Ist eine Technik, die der Interviewer erlernen muss. Dazu gehören:

nachgefragt werden. Missverständnisse können vermieden werden.

Die Art wie Fragen zu stellen sind

Individuelle Anpassung der Fragen möglich

 

Persönlich, direkt

 

Dass Notizen ab und zu durch Resümee abgesichert werden Dass das Erinnerungsvermögen des Interviewers nicht überfordert werden darf

 

Das Quer- und Kontrollfragen geschickt eingebaut werden usw.

Vergleichbarkeit oft schwierig, Auswertung oft intensiv Ergebnis ist oft vom Interviewer abhängig. Der Interviewer beeinflusst den Interviewten unbewusst durch seine Gestik oder Körperhaltung, aber auch durch die Tonlage und Formulierung der einzelnen Fragen.

Daten sollten überprüft werden auf:

 
 

Korrektheit

Aufgabenadäquanz

Relevanz

Vollständigkeit

Konsistenz

Glaubwürdigkeit

Aktualität

Exaktheit

Verständlichkeit

Pflichtenheft:

 

Zielbestimmung

Hier wird beschrieben welche Ziele durch den Einsatz eines Produkts erreicht werden müssen. Es wird unterschieden zwischen

 

Muss-, Wunsch-, und Abgrenzungskriterien.

 

Muss-Anforderungen

Hier werden die Unabdingbaren Leistungen aufgeführt. Diese Kriterien müssen zwingend erreicht werden.

 

Wunsch-

 

Hier werden die Anforderungen aufgeführt, welche wünschenswert, jedoch nicht zwingend sind. Natürlich wird versucht, diese wenn möglich

Anforderungen

zu erfüllen.

Abgrenzungskriterien

Sie zeigen die Systemgrenze auf und beschrieben, welche Dinge absichtlich nicht erreicht werden sollen.

 

Anwendungsbereich

Hier wird beschrieben, in welchem Gebiet oder das Produkt zu Anwendung kommt

 

Zielgruppen

Wer wird das Produkt bedienen und anwenden? Welches Nivea / Wissen besitzt diese Zielgruppe. Welche Hilfsfunktionen wird sie benötigen?

Betriebsbedienung

Dies ist auch sehr stark vom oben genannten Punkt Zielgruppe abhängig. Nehmen wir zum Beispiel eine Buchhaltungssoftware. Je nachdem ob die Benützer sich im Fach Buchhaltung auskennen oder ob dies gänzlich neue Benutzer sind die noch nie zuvor mit der Buchhaltung konfrontiert wurden, so ist für sie natürlich ein viel detailliertes Guideline zu erstellen welches noch zusätzlich Hilfs-Funktionen enthält. Zwingend sollten jedoch folgende Punkte in einer Betriebsbedienung erwähnt werden:

 

   

physikalische Umgebung des Systems

Betriebszeiten (täglich, wöchentlich) Notwendige Überwachung und Betreuung des Systems

Software

 

Hier wird aufgeführt welche System Voraussetzung für die Software sind. Nehmen wir als Beispiel die Software Microsoft Word. Damit diese läuft muss bereits ein Betriebssystem wie etwa Windows zur Verfügung stehen, da diese Software nicht direkt auf eine leere Harddisk installiert werden kann.

Hardware

 

Hier wird die erforderliche Leistung der Hardware beschrieben. Es ist gut möglich, dass eine Software noch zusätzlich Peripherie braucht. Beispiel: Inventursoftware braucht sicherlich noch ein angeschlossener Barcodescanner damit die Produkte mit diesem erfasst und nicht von Hand eingetippt werden müssen.

Orgware

 

Unter Orgware versteht man die organisatorischen Rahmenbedingungen unter welchen die Software eingesetzt werden soll.

Produktschnittstellen

Hier wird festgelegt wo dass das Endprodukt eingegliedert wird. Ist es ein komplettes eigenes System oder bezieht die Software zum Beispiel Daten aus einer Datenbank eines anderen Systems das bereits in Betrieb ist. Vorstellbar wäre auch, dass die neue Software die verarbeiteten Daten an ein anderes, bestehendes Softwareprodukt weitergeben muss.

Produkt-Funktionen

Hier werden die Funktionen des Produkts aufgegliedert.

 

Produkt Daten

Beschreibung der langfristig zu speichernden Daten aus der Sicht des Benützers

 

Produkt Leistung

Hier werden alle Leistungen die das System später erbringen muss aufgeführt.

 

Benutzeroberfläche

Je nach Produkt kann dies stark variieren. Wichtig ist allerding, dass folgende Punkte festgehalten werden:

 
 

Bildschirmlayout

Drucklayout

 

Tastaturbelegung

Dialogstruktur

Beispiel: Es muss einen separaten Exit-Knopf zum beende der Software geben.

Qualitäts-

Die Qualitätsmerkmale sollten in operationaler Form vorliegen. Danach wir bestimmt welche Qualitätsmerkmale die jeweilige Qualitätsstufe

Zielbestimmung

zu erfüllen hat.

Globale Testszenarien

Es sollte von Anfang an diverse Testszenarien ausgearbeitet werden, die dann auch bei der Übernahme ausgeführt werden um sicherzustellen, dass alles wie vereinbart funktioniert.

Ergänzungen

Zum Schluss werden hier noch zusätzlich Punkte festgehalten, die in den oberen Spalten nicht genannt wurden. Mögliche Beispiele sind;

baulich oder räumliche Voraussetzungen personelle Voraussetzungen (etwa das alle Mitarbeiter einen Office-Kurs oder einen Buchhaltungskurs besucht haben oder dies noch tun werden damit sie die nötigen Skills für die neu Software mitbringen) Ebenfalls könne hier gesetzliche Vorschriften, (interne) Normen usw. angegeben werden.

Pflichtenheft Aufbau nach IEEE:

1

Einleitung

2 Allgemeine Beschreibung

 

3 Spezifische Anforderungen

1.1

Zielsetzung (Purpose)

2.1

Produkt-Umgebung

Funktionale Anforderungen

1.2

Produktziele (Scope)

2.2

Produkt-Funktionen

Leistungsanforderungen

1.3

Definitionen

2.3

Benutzer-Eigenschaften

Entwurfsrestriktionen

1.4

Referenzen

2.4

Allgemeine Restriktionen

Qualitätsmerkmale

1.5

Überblick

2.5

Annahmen/Abhängigkeiten

Externe Schnittstell

Modellierung (Vorgehen):

 

UML Unified Modelling Language

 
  • 1. Analyse der Realität

  • 2. Entitäten bilden

  • Allgemeine visuelle Modellierungssprache

  • 3. Beziehungen zwischen den Entitäten festlegen

3. Beziehungen zwischen den Entitäten festlegen
 

Beliebige Entwicklungsmethoden

  • 4. Identifikationsschlüssel für jede Entität definieren

4. Identifikationsschlüssel für jede Entität definieren

Gesamte Laufzeit des Software-Systems

  • 5. Komplexe Beziehungen auflösen

5. Komplexe Beziehungen auflösen

Beliebige Applikationsbereiche

  • 6. Attribute für die verschiedenen Entitäten festlegen

6. Attribute für die verschiedenen Entitäten festlegen

Beliebige Medien

 
  • 7. Normalisieren

  • Beschreibt Software-Systeme

  • 8. Logisches Datenbankdesign

8. Logisches Datenbankdesign
 

Spezifikation

  • 9. Physikalisches Datenbankdesign

9. Physikalisches Datenbankdesign

Visualisierung

10.

Am Ziel: Datenbank implementiert!

Am Ziel: Datenbank implementiert!

Konstruktion

Dokumentation

Dokumentation

  • Dokumentiert Entscheidungen und Erfahrungen

  • Sinnvoll, um über Software-Entwicklung zu kommunizieren

Die UML Unified Modelling Language ist eine Sprache zur Spezifikation, Visualisierung, Konstruktion und Dokumentation von Modellen für Unternehmen und Softwaresysteme. Sie bietet den Entwicklern die Möglichkeit, den Entwurf und die Entwicklung von Softwaresystemen auf der Basis einer einheitlichen Sprache zu diskutieren.

Anwendungsfalldiagramme (Use-Case-Diagramme) dienen zur Definition der funktionalen Systemanforderungen und zeigen die wichtigsten Anwendungsfälle (Use Cases) bzw. Systemfunktionen sowie externe Akteure (Benutzer, Systeme), die mit dem geplanten System interagieren. Klassendiagramme sind die zentrale Diagrammart der meisten objektorientierten Modellierungssprachen. Sie zeigen die statische Klassenstruktur des Systems. Dargestellt werden neben den Klassen und ihren internen Strukturen, bestehend aus Attributen, Operationen etc., auch die strukturellen Beziehungen der Klassen untereinander, wie z.B. Assoziationen und Aggregationen/Kompositionen, Abhängigkeiten, Vererbungsbeziehungen und Gruppierungen zu Paketen, mit denen alle Arten von Modellierungselementen logisch zusammengefasst werden können. Objektdiagramme Als Variante dazu gibt es Objektdiagramme, die im Gegensatz zu Klassendiagrammen nur Objekte und Instanzen von Beziehungen zu einem bestimmten Zeitpunkt im Systemablauf zeigen, d.h. sie bilden einen „Schnappschuss“ des Systemzustands zu dem betrachteten Zeitpunkt ab. Aktivitätsdiagramme Zeigen sequentielle und parallele Flüsse von Aktivitäten im System. Dabei kommen typischerweise drei verschiedene Abstraktionsniveaus zum Einsatz. So können Aktivitätsdiagramme zur Beschreibung von Workflows (Vorgangsmodellierung), von Use Cases, sowie für die Spezifikation von Objekt- bzw. Klassenoperationen verwendet werden. Kollaborationsdiagramme sind Objektdiagramme, die zusätzlich ebenso wie Sequenzdiagramme die dynamischen Nachrichtenflüsse darstellen. Sequenzdiagramme veranschaulichen den dynamischen Ablauf des Nachrichtenversands zwischen den Objekten, d.h. deren Interaktion. Zustandsdiagramme beziehen sich i.d.R. auf einzelne Klassen und beschreiben den Lebenszyklus der Objekte dieser Klasse, d.h. sie spezifizieren mögliche Zustände der Objekte sowie Ereignisse, die zu Zustandsübergängen führen. Komponentendiagramme zeigen die physische Struktur des Codes, wobei sowohl Quellcodekomponenten als auch Binär- und ausführbare Komponenten gemeint sein können. Neben den Komponenten selbst können die Schnittstellen der Komponenten und ihre Abhängigkeiten untereinander explizit dargestellt werden. Einsatzdiagramme illustrieren schliesslich die physische Architektur der Hard- und Software im System. Es werden die zum Einsatz kommenden Computer und Geräte (Knoten) und ihre Verbindungen untereinander dargestellt. Innerhalb der Knoten befinden sich ausführbare Komponenten und Objekte, die auf dem betreffenden Knoten ausgeführt werden.

UML-Vorgehensweise

  • 1 Von den Anforderungen zu Klassendiagrammen

und dann über Use Case Diagrammen zu Interaktionsdiagrammen zu Zustandsübergangsdiagrammen

parallel Übergang zu OOD mit Hilfe von Komponentendiagrammen

Aktivitätsdiagramme nahezu beliebig zur Ablaufveranschaulichung

oder

  • 2 Von den Anforderungen zu Use Case Diagrammen

und dann Aktivitätsdiagrammen zur Detailbeschreibung von Use Cases

und dann über Klassendiagramme zu Interaktionsdiagrammen

und dann zu Zustandsübergangsdiagrammen parallel Übergang zu OOD mit Hilfe von Komponentendiagrammen

(Beide Ansätze nur grobe Richtlinien!)

Use-Case Diagramme:

    Zeigen die benötigten Interaktionen zwischen dem System und den Akteuren Werden durch
Zeigen die benötigten Interaktionen zwischen dem System und den Akteuren
Werden durch Szenarios beschrieben (Normalfall + Problemfälle)
Grundlage für die Erstellung des Systems (müssen daher vollständig sein!)
Grundlage für das Testen des Systems nach der Erstellung
 Tastaturbelegung  Dialogstruktur Beispiel: Es muss einen separaten Exit-Knopf zum beende der Software geben. Qualitäts-

Es können grundsätzlich vier Arten der Assoziationen unterscheiden werden:

Einfache (Min 1, Max 1)

Konditionelle (Min 0, Max 1)

Komplexe (Min 1, Max n) Konditionell komplexe (Min 0, Max n)

 Tastaturbelegung  Dialogstruktur Beispiel: Es muss einen separaten Exit-Knopf zum beende der Software geben. Qualitäts-

Das Spezifizieren von Anforderungen bedeutet Aufwand undkostet Geld. Dennoch retniert sich dieser Schritt, denn Fehlerkposten können einen wesentliochen Teil der Gesamtkosten im Rahmen der Systementwicklung verursachen. Diese Fehlerkosten umfassen sowohl das Lokalisieren als auch das Beheben von Fehlern. Anforderungsfehler sind dabei die teuersten Fehler., weil sie oft erst bei der Abnahme oder währen des Betriebs gefunden werden. Wenn nun Anforderungen gezielt oder systematisch erhoben werden, so können die Einsparungen bei den Fehlerkosten höher sein als die Aufwendungen beim Spezifizieren. Das Ziel heisst klar: Kosten senken!

Folgende Tätikeiten bilden den Anforderungsspezifikationsprozess;

Die Beschaffung (Gewinnung) der Anforderungen

Die Darstelluing der Anforderung

Die Prüfung der Anforderung

Eigenschaften einer guten Anforderungsspezifikation sind:

 

Adäquatheit (das beschreibt, was der Kunde will

Eindeutikeit (damit Fehlinterpretationen vermieden

bzw. braucht)

Wiederspruchsfreiheit

werden können)

Vollständikeit (alles beschreiben, was der Kunde will bzw. braucht)

Verständlichkeit

Prüfbarkeit (damit festgestellt werden kann, ob die Anforderungen erfüllt sind

Die Anforderungen werden am Anfang der Projektarbeit erhoben. Im Phasenmodell vom System Engineering entsprich dies der Phase Vorstudie.

Bevor Daten erhoben werden können, sind folgende Fragen im Rahmen der Vorbereitungen für eine Erhebnung von Informationen zu beantworten:

Welche Infromationen werden benötigt und welche davon sind unerlässlich?

Wo und wie können Informationen gefunden werden?

In welchem Genauikeits- und Detaillierungsgrad müssen die Daten vorliegen?

Welche Methoden und Techniken werden eingesetzt?

Was darf die Erhebung kosten? Welcher Aufwand ist zulässig?

Wie werden Ereignisse plausibilisiert? Wie werden die Ergebnisse dokumentiert?

Die Dokumentenstudie ist die einfachste Art der Informationsbeschaffung.Sie stören dabei niemnaden und können auf eine Fülle von Informationen zurückgreiffen. Beim Dokumentenstudium besteht jedoch die Gefahr, dass die Dokumente nicht vollständig sind und dass sie nicht mehr aktuell sind. Auch kann es sein, dass die Inhalte nicht oder nur teilweise der Realität entsprechen.

Wer erfolgreich ein Interview führen will, sollte folgende Regeln beachten:

Interview sollte in einer vertrauten Umgebung des Befragten stattfinden.

Sinn und Zweck des Interviews sowie zueitrahmen zu beginn des Interviews

Freundliches und zurückhaltendes Auftreten.

bekanntgeben

Das Interview sollte nicht länger als eine Stunde dauern.

Sprachanteile: Interviewer = 15%, Interviewte Person = 85%

Während des Interviews keine persönliche Stellung beziehen, sondern zuhören.

Mit einer kurzen Einleitungsphase eine angenehme Gesprächsatmosphäre schaffen.

Bei der Fragebogentechnik sind schriftlich gestellte Fragen zu beantworten. Vorteile:

Am Ende des Interviews eine positive Atmosphäre schaffen (evt. gibt es ja eine Fortsetzung)

Der Informationsbeschaffer hat während der Erhebung einen geringeren Aufwand

Anonymität kann gewährleistet werden.

Bei geschickter Fragestellung kann die Auswertung evtl. Automatisiert und somit schneller erfolgen.

Personen, die schlech verfügbar sind, können besser erreicht werden.

Mit adäquaten Kundenbedürnissen ist folgendes gemeint Der Kunde bzw. die gestellte Aufgabe gibt bestimmte Anforderungen vor. Es muss sichergestellt werden, dass die erhobenen Informationen genau diesen Anforderungen (des Kunden) entsprechen.

Unter Abstraktion versthet man Verallgemeinerung, das Absehen vom Besonderen und Einzelnen. Das Gegenteil von Abstraktion ist Konkretisierung. Unter Abstrahieren versteht man das Absehen vom Konkreten, das Herausheben des Wesentlichen aus dem Zufälligen, das Erkennen gleicher Merkmale. Anstelle von Abstraktion spricht man auch von Modellbildung. Durch Abstrahieren vom Konkreten macht mans ein Modell der realen Welt. Bei der Software-Entwicklung findet ein ständiges Wechselspiel zwischen Abstrahieren und Konkretisieren statt. Die Erstellung eines Produktmodells erfordert das Absehen vom Speziellen und Konzentration auf das Wesentliche und Allgemeine. Die Realisierung des konkreten Software-Systems wiederum erfordert die Konkretisierung des abstrakten Produktmodells.

Datenbanken bieten folgende Möglichkeiten:

Inegrierte Speicherung unterschiedlicher Daten

Programmunabhängige Verwaltung von Daten

Vielfältige Verarbeitungsmöglichkeiten

Eine Realitätsanalyse hat im Rahmen einer Datenmodellierung zwingend zu erfolgen.Sie dient dazu, in erster Linie Informationen zu beschaffen. Am Ende einer Realitätsanalyse wollen wir Aukunft über Ziele, Anfoderungen, Beziehungen, Abläufe usw. Haben. Die Datenmodellierung interessieren die relevanten Datenobjekte.

Eine Domäne stellt eine eindeutig bekannte Kollektion aller zulässigen Eigenschaftswerte einder Eigenschaft dar. Eine Domäne ist also die Menge der zulässigen Werte für ein Attribut. Im Falle der Postleitzahl sind es alle in der Schweiz gültigen PLZ (gem. Verzeichniss der POST).

MIS (Management-Information-System) nennt mann EDV-gestützte Systeme, die Managern verschiedener Hierarchiebenen erlauben, detaillierte und verdichtete Informationen aus einer Datenbasis zu extrahieren.

Aktivitäten der Systemeinführung:

Organisatorische und technische Vorbereitungen

Ausbildung und Unterstützung der Benutzer

Identifikation der Mängel und Durchführung der kurzfristig notwendigen Änderungen

Installationen (Software & Hardware)

Allfällige Parametrisierungen (Benutzer erfassen usw.) Initialload der Daten

Abnahme des in betrieb stehenden Systems Aufnahme des Betriebs

Die Schulung der Benutzer muss sorgfältig geplant werden. Dabei werden schwergewichtig zwei Themenbereiche behandelt:

Umgang mit dem End-User Tool

Wissen über die zur Verfügung stehenden Daten

Zum Zeitpunkt der Systemeinführung muss die Benutzerdokumentation verfügbar sein. Diese besteht aus:

Bedienungsanleitung

Zur Verfügung stehende Standard-Reports

Trainingsunterlagen

Benutzerhandbuch

Verhalten bei Problemen

Das Spezifizieren von Anforderungen bedeutet Aufwand undkostet Geld. Dennoch retniert sich dieser Schritt, denn Fehlerkposten können
Das Spezifizieren von Anforderungen bedeutet Aufwand undkostet Geld. Dennoch retniert sich dieser Schritt, denn Fehlerkposten können
Das Spezifizieren von Anforderungen bedeutet Aufwand undkostet Geld. Dennoch retniert sich dieser Schritt, denn Fehlerkposten können
Das Spezifizieren von Anforderungen bedeutet Aufwand undkostet Geld. Dennoch retniert sich dieser Schritt, denn Fehlerkposten können