Business Requirements an ein CMS

Heute fokussiere ich mich auf das Thema Business Requirements im Kontext von Systemevaluationen. Dabei sind die Erkenntnisse grundsätzlich unabhängig von der Art des Systems, sprich ob es sich dabei um ein Web Content Management System, ein Intranet- oder ein Collaboration-System handelt. Was genau verstehen unsere Kunden und wir unter Business Requirements? Welche besonderen Eigenschaften weisen diese auf? Wie können sie am einfachsten erhoben, respektive wie lassen sich diese zusammen mit anderen Anforderungen bewerten und interpretieren?

Was sind Business Requirements?
Neben den funktionalen Requirements (z.B. bietet das System Downloadcenter-Funktionalitäten?) und nicht-funktionale Requirements (z.B. lässt sich das System in einem LAMP-Stack betreiben?), die typischerweise direkt von den Systembetreibern und Systembenutzern gefordert werden, stellen die Business Requirements Anforderungen dar, die von verschiedenen Business-Stakeholdergruppen ausgehen. Diese Stakeholder stammen typischerweise aus unterschiedlichen Unternehmensbereichen wie zum Beispiel Geschäftsleitung, Marketing, Kommunikation, IT, HR oder dem Einkauf und sind im Rahmen einer umfassenden Evaluation ein fester Bestandteil des Requirement-Katalogs. Dieser setzt sich somit aus den folgenden Anforderungsarten zusammen:

* Funktionale Requirements
* Nicht-funktionale Requirements
* Business Requirements

2518-CMS_Evaluation_Requirements-thumb-500x287-2517.png

Aus Überlegungen und Fragestellungen wie zum Beispiel Lock-in Risiken, Produktmarktanteile, Entwickler-Arbeitsmarktsituation, Distributoren- und Implementierungspartnerdichte werden die Business Requirements abgeleitet und anschliessend priorisiert und bewertet.
Typischerweise werden im Rahmen einer Evaluation alle Requirements gruppiert. Dabei trifft man im Bereich der Business Requirements immer wieder auf die folgenden Anforderungsgruppen:

* Allgemeine Marktanforderungen, z.B. Verbreitungsgrad in der Branche XY > 50%
* Hersteller, Produkt & Support Anforderungen, z.B. Verfügbarkeit von Schulungsangeboten
* Implementierungspartner bezogene Anforderungen, z.B. Anzahl und Grösse der Partner in der Schweiz
* Personalanforderungen, z.B. Existenz eines Arbeitsmarkts für Entwickler mit Knowhow in XY
* Kostenanforderungen, z.B. für Lizenzen, Implementierung, Infrastruktur, Wartung & Betrieb, etc.

Wie werden Business Requirements erhoben?
Business Requirements werden wie die anderen Anforderungen am einfachsten direkt mit den Stakeholdern zusammen erhoben. In einem ersten Schritt gilt es diese Anspruchsgruppen zu identifizieren und zu bestimmen, um im zweiten Schritt mit ihnen zusammen die Anforderungen zu erarbeiten. Je nach Organisationsform, -grösse oder Präferenz können dafür verschiedene Methoden eingesetzt werden wie zum Beispiel geführte Interviews oder Workshops.
Nachdem die Anforderungen aller Stakeholder in einer Rohform vorliegen, müssen diese in priorisier- und bewertbare Anforderungen überführt werden. Diese Transformation ist für Business Requirements häufig schwieriger vorzunehmen als beispielsweise für funktionale Anforderungen, welche sich per se einfacher in eine Form bringen lassen, in welcher man sie sinnvoll bewerten kann.
So kann aus einer vermeintlich einfachen Aussage eines HR-Managers ein ganzer Strauss an Business Requirements abgeleitet werden (fiktives Beispiel):

„Deutschsprachige erfahrene Entwickler muss ich binnen 2-3 Wochen rekrutieren können.“

Daraus ableitbare Business Requirements sind zum Beispiel:

* Es existieren bewährte Plattformen zur raschen und einfachen Personalrekrutierung
* Auf dem betroffenen Arbeitsmarkt sind genügend Personalressourcen verfügbar
* Freelance-Personalressourcen sind neben anderen Ressourcen verfügbar
* Der Arbeitsmarkt ist in den Ländern Schweiz, Deutschland oder Österreich existent
* Der Hersteller bietet Zertifizierungsmöglichkeiten

Alle Requirements der Business-Stakeholder werden neben den anderen Anforderungsarten in einem sogenannten Evaluationsraster zusammengetragen und nachfolgend gruppiert. Eine Vermengung der auf diesem Weg erhobenen Requirements mit aus anderen, bereits bekannter Anforderungen, stellt eine gängige Praxis dar, um aus der bereits vorhandenen Evaluationserfahrung zu profitieren.

Teil 1 unserer Post-Serie, ‚Ein neues CMS?‚, führt in die Thematik CMS-Evaluation ein.

Zum Weiterlesen:

* Ein neues CMS?
* Funktionale und nicht-funktionale Requirements an ein CMS

4 Gedanken zu “Business Requirements an ein CMS

  1. Mehrsprachigkeit wird CMS-abhägig entweder über eine sog. Blatt- oder Baumstruktur gewährleistet oder integriert. Dabei wird in einer Blattstruktur der Inhalt in einem Dokument mehrsprachig gepflegt wohingegen in einer Baumstruktur je Sprache eine Sprachbaum geführt wird. Je nach Verfügbarkeit der Sprachübersetzungen je Seite können Fallbackszenarien vorgesehen werden, dass Seiten welche bspw. nicht in französich verfügbar sind, dann automatisch in der Fallbacksprache Englisch angezeigt werden.

  2. Auch wenn die Frage oben nach Mehrsprachigkeit vermutlich Spam ist, möchte ich zu Andris Antwort hinzufügen: nicht vom Redakteur pflegbare Systemtexte in Templates werden in der Regel mit GNU gettext eingebettet. Also etwa für eine Ausgabe wie „Ihre Suche ergab x Treffer“. Diese Platzhalter können von Programmen wie PO-Edit erfasst werden und können leicht von Übersetzern editiert werden. Heraus kommt eine .po- und eine binär-kompilierte .mo-Datei, deren Inhalte von gettext() an den entsprechenden Stellen eingefügt werden.

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

*

*

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>