Was bedeutet eigentlich Requirements Engineering oder auf deutsch Anforderungsanalyse. Wikipedia schreibt dazu folgendes:

„Die Anforderungsanalyse (englisch requirements analysis) ist in der Informatik ein Teil des Systementwicklungsprozesses (u. a. neben dem Anforderungsmanagement), sowie ein Teil der Business-Analyse. Ziel ist es, die Anforderungen des Auftraggebers an das zu entwickelnde System zu ermitteln, zu strukturieren und zu prüfen.

Institute of Electrical and Electronics Engineers (IEEE)
Laut IEEE kann das requirements engineering in Anforderungserhebung (requirements elicitation), Anforderungsanalyse (requirements analysis), Anforderungsspezifikation (requirements specification) und Anforderungsbewertung (requirements validation) unterteilt werden. Diese Schritte überlappen einander und werden oft auch mehrfach – iterativ – durchgeführt.

Vorgehen
In allen bekannten Modellen zum Requirementsengineering existieren die folgenden Schritte in der einen oder anderen Form. Dabei werden Anforderungen gesammelt (englisch elicitation), es soll durch Analyse ein gemeinsames Verständnis hergestellt werden, die Anforderungen müssen niedergeschrieben oder in Modellen niedergelegt, d. h. spezifiziert werden. Danach wird üblicherweise geprüft, ob das Ganze noch stimmig ist (englisch validation). Rund um diese Schritte existiert eine Verwaltung des Prozesses, das Management.

Ermittlung, Analyse
Beim Sammeln der Anforderungen (engl. elicitation) ist der Übersetzungsprozess zwischen Fachseite und Entwickler von besonderer Bedeutung. Folgende Kriterien sind zu erfüllen:

• vollständig
  Alle Anforderungen des Kunden müssen explizit beschrieben sein, es darf keine impliziten Annahmen des Kunden über das zu entwickelnde System geben.

• eindeutig definiert / abgegrenzt
  Präzise Definitionen helfen, Missverständnisse zwischen Entwickler und Auftraggeber zu vermeiden.

• verständlich beschrieben
  Damit sowohl der Auftraggeber als auch der Entwickler mit vertretbarem Aufwand die gesamten Anforderungen lesen und verstehen kann.

• atomar
  Es darf nur eine Anforderung pro Abschnitt oder Satz beschrieben sein. Das Kriterium für ein „Atom“ sollte die Entscheidbarkeit einer Anforderung sein.

• identifizierbar
  Jede Anforderung muss eindeutig identifizierbar sein (z. B. über eine Kennung oder Nummer).

• einheitlich dokumentiert
  Die Anforderungen und ihre Quellen sollten nicht in unterschiedlichen Dokumenten stehen oder unterschiedliche Strukturen haben.

• nachprüfbar
  Die Anforderungen sollten mit Abnahmekriterien verknüpft werden, damit bei der Abnahme geprüft werden kann, ob die Anforderungen erfüllt wurden. Testfälle werden aus den Abnahmekriterien abgeleitet. Siehe auch Verifizierung.

• rück- und vorwärtsverfolgbar
  Es muss nachverfolgbar sein, ob eine Anforderung vollständig erfüllt wurde (vorwärts). Ebenso soll für jede implementierte Funktionalität kontrollierbar sein, aufgrund welcher Anforderungen sie erstellt wird (rückwärts), um Überflüssiges zu vermeiden.

• Konsistent
  Die definierten Anforderungen sind untereinander widerspruchsfrei.

Quelle: https://de.wikipedia.org/wiki/Anforderungsanalyse_(Informatik)

Häufig wird bei der Ermittlung von Requirements auch von der sog. S-M-A-R-T Methode gesprochen, die als Abkürzung für folgende Anforderungen steht:

S = Specific (möglichst genau)
M = Measurable (messbar)
A = Attainable (machbar)
R = Realistic (realistisch)
T = Time-bound (zeitgebunden)

Nachfolgend möchten wir die einzelnen Aspekte nochmals etwas genauer beleuchten:

Specific

Eine gute Anforderung ist möglichst spezifisch und nicht allgemein. Es sollte möglichst wenig Interpretationsspielraum vorhanden sein. Dabei sollte Formulierungen wie „und“, „oder“, „aber“ vermieden werden, da diese zu Missverständnissen führen können. Darüberhinaus müssen undifferenzierte Angaben wie „bald“, „schnell“ oder „sofort“ vermieden werden.

Negativbeispiel: Der Report sollte alle monatlichen Daten der Marketingabteilung enthalten.

Positivbeispiel: Der Report sollte die folgenden Spalten enthalten: Gesamtverkäufe pro Monat, Durchschn. Verkaufspreis, Verkaufte Anzahl, Bestand, Verkaufskosten gesamt.

