BLOG-Artikel-Serie Teil 1
DeepSeek ist ein Large Language Model (LLM) eines chinesischen Unternehmens, dass bei üblichen LLM-Tests mit OpenAI und anderen großen LLMs mithalten soll. Der Coup? Das Training des Modells soll nur 5,5 Millionen Dollar gekostet haben [1], also nur ein Bruchteil im Vergleich zu OpenAI und Copilot [2].
Wir haben DeepSeek ausprobiert und wollen hier berichten, wie DeepSeek aus unserer Sicht im Requirements Engineering (RE) abschneidet.
Es ist nun schon ein paar Jahre her, dass wir von unserem hohen Standard in der Informationssicherheit berichtet haben. Wir haben uns in der Zwischenzeit nicht auf unseren Erfolgen ausgeruht. Nein, wir haben weiter an unseren Informationssicherheitsstandards gearbeitet, um unseren Kunden auch weiterhin belegen zu können, dass wir Vertraulichkeit, Verfügbarkeit und Integrität ihrer von uns verarbeiteten Daten gewährleisten können.
In diesem Blogbeitrag – dem letzten und abschließenden der Serie “Gemeinsames Arbeiten mit Anforderungen” möchten wir ein Fazit zu den Problemen und möglichen Lösungen bei der gemeinsamen Arbeit ziehen und die vergangenen Blogartikel nochmal Revue passieren lassen.
Im ersten Blogbeitrag haben wir Ihnen folgende Probleme bei der Arbeit mit Anforderungen aufgezeigt:
Im ersten Blogbeitrag haben wir folgende Erkenntnisse gewonnen:
Innerhalb einer Anforderungsspezifikation ist es gar nicht so leicht, zu erkennen, welche Stände der Anforderungen innerhalb einer Anforderungsspezifikation für die Freigabe relevant sind. Bei der Zusammenarbeit mehrerer Autor*innen an einer Anforderungsspezifikation ist Abstimmungsbedarf nötig, um die Anforderungsspezifikation konsistent zu halten und eine Freigabe der Anforderungsspezifikation erwirken zu können
Der zweite Blogbeitrag zeigt auf, dass Statusmodelle die Anwenderinnen und Anwender dabei unterstützen, den Anforderungsprozess zu durchlaufen. Professionelle RM-Tools bringen in der Regel Mechanismen mit, um Statusmodelle zu konfigurieren. Die identifizierten Probleme kann ein Statusmodell nicht ohne weitere Hilfsmittel lösen.
BLOG-Serie: Teil 4 von 8
Hiermit begrüßen wir Sie zum Teil 4 der Blogserie „Analysetätigkeiten für belastbare Anforderungen“.
In diesem Teil der Blogserie beschäftigen wir uns mit dem Abstrahieren von Anforderungen.
Allgemein ist Abstraktion der Prozess, bei dem wir die wesentlichen Merkmale eines Systems identifizieren und unwichtige Details ausblenden. Dadurch können wir uns auf das große Ganze konzentrieren, ohne uns in den Einzelheiten zu verlieren.
Worum geht es bei dieser Analysetätigkeit?
Blog-Serie – Teil 3 von 8
Willkommen zurück im Teil 3 der Blog-Serie „Analysetätigkeiten für belastbare Anforderungen“. In diesem Teil geht es um das Extrahieren von notwendigen Anforderungen aus der Menge der Stakeholder Wünsche.
Worum geht es bei dieser Analysetätigkeit?
Einigen von Ihnen wird diese Situation vielleicht bekannt vorkommen. Stellen Sie sich vor, Sie werden als Stakeholder damit beauftragt, Anforderungen an ein neues Produkt Ihres Unternehmens zu entwerfen. Natürlich soll das Produkt alle vergleichbaren Produkte auf dem Markt schlagen oder bekannte Probleme in der Industrie lösen.
