Share ZU:
22 April 2014 @ Karsten Krennrich

Anforderungen im ALM

ALM-orientierte Software-Entwicklungsprozesse versprechen Software in „kurzer“ Zeit mit „hoher“ Qualität entwickeln zu können. Die Implementierung der Software basiert auch hier auf Anforderungen von definierten Stakeholdern.

In diesem Blog möchte ich gerne betrachten, wie Anforderungen mit ihren unterschiedlichen Ausprägungen auf unterschiedlichen Abstraktionsebenen in einer ALM-orientierten Entwicklung behandelt werden können.

Betrachten wir hierzu den iterativen ALM Prozess mit den vier Hauptphasen „Define“, „Develop“, „Operate“ und „Adapt“. Die ersten drei Phasen stammen aus der Beschreibung aus [1].

Das Portfolio eines Unternehmens definiert zunächst übergeordnete Ziele, die nicht notwendigerweise auf Funktionen des zu entwickelnden Softwaresystems abzielen.

Diese Ziele und die Anforderungen der Stakeholder (Kundenanforderungen) an das System sind Input für die Definition (Phase „Define“) der Software. Innerhalb dieser Phase werden aus den meist natürlich sprachlich formulierten Anforderungen Features definiert. Die Features beschreiben konkrete Funktionen des Systems, welche den Nutzern zur Verfügung stehen. Diese Features können z.B. mit Hilfe von Use Case Diagrammen und -Beschreibungen spezifiziert werden. Häufig werden die Features auch als Systemanforderungen bezeichnet.

In der Phase „Develop“ des betrachteten ALM Prozesses entstehen aus den Features zunächst „Design Elemente“. Diese können z.B. durch Klassendiagramme, Sequenz- oder Datenflussdiagramme dargestellt werden. Aus diesen bereits sehr formalen „Design Elementen“ wird dann letztlich der Code des Systems implementiert. Teilweise kann dieser auch aus den formalen „Design Elementen“ automatisch generiert werden. Da wir uns hier auf Anforderungen konzentrieren, möchten wir an dieser Stelle nicht auf das kontinuierliche Testen während der Entwicklung eingehen.

In der Phase „Operate“ werden die Funktionen das System oder Teile des Systems in einer operativen Umgebung eingesetzt. Hier kann es passieren, dass der Anwender des Systems Änderungen an der Software wünscht. Hier hat er die Möglichkeit die Änderungswünsche als Ticket in den Prozess zurückzuspielen.

In der Phase „Adapt“ werden die eingegangen Tickets bewertet. Tickets, aus welchen ein Change Request resultiert, werden weiter analysiert. In dieser Analyse entstehen neue oder geänderte Anforderungen, welche wiederum als Input für die Phase „Design“ fungieren. Hier schließt sich der iterative Prozess.

Dieser Beitrag gibt einen kleinen Überblick darüber, wie Anforderungen in ihren unterschiedlichen Ausprägungen innerhalb eines ALM Prozesses eingegliedert werden können. In folgenden Blogbeiträgen wollen wir weitere spannende Aspekte des ALM näher betrachten, erläutern und auch hinterfragen.

 

Quellen:

[1] Richard Hundhausen: Professional Scrum Development with Microsoft® Visual Studio® 2012

Karsten Krennrich

Kontaktieren Sie Michael Jastram

Herr Karsten Krennrich ist als Consultant der HOOD Group tätig. Seine Schwerpunkte liegen in der Beratung von Requirements Engineering (RE) orientierten Entwicklungsprozessen. Er ist als Projektleiter bei der HOOD Software Division verantwortlich für die Realisierung von Softwarelösungen im Bereich der Entwicklungsprozess unterstützenden Werkzeuge. Für diese Anpassungen und Erweiterung von Standard Werkzeugen erarbeitet Herr Krennrich auch die zur Realisierung notwendigen Konzepte. Bei deren Implementierung arbeitet Herr Krennrich unter anderem auch mit den Konfigurationsmanagement Werkzeugen CMSynergy und Subversion. Neben dem RM-Werkzeug DOORS® von IBM hat Herr Krennrich auch Praxiserfahrungen mit den Werkzeugen CaliberRM® von Borland und RequisitePro® von IBM. Er verfügt außerdem über Erfahrungen im Bereich Datenbanken und Informationssysteme, im Software Engineering und im Themenbereich Produktlinien.