Requirement Traceability

“We just learned that the new union contract is changing how overtime pay and shift bonuses are calculated,” Justin reported at the weekly team meeting. “It’s also changing how the seniority rules affect priority for vacation scheduling and shift preferences. We have to update the payroll and staff scheduling systems to handle all these changes right away. How long do you think it will take to get this done, Chris?”

“Man, that’s going to be a lot of work,” said Chris. “The logic for the seniority rules is sprinkled throughout the scheduling system. I can’t give you a decent estimate yet. It’s going to take hours just to scan through the code and try to find all the places where those rules show up.” Source: Wiegers, K., & Beatty, J. (2013). Software requirements. Pearson Education.

Entitäten in Anforderungen

Worüber ich in diesem Beitrag reden möchte sind Entitäten, welche wir in unseren unterschiedlichen Requirements verwenden. In den Anforderungen bekommen wir es oft mit “Entitäten” zu tun, welche “etwas” im System repräsentieren. Beispiel hierfür sind:

• Personen: Meist beschrieben durch Vorname, Nachname, Geschlecht, Geburtstag, …
• Benutzerkonto: Meist beschrieben durch Benutzername, Status, E-Mail, …
• Ausrüstung: Meist beschrieben durch Hersteller, Modell, Chargennummer, Seriennummer, Gewicht, …
• Buch: Meist beschrieben durch Verlag, Format, Seitenanzahl, Autor, …
• Bildschirm: Auflösung, Anschlüsse, Gewicht, Leistungsaufnahme, …

Um diese Entitäten zu beschreiben, bedienen wir uns im Requirement-Engineering oft auch “Grafiken”, da diese komplexen Sachverhalte (u.a. Kardinalitäten) oft besser als Fließtext ausdrücken können. Ein sehr effektives Tool ist die Unified Modeling Language (UML).

Modelle helfen, die Welt besser zu verstehen

All models are wrong, but some are useful" (George E. P. Box)

Wir wissen, dass Modelle immer eine Abstraktion sind und meist nie den vollen Detailgrad beinhalten. Der Detailgrad richtet sich dabei immer nach der Fragestellung, die es zu beantworten gilt. Bei den meisten Requirements interessiert mich:

• Name der Entität
• Eigenschaften (Properties)
• Verbindungen zueinander (im Speziellen die Kardinalitäten)
• Gültigkeitsbereich (in welcher Domäne?)
• Etwaige Einschränkungen (Constraints) e.g. via OCL

Modelle können natürlich auch Vorgänge (Prozesse, Abläufe, …) beinhalten – ich möchte mich allerdings nur auf die Entitäten konzentrieren.

Gibt es in einem Projekt immer nur ein Model?

Nein.

George Fairbanks zeigt es mit seiner Traceability Hierachie sehr schön, wie Modelle, welche u.a. Entitäten beschreiben, zusammenhängen. Ich möchte das anhand eines konkreten Beispiels genauer beschreiben. Hierzu möchte ich folgende vereinfachte Tracebility von Modellen zeigen:

Domain-Model

Bildet die Realität ab und wird vom Analysten durchgeführt. In diesem Fall wurde festgestellt, dass es ein Feuerwehrfahrzeug gibt und dieses einen Bohrhammer beinhaltet. Beide Entitäten haben unterschiedliche Eigenschaften. Doch hier muss man auch folgendes in großen Projekten feststellen: Je nach Domänen haben diese Entitäten unterschiedliche Ausprägungen. Betrachtet man die Entität “Feuerwehrfahrzeug”:

• So interessiert dem Stakeholder, welcher die Ausschreibung betreut, primär der Preis, der Auftragnehmer und die Lieferkonditionen
• Den Fuhrparkleiter interessiert, welche Wartungsintervalle beim Fahrzeug und dem Inventar anzuwenden sind. Man darf hier nicht vergessen: ein hydraulisches Rettungsgerät arbeitet mit fast 700 bar – da will man keine Wartung und Inspektion verpassen.

Eine Methode dieser Herausforderung Herr zu werden, ist der sogenannte Bounded Context, welches Teil der Domain-Driven-Design Tool Suite ist. Man nutzt in einer Domäne daher eine einheitliche Sprache – die Ubiquitous Language

Source: Martin Fowler

Prinzipiell kann der Diagrammstil frei sein. Aber man kann sich dem Klassendiagramm und Objektdiagramm bedienen. Wichtig ist: Diese Diagramme werden nur Repräsentationen enthalten, welchem zum Verständnis beitragen.

