Softwaretechnik
Lesson 4
Requirementsengineering
Was für ein System soll entstehen?
Idealfall
Einziger Benutzer und Entwickler und Tester sind identisch
Realfall: Viele Stakeholder
Der Stakeholder ist jemand, dessen Einsatz auf dem Spiel steht und der daher ein Interesse an Wohl und Wehe dieses Einsatzes hat. Im übertragenen Sinne wird „Stakeholder“ heutzutage nicht nur für Personen verwendet, die tatsächlich einen Einsatz geleistet haben, sondern für alle, die ein Interesse am Verlauf oder Ergebnis eines Prozesses oder Projektes haben; beispielsweise auch Kunden oder Mitarbeiter. (Wikipedia)
Stakeholder
-
Ein Auftraggeber (Abteilungsleiter IT)
-
Der Einkauf
-
Der Projektleiter des Kunden
-
Die Testabteilung des Kunden
-
Abteilungsleiter des Fachbereichs
-
Poweruser
-
Poweruser der anderen Abteilung
-
300 oder 300.000 08/15 User
-
Entwickler von Systemen mit denen es Schnittstellen gibt
-
Betrieb
-
Operating
Viele Stakeholder
- viele Ziele
- teilweise wiedersprüchlich
- Wie findet man die Ziele?
- Wie einigt man sich auf Ziele?
- Wie kommt man von diesen Zielen auf Requirements?
- Ist das eigentlich das Gleiche?
- Wie sorgt man dafür das alle das Gleiche verstehen
Ziel
Ein Ziel ist ein in der Zukunft liegender, gegenüber dem Gegenwärtigen im Allgemeinen veränderter, erstrebenswerter und angestrebter Zustand (Zielvorgabe). Ein Ziel ist somit ein definierter und angestrebter Zustand innerhalb einer Ereignisfolge, meist einer menschlichen Handlung zu einem Zweck. (Wikipedia)
Ziele
sind (im Sinne der Vorlesung) sehr grobe Anforderungen
Beispiel: Die Bearbeitung einer Kundenanfrage soll schneller werden
=> Daraus können Sie im Normalfall keine Software bauen
Requirement
Eine Anforderung ist eine Aussage über die notwendige Beschaffenheit oder Fähigkeit,
die von einer Person zur Erreichung eines Ziels benötigt wird, die ein System oder Systemteile erfüllen oder besitzen muss, um einen Vertrag zu erfüllen oder einer Norm, einer Spezifikation oder anderen, formell vorgegebenen Dokumenten zu entsprechen. (Wikipedia)
Definitionsprobleme
Genauer sind Requirments also Aussagen, die war sind wenn ein Ziel erreicht wurde. Dies widerspricht leider der Art und Weise wie Requirements sinnvoller Weise formuliert werden.
Glücklicher Weise kümmert sich nicht wirklich jemand um Definitionen von solchen Dingen.
Ein Spezifikation
Ist die Summe alle Anforderungen
(ja, wir haben eine Zirkelschluss, aber Menschen können damit umgehen)
Title
Anforderungsarten / Kano Modell
Basis- Merkmale
Fehlen führt zu Unzufriedenheit. Erfüllung aber maximal zu Indifferenz
Leistungs-Merkmale
je mehr destso besser.
Begeisterungs-Merkmale
Fehlen sie werden sie nicht vermisst. Aber sie können echte Begeisterung auslösen.
Entwicklung
Begeisterungsmerkmale von Heute entwickeln sich zu Leistungs-Merkmalen von Morgen und den Basis-Mermalen von Übermorgen
Quellen für Anforderungen
Basis-Merkmale
-
Vorgängerversion
-
Handbücher
-
Ähnliche Systeme / Projekte
Achtung: Nicht alles was wie ein Basis-Merkmal aussieht ist eins. Es kann sich auch um einen Bug handeln.
Leistungs-Merkmale
Stakeholder "fragen"
Oft werden nur diese erhoben
Fragentechnik
-
Fragebogen: Fest vorgegebene Fragen -> Viel Teilnehmer
-
Interview: Es entwickelt sich ein Gespräch. Aufwendig
-
Beobachtung: Auch mit Kamera / Recorder. Vorsicht Persönlichkeitsrechte & Betriebsrat
-
Apprenticeship: Kombination der praktischen Erfahrung mit einem frischen Blick auf die Dinge
-
On Site Customer: Intensiver Informationsfluss durch ständige Anwesenheit. Gefahr zu einseitiger Anforderungen
Begeisterungs-Merkmale
Kreativtechniken
- Brainstorming
- Verändern des Produktes:
- Wie sieht die Software aus, wenn wir keinen Monitor verwenden.
- Wenn das System auf dem Mars betrieben wird (massive Latenz)
- Ideen von ganz anderen Bereichen übertragen.
Qualitätskriterien
- Vollständig
- Korrekt
-
Konsistent
-
Prüfbar
-
Eindeutig
-
Verständlich
-
Abgestimmt
-
Klassifizierbar (kann, soll, muss)
-
Notwendig
-
Bewertet (Priorisiert)
-
Gültig und aktuell
-
Realisierbar
-
Verfolgbar
-
Realisierungsneutral
Begriffsklärung
Was ist ein Zug
- Ein physikalische Fahrzeug mit 1-3Lokomotiven und beliebig vielen Wagons?
- Nur die Wagons?
- Ein Fahrzeug wie obiges, dass auf einer bestimmten Strecke fährt?
- Die wiederkehrende Fahrt eines Fahrzeugs (w.o.) auf einer bestimmten Strecke an einem bestimmten Wochentag?
- Die wiederkehrende Fahrt eines Fahrzeugs (w.o.) auf der Strecke von einem Bahnhof zum nächsten?
Glossar
Legen Sie ein Glossar an
-
Verwenden Sie nur die Begriffe aus dem Glossar
-
Genau so wie sie dort definiert sind
-
Synonyme vermeiden und nur die Standardvariante verwenden
-
Besonders wichtig ist dies bei den klassifizierenden Worten: darf, muss, soll
-
Ich habe bisher nicht erlebt, dass das so gelebt wird, aber es wäre bestimmt toll.
Verständlich / Eindeutig
Aktiv Formulieren
Vermeiden Sie passiv Konstruktionen
Nicht "Es wird eine Meldung ausgegeben"
Sondern "Das System gibt eine Meldung aus"
Es wird klarer wer etwas tut.
Es ist einfacher zu lesen
Echte Verben
Vermeiden sie substantivierte Verben
Beispiel: "Durch Knopfdruck startet der Benutzer das Drucken"
Was genau bedeutet "startet das Drucken?"
"Wenn der Benutzer den Knopf drückt zeigt das System den Betriebssystem Druckdialog an."
"Wenn der Benutzer den Knopf drückt druckt das System das Formular auf dem Standarddrucker aus."
Starke Verben
starke Verben, fordern bestimmte Angaben:
-
"drucken"
- Wer?
- Was?
- Wo?
Generalisierungen
Alle / Niemand / Keiner
Immer / Nie
Oft fehlen hier wichtige Einschränkungen
Sätze
- Einfach
- Kurz
- Nebensätze in eigene Anforderungen auftrenen
- Und / Oder / Nicht Konstrukte in Tabellen umwandeln
Abstimmung von Requirements
Requirements sind oft widersprüchlich
Praktisch nie lassen sich alle Requirements umsetzen.
Dabei kommt es zu Konflikten.
Konflikt Eskalationsmodell
Nach Friedrich Glast
- Verhärtung
- Debatte & Polemik
- Taten statt Worte
- Image & Koalition
- Gesichtsverlust
- Drohstrategien
- Begrenzte Vernichtungsschläge
- Zersplitterung
- Gemeinsam in den Abgrund
Konflikt Eskalationsmodell
1-3 Win - Win
4-6 Win-Lose
7-9 Lose-Lose
Verhaltensstrategien
Nur auf den 1. Stufen
-
Diskussion und Zusammenarbeit
- Zwang Druck vs Nachgeben Einlenken
- Vermeidung Verdrängung
Konflikt Gespräch
- Geführt durch neutralen Moderator
- Beide Parteien müssen dazu bereit sein
- Beide Parteien stellen Ihre Sicht der Dinge dar
- Anklagen vermeiden "Du hast"
- Stattdessen "Ich möchte"
- Statement: Wie soll sich die Situation ändern? Realistisch bitte
- Einigung auf konkrete Änderungen
Hilfsmittel
- Emotionen durch Sachinformationen ersetzen
- Kriterien sammeln
- bewerten
- Streng nach Bewertung entscheiden
- Vorgesetzten zur Entscheidung vorlegen
Dokumentation
- Sammlung von Anforderungssätzen
- Use Case
- User Story
- Specification by Example
- Roman
Sammlung von Anforderungssätzen
-
tendentiell sehr fein granular
-
es fehlt der Überblick
-
lassen sich gut nach diversen Kriterien sortieren
Use Case
-
Es wird eine Interaktion eines Users (oder eines anderen Systems) mit dem System beschrieben
-
enthält typischer Weise die folgenden Elemente
- Id
- Name
- Kurzbeschreibung
- Akteure
- Vorbedingung
- Fachlicher Auslöser
- Normalfall
- Varianten
- Nachbedingung
User Story
Formelhafter Satz: Wer, Was, Warum
plus Akzeptanzkriterien
Als ein erfahrener Schachspieler möchte ich dass mir das Programm Zugvarianten zu einer Stellung zeigt, damit ich Partien analysieren und daraus lernen kann.
-
Es werden nur die stärksten Züge gezeigt.
-
Jeder Zug wird gemäß seiner Stärke bewertet.
-
Die Anzeige erfolgt automatisch nach jedem Zug
-
Das Feature kann ein und aus geschaltet werden.
Specification by Example
-
Die Spezifikation erfolgt in tabellarischer Form
- Diese entsteht in Workshops zwischen Stakeholder, Entwickler und Tester
-
Vorteil:
- Sehr konkret
- Kann direkt als Test verwendet werden
-
Wird oft ergänzt durch mehr prosaische Texte als Einleitung.
Nicht funktionale Anforderungen
- technologische Anforderungen
- Es ist Java in Version x.y zu Verwenden.
- Die Anwendung muss auf einem JEE7 konformen Applikationsserver laufen
-
Qualitätsanforderungen
- Änderbarkeit
- Verfügbarkeit
- Performance
- Durchsatz
- Skalierbarkeit
- Wartbarkeit
- Bedienbarkeit
- Robustheit
Nicht funktionale Anforderungen
-
Anforderungen an die Benutzeroberfläche
- Die Benutzer Oberfläche muss dem Windows Design Standard X entsprechen
- Antwortzeiten auf Benutzeraktionen
-
Anforderungen an sonstige Lieferbestandteile
- Muss ein Handbuch, Installationsanleitung geliefert werden?
- Welche Eigenschaften muss das haben?
-
Anforderungen an durchzuführende Tätigkeiten
- Wartung
- Support
- Betrieb
- Projektplanung und Management
Anforderungen ändern sich
-
Es entstehen neue, oder sie werden neu entdeckt.
-
Sie werden detailliert oder überarbeitet
-
In einem Jahr werden ca 10% der Anforderungen geändert.
Anforderungen müssen wie praktisch alle Artefakte der Softwareentwicklung gepflegt werden so lange sie eine Relevanz haben.
Spezifikation bei Example kann hier massiv helfen
Ebenso der agile Ansatz: Ein Thema komplett abarbeiten und ausliefern. Danach ist das Requirement in gewisser Weise erledigt.
Aufgaben
-
Schreiben Sie Zehn Anforderungen für einen Gegenstand ihrer Wal (Waschmaschine, Toaster ...)
- Tauschen Sie die Anforderungen mit Ihrem Kommilitonen
- Finden Sie 10 Möglichkeiten die Anforderungen falsch / widersprüchlich zu interpretieren
- Formulieren Sie für jede Gruppe Stakeholder je zwei Anforderungen, eine Funktionale, eine nicht Funktionale
- Benennen Sie eine andere Gruppe, der wenigstens eine dieser Anforderungen nicht gefallen wird
Literatur
Softwaretechnik Lesson 4
By Jens Schauder
Softwaretechnik Lesson 4
- 1,556
