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.
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.
Blog-Serie – Teil 2 von 8
Willkommen im Teil 2 der Blog-Serie „Analysetätigkeiten für belastbare Anforderungen“. In diesem und den folgenden 5 Artikeln betrachten wir die im ersten Blogbeitrag erwähnten Analysetätigkeiten nacheinander im Detail.
Hierzu stellen wir zuerst vier Ursprungsanforderungen (U1 – U4) aus einem beispielhaften Smart-Home-System (SHS) vor, die gemäß den Analysetätigkeiten in Ergebnisanforderungen (E1 – Ex) umgewandelt werden:
Als erwähnenswert gelten auch die Regeln aus dem SOPHIST-REgelwerk, die wichtige Hinweise liefern, welche Defizite in den betrachteten Anforderungen vorhanden sind. Ebenso die SOPHIST-MASTeR-Schablone zum Formulieren von Anforderungen.
