Page 61

BIT 01-2017

BIT 1–2017 | 61 Die zweite Sicht ist die Benutzersicht, die die Interaktion zwischen dem Benutzer und dem System beschreibt. Sie wird durch UML Use Cases dargestellt und durch ihre schriftliche Fixierung spezifiziert. Im Weiteren werden diese zwei Elemente zusammenfassend als Use Cases bezeichnet. Sie ermöglichen Endbenutzern aber auch anderen Stakeholdern, die Funktionalitäten des Output-Systems näher zu bringen, ohne dabei auf technische Einzeleinheiten einzugehen. In der Praxis zeichnen sich Use Cases jedoch nicht durch Übersichtlichkeit und einen hohen Detaillierungsgrad aus. Dies erschwert die Verwendung von Use Cases als Diskussionsgrundlage. Ein Ansatz zur Lösung dieses Problems ist der Document Flow, der genutzt werden kann um die Use Cases zuzuschneiden. So werden kleinere, übersichtliche Modelle erstellt, die mithilfe des Document Flows einen logischen Zusammenhang darstellen. Die dritte Sicht besteht aus drei Dimensionen; die Verhaltens-, Funktionale und Strukturelle Sicht. Diese Sichten verlangen im Gegensatz zu der Benutzersicht ein erweitertes Verständnis der Anforderungen bzw. der Prozesse des Output-Systems. Die Verhaltenssicht wird durch ein UML-Zustandsdiagramm, die Funktionale Sicht durch ein UML-Aktivitätsdiagramm und die Strukturelle Sicht durch ein UML-Klassendiagramm visualisiert. Die Unübersichtlichkeit dieser Diagramme ähnelt der von Use Cases, besonders bei komplexen Output-Systemen. Auch hier bietet es sich an die Sicht dem übergreifenden Document Flow Prozess unterzuordnen. Die Modellierung von Anforderungen in diesen drei Sichten ist eine wertvolle Grundlage für die Erhebung von weiteren Anforderungen. Visualisierte Anforderungen können auf Vollständigkeit geprüft werden. Systematischer Ansatz Die Vorgehensempfehlung ist anwendbar für Neuentwicklungen von (Output) Systemen als auch zur Optimierung (z. B. im Rahmen der Ablösung eines Altsystems). Am Anfang des Projekts sollte der Document Flow den Projektbeteiligten vorgestellt werden und zentral in dem Projekt Repository abgelegt werden. In der Praxis reichen die Prozessschritte nicht aus, da sie nur den Dokumenterstellungsprozess beschreiben. Deswegen sollten weitere Kategorien wie z. B. Nicht-Funktionale Anforderungen, Administration und Integration von peripheren System hinzugefügt werden. Als zweiter Schritt sollten Analysen von Dokumentationen vorgenommen werden, um aus Quellen Anforderungen zu erheben. Nach der vollständigen Dokumentanalyse können die Use Cases modelliert werden. Nicht nur auf der Basis der Dokumentanalysen aber auch auf der Basis von industrieweiten Best Practices ähnlicher Systeme. Schon bei diesem Schritt werden Anforderungen aus der Dokumentation Analyse aktualisiert und verfeinert. So kann sich z. B. abzeichnen, wie viele Rollen oder Fehlerbehandlungen benötigt werden. Nach der Fertigstellung der Use Cases, sollten diese so früh wie möglich mit dem Endnutzer abgestimmt werden und als Grundlage für Workshops verwendet werden. Der vierte Schritt beinhaltet die Modellierung der abgestimmten Anforderungen mithilfe der drei Sichten: Die Verhaltenssicht, die Funktionale Sicht und die Strukturelle Sicht. Mithilfe dieser Sichten können auch Workshops ausgeführt werden, u. a. mit Stakeholdern, die erweiterte Informationen brauchen, sowie Softwareentwicklungsleiter von betroffenen Drittsystemen (z. B. das Archiv). Empfehlungen In ECM-Projekten, vor allem Output- Management-Projekten wird für die Konzeptions- und Analyse-Phase oft nicht genug Zeit und Budget eingeplant. Ein systematischer Ansatz für die Anforderungserhebung, aber auch für das gesamte Anforderungsmanagement sollte jedoch früh geplant und implementiert werden, um eine vollständige mehrdimensionale Sicht zu erstellen. So können nicht nur unterbewusste Begeisterungsmerkmale erhoben werden, sondern auch implizite, meist kundenspezifische Anforderungen. Die Vollständigkeit der Sicht wird durch die mehrfache Modellierung und Überprüfung der verschiedenen Sachverhalte gewährleistet, wodurch auch schnell Konflikte zwischen Anforderungen identifiziert werden können. Davon profitiert das ganze Projekt – wird das System initial richtig definiert, treten später weniger potenziell teure Change Requests auf. Das gesamte Projekt wird effizienter. (www.brainsphere.de) Das Kano-Modell zeigt die drei Arten von Anforderungen, mit denen die Kundenanforderungen klassifiziert werden können Der Document Flow wird als Werkzeug für die Grundlage der Anforderungserhebung genutzt und zur Strukturierung der Anforderungen.


BIT 01-2017
To see the actual publication please follow the link above