A.4 Produktmuster. OFTCRAFT SOFTCRAFT Projekt. Produktmuster Software-Anforderung. Beschreibung der Anforderung

Transkript

1 ok.book Seite 187 Freitag, 22. Februar :09 16 A.4 OFTCRAFT Projekt Software-Anforderung PM-01 Version JAN-2002 Anforderungs-Nr. Beschreibung der Anforderung Priorität: Typ der Anforderung: Begründung der Anforderung Quelle Datum: REGELWERK Software Standards & Procedures, Version 1.0 vom 21. Februar

2 ok.book Seite 188 Freitag, 22. Februar :09 16 At the leading edge of Software Development {Titel} {Ersteller} {Dokumenten-Nummer} Ersteller: Datum, Name, Unterschrift Unmittelbarer Vorgesetzter des Erstellers: Datum, Name, Unterschrift Projektleiter: Datum, Name, Unterschrift Qualitätsmanagement: Datum, Name, Unterschrift 1. Revision am durch 2. Revision am durch 188 Anhang

3 ok.book Seite 189 Freitag, 22. Februar :09 16 für die System-Spezifikation PM JAN-2002 Das Dokument ist wie folgt zu strukturieren: (1) Titelseite (2) Inhaltsverzeichnis (3) Einleitung (4) Referenzierte Dokumente (5) Anforderungen an das System (6) Behandlung von Daten (7) Anhang Die Titelseite muss die folgenden Informationen enthalten: Die Nummer des Dokuments in der vom Konfigurationsmanagement vorgegebenen Form. Das Projekt, zu dem das Dokument gehört. Den Namen und die Anschrift des Kunden, für den die System-Spezifikation erstellt wurde. Die Firma des Auftragnehmers und die Abteilung, die das Dokument gefertigt hat. Den Namen des Verfassers und seine Unterschrift. Auf dem Titelblatt sollten weiterhin der Leiter der Systemgruppe, der Projektleiter und das Konfigurationsmanagement unterschreiben. Inhaltsverzeichnis Das Dokument Systemanforderungen muss ein Inhaltsverzeichnis enthalten, in dem alle Kapitelüberschriften und die zugehörigen Seitenzahlen aufgeführt sind. Ferner müssen im Inhaltsverzeichnis alle Zeichnungen, die Tabellen und der Anhang mit den Seitenzahlen aufgeführt 1 Einleitung 1.1 Identifikation 189

4 ok.book Seite 190 Freitag, 22. Februar :09 16 für die System-Spezifikation PM JAN-2002 In Abschnitt 1.1 sollen die Dokumentennummer des Dokuments System-Spezifikation genannt werden sowie das Projekt, für das es gilt. 1.2 Überblick über das System In Abschnitt 1.2 soll kurz der Zweck des Systems angesprochen Die Hauptfunktionen können erwähnt 1.3 Überblick über das Dokument In Abschnitt 1.3 soll der Inhalt des Dokuments zusammenfassend beschrieben 1.4 Zusammenhang mit anderen Plänen In diesem Abschnitt soll der Zusammenhang mit anderen Dokumenten hergestellt werden, zum Beispiel zu einer Machbarkeitsstudie für das Projekt. 2 Referenzierte Dokumente Dieses zweite Kapitel soll alle in der Spezifikation referenzierten Dokumente aufführen. Die Angaben müssen so detailliert sein, dass der Leser des Dokuments für ihn notwendige Unterlagen besorgen kann. Bei Bedarf kann Kapitel 2 weiter untergliedert 3 Anforderungen an das System In diesem Kapitel und seinen Gliederungen sollen alle Anforderungen an das System beschrieben 3.1 Gesamtfunktion des Systems In diesem Abschnitt sollen die funktionellen Anforderungen beschrieben werden, wobei das System in Subsysteme heruntergebrochen werden muss. Eines oder mehrere dieser Subsysteme können aus Software bestehen Funktion Funktion Funktion n In diesen Abschnitten sind alle Hauptfunktionen des Systems zu beschreiben. 3.2 Leistungsmerkmale 190 Anhang

5 ok.book Seite 191 Freitag, 22. Februar :09 16 für die System-Spezifikation PM JAN-2002 In diesem Abschnitt sollen die geforderten Leistungen auf Systemebene beschrieben Die Angabe konkreter Zahlenwerte ist sinnvoll. 3.3 Einsatzumgebung In diesem Abschnitt soll beschrieben werden, in welcher Umgebung das System zum Einsatz kommen soll Organisatorische Einbettung In diesem Abschnitt soll beschrieben werden, wie das System innerhalb einer bestehenden oder noch zu schaffenden Organisation eingesetzt werden soll Technische Einbettung In diesem Abschnitt soll beschrieben werden, wie das System in ein bestehendes oder zu schaffendes technisches Umfeld eingebettet ist Nutzung des Systems, Wartung und Pflege Hier soll beschrieben werden, wie das System genutzt werden soll. Außerdem sind die Forderungen zur Wartung und Pflege des Systems zu spezifizieren. Eine Gesamtlebensdauer ist anzugeben. 3.4 Anforderungen an interne Schnittstellen In diesem Abschnitt ist anzugeben, welche Forderungen an interne Schnittstellen bestehen. Es könnte sich um einen Datenbus oder ein genormtes Protokoll handeln. 3.5 Anforderungen an externe Schnittstellen Falls sich das neue System in ein bestehendes Umfeld einfügen muss, sind die Schnittstellen zu diesem Umfeld zu definieren. Falls andererseits keine derartigen Forderungen an das System bestehen, sind die externen Schnittstellen des neuen Systems zu beschreiben Schnittstelle zum Benutzer Hier ist anzugeben, welche Forderungen sich durch den Einsatz eines menschlichen Benutzers ergeben. Ergonomische Gesichtspunkte sind zu berücksichtigen. Die Angabe von Zahlenwerten ist sinnvoll Datenfernübertragung 191

6 ok.book Seite 192 Freitag, 22. Februar :09 16 für die System-Spezifikation PM JAN-2002 Falls das System an externe Netzwerke angeschlossen werden soll, sind hier die Anforderungen an die Schnittstelle zu spezifizieren. 3.6 Kritikalität des Systems In diesem Abschnitt ist anzugeben, welche Kritikalität gefordert wird. Es ist zum Beispiel die mögliche Gefährdung von Menschen zu diskutieren. 3.7 Informationssicherheit In diesem Abschnitt sind die Forderungen zu nennen, die sich aus dem Schutz von Daten gegen unberechtigten Zugriff Dritter ergeben. 3.8 Qualitätsattribute Hier sind Qualitätsattribute zu diskutieren. Dabei kann es sich zum Beispiel um Zuverlässigkeit, Änderbarkeit oder Ausfallsicherheit handeln. 4 Behandlung von Daten In diesem Abschnitt ist zu beschreiben, welche Daten auf Systemebene behandelt werden müssen, und wie mit ihnen zu verfahren ist. Ein Mengengerüst oder die Zugriffshäufigkeit können genannt Anhang Der Anhang kann Material enthalten, das im Rahmen der Systemanforderungen nicht ohne weiteres einzuordnen war. Es muss festgelegt werden, ob der Anhang ein Teil des Dokuments ist. Anhänge sind mit A, B, C usw. zu bezeichnen. 192 Anhang

7 ok.book Seite 193 Freitag, 22. Februar :09 16 für die Machbarkeitsstudie PM AUG Das Dokument ist wie folgt zu strukturieren: (1) Titelseite (2) Inhaltsverzeichnis (3) Einleitung (4) Referenzierte Dokumente (5) Problembeschreibung (6) Zusammenfassung und Empfehlungen (7) Systembeschreibung (8) Technische Risiken (9) Analyse der Wirtschaftlichkeit (10) Rechtliche Bewertung (11) Alternativen (12) Anhang Die Titelseite muss die folgenden Informationen enthalten: Die Nummer des Dokuments in der vom Konfigurationsmanagement vorgegebenen Form. Den Titel der Machbarkeitsstudie. Den Namen und die Anschrift des Kunden, für den die Studie erstellt wurde. Die Firma des Auftragnehmers und die Abteilung, die die Machbarkeitsstudie gefertigt hat. Den Namen des Verfassers und seine Unterschrift. Auf dem Titelblatt sollten weiterhin der Projektleiter für die Studie, ein Vertreter der Firmenleitung und die Qualitätssicherung unterschreiben. Inhaltsverzeichnis Die Machbarkeitsstudie muss ein Inhaltsverzeichnis enthalten, in dem alle Kapitelüberschriften und die zugehörigen Seitenzahlen aufgeführt sind. 193

8 ok.book Seite 194 Freitag, 22. Februar :09 16 für die Machbarkeitsstudie PM AUG Ferner müssen im Inhaltsverzeichnis alle Zeichnungen, die Tabellen und der Anhang mit den Seitenzahlen aufgeführt 1 Einleitung Dieses Kapitel soll wie folgt untergliedert werden: 1.1 Identifikation In Abschnitt 1.1 sollen die Dokumentennummer der Studie, der Titel des Dokuments und eventuell die gebräuchliche Abkürzung des Systems genannt 1.2 Akronyme und Abkürzungen In diesem Abschnitt sollen in Listenform die verwendeten Akronyme und Abkürzungen aufgeführt 2 Referenzierte Dokumente Dieses zweite Kapitel soll alle in der Machbarkeitsstudie referenzierten Dokumente aufführen. Die Angaben müssen so detailliert sein, dass der Leser der Studie für ihn notwendige Unterlagen besorgen kann. Bei Bedarf kann Kapitel 2 weiter untergliedert 3 Problembeschreibung In Kapitel 3 soll das Problem umrissen werden, das gelöst werden muss. Die Umgebung soll skizziert und es müssen alle Hindernisse und Beschränkungen technischer, organisatorischer und wirtschaftlicher Natur aufgezählt werden, die einer Realisierung des Projekts im Wege stehen. 4 Zusammenfassung und Empfehlungen In diesem Abschnitt soll für das Management oder den eiligen Leser in gedrängter Form der Inhalt der Studie zusammengefasst Es sollen alle Ergebnisse der Studie und die sich daraus ergebenden Folgerungen angesprochen 5 Systembeschreibung In diesem Abschnitt soll das zu erstellende System beschrieben werden, wobei die Hauptkomponenten erkennbar sein sollen. 6 Technische Risiken 194 Anhang

9 ok.book Seite 195 Freitag, 22. Februar :09 16 für die Machbarkeitsstudie PM AUG Hier sollen alle erkennbaren technischen Risiken untersucht Gegebenenfalls soll dargelegt werden, wie die Risiken reduziert oder umgangen werden können. 7 Analyse der Wirtschaftlichkeit In diesem Abschnitt soll der geschätzte Aufwand dem Ertrag oder zumindest dem Nutzen des Systems gegenübergestellt Es soll dargelegt werden, dass sich das System lohnt. 8 Rechtliche Bewertung In diesem Abschnitt soll diskutiert werden, welche rechtlichen Konsequenzen sich bei der Realisierung des Projekts ergeben. 9 Alternativen Zuletzt soll untersucht werden, ob sich Alternativen zu dem oben gemachten Vorschlag zur Realisierung des Projekts anbieten. Anhang Der Anhang kann Material enthalten, das im Rahmen der Machbarkeitsstudie nicht ohne weiteres einzuordnen war, zum Beispiel separate Untersuchungen oder Gutachten. Es muss festgelegt werden, ob der Anhang ein Teil der Studie ist. Anhänge sind mit A, B, C usw. zu bezeichnen. 195

10 ok.book Seite 196 Freitag, 22. Februar :09 16 einer Software-Spezifikation PM JAN Das Dokument ist wie folgt zu strukturieren: (1) Titelseite (2) Inhaltsverzeichnis (3) Einleitung (4) Referenzierte Dokumente (5) Anforderungen an die Software (6) Forderungen in Bezug auf die Qualifikation (7) Auslieferung (8) Anhang Die Titelseite muss die folgenden Informationen enthalten: Die Nummer des Dokuments in der vom Konfigurationsmanagement vorgegebenen Form. Den Titel der Spezifikation sowie gegebenenfalls das System, zu dem die Software gehört. Den Namen und die Anschrift des Kunden, für den die Spezifikation erstellt wurde. Die Firma des Auftragnehmers und die Abteilung, die das Dokument gefertigt hat. Den Namen des Verfassers und seine Unterschrift. Auf dem Titelblatt sollten der verantwortliche Projektleiter, der Software- Manager, das Konfigurationsmanagement und die Qualitätssicherung unterschreiben. Inhaltsverzeichnis Das Lastenheft muss ein Inhaltsverzeichnis enthalten, in dem alle Kapitelüberschriften und die zugehörigen Seitenzahlen aufgeführt sind. Ferner müssen im Inhaltsverzeichnis alle Zeichnungen, die Tabellen und der Anhang mit den Seitenzahlen aufgeführt 196 Anhang

11 ok.book Seite 197 Freitag, 22. Februar : Einleitung einer Software-Spezifikation PM JAN Dieses Kapitel soll wie folgt untergliedert werden: 1.1 Identifikation In Abschnitt 1.1 sollen die Dokumentennummer des Lastenhefts, der Titel der Spezifikation und eventuell die gebräuchliche Abkürzung des Systems genannt 1.2 Überblick über das System In Abschnitt 1.2 soll kurz der Zweck des Systems, zu dem die Software gehört, angesprochen Außerdem soll die Rolle der Software im Rahmen dieses Systems beschrieben 1.3 Überblick über das Dokument In Abschnitt 1.3 soll der Inhalt des Lastenhefts zusammenfassend beschrieben 1.4 Akronyme und Abkürzungen In diesem Abschnitt sollen die verwendeten Akronyme und Abkürzungen aufgelistet 2 Referenzierte Dokumente Dieses zweite Kapitel soll die Titel aller im Lastenheft referenzierten Dokumente enthalten. Die Angaben müssen so detailliert sein, dass der Leser der Spezifikation für ihn notwendige Unterlagen besorgen kann. Bei Bedarf kann Kapitel 2 weiter untergliedert 3 Anforderungen an die Software In diesem Abschnitt und seinen Untergliederungen sollen die Anforderungen an die Software beschrieben 3.1 Funktionelle Anforderungen In diesem Abschnitt sollen die funktionellen Anforderungen an die Software beschrieben INPUT In diesem Abschnitt sollen alle Eingaben beschrieben 197

