Spezifikation von Software

Question 1

Lastenheft

Answer 1

• Anforderungen aus Sicht des Auftraggebers
• Ist-Zustand vs. Soll-Zustand
• Funktionale Anforderungen
• Nichtfunktionale Anforderungen
• Grundlage der Angebote potentieller Auftragnehmer

Question 2

Pflichtenheft

Answer 2

• Realisierungsvorhaben aus Sicht des Auftragnehmers
• detailliert das Lastenheft
• enthält Kriterien für die Abnahme
• begründet grundsätzliche Plattformentscheidungen

Question 3

Softwareanforderungen

Answer 3

• schriftlich fixiert, um Missverständnisse zu vermeiden
• funktionale Anforderungen beschreiben, was das System leisten und wie es auf Eingaben und Situationen reagieren soll
• nichtfunktionale Anforderungen beschreiben Beschränkungen der vom System angebotenen Dienste (zeitliche Einschränkungen, Einhaltung von Standards, Plattformkompatibilität)

Question 4

Ursprünge nichtfunktionaler Anforderungen

Answer 4

• Produkt (z.B. min. Anzahl concurrent users)
• Organisation (z.B. Zugriff auf Unternehmensdatenbanken)
• externen Quellen (z.B. Gesetze, Standards)

Question 5

Funktionale Anforderungen sollen..

Answer 5

• vollständig sein, also alles enthalten, was der Benutzer benötigt
• konsistent sein, also keine Widersprüche enthalten

Question 6

Nichtfunktionale Anforderungen

Answer 6

• werden oft als Systemziel formuliert (besser sind messbare Formulierungen)
  z. B. Performance: messbar in Transaktionen pro Sekunde bei gegebener Zahl von concurrent users
  z. B. Portierbarkeit: konkretisierbar mittels Auflistung der Zielplattformen

Question 7

Systemziel

Answer 7

Das System sollte für erfahrene Benutzer einfach zu bedienen und so aufgebaut sein, dass Fehler durch den Benutzer minimiert werden.

Question 8

Verifizierbare nichtfunktionale Anforderung

Answer 8

• erfahrene Benutzer sollen nach 2h Schulung alle Systemfunktionen verwenden können (max. 2 Fehler pro Tag)

Question 9

Dokumentation von Anforderungen

Answer 9

1) Funktionalität beschreiben
2) Systemaktivität beschreiben (Benutzerinteraktionen, Schnittstelleninteraktion)
3) Verbindlichkeitsgrad beschreiben (Vertragsbestandteil, Leistungsausschluss)
4) Daten beschreiben (Muss- und Kannfelder)
5) Bedingungen beschreiben (Pre- und Postconditions in Use-Case-Dokumenten)

Question 10

Arten, um Softwareanforderungen zu formulieren

Answer 10

1) natürliche Sprache (Nachteile: ungenaue, verwirrende Formulierungen und Gefahr der Verschmelzung von Anforderungen)
2) in vorstrukturierten Formularen (z.B. Use-Case-Dokument)
3) als graphisches Modell (Sequenz- und Aktivitätsdiagramme aus UML)

Question 11

Definition Requirement Engineering

Answer 11

• Zur Sammlung der Anforderungen arbeitet das Softwareteam u.a. mit Kunden und Endbenutzern zusammen
• Erfassung von Use Cases
• IT-Terminologie vermeiden

Question 12

Schwierigkeiten bei Requirement Engineering

Answer 12

• Beteiligten haben unklare Erwartungen
• Beteiligte können Erwartungen nicht in Worte fassen
• Beteiligte haben unrealistische Erwartungen
• Benutzung von unternehmensspezifischer Terminologie
• Erwartungen der Beteiligten widersprechen sich

Question 13

Nachgelagerter Prozess Requirement Engineering

Answer 13

Anforderungen werden

• klassifiziert, strukturiert, gruppiert
• priorisiert, verhandelt, Konflikte gelöst
• dokumentiert

Question 14

Requirement Validation

Answer 14

• Validierung der Anforderungen in Review-Meeting von Anbieter und Kunde
• Verständlich? Verifiziert? Vollständig? Widerspruchsfrei? Budget-realistisch?

Question 15

Was kann Requirement Validation vereinfachen?

Answer 15

• früher Prototyp

- frühzeitiges Ableiten von Testfällen aus Anforderungen

Question 16

Pflege der Anforderungen / Change Management

Answer 16

Prozess, der beschreibt, wie über Änderungen entschieden wird und wie sie dokumentiert werden

Question 17

Spezifikation kritischer Systeme

Answer 17

• Besonderheiten in funktionalen (z.B. Wiederherstellung) und nicht-funktionalen Anforderungen (z.B. Verfügbarkeit)
• abstrakte Sicherheitsanforderungen (‘Shall not’-requirements)