2.2. Project Management

Customer Requirements
Specification
(Lastenheft)
(TINF11D, SWE I Praxisprojekt 2012/2013)
Projekt:
SalomeTMF 4.0
Auftraggeber:
Rentschler & Stuckert
Rotebühlplatz 41/1
70178 Stuttgart
Auftragnehmer:
TINF11D –Team 3
Rotebuehlplatz 41
70178 Stuttgart
Version
0.1
Datum
05.09.2012
Autor
Kommentar
Dokument angelegt
Allgemeine Hinweise:
Alles, was in dieser Schriftart gesetzt ist, dient nur zur Erläuterung und sollte im fertigen
Pflichtenheft nicht mehr auftauchen!
Ein Lastenheft enthält eine grobe Beschreibung aller fachlichen Anforderungen, die das zu
entwickelnde Produkt erfüllen muss. Die Inhalte des Lastenheftes dienen als Grundlage für
das Pflichtenheft und können im Pflichtenheft wieder verwendet werden. Im Gegensatz zum
Lastenheft sind im Pflichtenheft die Produktanforderungen jedoch detailliert und vollständig
aufzuführen.
1
CRS SalomeTMF 4.0 | TINF11D | Team 3 | 15/05/2016
Inhalt
1.
OBJECTIVES .............................................................................................................................................. 2
2.
PRODUCT SCOPE ..................................................................................................................................... 3
2.1.
2.2.
2.3.
2.4.
2.5.
2.6.
3.
USER MANAGEMENT ............................................................................................................................ 3
PROJECT MANAGEMENT ....................................................................................................................... 3
REQUIREMENTS MANAGEMENT ............................................................................................................ 4
TESTCASE MANAGEMENT ..................................................................................................................... 4
TESTEXECUTION MANAGEMENT ........................................................................................................... 5
DOCUMENTATION AND REPORTING ..................................................................................................... 7
PRODUCT FUNCTIONALITY................................................................................................................. 7
3.1.
OPEN POINTS ........................................................................................................................................ 7
3.2.
USE CASES............................................................................................................................................ 8
3.2.1. /LUC10/ Manage User .................................................................................................................... 8
3.2.2. /LUC20/ Manage Project ................................................................................................................ 8
3.2.3. /LUC40/ Configure Settings ............................................................................................................ 8
3.3.
FUNCTIONAL REQUIREMENTS ............................................................................................................... 9
3.3.1. /LF10/ GUI ...................................................................................................................................... 9
3.3.2. /LF50/ Manual .............................................................................................................................. 10
4.
PRODUCT DATA ..................................................................................................................................... 10
4.1.
4.2.
5.
/LD10/ USER DATA ............................................................................................................................ 10
/LD20/ PROJECT DATA ....................................................................................................................... 10
PRODUCT CHARAKTERISTICA ......................................................................................................... 10
5.1.
SYSTEM ENVIRONMENT ...................................................................................................................... 11
5.1.1. Hardware Environment ................................................................................................................. 11
5.1.2. Software Environment ................................................................................................................... 11
5.2.
NON-FUNCTIONAL REQUIREMENTS .................................................................................................... 11
5.2.1. /LL10/ Quality Assurance.............................................................................................................. 11
5.2.2. /LL20/ Workflow............................................................................................................................ 11
1.
Objectives
The test management solution “Salome-TMF“ (https://wiki.ow2.org/salome-tmf/) offers
tool support for the management of the software quality assurance lifecycle.
Salome-TMF 3.x is implemented in Java and technologically rathrr outdated. From its
usability concept, it is testplan oriented. A new version 4.0 shall be developed in
Web 2.0 achitecture and a uability centered on the software development lifecycle
(SDLC). Since the wheel need not to be reinvented, the framework of the document
management system OpenKM (http://www.openkm.org) can be used as a basis.
The goal is to develop a web-based tool that enables a centralized management of
artefacts in the software development life cycle. To be able to track all artefacts that
are used during the software development process, functionality is required for:
Requirements management
Project management
Quality management
Defect management
2
CRS SalomeTMF 4.0 | TINF11D | Team 3 | 15/05/2016
Release management
Resource management
Task management
2.
Product Scope
Figure 1: Use Cases and Workflows of Salome TMF 3.3
2.1. User Management
2.2. Project Management
3
CRS SalomeTMF 4.0 | TINF11D | Team 3 | 15/05/2016
2.3. Requirements Management
Figure 4: GUI Example for Requirements (Salome TMF 3.3)
2.4. Testcase Management
Figure 5: GUI Example for Testcases (HP ALM)
4
CRS SalomeTMF 4.0 | TINF11D | Team 3 | 15/05/2016
Figure 6: GUI Example for Testcases (MicroFocus SilkCentral)
Figure 7: GUI Example for Testcases (SalomeTMF 3.3)
2.5. Testexecution Management
5
CRS SalomeTMF 4.0 | TINF11D | Team 3 | 15/05/2016
Figure 8: GUI Example for Testplanning (MicroFocus SilkCentral)
Figure 9: GUI Example for Testexecution Tracking (MicroFocus SilkCentral)
6
CRS SalomeTMF 4.0 | TINF11D | Team 3 | 15/05/2016
Figure 10: GUI Example for Testexecution Tracking (HP ALM)
2.6. Documentation and Reporting
3.
Product Functionality
Dieser Abschnitt hat die Aufgabe, die Funktionalität des zu entwickelnden Systems sowohl
überblicksartig als auch detaillierter zu beschreiben.
3.1. Open Points
In diesem Abschnitt sollen alle Probleme und offenen Fragen gesammelt werden. Bei einem
fertigen Lastenheft sollte er hoffentlich leer sein, aber bei Zwischenversionen kommt diesem
Abschnitt besondere Bedeutung zu!
7
CRS SalomeTMF 4.0 | TINF11D | Team 3 | 15/05/2016
3.2. Use Cases
V-DHC
Auftragsannahme
Kommisioniervorgang
durchführen
Durch eigenes
Waren einlagern
Use
Case-Diagramm
ersetzen.
WWS
Lagerist
Bestandsanfrage
Retoure
Neue Warengruppe
anmelden
Apotheker
Figure 11: Use Case Diagram
3.2.1.
/LUC10/ Manage User
The software must support the management of users. Subordinate use cases are
create user, edit user data, roles and access rights, delete user, assign user to
project, LDAP support, user login, user logout, etc.
3.2.2.
/LUC20/ Manage Project
The software must support the management of projects. Subordinate use cases
are create project, edit project, delete project, clone project, show project states
etc.
3.2.3.
/LUC40/ Configure Settings
The software must support the management of configuration settings, such as
for the appearance, language, the database connection etc.
8
CRS SalomeTMF 4.0 | TINF11D | Team 3 | 15/05/2016
3.3. Functional Requirements
3.3.1.
/LF10/ GUI
/LF11/ The software shall support a dialog for language settings.
Figure 12: Language Settings (OpenKM)
/LF12/ The software shall support a user related dashboard with assigned task status from the
projects.
Figure 13: User Dashboard (OpenKM)
9
CRS SalomeTMF 4.0 | TINF11D | Team 3 | 15/05/2016
/LF13/ The software shall support a text search functionality over all artefacts.
Figure 14: Search Functionality (OpenKM)
3.3.2.
/LF50/ Manual
/LF51/ An english Manual PDF must be supplied.
4.
Product Data
In diesem Abschnitt werden die Hauptdaten beschrieben, auf denen das Produkt arbeitet. Im
Allgemeinen werden die Hauptdaten eines Programms auch gespeichert.
4.1. /LD10/ User Data
/LD11/ User Name
4.2. /LD20/ Project Data
/LD21/ Project Name
5.
Product Charakteristica
In diesem Abschnitt werden Eigenschaften des zu entwickelnden Produktes beschrieben, die
nicht direkt die zu leistende Funktionalität betreffen. Dies sind insbesondere die
Systemumgebung in der das Produkt eingesetzt werden soll sowie die nicht-funktionalen
10
CRS SalomeTMF 4.0 | TINF11D | Team 3 | 15/05/2016
Anforderungen. Je präziser diese Angaben sind, desto besser kann das realistische Verhalten
des Produktes in Testumgebungen bestimmt werden.
5.1. System Environment
Hier sollten alle wesentlichen Parameter der Systemumgebung beschrieben werden, soweit
diese bereits festgelegt ist.
Figure 15: Global System Architecture
5.1.1.
Hardware Environment
Angaben über die existierenden oder zu erwartenden Hardwareumgebungen. Je nach
Architektur können hier auch mehrere verschiedene Umgebungen relevant sein.
5.1.2.
Software Environment
In diesem Abschnitt werden Angaben zur Softwareumgebung des zu entwickelnden Produktes
gemacht. Insbesondere das Betriebssystem und zur Verfügung stehende Laufzeitumgebungen
/Bibliotheken sind wichtig. Andere Systeme mit denen das zu entwickelnde Produkt
kooperieren muss, sollten möglichst genau spezifiziert sein.
5.2. Non-functional Requirements
Die Aufgabe dieses Abschnittes ist die Beschreibung der nicht-funktionalen Anforderungen.
Dabei handelt es sich um Charakteristiken oder Qualitäten, die das Produkt attraktiv machen
und es von vergleichbaren Produkten unterscheiden.
Die folgende Tabelle ist für jede nicht-funktionale Anforderung zu wiederholen.
In diesem Abschnitt werden die wesentlichen Eigenschaften des zu entwickelnden Produktes
beschrieben, die nicht direkt die zu leistende Funktionalität betreffen.
5.2.1.
/LL10/ Quality Assurance
Name:
Type:
Description:
Assigned Use Case(s):
5.2.2.
/LL10/
MAINTAINABILITY
An automated Unit Testsuite must be designed and implemented that is automatically executable at the end of
a build process.
Use Case-ID (wenn eine direkte Zuordnung möglich ist)
/LL20/ Workflow
11
CRS SalomeTMF 4.0 | TINF11D | Team 3 | 15/05/2016
Name:
Type:
Description:
Assigned Use Case(s):
/LL21/
USABILITY
The usability and workflow of the GUI shall be designed to support the software development lifecycle
(SDLC).
Use Case-ID (wenn eine direkte Zuordnung möglich ist)
12
CRS SalomeTMF 4.0 | TINF11D | Team 3 | 15/05/2016
Typen von Produktcharakteristiken
Typ USABILITY: Benutzbarkeitsanforderung
Die in Abschnitt 1 beschriebene Zielgruppe liegt diesen Anforderungen zugrunde. Wie muss die Software
beschaffen sein, damit diese Zielgruppe gerne damit arbeitet?
Beispiel: Die Software soll flexibel für unterschiedliche Arbeitsweisen einsetzbar sein.
ODER
Die Software soll dem Erscheinungsbild anderer Produkte des Herstellers entsprechen.
Typ EFFICIENCY: Effizienzanforderung
Hier geht es sowohl um Laufzeit- als auch um Speichereffizienz. Was wird unter dem sparsamen Einsatz dieser
Ressourcen verstanden?
Beispiel: Die Berechnung darf nicht länger als 0,25 Sekunden dauern.
Typ MAINTAINABILITY: Wartbarkeits- und Portierbarkeitsanforderung
Welcher Grad an Änderbarkeit wird gefordert? Hier werden, soweit wie möglich, kommende Anpassungen und
Erweiterungen vorhergesehen.
Beispiel: Das Produkt soll später auch in englischer Sprache verfügbar sein.
Typ SECURITY: Sicherheitsanforderung
Zu den Sicherheitsanforderungen gehören die Aspekte Vertraulichkeit, Datenintegrität und Verfügbarkeit. Wie
sehr müssen die Daten vor dem Zugriff durch Dritte geschützt werden? Ist es entscheidend, die Korrektheit der
erfassten Daten und ihre Konsistenz zu gewährleisten? Dürfen Systemausfälle vorkommen?
Beispiel: Das System muss gewährleisten, dass Daten nie verändert werden können.
Typ LEGALITY: Gesetzliche Anforderung
Welche Standards und Gesetze müssen beachtet werden?
Beispiel: Das Produkt muss die ISO 9000 Norm erfüllen.
13
CRS SalomeTMF 4.0 | TINF11D | Team 3 | 15/05/2016