12 ok.book Seite 198 Freitag, 22. Februar : Verarbeitung einer Software-Spezifikation PM JAN In diesem Abschnitt soll die geforderte Verarbeitung im Computer beschrieben OUTPUT In diesem Abschnitt sollen die geforderten Ausgaben beschrieben Dazu gehören auch Angaben zum Format der Daten. 3.2 Leistungsanforderungen In diesem Abschnitt sollen alle Forderungen zur Leistung der Software bzw. des Systems beschrieben Es sollen möglichst Zahlenwerte genannt werden, die messbar und überprüfbar sind. 3.3 Forderungen bzgl. der Datensicherheit In diesem Abschnitt sind alle Forderungen aufzuführen, die sich aus Gründen der Datensicherheit (Security) ergeben. 3.4 Einschränkungen für das Design In diesem Abschnitt sind alle Einschränkungen aufzulisten und zu erklären, die Restriktionen für das Design der Software darstellen. 3.5 Qualitätsattribute In diesem Abschnitt sind geforderte Qualitätsattribute wie zum Beispiel Zuverlässigkeit, Benutzerfreundlichkeit oder Portabilität aufzuführen. 3.6 Schnittstelle zum Benutzer In diesem Abschnitt ist die Schnittstelle zum Benutzer des Systems und der Software zu beschreiben. Es ist darauf zu achten, dass die Forderungen überprüfbar sind. 4 Forderungen in Bezug auf die Qualifikation 4.1 Einleitung In diesem Abschnitt kann eine Norm zitiert werden, nach der die Software erstellt werden muss. Weiterhin sollten bestimmte Arten von Tests vorgeschrieben 198 Anhang

13 ok.book Seite 199 Freitag, 22. Februar :09 16 einer Software-Spezifikation PM JAN Der Ansatz zur Verifikation und Validation der Software während des gesamten Lebenszyklus der Software sollte skizziert Anforderungen an den Test In diesem Abschnitt sollen die Anforderungen für den Test der Software genannt Kriterien für die Akzeptanz der Software In diesem Abschnitt sollen die Kriterien genannt werden, die für die Akzeptanz der Software gültig sind. 5 Auslieferung Hier soll beschrieben werden, in welcher Form die Software an den Kunden ausgeliefert wird. Anhang Der Anhang kann Material enthalten, das im Rahmen der Spezifikation nicht ohne weiteres einzuordnen war. Es muss festgelegt werden, ob der Anhang ein Teil der Spezifikation ist. Anhänge sind mit A, B, C usw. zu bezeichnen. 199

14 ok.book Seite 200 Freitag, 22. Februar :09 16 einer Software-Spezifikation PM JAN Das Dokument ist wie folgt zu strukturieren: (1) Titelseite (2) Inhaltsverzeichnis (3) Einleitung (4) Referenzierte Dokumente (5) Detaillierte Anforderungen an die Software (6) Anhang Die Titelseite muss die folgenden Informationen enthalten: Die Nummer des Dokuments in der vom Konfigurationsmanagement vorgegebenen Form. Den Titel des Lastenhefts sowie gegebenenfalls das System, zu dem die Software gehört. Den Namen und die Anschrift des Kunden, für den das Lastenheft erstellt wurde. Die Firma des Auftragnehmers und die Abteilung, die das Lastenheft gefertigt hat. Den Namen des Verfassers und seine Unterschrift. Auf dem Titelblatt sollten weiterhin der verantwortliche Projektleiter, der Software-Manager, das Konfigurationsmanagement und die Qualitätssicherung unterschreiben. Inhaltsverzeichnis Das Lastenheft muss ein Inhaltsverzeichnis enthalten, in dem alle Kapitelüberschriften und die zugehörigen Seitenzahlen aufgeführt sind. Ferner müssen im Inhaltsverzeichnis alle Zeichnungen, die Tabellen und der Anhang mit den Seitenzahlen aufgeführt 1 Einleitung Dieses Kapitel soll wie folgt untergliedert werden: 1.1 Identifikation 200 Anhang

15 ok.book Seite 201 Freitag, 22. Februar :09 16 In Abschnitt 1.1 sollen die Dokumentennummer des Lastenhefts, der Titel der Spezifikation und eventuell die gebräuchliche Abkürzung des Systems genannt 1.2 Überblick über das System In Abschnitt 1.2 soll kurz der Zweck des Systems, zu dem die Software gehört, angesprochen Außerdem soll die Rolle der Software im Rahmen dieses Systems beschrieben 1.3 Überblick über das Dokument In Abschnitt 1.3 soll der Inhalt des Lastenhefts zusammenfassend beschrieben 2 Referenzierte Dokumente Dieses zweite Kapitel soll alle im Lastenheft referenzierten Dokumente aufführen. Die Angaben müssen so detailliert sein, dass der Leser des Lastenhefts für ihn notwendige Unterlagen besorgen kann. Bei Bedarf kann Kapitel 2 weiter untergliedert 3 Detaillierte Anforderungen an die Software Das Kapitel 3 muss alle Anforderungen an die Software enthalten. Die spezifizierten Anforderungen sollen auf ein Lastenheft des Systems zurückverfolgbar sein. Das Kapitel wird weiter untergliedert Anforderungen an externe Schnittstellen In Abschnitt 3.1 sollen die externen Schnittstellen der Software beschrieben Bei entsprechendem Umfang kann dieser Text ausgegliedert und in der Schnittstellen-Spezifikation beschrieben Schnittstelle zum Benutzer In diesem Abschnitt soll das Interface zum menschlichen Benutzer beschrieben Hardware-Schnittstelle In diesem Abschnitt soll die Schnittstelle zur Hardware beschrieben Software-Schnittstelle einer Software-Spezifikation PM JAN

16 ok.book Seite 202 Freitag, 22. Februar :09 16 In diesem Abschnitt sollen alle externen Schnittstellen der Software beschrieben Kommunikation In diesem Abschnitt soll die Kommunikation mit externen Einheiten, wie zum Beispiel einem Netzwerk zur Datenübertragung, beschrieben 3.2 Geforderte Eigenschaften des Systems In Abschnitt 3.2 und seinen Unterpunkten müssen alle funktionellen Anforderungen des Systems spezifiziert Eigenschaft Zweck der Funktion Stimulus für die Funktion Funktionelle Eigenschaften Funktionelle Eigenschaft Funktionelle Eigenschaft Leistungsanforderungen In Abschnitt 3.3 und seinen Unterpunkten sollen die geforderten Leistungen der Software oder des Systems beschrieben 3.4 Einschränkungen für das Design In Abschnitt 3.4 sollen alle Einschränkungen für den Entwurf der Software aufgelistet 3.5 Sonstige Anforderungen In diesem Abschnitt können zum Beispiel Forderungen bezüglich der Datensicherheit spezifiziert Anhang einer Software-Spezifikation Der Anhang kann Material enthalten, das im Rahmen der Spezifikation nicht ohne weiteres einzuordnen war. Es muss festgelegt werden, ob der Anhang ein Teil der Spezifikation ist. Anhänge sind mit A, B, C usw. zu bezeichnen. PM JAN Anhang

