Lastenheft

Bild von geralt auf Pixabay
Veröffentlichungsdatum: 06-02-2020 Autor: Tim Bischoff Modul­ent­wicklung OXID eShop OXIDforge.org

Modul­lösungen für OXID eShop gibt es sehr viele, die meisten Modul­lösungen werden Individualentwicklungen für einen Kunden sein.

Aber auch bei Individualentwicklungen welche nur für einen speziellen Onlineshop funktionieren müssen lohnt es sich zu Beginn Zeit in die Planung der Modullösung zu investieren.

Planung

Eine ordentliche Planung erhöht die Wahrscheinlichkeit, dass eine Modullösung später erfolgreich im Onlineshop eingesetzt wird und seinen bestmöglichen Nutzen stiften kann.

Ein Lastenheft hilft einem Shopbetreiber dabei seine gewünschte Modullösung zu beschreiben, was sie können sollte.

Zusätzlich eignet sich ein Lastenheft super dazu sich von mehreren Agenturen oder Softwareentwicklern ein Angebot über die Modul­ent­wicklung einzuholen.

Inhalt

Ein Lastenheft beschreibt immer die Kundensicht.

Beschreibung

Fragestellungen die in einer Beschreibung des Moduls beantwortet werden sollten könnten lauten:

  • Welches Problem soll das Modul lösen?
  • Was soll das Modul können?
  • Wo liegt der Kernnutzen vom Modul?

Auftraggeber

Ein guter Einstieg in ein Lastenheft ist es den Auftraggeber zu nennen.

Versionen

Da sich ein Lastenheft in einer Kommunikationsschleife ändern kann ist es hilfreich Versionsänderungen in einer Tabelle festzuhalten.

Shop URL

Die Shop URL wo das Modul - was es zu entwickeln gilt - später eingesetzt wird hilft um einen ersten Eindruck vom Onlineshop zu bekommen.

Shopvserion

Die Shopversion ist ein wichtiges Detail für die Umsetzung. Da es kleine bis sehr große Unterschiede zwischen den OXID eShop Versionen geben kann, welche in die Program­mierung einfließen.

Serverumgebung

Ein Onlineshop ist festverbunden mit seiner Serverumgebung. Für den Auftragnehmer sind daher Informationen wo der Shop gehostet ist und welche PHP Version verwendet wird wichtig.

Theme

Das eingesetzte Theme inklusive Eltern-Theme sollten sich im Lastenheft wiederfinden, damit sichergegangen wird in welcher späteren Frontend Umgebung die Modullösung seinen Dienst tun soll.

Module

Jeder OXID eShop Onlineshop wird nach einiger Zeit bereits verschiedene Modul­lösungen einsetzen.

Diese Modul­lösungen haben einen nicht häufig unterschätzten Einfluss auf die Program­mierung. Da der Programmierer sicherstellen muss, dass Überladungsketten gezielt unterbrochen oder eingehalten werden je nach Anwendungsfall.

Umso mehr Modul­lösungen in einem OXID eShop Onlineshop eingesetzt werden umso höher steigen die Abhängigkeiten die bei einer Entwicklung einer neuen Modullösung berücksichtig werden müssen.

Ein Augenmerk sollte auf die quelloffene Codeauslieferung gelegt werden. Wenn man zwischen den Lizenzerwerb einer quelloffenen oder verschlüsselten Modullösung wählen kann sollte man sich immer für die quelloffene Modullösung entscheiden.

Sprachen

Die Internationalisierung im Onlinehandel schreitet stetig voran. Daher kommen immer mehr Sprachen zum Einsatz.

Daher sollten die benötigten Sprachen aufgezählt werden.

Währungen

Auch sollten die Währungen in einem Lastenheft eine Berücksichtigung finden. Da Währungen in der Darstellung Unterschiede aufweisen.

Funktionale Anforderungen

Mit den funktionalen Anforderungen geht es ins Detail. An dieser Stelle sind neben Ausformulierungen Screenshots, Wireframes und Mockups sehr hilfreich.

Bei einen OXID eShop Onlineshop kann man hier zwischen Frontend und Backend unterscheiden.

Frontend

Unter dem Punkt Frontend sollte man erklären, welche Seitentypen betroffen sind dies können z.B. die Kategorien- und Artikeldetailseiten sein.

Backend

Sollen Dinge über den OXID eShop Admin editierbar sein, dann kann man an dieser Stelle angeben welche zusätzlichen Eingabenfelder und/oder Eingabemasken von der Modullösung erwartet werden.

Nichtfunktionale Anforderungen

Unter nichtfunktionale Anforderungen fallen Punkte wie z.B. Performance, Benutzer­freundlichkeit oder Suchmaschinenfreundlichkeit.

Schnittstellen

Sollen Schnittstellen z.B. in Form einer REST-API Anbindung an einen Drittdienst eingesetzt werden, dann wird dies hier notiert.

Besonderheiten

Viele individualisierte Onlineshops bringen Ihre Besonderheiten mit. Dies könnte z.B. sein, dass es sich um einen OXID eShop aus der Community Edition 4.10er Serie handelt welcher bereits die PHP Version 7.x einsetzt.

Roadmap

Eine Roadmap stellt für mich eine Vorstufe eines Pflichtenheftes dar oder beschreibt Alternativ eine Wiederholungsschleife der Verfeinerung der Anforderungen für das Lastenheft.

Nachdem ein Lastenheft erstellt und erste Angebote damit eingeholt werden wird ein potenzieller Auftragnehmer aus den ersichtlichen Anforderungen eine Art Roadmap erstellen.

Eine Roadmap beinhaltet meist Teilschritte wie der Auftragnehmer gedenkt die Anforderungen umzusetzen.

Meist entstehen durch das Lastenheft noch Rückfragen, so dass das Lastenheft noch Anpassungen unterliegen kann. Vielleicht stellt ein Auftragnehmer fest, dass eine Funktionalität wie vom Auftraggeber beschrieben nicht umsetzbar ist und schlägt eine adäquate Lösung vor.

Pflichtenheft

Auf Grundlage des so entstandenen Lastenheftes kann ein potenzieller Auftragnehmer nun ein Pflichtenheft erstellen wie er gedenkt die definierten Anforderungen zu lösen.

Anhand vom Pflichtenheft entsteht auch der genaue oder ungefähre Kostenrahmen, welcher bei Umsetzung auf den Auftraggeber zukommen würde.

So erhält der Auftragnehmer eine planbare Größe was die Umsetzung des Moduls ihn kosten würden.

Fazit

Der Einsatz von einem Lasten- und Pflichtenheft schafft für beide Vertragspartner eine bessere Arbeitsgrundlage und erhöht eine erfolgreiche, gewinnbringende Umsetzung für beide Vertragspartner.

Lastenheftvorlage

Du möchtest gerne eine Modul­ent­wicklung beauftragen und würdest gerne eine Lastenheftvorlage haben um Dir Angebote für die Modul­ent­wicklung einzuholen, dann stell mir eine unverbindliche Anfrage.

Nach dem Absenden kannst Du Dir meine kostenlose Lastenheftvorlage downloaden.

Unverbindliche Anfrage