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 haltenund 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.
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.
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.
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:
Das SHS muss die Erlaubnis zum Öffnen der Tür überprüfen und innerhalb von 2 Sekunden die Tür öffnen. (U1)
Das SHS muss jede Entriegelung einer Tür auf konfigurierten Handys und Tablets innerhalb von 2 Sekunden anzeigen. (U2)
Der Türsensor muss den Status einer Tür (offen/geschlossen) melden. (U3)
Die Nutzung des SHS muss so einfach wie möglich sein. (U4)
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.
Wir verwenden Cookies, um Inhalte und Anzeigen zu personalisieren, Funktionen für soziale Medien anbieten zu können und die Zugriffe auf unsere Website zu analysieren. Außerdem geben wir Informationen zu Ihrer Verwendung unserer Website an unsere Partner für soziale Medien, Werbung und Analysen weiter. Unsere Partner führen diese Informationen möglicherweise mit weiteren Daten zusammen, die Sie ihnen bereitgestellt haben oder die sie im Rahmen Ihrer Nutzung der Dienste gesammelt haben.
Funktional
Immer aktiv
Die technische Speicherung oder der Zugang ist unbedingt erforderlich für den rechtmäßigen Zweck, die Nutzung eines bestimmten Dienstes zu ermöglichen, der vom Teilnehmer oder Nutzer ausdrücklich gewünscht wird, oder für den alleinigen Zweck, die Übertragung einer Nachricht über ein elektronisches Kommunikationsnetz durchzuführen.
Vorlieben
Die technische Speicherung oder der Zugriff ist für den rechtmäßigen Zweck der Speicherung von Präferenzen erforderlich, die nicht vom Abonnenten oder Benutzer angefordert wurden.
Statistiken
Die technische Speicherung oder der Zugriff, der ausschließlich zu statistischen Zwecken erfolgt.Die technische Speicherung oder der Zugriff, der ausschließlich zu anonymen statistischen Zwecken verwendet wird. Ohne eine Vorladung, die freiwillige Zustimmung deines Internetdienstanbieters oder zusätzliche Aufzeichnungen von Dritten können die zu diesem Zweck gespeicherten oder abgerufenen Informationen allein in der Regel nicht dazu verwendet werden, dich zu identifizieren.
Marketing
Die technische Speicherung oder der Zugriff ist erforderlich, um Nutzerprofile zu erstellen, um Werbung zu versenden oder um den Nutzer auf einer Website oder über mehrere Websites hinweg zu ähnlichen Marketingzwecken zu verfolgen.