17 ok.book Seite 203 Freitag, 22. Februar :09 16 einer Software-Spezifikation PM JAN Das Dokument ist wie folgt zu strukturieren: (1) Titelseite (2) Inhaltsverzeichnis (3) Einleitung (4) Referenzierte Dokumente (5) Detaillierte Anforderungen an die Software (6) Anhang Die Titelseite muss die folgenden Informationen enthalten: Die Nummer des Dokuments in der vom Konfigurationsmanagement vorgegebenen Form. Den Titel des Lastenhefts sowie gegebenenfalls das System, zu dem die Software gehört. Den Namen und die Anschrift des Kunden, für den das Lastenheft erstellt wurde. Die Firma des Auftragnehmers und die Abteilung, die das Lastenheft gefertigt hat. Den Namen des Verfassers und seine Unterschrift. Auf dem Titelblatt sollten weiterhin der verantwortliche Projektleiter, der Software-Manager, das Konfigurationsmanagement und die Qualitätssicherung unterschreiben. Inhaltsverzeichnis Das Lastenheft muss ein Inhaltsverzeichnis enthalten, in dem alle Kapitelüberschriften und die zugehörigen Seitenzahlen aufgeführt sind. Ferner müssen im Inhaltsverzeichnis alle Zeichnungen, die Tabellen und der Anhang mit den Seitenzahlen aufgeführt 1 Einleitung Dieses Kapitel soll wie folgt untergliedert werden: 203

18 ok.book Seite 204 Freitag, 22. Februar : Identifikation einer Software-Spezifikation PM JAN In Abschnitt 1.1 sollen die Dokumentennummer des Lastenhefts genannt werden, der Titel der Spezifikation und eventuell die gebräuchliche Abkürzung des Systems. 1.2 Überblick über das System In Abschnitt 1.2 soll kurz der Zweck des Systems, zu dem die Software gehört, angesprochen Außerdem soll die Rolle der Software im Rahmen dieses Systems beschrieben 1.3 Überblick über das Dokument In Abschnitt 1.3 soll der Inhalt des Lastenhefts zusammenfassend beschrieben 2 Referenzierte Dokumente Dieses zweite Kapitel soll alle im Lastenheft referenzierten Dokumente aufführen. Die Angaben müssen so detailliert sein, dass der Leser des Lastenhefts für ihn notwendige Dokumente besorgen kann. Bei Bedarf kann Kapitel 2 weiter untergliedert 3 Detaillierte Anforderungen an die Software Das Kapitel 3 muss alle Anforderungen an die Software enthalten. Die spezifizierten Anforderungen sollen auf ein Lastenheft des Systems zurückverfolgbar sein. Das Kapitel wird weiter untergliedert Anforderungen an externe Schnittstellen In Abschnitt 3.1 sollen die externen Schnittstellen der Software beschrieben Bei entsprechendem Umfang kann dieser Text ausgegliedert und in der Schnittstellen-Spezifikation beschrieben Schnittstelle zum Benutzer In diesem Abschnitt soll das Interface zum menschlichen Benutzer beschrieben Hardware-Schnittstelle In diesem Abschnitt soll die Schnittstelle zur Hardware beschrieben 204 Anhang

19 ok.book Seite 205 Freitag, 22. Februar :09 16 einer Software-Spezifikation PM JAN Software-Schnittstelle In diesem Abschnitt sollen alle externen Schnittstellen der Software beschrieben Kommunikation In diesem Abschnitt soll die Kommunikation mit externen Einheiten, wie zum Beispiel einem Netzwerk zur Datenübertragung, beschrieben 3.2 Funktionelle Eigenschaften In Abschnitt 3.2 und seinen Unterpunkten müssen alle funktionellen Anforderungen des Systems spezifiziert Der Abschnitt ist nach den Modi geordnet, in denen sich eine Finite State Machine befinden kann Mode Funktionelle Anforderung Funktionelle Anforderung Mode Funktionelle Anforderung Funktionelle Anforderung n Mode n Leistungsanforderungen In Abschnitt 3.3 und seinen Unterpunkten sollen die geforderten Leistungen der Software oder des Systems beschrieben 3.4 Einschränkungen für das Design In Abschnitt 3.4 sollen alle Einschränkungen für den Entwurf der Software aufgelistet 3.5 Sonstige Anforderungen In diesem Abschnitt können zum Beispiel Forderungen bezüglich der Datensicherheit spezifiziert 205

20 ok.book Seite 206 Freitag, 22. Februar :09 16 Anhang einer Software-Spezifikation PM JAN Der Anhang kann Material enthalten, das im Rahmen der Spezifikation nicht ohne weiteres einzuordnen war. Es muss festgelegt werden, ob der Anhang ein Teil der Spezifikation ist. Anhänge sind mit A, B, C usw. zu bezeichnen. 206 Anhang

21 ok.book Seite 207 Freitag, 22. Februar :09 16 einer Software-Spezifikation PM AUG Das Dokument ist wie folgt zu strukturieren: (1) Titelseite (2) Inhaltsverzeichnis (3) Einleitung (4) Referenzierte Dokumente (5) Detaillierte Anforderungen an die Software (6) Anhang Die Titelseite muss die folgenden Informationen enthalten: Die Nummer des Dokuments in der vom Konfigurationsmanagement vorgegebenen Form. Den Titel des Lastenhefts sowie gegebenenfalls das System, zu dem die Software gehört. Den Namen und die Anschrift des Kunden, für den das Lastenheft erstellt wurde. Die Firma des Auftragnehmers und die Abteilung, die das Lastenheft gefertigt hat. Den Namen des Verfassers und seine Unterschrift. Auf dem Titelblatt sollten weiterhin der verantwortliche Projektleiter, der Software-Manager, das Konfigurationsmanagement und die Qualitätssicherung unterschreiben. Inhaltsverzeichnis Das Lastenheft muss ein Inhaltsverzeichnis enthalten, in dem alle Kapitelüberschriften und die zugehörigen Seitenzahlen aufgeführt sind. Ferner müssen im Inhaltsverzeichnis alle Zeichnungen, die Tabellen und der Anhang mit den Seitenzahlen aufgeführt 1 Einleitung Dieses Kapitel soll wie folgt untergliedert werden: 207

22 ok.book Seite 208 Freitag, 22. Februar : Identifikation einer Software-Spezifikation PM AUG In Abschnitt 1.1 sollen die Dokumentennummer des Lastenhefts genannt werden, der Titel der Spezifikation und eventuell die gebräuchliche Abkürzung des Systems. 1.2 Überblick über das System In Abschnitt 1.2 soll kurz der Zweck des Systems, zu dem die Software gehört, angesprochen Außerdem soll die Rolle der Software im Rahmen dieses Systems beschrieben 1.3 Überblick über das Dokument In Abschnitt 1.3 soll der Inhalt des Lastenhefts zusammenfassend beschrieben 2 Referenzierte Dokumente Dieses zweite Kapitel soll alle im Lastenheft referenzierten Dokumente aufführen. Die Angaben müssen so detailliert sein, dass der Leser des Lastenhefts für ihn notwendige Dokumente besorgen kann. Bei Bedarf kann Kapitel 2 weiter untergliedert 3 Detaillierte Anforderungen an die Software Das Kapitel 3 muss alle Anforderungen an die Software enthalten. Die spezifizierten Anforderungen sollen auf ein Lastenheft des Systems zurückverfolgbar sein. Das Kapitel wird weiter untergliedert Anforderungen an externe Schnittstellen In Abschnitt 3.1 sollen die externen Schnittstellen der Software beschrieben Bei entsprechendem Umfang kann dieser Text ausgegliedert und in der Schnittstellen-Spezifikation beschrieben Schnittstelle zum Benutzer In diesem Abschnitt soll das Interface zum menschlichen Benutzer beschrieben Hardware-Schnittstelle In diesem Abschnitt soll die Schnittstelle zur Hardware beschrieben 208 Anhang

