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!
Um weiterhin Methodenführer im Requirements Engineering zu bleiben, forschen und entwickeln wir immer weiter rund um Anforderungen. Egal ob natürlichsprachlich oder mittels Diagrammen notiert, in Form von reinen Methoden zur Projektunterstützung oder als Buchprojekte bzw. Trainingsausarbeitungen. Weiterlesen
Wir SOPHISTen haben in den letzten 15 Jahren viel Innovatives im Requirements Engineering erfunden. Dadurch wurde die Qualität im Requirements Engineering (RE) deutlich verbessert, darüber hinaus dessen Bekanntheitsgrad erhöht und weiterhin wurde der Platz des RE als fester Teil im gesamten Entwicklungsprozess gesichert.
Wie kam es jedoch dazu, dass wir stetig neue innovative Produkte im Requirements Engineering entwickelten? Weiterlesen
1. Klären Sie die Ebenen von Anforderungen!
In vielen Projekten entdecke ich während Reviews und Audits vielfach redundante Beschreibungen in fachlichen Konzepten, groben Anforderungen, detaillierten Anforderungen, technischen Konzepten, u.v.m. Diese mehrfach dokumentierten und teils auch mehrfach ermittelten Informationen können teilweise durch eine von Beginn an durchdachte Dokumentenlandschaft vermieden werden. Beginnen Sie sehr früh, bevor die erste Person anfängt erste Anforderungen zu formulieren, mit der Festlegung von deutlich voneinander abgestuften Anforderungsebenen. Dazu führe ich sehr gerne einen kleinen Workshop zur Klärung der Dokumentenlandschaft durch. Während des Workshops zeigen Sie ebenso die mit Anforderungen verbundenen (u.U. nachvollziehbar verfolgten) Informationen auf. Klären Sie die Ebenen von Anforderungen (z.B. Grobkonzept und Feinspezifikation) in Ihrem Projekt immer inklusive exemplarischer Verdeutlichungen mit einem Beispiel. Vermitteln Sie die definierte Dokumentenlandschaft dann an das Projektteam. Weiterlesen
Für „richtige“ Anforderungen ist die Verbindlichkeit typischerweise in einfacher Art und Weise festzulegen: In jedem Satz, in dem beschrieben ist, dass das System etwas tun soll wird ein Hilfsverb muss, sollte, shall, should, o.ä. integriert. Die Abgrenzung des verbindlichen Teils einer funktionalen oder der meisten nicht-funktionalen Anforderungen gegenüber dem Geschäftsprozess, den Nachbarsystemen oder genannten Beispielen ist damit kaum ein Problem. Weiterlesen