Direkt zum Hauptinhalt

Plugin-Entwicklung: Anforderungssammlung

Wie sammle ich Anforderungen?

Anforderungen an das geplante Plugin können mit Hilfe der folgenden Methoden gesammelt werden:

Anforderungs-Workshop

Nutzt frühzeitig die Gelegenheit, die Akteure einzubeziehen, die mit dem Plugin arbeiten werden. Je nach Plugin-Idee können das Moodle-Administrator*innen und auch die Nutzer*innen des LMS sein. Ein entsprechender Workshop, bei dem diese Akteure ihre Bedürfnisse äußern können, bietet sich an, um die verschiedenen Perspektiven zu dokumentieren. Damit kann dann die Planung auf die Anforderungen der Akteure zugeschnitten werden.

Interviews & Clusterung

Eine gute Alternative zum Workshop ist es, mit den oben genannten Akteuren Interviews zu führen und so die Anforderungen an das Plugin zu identifizieren. Die Informationen aus den Interviews können dann zu Informationsclustern visuell aufbereitet werden.

Bestehende Lösungsmöglichkeiten analysieren und ggf. Lücken identifizieren

Ein wichtiger erster Schritt besteht stets darin die Plugins zu sichten, die es bereits gibt und sich mit der gleichen Problemlage befassen. So kann das Projektteam herausfinden, ob ein bestehendes Plugin in Kooperation mit den jeweiligen Maintainer*innen weiter entwickelt werden kann oder ob es sinnvoll ist, ein vollständig neues Plugin zu entwickeln. So können ggf. Synergien unter dem Stichwort „Das Rad braucht nicht neu erfunden werden“ genutzt werden.

Geeignete Quellen für die Recherche sind:

Kuratierte Liste im Vereins-Moodle [Link ergänzen]

Bereich Plugins in der Knowledge Base des Vereins

Beispielanalyse Existing Solutions für den Quiz Archiver von Niels Gandraß

Workflow-Diagramm des zu lösenden Problems

Ein solches Diagramm bietet sich bei Plugins an, mit denen ein mehrschrittiger Arbeitsprozess durchgeführt wird. Ein gutes Beispiel für einen solchen Prozess ist die Buchung einer E-Prüfung, für die von der ersten Einreichung bis zum bestätigten Termin sowie der Prüfungsdurchführung eine Vielzahl miteinander verzahnter Schritte durch unterschiedliche Akteure (Buchende*r, Prüfende*r, Service-Team etc.) durchlaufen werden. Wenn im Vorfeld ein Diagramm mit allen Einzelschritten der einzelnen Akteure und ihrer Kommunikation entwickelt wird, dann hilft das dabei, die Anforderungen an das Plugin zu erkennen.

User Stories

User Stories sind ein gutes Mittel, um sich in die Lage der einzelnen Akteure zu versetzen, die mit dem fertigen Plugin arbeiten werden. Für jede*n Akteur*in – bei einem Buchungsprozess einer Prüfung beispielsweise die Personen des Serviceteams – kann aufgeschrieben werden, welche Aktionen die jeweiligen Personen durchführen können sollen und welche Erwartungen sie an Funktionen des Plugins haben. Hier geht es beispielsweise um die einzelnen Rechte (Schreib-, Lese- oder Administrationsrechte) der jeweiligen Akteure.

Autor(inn)en: ?