23 ok.book Seite 209 Freitag, 22. Februar :09 16 einer Software-Spezifikation PM AUG Software-Schnittstelle In diesem Abschnitt sollen alle externen Schnittstellen der Software beschrieben Kommunikation In diesem Abschnitt soll die Kommunikation mit externen Einheiten, wie zum Beispiel einem Netzwerk zur Datenübertragung, beschrieben 3.2 Funktionelle Eigenschaften In Abschnitt 3.2 und seinen Unterpunkten müssen alle funktionellen Anforderungen des Systems spezifiziert Der Abschnitt ist nach den Stimuli geordnet, die von außen auf die Software oder das System einwirken Stimulus Funktionelle Anforderung Funktionelle Anforderung Stimulus Funktionelle Anforderung Funktionelle Anforderung n Stimulus n Leistungsanforderungen In Abschnitt 3.3 und seinen Unterpunkten sollen die geforderten Leistungen der Software oder des Systems beschrieben 3.4 Einschränkungen für das Design In Abschnitt 3.4 sollen alle Einschränkungen für den Entwurf der Software aufgelistet 3.5 Sonstige Anforderungen In diesem Abschnitt können zum Beispiel Forderungen bezüglich der Datensicherheit spezifiziert 209

24 ok.book Seite 210 Freitag, 22. Februar :09 16 Anhang einer Software-Spezifikation PM AUG Der Anhang kann Material enthalten, das im Rahmen der Spezifikation nicht ohne weiteres einzuordnen war. Es muss festgelegt werden, ob der Anhang ein Teil der Spezifikation ist. Anhänge sind mit A, B, C usw. zu bezeichnen. 210 Anhang

25 ok.book Seite 211 Freitag, 22. Februar :09 16 Operationelles Konzept PM-08 Version JAN Das Dokument ist wie folgt zu strukturieren: (1) Titelseite (2) Inhaltsverzeichnis (3) Einleitung (4) Referenzierte Dokumente (5) Gegenwärtig eingesetztes System oder Situation (6) Rechtfertigung für Änderungen (7) Systemkonzept (8) Operationen (9) Auswirkungen (10) Analyse des vorgeschlagenen Systems (11) Anhang Die Titelseite muss die folgenden Informationen enthalten: Die Nummer des Dokuments in der vom Konfigurationsmanagement vorgegebenen Form. Das Projekt, zu dem das Dokument gehört. Den Namen und die Anschrift des Kunden, für den das operationelle Konzept erstellt wurde. Die Firma des Auftragnehmers und die Abteilung, die das Dokument gefertigt hat. Den Namen des Verfassers und seine Unterschrift. Auf dem Titelblatt sollten weiterhin der Leiter der Systemgruppe, der Projektleiter und das Konfigurationsmanagement unterschreiben. Inhaltsverzeichnis Das Dokument muss ein Inhaltsverzeichnis enthalten, in dem alle Kapitelüberschriften und die zugehörigen Seitenzahlen aufgeführt sind. 211

26 ok.book Seite 212 Freitag, 22. Februar :09 16 Operationelles Konzept PM-08 Version JAN Ferner müssen im Inhaltsverzeichnis alle Zeichnungen, die Tabellen und der Anhang mit den Seitenzahlen aufgeführt 1 Einleitung 1.1 Identifikation In Abschnitt 1.1 sollen die Dokumentennummer genannt werden sowie das Projekt, für das es gilt. 1.2 Überblick über das System In Abschnitt 1.2 soll kurz auf das bisherige System oder die Situation eingegangen Der wichtigste Grund für eine Änderung kann angesprochen 1.3 Überblick über das Dokument In Abschnitt 1.3 soll der Inhalt des Dokuments zusammenfassend beschrieben 1.4 Zusammenhang mit anderen Plänen In diesem Abschnitt soll der Zusammenhang mit anderen Dokumenten hergestellt werden, zum Beispiel zu einer Machbarkeitsstudie für das Projekt oder einem Bericht zu Mängeln des gegenwärtig eingesetzten Systems. 2 Referenzierte Dokumente Dieses zweite Kapitel soll alle im operationellen Konzept referenzierten Dokumente mit ihren Titeln enthalten.. Die Angaben müssen so detailliert sein, dass der Leser des Dokuments für ihn notwendige Unterlagen besorgen kann. Bei Bedarf kann Kapitel 2 weiter untergliedert 3 Gegenwärtig eingesetztes System oder Situation In diesem Kapitel und seinen Unterpunkten sollen die gegenwärtige Situation oder die Schwierigkeiten mit dem verwendeten System beschrieben 3.1 Hintergrund, Ziele und Umfang In diesem Abschnitt sollen der Hintergrund für notwendige Änderungen beschrieben sowie die Ziele des geplanten Systems erklärt Dazu zählt auch der Umfang, den das neue System haben soll. 212 Anhang

27 ok.book Seite 213 Freitag, 22. Februar :09 16 Operationelles Konzept PM-08 Version JAN Betrieb und Restriktionen In diesem Abschnitt ist zu beschreiben, unter welchen Bedingungen das gegenwärtig eingesetzte System betrieben wird und welche Einschränkungen zu beachten sind. 3.3 Beschreibung des gegenwärtigen Zustands In diesem Abschnitt ist der gegenwärtige Zustand oder die gegenwärtige Situation zu beschreiben. Beispiele sind dabei sinnvoll. 3.4 Operationsmodi In diesem Abschnitt soll beschrieben werden, in welchen verschiedenen Operationsmodi das gegenwärtig eingesetzte System zum Einsatz kommt. 3.5 Nutzerkategorien und Anwender In diesem Abschnitt sollen die Nutzer des Systems beschrieben Dabei kann auf ihre Qualifikation eingegangen 3.6 Umgebung In diesem Abschnitt soll beschrieben werden, in welcher Umgebung das gegenwärtig eingesetzte System operiert. 4 Rechtfertigung für Änderungen In diesem Abschnitt sind die vorgeschlagenen Änderungen zu rechtfertigen. 4.1 Rechtfertigung In diesem Abschnitt sind die vorgeschlagenen Änderungen im Detail zu rechtfertigen. 4.2 Beschreibung wünschenswerter Änderungen In diesem Abschnitt sind die gewünschten Änderungen mit ihren Funktionen zu beschreiben. 4.3 Prioritäten In diesem Abschnitt sind die gewünschten Änderungen nach Prioritäten zu ordnen. 4.4 Wünschenswerte, aber nicht diskutierte Änderungen 213

