• Facebook
  • Google+
  • Twitter
  • XING

Requirements Engineering für Magento Shops

© alphaspirit - Fotolia.com

Sie planen einen neuen Online-Shop und wissen noch nicht genau, wie Sie ins Thema einsteigen sollen? Bitte konfrontieren Sie einen möglichen Dienstleister nicht mit einer Anfrage im Stile von „Wir hätten gerne einen Online-Shop wie Amazon“, sondern machen Sie sich im Vorfeld – bei Bedarf auch mit Hilfe eines erfahrenen Partners – detailliert Gedanken, was Ihre Wünsche, Ziele und Anforderungen hierfür sind, um unnötigen Aufwand zu vermeiden und die Erfolgsaussichten eines Shop-Projektes zu steigern. Ähnlich wie beim Bau eines Hauses benötigt man auch im E-Commerce vor Beginn der eigentlichen Implementierung eine Art Bauplan bzw. ein Dokument mit den entsprechenden Anforderungen und Priorisierungen. Dies ist im Übrigen auch losgelöst von der gewählten Projektmanagementmethodik.

Während man früher klassisch nach dem Wasserfallmodell vorging und hier zuerst ein Lastenheft, danach ein darauf aufbauendes Pflichtenheft und ggf. im Anschluss dann noch technische Feinkonzepte entwickelt hat, dekliniert man bei der agilen Projektmanagementmethode „Scrum“ – die inzwischen sehr häufig zum Einsatz kommt, da sie gegenüber der klassischen Methode einige entscheidende Vorteile mit sich bringt – die Anforderungen nicht bis ins kleinste Detail vorab durch, sondern beschränkt sich hier auf die wesentlichen Elemente und Anforderungen. Die genaue Umsetzung und Ausgestaltung wird dann dem Team überlassen, wodurch deutlich mehr Flexibilität gewährleistet wird und am Ende meist auch deutlich praxisorientiertere Lösungsansätze geliefert werden. Dabei ist besonders wichtig nochmals herauszustellen, dass agil bzw. Scrum mitnichten bedeuten, möglichst schnell und ohne Vorarbeit „einfach mal loszulegen“. Genau das Gegenteil ist hier der Fall.

Mit vorliegendem Artikel möchten wir versuchen, Ihnen den Einstieg in das Thema etwas zu vereinfachen und einige Hilfsmittel an die Hand zu geben, mit denen Sie zielgerichtet effizient und strukturiert zum Ziel kommen. Wir beziehen uns dabei in einigen Bereiche auf die Shopsoftware Magento und die damit einhergehenden Besonderheiten, wobei der überwiegende Teil allgemein gültig ist und für jede Art von Technologie verwendet werden kann.

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)

SMART Requirements

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.

Strukturierung und Abstimmung

„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.

Prüfung und Bewertung

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)

Wie ordnet sich das Requirements Engineering im gesamten Projektverlauf ein?

Die nachfolgende Grafik soll hierbei Aufschluss geben. Dabei wird sehr schnell klar, dass das Thema fester Bestandteil der eigentlichen Projekt(umsetzungs-)phase ist, wobei bereits im Sales-Prozess auf die grundlegenden Anforderungen und High-Level-Requirements eingegangen werden sollte:

Quelle: Requirements Engineering Training, Magento Inc.

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.

User Stories

Bei User Stories handelt es sich um eine Methode mit der (Business-)Requirements so erfasst werden, dass der Inhalt und Wert der Anforderungen von jedem Projektbeteiligten verstanden wird. Dabei wird jede User Story mit einem Satz unter Berücksichtigung nachfolgeder Vorgaben formuliert:

  • Wer profitiert, wenn die Anforderung umgesetzt ist?
  • Was ist der Benefit?
  • Warum handelt es sich dabei um einen Benefit?

Kurz- und allgemein gefasst wird eine User Story immer nach folgendem Schema formuliert:

„Als <Handelnder> möchte ich <Ziel>, damit ich <Benefit>.“

Dabei handelt es sich bei einer User Story um die kleinste denkbare Einheit eines zu liefernden Systems. Eine User Story ist entweder erledigt oder noch nicht – Zwischenstufen gibt es nicht!

User Stories beinhalten sowohl Front- als auch Backendfunktionalitäten.

Beispiel:

Ein Händler möchte die in Magento standardmäßig vorhandene Inputbox zur Eingabe der Verkaufsmenge durch ein Dropdown mit fest vorgegebenen Werten ersetzen.

