2.1. User Management
Werbung
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