28 ok.book Seite 214 Freitag, 22. Februar :09 16 Operationelles Konzept PM-08 Version JAN In diesem Abschnitt werden wünschenswerte, aber im Dokument nicht angesprochene Änderungen erwähnt. 5 Systemkonzept In diesem Abschnitt wird das Systemkonzept vorgestellt. 5.1 Hintergrund, Ziele und Umfang In diesem Abschnitt ist auf die Hintergründe für die Änderung einzugehen. Ferner sind die damit verfolgten Ziele und der Umfang des System anzusprechen. 5.2 Betrieb und Restriktionen In diesem Abschnitt ist auf den Betrieb einzugehen, und es sind eventuelle Restriktionen zu beschreiben. 5.3 Beschreibung des vorgeschlagenen Systems In diesem Abschnitt ist das vorgeschlagene System zu beschreiben. 5.4 Operationsmodi In diesem Abschnitt werden die verschiedenen Operationsmodi vorgestellt. 5.5 Kategorien von Nutzern In diesem Abschnitt werden die verschiedenen Nutzer vorgestellt. Es kann auf ihre Ausbildung eingegangen 5.6 Umgebung In diesem Abschnitt wird die Umgebung beschrieben, in der das System arbeiten muss. 6 Operationelle Szenarios In diesem Abschnitt wird der Einsatz des Systems erklärt. 7 Auswirkungen In diesem Abschnitt werden die Auswirkungen diskutiert, die beim Bau und Einsatz des Systems eintreten würden. 7.1 Auswirkungen auf Operationen 214 Anhang

29 ok.book Seite 215 Freitag, 22. Februar :09 16 Operationelles Konzept PM-08 Version JAN In diesem Abschnitt wird beschrieben, welche Auswirkungen das System auf Operationen haben würde. 7.2 Auswirkungen auf die Organisation In diesem Abschnitt wird dargestellt, welche Auswirkungen der Einsatz des Systems auf die Organisation hätte. 7.3 Auswirkungen während der Entwicklung In diesem Abschnitt werden, falls zutreffend, die Auswirkungen während der Entwicklung beschrieben. 8 Analyse des vorgeschlagenen Systems In diesem Abschnitt wird das vorgeschlagene System analysiert. 8.1 Verbesserungen In diesem Abschnitt wird aufgezählt, welche Verbesserungen durch das neue System erreichbar sind. 8.2 Nachteile und Grenzen In diesem Abschnitt wird auf die Nachteile des vorgeschlagenen Systems eingegangen, und es werden seine Grenzen aufgezeigt. 8.3 Alternativen In diesem Abschnitt werden Alternativen zum vorgeschlagenen System aufgezeigt. Anhang Der Anhang kann Material enthalten, das im Rahmen der Systemanforderungen nicht ohne weiteres einzuordnen war. Es muss festgelegt werden, ob der Anhang ein Teil des Dokuments ist. Anhänge sind mit A, B, C usw. zu bezeichnen. 215

30 ok.book Seite 216 Freitag, 22. Februar :09 16 Plan zur Ermittlung der Anforderungen PM-09 Version JAN-2002 Das Dokument ist wie folgt zu strukturieren: (1) Titelseite (2) Inhaltsverzeichnis (3) Einleitung (4) Referenzierte Dokumente (5) Zweck des Projekts (6) Essenz des Vertrags (7) Prozess zur Ermittlung der Anforderungen (8) Mechanismen, Werkzeuge und Methoden (9) Anhang Die Titelseite muss die folgenden Informationen enthalten: Die Nummer des Dokuments in der vom Konfigurationsmanagement vorgegebenen Form. Das Projekt, zu dem das Dokument gehört. Den Namen und die Anschrift des Kunden, für den der Plan erstellt wurde. Die Firma des Auftragnehmers und die Abteilung, die das Dokument gefertigt hat. Den Namen des Verfassers und seine Unterschrift. Auf dem Titelblatt sollten weiterhin ein Leitender Angestellter des Unternehmens, der Projektleiter und das Konfigurationsmanagement unterschreiben. Inhaltsverzeichnis Das Dokument muss ein Inhaltsverzeichnis enthalten, in dem alle Kapitelüberschriften und die zugehörigen Seitenzahlen aufgeführt sind. Ferner müssen im Inhaltsverzeichnis alle Zeichnungen, die Tabellen und der Anhang mit den Seitenzahlen aufgeführt 1 Einleitung 1.1 Identifikation In Abschnitt 1.1 sollen die Dokumentennummer genannt werden sowie das Projekt, für das es gilt. 216 Anhang

31 ok.book Seite 217 Freitag, 22. Februar : Überblick über das System In Abschnitt 1.2 soll kurz ein Überblick zum geplanten System oder zu der Software gegeben 1.3 Überblick über das Dokument In Abschnitt 1.3 soll der Inhalt des Dokuments zusammenfassend beschrieben 1.4 Zusammenhang mit anderen Plänen In diesem Abschnitt soll der Zusammenhang zu anderen Dokumenten hergestellt werden, zum Beispiel zu einer Machbarkeitsstudie für das Projekt. 2 Referenzierte Dokumente Dieses zweite Kapitel soll alle im operationellen Konzept referenzierten Dokumente mit ihrem Titel enthalten.. Die Angaben müssen so detailliert beschrieben werden, der Leser des Dokuments für ihn notwendige Unterlagen besorgen kann. Bei Bedarf kann Kapitel 2 weiter untergliedert 3 Zweck des Projekts In diesem Kapitel soll der Zweck des Projekts aus Kundensicht dargestellt 4 Essenz des Vertrags In diesem Kapitel sollen die wesentlichen Punkte aus dem Vertrag, soweit sie sich auf die Software-Erstellung beziehen, aufgeführt Insbesondere sind hier Restriktionen anzuführen, die Vertragsbestandteil geworden sind. 5 Prozess zur Ermittlung der Anforderungen In diesem Kapitel sind projektspezifisch der Prozess zur Ermittlung der Anforderungen sowie deren Analyse darzustellen. 6 Mechanismen, Werkzeuge und Methoden In diesem Kapitel ist aufzulisten, welche Mechanismen, Methoden und Werkzeuge im Projekt eingesetzt Anhang Plan zur Ermittlung der Anforderungen Der Anhang kann Material enthalten, das im Rahmen der Systemanforderungen nicht ohne weiteres einzuordnen war. Es muss festgelegt werden, ob der Anhang ein Teil des Dokuments ist. Anhänge sind mit A, B, C usw. zu bezeichnen. PM-09 Version JAN

32 ok.book Seite 218 Freitag, 22. Februar :09 16 für den Risk Management Plan PM AUG Das Dokument ist wie folgt zu strukturieren: (1) Titelseite (2) Inhaltsverzeichnis (3) Einleitung (4) Referenzierte Dokumente (5) Bewertung und Kontrolle der Risiken (6) Zusammenfassung (7) Anhang Die Titelseite muss die folgenden Informationen enthalten: Die Nummer des Dokuments in der vom Konfigurationsmanagement vorgeschriebenen Form. Den Titel des Risk Management Plans und die Bezeichnung des Systems, zu dem die Software gehört. Den Namen und die Anschrift des Kunden, für den der Risk Management Plan erstellt wird. Die Firma des Auftragnehmers und die Abteilung oder Gruppe, die den Risk Management Plan geschrieben hat. Den Namen des Verfassers sowie seine Unterschrift. Auf dem Titelblatt sollen weiterhin der Vorgesetzte des Verfassers, der Projektleiter und die Qualitätssicherung unterschreiben. Inhaltsverzeichnis Der Risk Management Plan muss ein Inhaltsverzeichnis enthalten, in dem alle Kapitelüberschriften und die zugehörigen Seitenzahlen aufgeführt sind. Ferner müssen im Inhaltsverzeichnis alle Grafiken, die Tabellen und der Anhang mit den zugehörigen Seitenzahlen aufgeführt 1 Einleitung Dieses Kapitel soll wie folgt untergliedert werden: 218 Anhang