Das Design-Model

Anhand von Anforderungen entscheidet z.B. der Architekt, dass man die Entitäten der Domäne “Auschreibung” mit 2 Entitäten abbildet, welche entsprechenden Eigenschaften haben. Hier wird ebenfalls das Klassendiagrammen verwendet. Doch das Ganze ist oft sehr abstrakt und schwer zu verstehen und man untermauert das oft konkreten Instanziierungen in Form von Objektdiagrammen.

Code-Model

Hier modelliert man Klassen und Entity-Relationship-Models, welche Entitäten aus dem Design repräsentieren. Es ist wichtig, dass man sich auf einem Format einigt, der die Traceability zum höheren Model herstellt. Leider ist mir kein Standard bekannt. E.g.

/// <summary>Some summary</summary>
/// <domain>Procurement</domain>
/// <design-model>Generic Equipment</design-model>
/// <description>https://.../requirements/domains/procurement/generic-equipment</description>
/// <feature>https://jira..../browse/FOOBAR-123</feature>
/// <changes>
///   <change>https://jira..../browse/FOOBAR-432</change>
///   <change>https://jira..../browse/FOOBAR-545</change>
/// </changes>
public class GenericEquipment 
{
    // ...
}

Wichtig ist zu beachten, dass natürlich im “refinement” vom Design-Model auch Abstrakte Klassen oder mehrere Klassen rauspurzeln können.

Domain-Driven-Design, obwohl man die Realität abstrahiert bzw. generalisiert?

Eine Interessante Diskussion hatte ich zum Thema DDD: Wenn man wie im Beispiel oben die Realität (Feuerwehrfahrzeug, Bohrhammer) mit einer Equipment Entität abstrahiert – ist das dann noch DDD? Oder muss es immer ein 1:1 Mapping zur Realität geben?

Ein anderes Beispiel: in der Realität gibt es Schiffe, Flugzeuge und Autos – dürfen sie als Transportmittel modelliert werden?

Domain-Driven Design(DDD) is a collection of principles and patterns that help developers craft elegant object systems. Properly applied it can lead to software abstractions called domain models. These models encapsulate complex business logic, closing the gap between business reality and code. Source: https://learn.microsoft.com/en-us/archive/msdn-magazine/2009/february/best-practice-an-introduction-to-domain-driven-design

Wie die Definition schon sagt, handelt es sich bei DDD um eine Sammlung von Prinzipien und Patterns. Schauen wir mal die Literatur durch:

• Domain modeling is not a matter of making as “realistic” a model as possible. Even in a domain of tangible real-world things, our model is an artificial creation.
• Of course there are technical components of the design that may not concern the domain experts, but the core of the model had better interest them.
• If sophisticated domain experts don’t understand the model, there is something wrong with the model.
• When domain experts use this LANGUAGE in discussions with developers or among themselves, they quickly discover areas where the model is inadequate for their needs or seems wrong to them.
• The trouble comes when people feel compelled to convey the whole model or design through UML. A lot of object model diagrams are too complete and, simultaneously, leave too much out. They are too complete because people feel they have to put all the objects that they are going to code into a modeling tool. With all that detail, no one can see the forest for the trees.
• Always remember that the model is not the diagram. The diagram’s purpose is to help communicate and explain the model.
• There are always many ways of abstracting a domain, and there are always many designs that can solve an application problem. This is what makes it practical to bind the model and design. Quelle: Evans, E. (2004). Domain-driven design: tackling complexity in the heart of software. Addison-Wesley Professional.

Zusammengefasst geht es darum, dass Domain und Nicht-Domain Experten miteinander reden können. Schaut man also das Beispiel “Feuerwehr” an: Die Sacharbeiter werden den Term “generisches Equipment” nie in den Mund nehmen. Sie werden sich vermutlich auch nie groß Gedanken drüber machen, welche Gemeinsamkeiten das Fahrzeug und er Bohrhammer haben und welche gemeinsamen Eigenschaften sie in der Beschaffung dafür überhaupt brauchen.

Es liegt also in der Aufgabe des Analysten das zu erkennen. Man würde sich also mit den Domain-Experten auf einen Term wie “Beschaffungsgegenstand” einigen, der dann im Design einem “generisches Equipment” entspricht. Denn: designation bedeutet:

The designation relationship enables you to say that similar things in different models should correspond. (Quelle: Fairbanks, G. (2010). Just enough software architecture: a risk-driven approach. Marshall & Brainerd.)