Sie befinden sich hier: Blog  

UML in der Anforderungsanalyse

22. Juni 2012

Die Spezifikation der Requirements sollte in einer semi-formalen Notation erfolgen. Weiterhin basieren viele moderne Methoden der Softwareentwicklung auf objektorientierten Konzepten. Die objektorientierte Analyse setzt auf diese Ausgangssituation auf und nutzt die UML (Unified Modeling Language) bereits erfolgreich während der Analyse von Systemen.

Dabei braucht der Analytiker aus dem Gesamtumfang der UML für seine tägliche Arbeit vor allem vier wesentliche Diagramme. Für die Spezifikation des Verhaltens:

  • Use Case Diagramm
    Stellen die fachliche Beziehung eines Akteurs mit dem System dar und „zerlegen“ das System in handhabbare, logische Teile
  • Aktivitätsdiagramm
    Modellieren das Verhalten des System und geben einen detaillierten Einblick in alle möglichen Abläufe inklusive Nebenläufigkeiten und alternativen Entscheidungswegen
  • Zustandsdiagramm
    Zeigen wie ein Element (z.B. ein Fachklassenobjekt) seinen Zustand verändern kann und wie durch diese Zustandsänderung das Systemverhalten beeinflusst wird

Neben dem Verhalten wird die Systemstruktur spezifiziert. Hier ist für die Analyse vor allem das „Klassendiagramm“  hervorzuheben, wodurch sich statische Eigenschaften und Beziehungen spezifizieren lassen. Hieraus ergeben sich für den Analytiker zwei Vorteile:

  • Zusammenhang  der Fachbegriffe
    Fachbegriffe, die z.B. in einer Use Case Beschreibung zu Missverständnissen führen könnten, werden in einem natürlich-sprachlichen Glossar hinterlegt. Durch die Verwendung des Klassendiagramms lassen sich „Fachklassen/-attribute“ in einen fachlichen Zusammenhang bringen. Auch ein „Mengengerüst“, fachliche Kompositionen,…, sind im Klassendiagramm gut darstellbar. Das Klassendiagramm ergänzt hierdurch das natürlich-sprachliche Glossar.
  • Ein Bild sagt mehr als tausend Worte
    Das früher verwendete „Entity-Relationship-Modell“  wird heutzutage weitgehend durch das Klassendiagramm ersetzt. Dabei übernimmt das Klassendiagramm weniger die spätere Umsetzung der Architektur, sondern schafft vielmehr eine erste, korrekte Sichtweise auf das spätere System. Dieses „Fach(-klassen)konzept“ beantwortet die Frage, wie entsprechende Fachklassen und das Systemverhalten strukturiert sind. Jeder Stakeholder ist somit in Lage sich effizient einen Überblick über das System in seiner fachlichen Beschaffenheit zu bilden.

Die UML ist eine mächtige Technik für die Umsetzung der Objektorientierten Analyse. Mit dem richtigen Wissen über deren Einsatz lassen sich System- und Softwarespezifikationen erstellen die allen Anforderungen genügen.

Erfahren Sie mehr zum Thema UML (und SysML) in unserem „Certified Professional for Requirements Engineering – Advanced Level“-Training.

Gute Schätzungen vor guten Anforderungen?

03. März 2011

Sind gute Schätzungen vor guten Anforderungen möglich? Eine Schätzung ist ein Versuch, begründet Vermutungen über den zukünftigen Verbrauch einer Ressource anzustellen. Die Informationsgrundlage zum Zeitpunkt der Schätzung ist entscheidend für die Qualität einer Schätzung. In der Praxis liegen bei IT-Projekten die tatsächlichen Werte um bis zu 400% über oder unter den initialen Schätzwerten. Eine Abweichung, die  lax formuliert der  “GIGO”-Regel folgt, denn eine frühe Schätzung hat schlichtweg oft keine zufriedenstellende Informationsgrundlage. Weiterlesen »

Knowledge Department erweitert Büros

20. Februar 2011

Knowledge Department hat in dieser Woche die Schlüssel für die nächsten 400 qm Büro- und Seminarräume erhalten. Damit können noch mehr Seminare parallel zu den bekannt hohen Standards in Nürnberg durchgeführt werden. Ebenso sind damit weitere Gruppenarbeitsräume möglich geworden. Noch im Februar 2011 sollen diese Räume für die ersten Kurse zum ISTQB Certified Tester und REQB Certified Professional for Requirements Engineering genutzt werden.

Entscheidungstabellen: logisch-leicht-lösbar

20. Februar 2011

Beim Black-Box-Test betrachtet man das Programm, ohne etwas über dessen innere Beschaffenheit zu wissen bzw. wissen zu müssen. Mit entsprechenden Black-Box-Testverfahren wird dann gegen eine Anforderungsspezifikation geprüft, ob das Programm das tut, was es tun soll. Eine Abweichung zwischen dem „Ist“ des Programms und dem „Soll“ des Programms weist den Tester auf einen möglichen Fehler hin.
Soweit die Theorie.

In der Praxis fehlen uns Testern hier oftmals ganz grundlegende Parameter. Anforderungen von minderwertiger Qualität (oder deren vollkommene Abwesenheit) ist eher die Regel als eine Ausnahme. Eine „Testbarkeit“ der Anforderungen, was einem Qualitätskriterium an Anforderungen entspricht, ist dann natürlich auch nicht gegeben. Das ist unsere Herausforderung. Weiterlesen »

Anforderungen: Grundlagen der Qualität

20. Februar 2011

Qualität ist lateinischen Ursprungs (qualitas, -atis, Eigenschaft, Beschaffenheit) und enthält in seiner ursprünglichen Bedeutung keinerlei Wertung. Das ist hat sich im Laufe der Zeit verändert. Wer heute von „Qualität” spricht, meint implizit „gute Qualität” (denken sie nur an das Gütesiegel „Made in Germany”). Eine Eigenschaft, die jeder von uns auch Software zu- oder abspricht. Was genau sind die Kriterien, mit denen wir uns ein Urteil über die Qualität der Software bilden? Und wie wird „Qualität“ in Software-Produkten überhaupt erreicht? Weiterlesen »

Jede(r) kann Software testen

20. Februar 2011

“Jede(r) kann Software testen!” – Sicher haben Sie dies auch schon mal gehört! Es ist auch wahr. Aber kommt auch das beste Ergebnis dabei heraus? Nicht immer! Es gibt so enorm viele Möglichkeiten, dass bei Software Fehler auftreten. Testen ist da nicht einfach. Eigentlich kann immer etwas falsch sein. Wie testet man da vernünftig? Weiterlesen »