33 ok.book Seite 219 Freitag, 22. Februar : Identifikation für den Risk Management Plan PM AUG In Abschnitt 1.1 sollen die Dokumentennummer des Risk Management Plans angegeben werden, der Name der Software, für den er gilt, und eventuell die gebräuchliche Abkürzung für die Software oder das System. 1.2 Überblick über das System In Abschnitt 1.2 soll kurz der Zweck des Systems, zu dem die Software gehört, erläutert Außerdem soll die Rolle der Software im Rahmen dieses Systems beschrieben 1.3 Überblick über das Dokument In Abschnitt 1.3 soll der Inhalt des Risk Management Plans kurz zusammengefasst 1.4 Zusammenhang mit anderen Plänen In Abschnitt 1.4 soll der Risk Management Plan mit anderen Plänen verknüpft werden, also zum Beispiel dem Software-Entwicklungsplan. 1.5 Geltungsbereich In Abschnitt 1.5 soll der Geltungsbereich des Plans beschrieben werden 1.6 Definitionen und Abkürzungen In Abschnitt 1.6 können verwendete Definitionen und Abkürzungen aufgelistet 2 Referenzierte Dokumente Im zweiten Kapitel sollen alle referenzierten Dokumente aufgeführt Die Angaben müssen so detailliert sein, dass sich der Leser des Risk Management Plans notwendige Unterlagen besorgen kann. Bei Bedarf kann Kapitel 2 weiter untergliedert 3 Bewertung und Kontrolle der Risiken 3.1 Vorgehensweise In diesem Abschnitt soll das Vorgehen des Unternehmens und des Managements für das Projekt beschrieben Die einzelnen erkannten Risiken werden in den folgenden Abschnitten im Detail behandelt. 219

34 ok.book Seite 220 Freitag, 22. Februar :09 16 für den Risk Management Plan PM AUG Technische Risiken In diesem Abschnitt sollen die technischen Risiken behandelt 3.3 Risiken bei der Sicherheit (SAFETY) In diesem Abschnitt sollen die Risiken beschrieben werden, die sich auf die mögliche Gefährdung menschlichen Lebens und den Verlust von Sachgütern beziehen. 3.4 Gefährdung der Programme und Daten (SECURITY) In diesem Abschnitt sollen die Risiken beschrieben werden, die sich auf die Sicherheit der Daten beziehen. 3.5 Ressourcen In diesem Abschnitt sollen die Risiken behandelt werden, die sich aus knappen oder nicht verfügbaren Ressourcen ergeben. 3.6 Zeitplan In diesem Abschnitt sollen die Risiken angesprochen werden, die sich aus Terminen und deren Einhaltung unter Berücksichtigung der endlichen Ressourcen ergeben. 3.7 Kosten In diesem Abschnitt sollen die Risiken beschrieben werden, die sich in Zusammenhang mit den Kosten ergeben. 4 Zusammenfassung In diesem Kapitel soll das Ergebnis der Betrachtungen zu den Risiken des Projekts zusammenfassend beschrieben Anhang Der Anhang kann Material enthalten, das im Rahmen des Textes nicht ohne weiteres einzuordnen war. Es muss festgelegt werden, ob der Anhang ein Teil des Plans ist. Anhänge sind mit A, B, C usw. zu bezeichnen. 220 Anhang

35 ok.book Seite 221 Freitag, 22. Februar :09 16 SOFT- CRAFT für den Testplan PM-11 Version JAN Das Dokument ist wie folgt zu strukturieren: (1) Titelseite (2) Inhaltsverzeichnis (3) Einleitung (4) Referenzierte Dokumente (5) Rollen und Verantwortlichkeiten (6) Testprogramm (7) Testumgebung (8) Durchführung des Tests (9) Sonstiges (10) Anhang Die Titelseite muss die folgenden Informationen enthalten: Die Nummer des Dokuments in der vom Konfigurationsmanagement vorgegebenen Form. Den Titel des Testplans und die Bezeichnung des System, für den der Testplan gilt. Den Namen und die Anschrift des Kunden, für den der Testplan erstellt wurde. Die Firma des Auftragnehmers und die Abteilung, die den Testplan gefertigt hat. Den Namen des Verfassers und seine Unterschrift. Unterschriften des Planerstellers, des Software-Managers, des Projektleiters, des Konfigurations- und des Qualitätsmanagers. Inhaltsverzeichnis Der Testplan muss ein Inhaltsverzeichnis enthalten, in dem alle Kapitelüberschriften und die zugehörigen Seitenzahlen aufgeführt sind. Ferner müssen im Inhaltsverzeichnis alle Grafiken, die Tabellen und der Anhang mit den Seitenzahlen aufgeführt 221

36 ok.book Seite 222 Freitag, 22. Februar :09 16 SOFT- CRAFT 1 Einleitung für den Testplan PM-11 Version JAN Dieses Kapitel soll mit 1 beginnen und wie folgt untergliedert werden: 1.1 Identifikation In Abschnitt 1.1 sollen die Dokumentennummer des Testplans genannt werden, der Name des Systems oder der Software, für den er gilt, und eventuell die gebräuchliche Abkürzung des Systems. 1.2 Überblick über das System In Abschnitt 1.2 soll kurz der Zweck des Systems und/oder der Software angesprochen Außerdem kann die Rolle wichtiger Komponenten im Rahmen dieses Systems beschrieben 1.3 Überblick über das Dokument In Abschnitt 1.3 soll der Inhalt des Testplans zusammenfassend beschrieben 1.4 Zusammenhang mit anderen Plänen In Abschnitt 1.4 soll der Testplan mit anderen Dokumenten verknüpft werden, also zum Beispiel der Spezifikation oder dem Entwicklungsplan. 2 Referenzierte Dokumente Dieses zweite Kapitel soll alle im Testplan referenzierten Dokumente aufführen. Die Angaben müssen so detailliert sein, dass der Leser des Plans für ihn notwendige Dokumente besorgen kann. Bei Bedarf kann Kapitel 2 weiter untergliedert 3 Rollen und Verantwortlichkeiten In Kapitel 3 soll erklärt werden, wer im Rahmen des Projekts welche Rollen ausfüllen wird und welche Verantwortung damit verbunden ist. Die Anbindung zur Organisation der Firma ist darzustellen. 3.1 Projektorganisation In Abschnitt 3.1 ist die Projektorganisation zu beschreiben. Die Anbindung an die Organisation der Firma ist aufzuzeigen, allerdings müssen Organigramme des Gesamtunternehmens nicht beigefügt 222 Anhang