Measurable

Damit sollte es möglich sein, festzustellen ob die Anforderung erledigt ist. Hier besteht insbesondere bei der Verwendung von nicht quantitativen Aussagen die Gefahr von Missverständnissen und darauf basierenden Fehlern bei der Implementierung.

Negativbeispiel: Das System soll eine optimale Reaktionszeit für den Enduser gewährleisten.

Positivbeispiel: Das System sollte eine Reaktionszeit bei On-Klick-Events von max. 5 Sekunden oder weniger gewährleisten.

Attainable

Die Anforderungen sollten grundsätzlich erreichbar bzw. machbar und angemessen sein. Können die Anforderungen unter den gegebenen Bedingungen auch tatsächlich realisiert werden?

Negativbeispiel: Der monatliche Verkaufsreport und die monatlichen Finanzdaten sollten jeweils am ersten Werktag eines Monats verfügbar sein.

Positivbeispiel: Der monatliche Verkaufsreport soll jeweils am ersten Werktag eines Monats verfügbar sein. Die monatlichen Finanzdaten werden bis zum dritten Werktag eines Monats bereitgestellt.

Realistic

Kann die Anforderung generell bzw. überhaupt erfüllt werden?

Negativbeispiel: Der Verkaufsreport wird an die Produktion am oder vor dem 01.11.2013 geliefert. Das Problem hierbei ist, dass nach Analyse der dafür notwendig Tasks und Ressourcen das genannte Datum nicht machbar ist.

Positivbeispiel: Es muss gewährleiste werden, dass nach Lieferung der monatlichen Zahlen, die zur Weiterbearbeitung notwendigen Zeiten und Ressourcen verfügbar sind.

Time-bound

Es muss klar und unmissverständlich definiert werden, wann bzw. wie schnell eine Anforderung fertig gestellt werden muss.

Negativbeispiel: Der Report wird nach Monatsende baldmöglichst bereitgestellt.

Positivbeispiel: Der Report wird nach erfolgreich und komplett fertig gestelltem Monatsabschluss bis Mittag des darauffolgenden Werktages bereitgestellt.

Das Ergebnis der Anforderungsaufnahme ist eine Liste mit Anforderungen (Requirements). Diese kann bei klassischem Projektmanagement nach dem Wasserfallmodell z. B. in ein Lastenheft überführt oder bei agilem Projektmanagement als Basis für sog. User-Stories verwendet werden. Was es damit auf sich hat erläutern wir etwas später.

„Nach der Erfassung muss eine Strukturierung und Klassifizierung der Anforderungen vorgenommen werden. Damit erreicht man, dass die Anforderungen übersichtlicher werden. Dies wiederum erhöht das Verständnis von den Beziehungen zwischen den Anforderungen. Kriterien sind hierbei:

• abhängig
  Anforderungen müssen daraufhin überprüft werden, ob eine Anforderung die Voraussetzung für eine andere ist, sich gegenseitig bedingen oder sich unabhängig voneinander realisieren lassen.

• zusammengehörig
  Anforderungen, die fachlich-logisch zusammengehören, sollen nicht allein realisiert werden.

• rollenbezogen
  Jede Benutzergruppe hat ihre eigene Sicht auf die Anforderungen, die damit unterstützt werden soll.

Weitere Strukturierungsmöglichkeiten sind funktionale und nichtfunktionale Anforderungen sowie fachlich motivierte (fachliche und technische) und technisch motivierte (nur technische) Anforderungen. Die so strukturierten Anforderungen müssen dann zwischen Kunde und Entwickler abgestimmt werden. Diese Abstimmung kann gegebenenfalls zu einem iterativen Prozess werden, der zur Verfeinerung der Anforderungen führt.

Nach der Strukturierung, zum Teil auch parallel dazu, erfolgt die Qualitätssicherung der Anforderungen nach diesen Qualitätsmerkmalen:

• korrekt
  Die Anforderungen müssen untereinander widerspruchsfrei sein.

• machbar
  Die Anforderung muss realisierbar sein.

• notwendig
  Was nicht vom Auftraggeber gefordert wird, ist keine Anforderung.

• priorisiert
  Es muss erkennbar sein, welche Anforderungen die wichtigsten sind. Ziel der Priorisierung ist es, häufig benötigte oder dem Kunden besonders wichtige Funktionen vor den weniger häufig benötigten bereitzustellen. Man erreicht es über eine Quantifizierung der Funktionszweige.

• nutzbar, nützlich
  Auch bei teilweiser Realisierung soll bereits ein produktives System entstehen.“

Quelle: https://de.wikipedia.org/wiki/Anforderungsanalyse_(Informatik)

