Rückblick: SOPHISTische Innovationsprojekte 2012

Was haben Beachvolleyballfans, Fans der Borussia aus Dortmund und SOPHISTen gemeinsam? Richtig, sie schauen stolz und gerne auf das Jahr 2012 zurück.

Intensiv haben wir uns im letzten Jahr interessanten und herausfordernden Innovationsprojekten gewidmet. Blicken Sie mit uns zurück!

Mustergültige Anforderungen – die SOPHIST Templates für Requirements

Ist es nicht frustrierend: Sie meistern die Herausforderung Anforderungen ermitteln und schon stehen Sie vor der nächsten: Wie dokumentieren Sie? Besonders ein strukturiertes Dokumentieren von nicht-funktionalen Anforderungen war bis jetzt schwierig. Eine Sondierung im Rahmen unseres Innovationsprojekts MASTeR bestätigte, dass bestehende Satzschablonen bei der Dokumentation von nicht-funktionalen Anforderungen an ihre Grenzen stoßen. Was bleibt, sind unschöne Formulierungen. Ausgehend von der SOPHIST-Satzschablone für funktionale Anforderungen haben wir eine Satzsschablonenfamilie für nicht-funktionale Anforderungen entwickelt. Nun ist es möglich, eine Vielzahl der nicht-funktionalen Anforderungen sprachlich ordentlich zu formulieren. Ein gewinnbringender Nebeneffekt: Auch die Satzschablone für funktionale Anforderungen konnten wir verbessern, indem sie für detaillierte Anforderungen (Bedingungsschablonen) erweitert wurde. Jede Satzschablone hilft Ihnen, sprachliche Defekte in Ihren Anforderungen zu vermeiden und erhöht deren Qualität in einem optimalen Zeit- und Kostenrahmen. Sie eignen sich zudem für alle Arten von Systemen, sind einfach erlernbar und haben eine einheitliche stilistische Satzstruktur. In diesem Sinne: Frohes Weiterformulieren!

Wissensvermittlung im Requirements-Engineering

Nehmen wir an, Sie möchten einem Kollegen die Nutzung der Satzschablonen für nicht-funktionale Anforderungen näher bringen. Wie gehen Sie da vor? Überfallen Sie ihn einfach und hoffen auf das beste, nämlich die Akzeptanz der neuen Methode? Sie ahnen es schon: Dieses Vorgehen wird nicht von Erfolg gekrönt sein. Dieser Problematik stellten wir uns im Innovationsprojekt WIRE.

Sie können Wissen über Methoden z.B. der Anforderungsermittlungsmethode Brainstorming paradox auf verschiedenste Weise vermitteln und ebenso das fachlich-inhaltliche Wissen in den dokumentierten Anforderungen auf unterschiedliche Weise dem Entwicklerteam vermitteln. Doch egal, wie Sie verfahren, Sie sollten sich immer das Verständnis und die Akzeptanz Ihrer Lerner sichern. Überlegen Sie daher: Was hat Einfluss auf meine Vermittlungsmethode? Solche Einflussfaktoren können u.a. Größe und Vorwissen der Lernergruppe, Art und Kritikalität des Wissens, das ich vermitteln möchte, oder Wichtigkeit des Vermittlungserfolgs sein. Anhand dieser Kriterien wählen Sie Ihre Vermittlungsmethode aus (Partnerarbeit, Frontalunterricht etc.). Übrigens eignet sich das beschriebene Vorgehen auch bestens dazu, nicht enden wollende Meetings optimaler zu gestalten.

Training RE deluxe

Einen ähnlichen Ansatz wie im Innovationsprojekt WIRE verfolgen wir mit der Einführung unseres RE deluxe-Trainings: Wir holen den Anforderungsalltag in unser Training und erzielen durch den Workshopcharakter des Trainings einen größtmöglichen Lerneffekt. Der wirkliche Lernbedarf unserer Trainingsteilnehmer wird bedient. So werden anhand von Praxisbeispielen die sich daraus ergebenden theoretischen Grundlagen vermittelt (und nicht anders herum). Durch diese Simulation ist es unseren erfahrenen Trainern möglich, optimaler auf die Bedürfnisse der Trainingsteilnehmer einzugehen. Sollten Sie also theorieschwere Trainings ohne Praxisbezug satt haben, ist dieses Training genau das richtige für Sie. Hier geht‘s zu weiteren Trainingsinformationen.

Integration von Usability Engineering-Methoden ins Requirements Engineering

Ein Blick in die Praxis war auch der Auslass für Innovationsprojekt Nummer 4. Methoden des Requirements Engineering und Usability Engineering wurden bis jetzt in der Systementwicklung getrennt voneinander betrachtet. Getreu unserem Motto, Althergebrachtes in infrage zu stellen, ist im Innovationsprojekt USER ein methodisches Vorgehen entstanden, das nach der näheren Betrachtung der Ermittlungs- und Dokumentationsmethoden im Usability Engineering, diese mit dem Requirements-Engineering zusammenführte. Einem Aneinander-Vorbei-Arbeiten und -Kommunizieren von Requirements Engineer und Usability Engineer wird so entgegengewirkt. Es ist dem Requirements-Engineer nun möglich, die bisher von ihm typischerweise weniger intensiv analysierten Bedürfnisse und Ziele der Nutzer zu berücksichtigen. Eine verbesserte Anforderungsermittlung einerseits, und die wiederum verminderte Enttäuschung und Frust auf Seiten der Nutzer des Systems andererseits, ist das Ergebnis.

Qualitätsmetriken für Anforderungen

Die Frage, wie lässt sich die Qualität einer geschriebenen Anforderungsspezifikation bewerten, stand im Mittelpunkt eines weiteren Innovationsprojekts. Mithilfe bestehender Kriterien des IEEE wurde eine Methode entwickelt, wie man die Einhaltung der Qualitätskriterien prüfen und nachweisen kann. Solche Kriterien sind beispielsweise Vollständigkeit, Korrektheit, Eindeutigkeit, Identifizierbarkeit. Es ist nun möglich, Kennzahlen für die Qualität einer Anforderungsspezifikation zu erzeugen und so die Einhaltung eines bestimmten Qualitätskriteriums (wie beispielsweise Identifizierbarkeit) zu prüfen.

Auch in diesem Jahr geht es bei SOPHIST innovativ weiter! Unsere Innovationsprojekte für 2013 stehen schon in den Startlöchern bzw. sind bereits gestartet und bald auch auf dieser Webseite. Falls Sie sich die Zwischenzeit mit mehr Informationen zu den fünf obigen Projekten vertreiben wollen, melden Sie sich einfach telefonisch (0911 – 40 900-0) oder per Email (heureka@sophist.de) bei uns. Gern lassen wir Ihnen eine inhaltliche Übersicht eines Innovationsprojekts zukommen.

Hinterlasse eine Antwort

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


1 × fünf =

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>