37 ok.book Seite 223 Freitag, 22. Februar :09 16 SOFT- CRAFT für den Testplan PM-11 Version JAN Verantwortung im Projekt In Abschnitt 3.2 ist aufzuführen, welche Verantwortlichkeiten und Befugnisse die Mitarbeiter im Projekt besitzen. 3.3 Struktur der durchzuführenden Tests In Abschnitt 3.3 soll erklärt werden, wie die Aufgabe beim Test der Software aufgefasst und angegangen wird. 3.4 Ressourcen der Testgruppe In Abschnitt 3.4 ist zu beschreiben, welche personellen und materiellen Ressourcen die Testgruppe im Rahmen des Projekts zur Verfügung hat. 4 Testprogramm In Kapitel 4 ist das Testprogramm für das Projekt zu beschreiben. 4.1 Ansatz In Abschnitt 4.1 soll beschrieben werden, wie die Aufgabe aufgefasst und angegangen wird. 4.2 Strategie In Abschnitt 4.2 soll erklärt werden, welche Strategie beim Test verfolgt wird Herleitung der Anforderungen an den Test In Abschnitt soll erklärt werden, aus welchen Dokumenten oder sonstigen Quellen die Anforderungen an den Test hergeleitet Testkategorien In Abschnitt sollen die Testkategorien für den Test aufgeführt werden, etwa Tests auf verschiedenen Ebenen. Arten des Tests sollen ebenfalls aufgeführt Testebenen In Abschnitt soll spezifiziert werden, auf welcher Ebene des Systems mit dem formellen Test begonnen werden soll, also zum Beispiel auf der niederen Ebene von Bauteilen oder Baugruppen oder auf der höheren Ebene von Komponenten oder des integrierten Systems. 223

38 ok.book Seite 224 Freitag, 22. Februar :09 16 SOFT- CRAFT für den Testplan PM-11 Version JAN Testschritte In Abschnitt und seinen Unterpunkten soll der Test Schritt für Schritt beschrieben Zeitplan für den Test In Abschnitt soll der Zeitplan für den Test in einer groben Übersicht (Master Schedule) aufgezeigt Die Verknüpfungen zum Zeitplan der Entwicklung sind aufzuzeigen. Falls der Testplan mit einem Werkzeug erstellt wird, kann darauf Bezug genommen 4.3 Automatische Werkzeuge Falls automatische Werkzeuge für den Test eingesetzt werden, sind sie in Abschnitt 4.3 aufzuführen. 4.4 Qualifikationsmethoden Falls besondere Qualifikationsmethoden zutreffen oder bestimmte numerische Vorgaben bestehen, etwa bei der Testabdeckung, sind sie in Abschnitt 4.4 anzugeben. 5 Testumgebung In Abschnitt 5 ist die Testumgebung zu beschreiben. 5.1 Konfiguration der Testumgebung In Abschnitt 5.1 ist die Testumgebung im Detail zu beschreiben. Falls sie weitgehend mit der Entwicklungsumgebung identisch ist, kann auf den Entwicklungsplan verwiesen Unterschiede sind zu benennen. Falls als Testumgebung der Rechner des Kunden in Frage kommt, sind dazu Ausführungen zu machen. 5.2 Testdaten In Abschnitt 5.2 ist aufzuführen, mit welchen Daten getestet werden soll. Das kann sich auch auf Daten beziehen, die der Kunde stellt. Fragen des geistigen Eigentums sind zu klären und gegebenenfalls zu dokumentieren. 6 Durchführung des Tests 224 Anhang

39 ok.book Seite 225 Freitag, 22. Februar :09 16 SOFT- CRAFT für den Testplan PM-11 Version JAN Die Durchführung des Tests und die Ausführung von Testfällen ist zu beschreiben. 6.1 Aufzeichnung von Testdaten In Abschnitt 6.1 soll spezifiziert werden, welche Daten aufgezeichnet werden müssen, und welche Daten unter Umständen komprimiert und analysiert werden sollen. 6.2 Berichte Die mit dem Test zusammenhängenden Berichte, auch in maschineller Form, sind aufzuführen. Etwaige Formvorschriften sind zu nennen. 6.3 Metriken Falls beim Test Metriken erhoben werden, sind diese aufzuführen. Ein firmenweiter Metrikenplan kann referenziert 6.4 Fehlerverfolgung In Abschnitt 6.4 ist das System zur Fehlerverfolgung zu nennen. Falls ein etabliertes System der Firma benutzt wird, kann darauf verwiesen 6.5 Konfigurationsmanagement Das Konfigurationsmanagement während der Testdurchführung ist zu beschreiben. Falls ein Konfigurationsmanagementplan existiert, kann dieser referenziert 7 Sonstiges In diesem Kapitel kann sonstiges Material behandelt werden, das in keinen der anderen Abschnitte passt. Anhang Der Anhang kann Material enthalten, das im Rahmen des Testplans nicht ohne weiteres einzuordnen war. Es muss festgelegt werden, ob der Anhang ein Teil des Testplans ist. Anhänge sind mit A, B, C usw. zu bezeichnen. 225

40 ok.book Seite 226 Freitag, 22. Februar :09 16 für den Software-Entwicklungsplan PM AUG Das Dokument ist wie folgt zu strukturieren: (1) Titelseite (2) Inhaltsverzeichnis (3) Einleitung (4) Referenzierte Dokumente (5) Management der Software-Entwicklung (6) Entwicklung der Software (7) Formeller Test (8) Überprüfung der Software (9) Software Configuration Management (10) Weitere beteiligte Gruppen (11) Sonstiges (12) Anhang Die Titelseite muss die folgenden Informationen enthalten: Die Nummer des Dokuments in der vom Konfigurationsmanagement vorgeschriebenen Form. Den Titel des Entwicklungsplans und die Bezeichnung des Systems, zu dem die Software gehört. Den Namen und die Anschrift des Kunden, für den der Software-Entwicklungsplan erstellt wird. Die Firma des Auftragnehmers und die Abteilung oder Gruppe, die den Software-Entwicklungsplan geschrieben hat. Den Namen des Verfassers (des Software-Managers) sowie seine Unterschrift. Auf dem Titelblatt sollen weiterhin der Vorgesetzte des Software-Managers, der Projektleiter und die Qualitätssicherung unterschreiben. Inhaltsverzeichnis 226 Anhang

41 ok.book Seite 227 Freitag, 22. Februar :09 16 für den Software-Entwicklungsplan PM AUG Der Software-Entwicklungsplan muss ein Inhaltsverzeichnis enthalten, in dem alle Kapitelüberschriften und die zugehörigen Seitenzahlen aufgeführt sind. Ferner müssen im Inhaltsverzeichnis alle Grafiken, die Tabellen und der Anhang mit den zugehörigen Seitenzahlen aufgeführt 1 Einleitung Dieses Kapitel soll wie folgt untergliedert werden: 1.1 Identifikation In Abschnitt 1.1 sollen die Dokumentennummer des Software-Entwicklungsplans angegeben werden, der Name der Software, für den er gilt, und eventuell die gebräuchliche Abkürzung für die Software. 1.2 Überblick über das System In Abschnitt 1.2 soll kurz der Zweck des Systems, zu dem die Software gehört, erläutert Außerdem soll die Rolle der Software im Rahmen dieses Systems beschrieben 1.3 Überblick über das Dokument In Abschnitt 1.3 soll der Inhalt des Software-Entwicklungsplans kurz zusammengefasst 1.4 Zusammenhang mit anderen Plänen In Abschnitt 1.4 soll der Software-Entwicklungsplan mit anderen Plänen verknüpft werden, also zum Beispiel dem Software Quality Program Plan und dem Software Configuration Management Plan. 2 Referenzierte Dokumente Im zweiten Kapitel sollen alle referenzierten Dokumente aufgeführt Die Angaben müssen so detailliert sein, dass sich der Leser des Software-Entwicklungsplans notwendige Unterlagen besorgen kann. Bei Bedarf kann Kapitel 2 weiter untergliedert 3 Management der Software-Entwicklung In Kapitel 3 soll das Management der Software-Entwicklung beschrieben Es wird weiter untergliedert. 227