Requirements Engineering Übung am 11.11.2011 Maximilian Junker
Organisatorisches Unser Konzept für die Drive-Now Fallstudie ist online (siehe Vorlesungsseite) Bis zum nächsten Mal 4-er Gruppen bilden
Aufgabe 1: Express Repeat
Aufgabe 2 In der dritten Vorlesung haben Sie gesehen welche Auswirkungen und Einflüsse die Anforderungen bzw. das Requirements Engineering allgemein auf die folgenden Prozessschritte hat Projektplanung (Releases, Testplan,... ) Abstimmung zwischen den Stakeholdern (Kunde, Nutzer, Entwicklungsingenieure,... ) Kostenschätzung Auftragsabstimmung und vergabe Entwurf, Realisierung und Integration Verifikation und Abnahme (auch Testspezifikation) Qualitätssicherung zukünftige (Weiter-) Entwicklungen System/Nutzerdokumentation
Projektplanung Vorgehensmodell A-2.3.1f: Hardware/ Software Documentation Diese Artefakte müssen erstellt werden A-2.4: Important is the allocation of tasks to persons that is done by roles... Strukturplanung A-3: Komponentenstruktur Terminplanung A-2.1: The product has to be ready for series production at the beginning of the 3 rd quarter 2006 A-2.4: Three sample states with ten prototypes each have to be provided. Personalplanung A-2.4: The distribution of the roles to persons should be, if possible, constant during the life span of the project.
Abstimmung zwischen Stakeholdern Wer ist ein Stakeholder? A-2.1: The automotives will be sold worldwide. A-2.1: family car Was wird kommuniziert? A-1: If the supplier is acquainted with improved or low-priced alternatives, this fact has also to be communicated to the OEM. Wann wird kommuniziert? A-2.4: A meeting of the project team has to take place every week Sichten der Stakeholder B: Business vs. User vs. System Requirements
Kostenschätzung Wahl der Schätzmethode A-2.1: The application of the described electronic control unit CoSysMo B-User Requirements Use-Case basierte Schätzmethoden Schätzparameter A-2.1: The application of the described electronic control unit Cocomo: Embedded Mode Durchführung der Schätzung A-3: Komponentenübersicht Beschränkung von Teile Kosten B-1.5.2.2.2: The costs of the outside temperature sensor shall not exceed the costs of the outside temperature sensor of model EMP034.
Auftragsabstimmung und vergabe Allgemein Requirements Dokument ist die Basis für die Auftragsvergabe Anforderungen an den Auftragsnehmer (z.b. Zertifizierung) A-2.4: The production process has to be certified by ISO 9000.
Entwurf, Realisierung und Integration Entwurfsparadigma A-2.2: There are four different hardware variants of the instrument cluster. Schnittstellen A-4 Software-Architektur: Software-Architektur wird beeinflusst von nicht-funktionalen Anforderungen, z.b. A-4.3.2.2.1:The reaction time of both, the pointer and the digital display, to a signal given is 500 ms +/- 10 ms Hardware-Architektur A-4.1: Transferred by the CAN bus A-2.4: The provision with replacement parts has to be reliable for at least 20 years after the end of the series production
Verifikation und Abnahme Prototypen als Zwischenprodukte A-2.4: Three sample states with ten prototypes each have to be provided Testdaten für Akzeptanztests A-4.1.2.2.2: Processing of the Signals B-1.X.3: Use-Cases (als Input für Black-Box Systemtests)
Qualitätssicherung Prozessqualität A-2.4: The production process has to be certified by ISO 900 Produktqualität Accuracy: A.2.2.2.2: The display tolerance of the system amounts to 1,5 degree.
Zukünftige (Weiter-) Entwicklungen Geplante Lebensdauer der Software A-2.4: The provision with replacement parts has to be reliable for at least 20 years after the end of the series production. Wartbarkeit A-2.3.1f (Zu erstellende Artefakte): Die Art der Artefakte und deren Qualität beeinflussen die Evolution und Wartung Evolution A-2.4: Any product, idea, patent, etc. developed in the process of the production of the system is part of the ownership of the OEM and is not allowed to be employed in further projects A-4.5.3.2.2.1 Flexibilität in Protokollen für zukünftige Nutzung B-1.4.2.2 The driver is used to the outer appearance and behavior of these light change in the appearance of these lights would be confusing for the driver.
System/Nutzerdokumentation Was wird dokumentiert? A-2.3: Software/ Hardware Dokumentation Wie wird dokumentiert? A-2.3: all documents have to be provided as PDF-files Ausganspunkt für Dokumentation B-1.X.3: Use-Cases
Aufgabe 3 In der Vorlesung wurden die Begriffe Artefakt, Content Item und Concept und deren Zusammenhänge erläutert. Bestimmten Sie für folgende Begriffe, ob es sich dabei um ein Artefakt, ein Content Item oder ein Concept handelt und verknüpfen Sie diese, wo möglich, entsprechend ihrer Zusammenhänge miteinander. UML Aktivitätsdiagramm System Requirements Specification Usage Model System Vision Volere Requirements Shell (VL 3, Folie 61) Stakeholder ER-Diagramm Domain Model Business Specification KAOS Goals
Content Item, Concept, Artefakt Ein Content Item ist ein Inhalt, der durch eine RE-spezifische Aktivität entsteht. Beispiel: Domain-Model Ein Concept ist eine Beschreibungstechnik für Content-Items Beispiel: UML-Klassendiagramm Ein Artefakt ist ein konkretes Dokument, in dem mehrere Content Items beschrieben sind (mittels Concepts). Ein Artefakt hat eine Struktur und kann qualitätsgesichert werden. Beispiel: Lastenheft
Aufgabe 3 UML Aktivitätsdiagramm System Requirements Specification Usage Model System Vision Volere Requirements Shell (VL 3, Folie 61) Stakeholder ER-Diagramm Domain Model Business Specification KAOS Goals Concept Artefakt Content-Item Content-Item Concept Content Concept Content Artefakt Concept Content
Zusammenhänge E/R Diagramm UML Aktivitätsdiagramm System Vision Stakeholder Goals SRS KAOS Usage Model Business Specification Domain Model Volere Template
Aufgabe 4 Analysieren Sie die Struktur dieser beiden Dokumente und bilden Sie dessen Bestandteile auf die Content-Items des ab. Welche Inhalte konnten Sie im Dokument nicht vorfinden oder zuordnen? Welche Risiken ergeben sich damit für den gesamten Lebenszyklus eines qualitätskritischen Systems von der Idee über dessen Entwicklung bis zur Außerbetriebnahme?
Aufgabe 4 - Dokumentstruktur System Requirements: Kapitel 1 Kapitel 2 Kapitel 3 Kapitel 4 Kapitel 5 System Specification Kapitel 1.X.1 Kapitel 1.X.2 Kapitel 1.X.3 Kapitel 1.X.4 Kapitel 2 Kapitel 3 - System Vision, Constraints Functions / Services, (Usage Model) Functions / Services, Data Model, Usage Model (UI), Quality Requirements Usage Model (UI) Objectives/Goals & Constraints Product Contraints Usage Model Functions / Services Usage Model (UI) Data Model
Aufgabe 4 Was fehlt? Zum Beispiel: Stakeholder Evtl. wichtige Stakeholder vergessen, damit Requirements u.u. nicht vollständig Risk Model Risiken nicht systematisch betrachtet.