Diese Anforderung würde in Form einer User Story beispielsweise wie folgt formuliert werden:

„Als Händler möchte ich das Eingabefeld bei der Verkaufsmenge durch ein Dropdown mit fest vorgegebenen Werten ersetzen, damit meine Kunden animiert werden, eine größere Anzahl zu kaufen und keine fehlerhaften Eingabe zu machen.“

Zum Einstieg sollten dabei die folgenden funktionalen Standardbereiche „abgeklopft“ und die Anforderungen in Form der skizzierten User Story Terminologie festgehalten werden:

Quelle: Requirements Engineering Training, Magento Inc.

Sofern bestimmte Standardbereiche nicht relevant sind, sollte diese nicht gelöscht sonder als „Out of Scope“ markiert werden.

Darüberhinausgehende Anforderungen werden als zusätzliche User Stories erfasst, wobei jede User Story folgende Informationen enthalten muss:

  • Eindeutige ID
  • Definition „In Scope“ mit „Ja“ oder „Nein“
  • Priorisierung
  • Verantwortlicher/Zuständiger Ansprechpartner

Hierzu kann folgende Vorlage zur Erfassung von Requirements als Orientierung dienen:

Quelle: Requirements Engineering Training, Magento Inc.

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.

Use Cases

Ein Use Case beschreibt eine spezifische Interaktion zwischen einem User und einer Applikation ohne das User Interface zu spezifizieren und besteht aus den folgenden Parametern:

  • Der Handelnde (derjenige, der die Applikation benutzt)
  • Die Interaktion (zwischen Handelndem und System)
  • Das Ziel (des Handelnden)

Dabei beginnt ein Use Case immer mit dem Ziel des Handelnden und endet sobald das Ziel erreicht wurde.

Use Cases sollte für folgende Bereiche definiert werden, sofern es hier keine 100-prozentig klaren Vorgaben gibt:

  • Integrationen (Schnittstellen)
  • Customizing

Eine User Story kann dabei mehrere Use Cases beinhalten. Es sollte folgendes berücksichtigt werden:

  • Eine User Story definiert einen Bedarf.
  • Ein Use Case beschreibt die Schritte um den Bedarf zu decken.

Nicht jede User Story benötigt auch einen Use Case. Bei folgenden User Story kann demnach auf Use Cases verzichtet werden:

  • Standardfunktionalitäten von Magento
  • Eine User Story ist eindeutig und lässt keinen Raum für Interpretationen.
    Beispiel: Als Administrator möchte ich PayPal Express als Zahlungsoption anbieten, damit meine Kunde mehr Auswahlmöglichkeiten im Bereich Zahlung haben.

Für individuelle Anpassungen und im Bereich Schnittstellen sollte jedoch nach Möglichkeit mit Use Cases gearbeitet werden um hier größtmögliche Sicherheit gewährleisten zu können.

Nachfolgende Elemente gehören zu einem Use Case, der normalerweise in Form eines Prozessdiagramms dargestellt wird:

  • Handelnde
  • Vorbedingung(en)
  • Hauptprozess
  • Alternative Möglichkeiten
  • Nachbedingung(en)
  • Ausnahmen
Use Case in Form eines Prozessdiagramms

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.

Exemplarische Vorgehensweise bei agilem Projektmanagement anhand von User Stories und Use Cases

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.

Autor

Josef Willkommer

Als Geschäftsführer der TechDivision GmbH, einer der führenden Magento- und E-Commerce-Agen- turen im deutschsprachigen Raum, beschäftigt sich Josef Willkommer seit vielen Jahren sehr intensiv mit E-Commerce und Online-Marketing. Darüber hinaus ist er als Chef-Redakteur des eStrategy-Magazins sowie als Autor diverser Fachbeiträge rund um E-Commerce und Online-Marketing auch journalistisch tätig. Neben diversen Beratungs- tätigkeiten für unterschiedlichste Unternehmen trifft man ihn bei diversen Fachkonferenzen auch als Speaker zu E-Commerce- und Online- Marketing-Themen.

www.techdivision.com
j.willkommer@estrategy-magazin.de

www.xing.com/profiles/Josef_Willkommer


Kommentare (0)

Keine Kommentare gefunden!

Neuen Kommentar schreiben

  • Facebook
  • Google+
  • Twitter
  • XING
© 2016 eSTRATEGY-Magazin
Facebook
Twitter
RSS
Xing
Google+