Bevor jedoch mit dem eigentlichen Requirements Engineering begonnen wird, sollte das gesamte Projekt in einer Projektplanungsphase umrissen und die nachfolgenden Parameter geklärt und festgehalten werden:

• Allgemeine Projektinformationen
  a) Scope und grundlegende Ziele (High-Level-Requirements)
  b) Identifizierung der primären Stakeholder
  c) Definition der Befugnisse des Projektleiters

• Stakeholder Map
  a) Grundlegende Identifizierung aller beteiligten Parteien
  b) Definition der Rollen und Verantwortlichkeiten
  c) Festhalten der Interessen und Erwartungen der Stakeholder

• Projektplanung
  a) Grundlegende Vorgehensweise mit groben Zeitfenstern
  b) Stakeholder mit entsprechenden Aufgaben und Abhängigkeiten

Die Ergebnisse der groben Projektplanungsphase werden dann im Rahmen eines Kick-Off-Workshops mit allen Projektbeteiligten verfeinert, verifiziert, abgestimmt und final festgehalten. Darüberhinaus dient der Kick-Off-Workshop dazu die wesentlichen Anforderungen (Requirements) aller relevanten Projektbeteiligten zu erfassen und nach Business-Value zu priorisieren.

Erfassen der Anforderungen

Die genaueren Anforderungen werden dabei in drei grundlegende Segmente unterteilt und nacheinander aufgerollt:

• 1. Funktionale Anforderungen
  Hierbei wird definiert, was ein System leisten muss. Das „wie“ wird hierbei ausgeblendet:
  a) Magento Standard
  b) Customizing

• 2. Integrationsanforderungen (3rd Party Integration, Schnittstellen)

• 3. Infrastrukturelle Anforderungen (Hardware/Hosting, Monitoring)

Wichtig dabei ist, dass alle involvierten Parteien bei der Erfassung der Anforderungen mitarbeiten und aktiv ihren Beitrag leisten. Vermeiden Sie dabei insbesondere auch im Zweifelsfall mit Annahmen zu arbeiten. Sollten Dinge unklar sein bzw. Raum für Interpretationen vorhanden sein, Fragen Sie bitte detailliert nach! Am Ende sollten die Anforderungen für alle Projektbeteiligten klar, verständlich und nachvollziehbar sein. Beachten Sie hierbei die bereits skizzierte SMART-Methode, die für das Erfassen von Anforderungen zwingende Gültigkeit hat.

In der Praxis hat sich hierbei bewährt, für den Requirements Engineering Prozess eine Magento-Testinstanz aufzusetzen und die vom Kunden geäußerten Anforderungen „on the fly“ in Magento zu zeigen bzw. die Magento Standardfeatures zu demonstrieren um hier möglichst frühzeitig für alle Beteiligten ein klares Gefühl im Hinblick auf Standard vs. Customizing zu schaffen. Wichtig dabei ist auch, etwaige technische Aspekte so lange auszublenden, bis die Anforderung auch wirklich verstanden wurde.

Ganz wichtig: Am Ende des Erfassungsprozesses sollte der Projektverantwortliche auf Dienstleisterseite die Anforderungen nochmals mit eigenen Worten vortragen um etwaige Missverständnisse weitestgehend von Beginn an ausschließen zu können.

Priorisierung von Anforderungen

Nach dem die Anforderungen erfasst und von allen relevanten Projektbeteiligten auch verstanden wurden, erfolgt die Priorisierung der Requirements, wobei hier primär nach sog. Business-Value vorgegangen werden sollte. Darunter versteht man den wirtschaftlichen Wert einer Anforderung für den Shopbetreiber. Demnach haben Features, die wirtschaftlich negative Auswirkungen auf einen Online-Shop haben können, ein höheres Gewicht erhalten. Dazu zählt beispielsweise der komplette Checkout-Prozess, ohne den ein Shop wertlos ist. Auch Schnittstellen – insbesondere zur Warenwirtschaft – werden einen hohen Business-Value erhalten.

Für die Priorisierung kann auf die sog. MoSCoW Technik zurückgegriffen werden. Diese Abkürzung steht für:

Must – Die Anforderung ist zwingend erforderlich
Should – Hochpriorisierte Anforderung, die vorhanden sein sollte
Could – Wünschenswerte Anforderung, die jedoch nicht zwingend erforderlich ist
Won´t – Die Anforderungen wird (zumindest vorerst) nicht benötigt, jedoch für die Zukunft in Betracht gezogen

Techniken und Quellen zur Sammlung von Anforderungen

Um ein möglichst umfassendes Bild der entsprechenden Requirements zu erhalten, sollten unterschiedliche Quellen und Techniken verwendet werden:

