Thema: Requirements Engineering

Softwareentwicklung definiert sich von den Anforderungen her. Sie zu systematisieren ist nicht leicht. Daher hat sich das Themengebiet des Requirements Engineering etabliert. Unsere Experten geben fundierte Einblicke....

Dr. Kim Lauenroth ist Chief Requirements Engineer bei der adesso AG und verfügt über mehr als zehn Jahre Erfahrung im Software und Requirements Engineering. Er hat Beratungs-, Forschungs- und Entwicklungsprojekte in verschiedensten Branchen durchgeführt, unter anderem für die Automobilindustrie, in der Luftfahrt, der Energiewirtschaft, im Versicherungswesen und in der Gesundheitsbranche. Darüber hinaus engagiert er sich im International Requirements Engineering Board (IREB) e.V. für die Aus- und Weiterbildung im Requirements Engineering.

 Dr. Thorsten Weyer leitet den Bereich „Requirements Engineering“ am Forschungsinstitut „paluno“ (The Ruhr Institute for Software Technology) in Essen. Er war der technische Koordinator der Arbeiten zum modellbasierten Requirements Engineering in der BMBF-Innovationsallianz „Software Plattform Embedded Systems 2020“ (SPES 2020) und leitet die Arbeiten zum Technologietransfer im Nachfolgeprojekt SPES 2020 XT, an dem mehr als 20 namhafte Forschungseinrichtungen und Industrieunternehmen beteiligt sind. Thorsten Weyer ist auch Mitglied und Prüfer des International Requirements Engineering Board (IREB).

Das Requirements Engineering (manchmal auch „Anforderungsmanagement“) nimmt im Entwicklungsprozess von Software bzw. softwarebasierten Systemen eine gestaltende Rolle ein. Aufgabe des Requirements Engineerings ist es, die Anforderungen an das zu entwickelnde System möglichst korrekt, vollständig und präzise zu spezifizieren.

Die im Requirements Engineering spezifizierten Anforderungen nehmen in Entwicklungsprojekten eine zentrale Stellung ein, da diese die Architektur und das Design des Systems prägen und als Referenz für die Qualitätssicherung herangezogen werden.

Typischerweise startet das Requirements Engineering mit einer Idee von dem zu entwickelnden System, die in der Regel durch die Problemstellung oder den Mehrwert charakterisiert wird, den das System seiner Umgebung (Kontext) erbringen soll.

Die Systemidee kann je nach Projektkontext sehr konkret und sehr weit gefasst sein und erlaubt die Bestimmung der Systemgrenze (Scope) und des Systemkontext.
Die Systemgrenze bestimmt den Entwicklungsgegenstand und grenzt die spätere Verantwortlichkeiten des zu entwickelnden Systems von dem ab, was nicht in dessen Verantwortung steht und ggf. von anderen Systemen im Systemkontext erbracht wird. Im Rahmen der Bestimmung des Systemkontexts durch die Kontextgrenze identifiziert der Requirements Engineer sämtliche Aspekte, die in irgendeiner Weise das zu entwickelnde System und damit auch dessen Anforderungen beeinflussen. Um den Systemkontext bestimmen zu können und die Anforderungen des Systems zu ermitteln, greift der Requirements Engineer auf verschiedene Quellen  zurück.

In der Ermittlung von Anforderungen geht es darum, Wissen über den Systemkontext und über die notwendigen Anforderungen in und mit den Quellen aufzudecken, zu erarbeiten und zu sammeln.

Im Rahmen der Dokumentation von Anforderungen wird das in der Ermittlung explizit gemachte Wissen über den Systemkontext und die Anforderungen zweckmäßig dokumentiert.

Durch die Prüfung und Abstimmung von Anforderungen werden Anforderungen auf notwendige Qualitäten hin geprüft, wie z.B. auf Korrektheit, Vollständigkeit oder Eindeutigkeit – aber auch auf den Grad an Übereinstimmung, den die relevanten Stakeholder bezüglich dieser Anforderung haben.

Die Verwaltung von Anforderungen hat die Verantwortung, das dokumentierte Wissen über den Systemkontext und die dokumentierten Anforderungen an das zu entwickelnde System über den des Entwicklungsprojektes hinweg zu verwalten und zu pflegen.

Strategic Architecting

Sprecher / Autor: Rick Kazman

For more than a century, since the “discovery” of the 80-20 principle by the Italian economist Vilfredo Pareto, scholars and practitioners alike have preached the merits of applying this principle in business. The popular thesis, as applied to software development, is that 80% of property X involves only 20% of property Y. For example, “80% of the defects are found in 20% of the code,” or “80% of the value is found in 20% of the features.” The implication of such results seems clear: Focus your efforts on the high-payoff. But the reality is less simple.

Ansehen

Bereitgestellt von:

SEI

zurück


Newsletter abonnieren



Empfehlung an diese E-Mail-Adresse senden:


 

 

 

Ihre eigenen Angaben:

 

 

 

 

Diese Seite empfehlen Sie weiter: