2.1. User Management

Customer Requirements
Specification
(Lastenheft)
(TINF11D, SWE I Praxisprojekt 2012/2013)
Projekt:
SalomeTMF 3.5
Auftraggeber:
Rentschler & Stuckert
Rotebühlplatz 41/1
70178 Stuttgart
Auftragnehmer:
TINF11D –Team 2
Rotebuehlplatz 41
70178 Stuttgart
Version
0.1
Datum
05.09.2012
Autor
Kommentar
Dokument angelegt
1
CRS SalomeTMF 3.5 | TINF11D | Team 2 | 15/05/2016
Inhalt
1.
ZIELBESTIMMUNG ................................................................................................................................. 2
2.
PRODUKTEINSATZ.................................................................................................................................. 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 ........................................................................................................... 4
DOCUMENTATION AND REPORTING ..................................................................................................... 4
PRODUKTFUNKTIONEN ........................................................................................................................ 4
3.1.
USE CASES............................................................................................................................................ 4
3.1.1. /LUC10/ Manage User .................................................................................................................... 5
3.1.2. /LUC20/ Manage Project ................................................................................................................ 5
3.1.3. /LUC40/ Configure Settings ............................................................................................................ 5
3.2.
OFFENE PUNKTE ................................................................................................................................... 5
3.3.
ANFORDERUNGEN................................................................................................................................. 5
4.
PRODUKTDATEN ..................................................................................................................................... 5
5.
PRODUKTCHARAKTERISTIKEN ......................................................................................................... 6
5.1.
SYSTEMUMGEBUNG .............................................................................................................................. 6
5.1.1. Hardwareumgebung ........................................................................................................................ 6
5.1.2. Softwareumgebung .......................................................................................................................... 6
5.2.
NICHT-FUNKTIONALE ANFORDERUNGEN .............................................................................................. 6
1.
Zielbestimmung
Die Testmanagement-Lösung „Salome-TMF“ (https://wiki.ow2.org/salome-tmf/) bietet umfassende Werkzeugunterstützung für den Software-Qualitätssicherungsprozess, vom Requirements-Management über Testfallmanagement, Testprojektmanagement und Bugtracking
bis zum Reporting und hat eine breite Benutzerbasis.
http://www.java2s.com/Open-Source/Java-Document/Test-Coverage/salometmf/Catalogsalome-tmf.htm
Salome-TMF ist in Java programmiert und wurde mit einer Architektur entworfen, die
Schnittstellen für sog. „Plugins“ bereitstellt. Dadurch ist das Tool flexibel erweiter- und konfigurierbar.
Das Login-, Benutzer-, Rollen- und Projektverwaltungsmodul soll überarbeitet werden. Hierzu sollte evtl. auch der französische Maintainer des Open-Source-Projekts kontaktiert werden,
der den allerneuesten Bugfix-Code zur Verfügung stellen kann, auf dessen Basis dann gearbeitet werden soll.
Es müssen folgende Punkte bearbeitet werden:
1. Lauffähige Installation von Salome-TMF 3.3 auf einem DHBW-Server.
2. Usability-Analyse und ggf. Verbesserung der Screens, Dialoge und Icons, insbesondere der Installationsroutine, des Login-Screens, des Projektverwaltungs-Moduls und der
Artefakte-Bäume.
2
CRS SalomeTMF 3.5 | TINF11D | Team 2 | 15/05/2016
3. Sprachunterstützung des Tools auf Deutsch erweitern und korrekte Sprachunterstützung (Deutsch, Englisch, Französisch) prüfen und ggf. verbessern. Rudimentäre Manualdateien in den verschiedenen Sprachen erstellen.
4. Weiterentwicklung des generischen Hilfe-Konzepts, so dass über den jeweiligen Modul/Plugin-Screen die zugehörige Manual-Datei aufgerufen werden kann.
5. Externe oder angehängte Objekt- und Grafik-Dateien sollen im Text eingebettet bzw.
verlinkt werden können und bei Doppelklick bzw. Rechtsklick und Auswahlmenü auf
das Objekt bzw. den Link die zugehörige Anzeige- oder Bearbeitungsapplikation gestartet werden können.
6. Im Beschreibungstext integrierte Verlinkung zwischen Artefakten (Requirements bzw.
Testfälle) sollte möglich sein und durch eine Art Browser-Funktion mit Vor- und Zurück-Navigation unterstützt werden.
7. Die integrierte Verlinkung sollte auf Konsistenz geprüft werden können, wenn ein
neuer Link eingefügt oder ein bestehendes -evtl. verlinktes- Element umbenannt oder
gelöscht wird.
8. Die geänderte Software muss am Ende sorgfältig getestet werden.
Das Projekt ist entwicklungsbegleitend weitgehend in Salome-TMF selbst zu dokumentieren.
Die erzielten Ergebnisse sollen anschliessend als Salome 3.5 in das zugehörige Open-SourceProjekt einfliessen.
.
2.
Produkteinsatz
Dieser Abschnitt hat die Aufgabe den Einsatzbereich des zu entwickelnden Systems klarzustellen. Dazu gehören Erläuterungen der notwendigen Fachbegriffe und deren Zusammenhänge
ebenso wie die Darstellung der systemrelevanten Abläufe im Einsatzbereich
.
Unter dem Produkteinsatz versteht man sowohl den direkten Problembereich, in dem das zu
entwickelnde System eingesetzt werden soll, als auch die umgebenden Geschäftsprozesse.
Hier also den Problembereich des Projektes benennen und erläutern, ob es zu unterstützende
Abläufe im Einsatzbereich (Geschäftsprozesse) gibt und wo sie zu finden sind.
Dieser Abschnitt muss so geschrieben sein, dass er, den Laien mit der Terminologie und den
Zusammenhängen im Problembereich vertraut macht. Daher muss die Beschreibung möglichst allgemein sein. Außerdem sollte der Text gut strukturiert sein. Auch der Einsatz von
erläuternden Graphiken ist manchmal sinnvoll.
Wichtig ist es auch noch, gemachte Annahmen sauber von den oben beschriebenen Fakten
getrennt aufzulisten. Dies erleichtert eine spätere Fehlersuche, wenn das System nicht die
Erwartungen erfüllt.
2.1. User Management
2.2. Project Management
3
CRS SalomeTMF 3.5 | TINF11D | Team 2 | 15/05/2016
2.3. Requirements Management
2.4. Testcase Management
2.5. Testexecution Management
2.6. Documentation and Reporting
3.
Produktfunktionen
Dieser Abschnitt hat die Aufgabe, die Funktionalität des zu entwickelnden Systems sowohl
überblicksartig als auch detaillierter zu beschreiben. In diesem Abschnitt werden die vom
Produkt erwarteten Funktionalitäten beschrieben.
3.1. Use Cases
Abbildung 3: Use Case Diagramm
Beschreibung der Use Cases aus Abbildung 1:
4
CRS SalomeTMF 3.5 | TINF11D | Team 2 | 15/05/2016
3.1.1.
/LUC10/ Manage User
The software must support the management of users. Subordinate use cases are
create user, edit user data and access rights, delete user, assign user to project,
LDAP support, user login, user logout, etc.
3.1.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 activities etc.
3.1.3.
/LUC40/ Configure Settings
The software must support the management of configuration settings, such as
for the appearance, the database connection etc..
3.2. Offene Punkte
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!
3.3. Anforderungen
/LF10/ The software shall support a user related dashboard with assigned task status from the
projects.
/LF30/ The usability and workflow of the GUI shall be designed to support the software development lifecycle (SDLC).
/LF50/ Ein englischsprachiges Manual PDF mit ausführlichem Inhalt ist zu erstellen
/LF51/ About – Help: Aufruf des Manual-PDFs
/LF55/ Das Historienkapitel mit Bildern der Ersteller ist im Manual entsprechend zu ergänzen.
/LF80/ Für MultiCastor 3.0 müssen verschiedene automatisierte Testszenarien beschrieben
und eine STAF/STAX-Unterstützung nachgewiesen werden
/LF90/ Gefordert ist die Erstellung einer automatisierten Regressionstestsuite
4.
Produktdaten
In diesem Abschnitt werden die Hauptdaten beschrieben, auf denen das Produkt arbeitet. Im
Allgemeinen werden die Hauptdaten eines Programms auch gespeichert.
/LD10/ User Data
5
CRS SalomeTMF 3.5 | TINF11D | Team 2 | 15/05/2016
/LD20/ Project Data
5.
Produktcharakteristiken
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 Anforderungen.
Je präziser diese Angaben sind, desto besser kann das realistische Verhalten des Produktes in
Testumgebungen bestimmt werden.
5.1. Systemumgebung
Hier sollten alle wesentlichen Parameter der Systemumgebung beschrieben werden, soweit
diese bereits festgelegt ist.
5.1.1.
Hardwareumgebung
Angaben über die existierenden oder zu erwartenden Hardwareumgebungen. Je nach Architektur können hier auch mehrere verschiedene Umgebungen relevant sein.
5.1.2.
Softwareumgebung
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. Nicht-funktionale Anforderungen
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.
Name:
Typ:
Beschreibung:
Zugeordnete(r) Use Case(s)
/LL10/
Einen Typ aus der im Anhang definierten Liste auswählen
Beschreibung in Sprache des Nutzers, die versucht
Mehrdeutigkeiten zu vermeiden
Use Case-ID (wenn eine direkte Zuordnung möglich ist)
6
CRS SalomeTMF 3.5 | TINF11D | Team 2 | 15/05/2016
Typen von Produktcharakteristiken
Typ USE: 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 EFFIZIENZ: 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 PFLEGE: 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 SICHER: 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 LEGAL: Gesetzliche Anforderung
Welche Standards und Gesetze müssen beachtet werden?
Beispiel: Das Produkt muss die ISO 9000 Norm erfüllen.
7
CRS SalomeTMF 3.5 | TINF11D | Team 2 | 15/05/2016