• 1. Brainstorming mit den relevanten Stakeholdern
  a) Vorab klare Zieldefinition
  b) Generierung von möglichst vielen Ideen
  c) Möglichst großer Freiraum und Ausblenden von etwaigen Limitierungen
  d) Keine Kritik oder Diskussion während der Ideensammlung
  e) Abschließende Diskussion und Kombination

• 2. Analyse vorhandener Dokumente/Dokumentationen
  a) Prüfung der bestehenden Systemdoku
  b) Vergleich der Anforderungen des bestehenden mit dem zukünftigen System („As is“ und „to be“ Analyse)
  c) Entwicklung von Fragen, um die Vollständigkeit der Anforderungen validieren zu können

• 3. Interviews mit den Stakeholdern
  a) Verstehen der Ziele und Erwartungen der einzelnen Stakeholder
  b) Erkennen der jeweiligen Sichtweise des Interviewte
  c) Herausfinden von Problemen eines Users, um diese möglichst genau und vollständig zu beschreiben

• 4. Fokusgruppen
  a) Gemanagter Prozess mit spezifischen Teilnehmer unter Berücksichtigung folgender Punkte: Bedarf, Möglichkeiten, Probleme
  b) Gefahr durch „Herdentrieb“

• 5. Interface Analyse
  a) Prüfung der Touchpoints mit externen Systemen
  b) User-Centric Design Ansatz (= nutzerorientierte Gestaltung)„Die nutzerorientierte Gestaltung zielt darauf ab, interaktive Produkte so zu gestalten, dass sie über eine hohe Gebrauchstauglichkeit (Usability) verfügen. Dies wird im Wesentlichen dadurch erreicht, dass der (zukünftige) Nutzer eines Produktes mit seinen Aufgaben, Zielen und Eigenschaften in den Mittelpunkt des Entwicklungsprozesses gestellt wird.“ (Quelle: Wikipedia)

• 6. Prototyping
  a) Demo einer Magento Standardinstallation
  b) Erlaubt sofortiges und eindeutiges User-Feedback
  c) User können sehr schnell fehlende Features identifizieren

• 7. Workshops
  a) Strukturierter Ansatz
  b) Richtige und vollständige Auswahl der Teilnehmer
  c) Schnelle und übergreifende Generierung von Anforderungen
  d) Gute Vorbereitung und Moderation zwingend erforderlich

Die Erfassung der funktionalen Anforderungen erfolgt im Rahmen der Anforderungsaufnahme bei einer agilen Projektvorgehensweise – die insbesondere im Rahmen von E-Commerce-Projekten aufgrund der erhöhten Flexibilität – klar zu favorisieren ist, durch sog. User Stories und Use Cases.

Nach Erfassung aller User Stories sollten diese dann idealerweise mit allen relevanten Stakeholdern nochmals geprüft und ggf. nochmals angepasst werden.

Für manche User Stories werden im Anschluss noch sog. Use Cases benötigt, die in der Folge kurz erläutert werden.

Die Aufgabe des Requirements Engineering Prozesses besteht nun darin, alle Anforderungen eines Shop-Projektes anhand von User Stories und Use Cases abzubilden, zu priorisieren und anhand der Ergebnisse einen Fahrplan für die Umsetzung zu definieren.

Die Umsetzung erfolgt dann idealerweise agil und iterativ anhand von sog. Sprints, wobei ein Sprint aus n User Stories besteht, zu denen sich das Entwicklungsteam im vorgegebenen Sprintzeitraum (meist 2-3 Wochen) committet. Ein Sprint muss dabei immer in sich abgeschlossen sein und als Ziel auslieferbare und funktionsfähige Software beinhalten. Nach jedem Sprint wird das Ergebnis in Form eines sog. Sprint Reviews den relevanten Stakeholdern präsentiert. Die Feedbacks auf die Präsentation fließen daraufhin in den weiteren Projektverlauf und die weiteren Sprints ein. Damit wird zum einen höchstmögliche Flexibilität und zum anderen auch größtmögliche Praxisorientierung garantiert.

Wer jetzt tiefer in das Thema Requirements Engineering einsteigen möchte, dem sei das sehr umfangreiche und gut verständliche Magento Training „Requirements Discovery for Successful Magento Implementations“ empfohlen, das für jeden angehenden Shopbetreiber enorm wertvolles Wissen zum richtigen Einstieg in ein Magento-Shop-Projekt vermittelt.

Das Training ist als Online-Seminar konzipiert, besteht aus 4 x 2 Stunden geführtem Training durch einen erfahrenen Consultant und beinhaltet umfangreiche Unterlagen und Checklisten. Die Kosten von $ 1.850.- amortisieren sich dabei aus unserer Sicht vom ersten Tag an. Mehr Infos zu den Inhalten finden Sie auch unter http://www.magentocommerce.com/training/descriptions.

zur Ausgabe