Template für Lastenheft - DHBW Stuttgart€¦ · Web viewSubordinate use cases are create project,...

Customer Requirements Specification

(Lastenheft)

(TINF11D, SWE I Praxisprojekt 2012/2013)

Projekt: SalomeTMF 4.0Auftraggeber: Rentschler & Stuckert

Rotebühlplatz 41/170178 Stuttgart

Auftragnehmer: TINF11D –Team 3Rotebuehlplatz 4170178 Stuttgart

Version Datum Autor Kommentar

0.1 05.09.2012 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

CRS SalomeTMF 4.0 | TINF11D | Team 3 | 20/05/2023 1

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.


Inhalt

1. OBJECTIVES....................................................................................................................................................2

2. PRODUCT SCOPE.......................................................................................................................................3

2.1. USER MANAGEMENT..............................................................................................................................32.2. PROJECT MANAGEMENT.........................................................................................................................32.3. REQUIREMENTS MANAGEMENT.............................................................................................................42.4. TESTCASE MANAGEMENT......................................................................................................................42.5. TESTEXECUTION MANAGEMENT............................................................................................................52.6. DOCUMENTATION AND REPORTING......................................................................................................7

3. PRODUCT FUNCTIONALITY..................................................................................................................7

3.1. OPEN POINTS..........................................................................................................................................73.2. USE CASES.............................................................................................................................................8

3.2.1. /LUC10/ Manage User......................................................................................................................83.2.2. /LUC20/ Manage Project..................................................................................................................83.2.3. /LUC40/ Configure Settings..............................................................................................................8

3.3. FUNCTIONAL REQUIREMENTS................................................................................................................93.3.1. /LF10/ GUI........................................................................................................................................93.3.2. /LF50/ Manual................................................................................................................................10

4. PRODUCT DATA.......................................................................................................................................10

4.1. /LD10/ USER DATA..............................................................................................................................104.2. /LD20/ PROJECT DATA.........................................................................................................................10

5. PRODUCT CHARAKTERISTICA...........................................................................................................10

5.1. SYSTEM ENVIRONMENT........................................................................................................................115.1.1. Hardware Environment...................................................................................................................115.1.2. Software Environment.....................................................................................................................11

5.2. NON-FUNCTIONAL REQUIREMENTS......................................................................................................115.2.1. /LL10/ Quality Assurance...............................................................................................................115.2.2. /LL20/ Workflow............................................................................................................................11

1. ObjectivesThe 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 managementProject management


Markus Rentschler, 12.08.11,

Dieser Abschnitt hat die Aufgabe als Einleitung zu dienen. Beschrieben wird die Hauptaufgabe des Systems. Meist kann man von der Aufgabenstellung bzw. Auftragsanfrage abschreiben. Wichtig ist es, den Grund für die Systementwicklung (Probleme oder Geschäftsideen) und damit ihre Ziele herauszuarbeiten. Erläutern Sie auch die Zielgruppe, die später mit dem System arbeiten soll. Welches Vorwissen und welche Erfahrungen hat sie?

http://www.openkm.org/de/screenshotsde.html

https://wiki.ow2.org/salome-tmf/

http://www.bredemeyer.com/papers.htm%20%0D%0CInhalt

Quality managementDefect managementRelease managementResource managementTask management

2. Product Scope

Figure 1: Use Cases and Workflows of Salome TMF 3.3

2.1. User Management

2.2. Project Management


MXR01012, 26.08.12,

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.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)


Figure 6: GUI Example for Testcases (MicroFocus SilkCentral)

Figure 7: GUI Example for Testcases (SalomeTMF 3.3)

2.5. Testexecution Management


Figure 8: GUI Example for Testplanning (MicroFocus SilkCentral)

Figure 9: GUI Example for Testexecution Tracking (MicroFocus SilkCentral)


Figure 10: GUI Example for Testexecution Tracking (HP ALM)

2.6. Documentation and Reporting

3. Product FunctionalityDieser Abschnitt hat die Aufgabe, die Funktionalität des zu entwickelnden Systems sowohl überblicksartig als auch detaillierter zu beschreiben.

3.1. Open PointsIn 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.2. Use Cases

WWS

V-DHC

Auftragsannahme

Kommisioniervorgang durchführen

Lagerist

Waren einlagern

Retoure

ApothekerNeue Warengruppeanmelden

Bestandsanfrage

Figure 11: Use Case Diagram

3.2.1. /LUC10/ Manage UserThe 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 ProjectThe 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 SettingsThe software must support the management of configuration settings, such as for the appearance, language, the database connection etc.


Durch eigenesUse Case-

Diagramm ersetzen.

Markus Rentschler, 12.08.11,

Aufgabe dieses Abschnittes ist es, einen Überblick über die Produktfunktionen zu geben. Dazu wird ein Use Case Diagramm eingesetzt, das eine abstrakte Sicht auf die Produktfunktionen und die externen Beteiligten an diesen Funktionen gibt.

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)

/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 DataIn 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 CharakteristicaIn 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. System EnvironmentHier sollten alle wesentlichen Parameter der Systemumgebung beschrieben werden, soweit diese bereits festgelegt ist.

Figure 15: Global System Architecture

5.1.1. Hardware EnvironmentAngaben über die existierenden oder zu erwartenden Hardwareumgebungen. Je nach Architektur können hier auch mehrere verschiedene Umgebungen relevant sein.

5.1.2. Software EnvironmentIn 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: /LL10/Type: MAINTAINABILITYDescription: An automated Unit Testsuite must be designed and im-

plemented that is automatically executable at the end of a build process.


Assigned Use Case(s): Use Case-ID (wenn eine direkte Zuordnung möglich ist)

5.2.2. /LL20/ Workflow

Name: /LL21/Type: USABILITYDescription: The usability and workflow of the GUI shall be de-

signed to support the software development lifecycle (SDLC).

Assigned Use Case(s): Use Case-ID (wenn eine direkte Zuordnung möglich ist)


Typen von Produktcharakteristiken

Typ USABILITY: BenutzbarkeitsanforderungDie 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.

ODERDie Software soll dem Erscheinungsbild anderer Produkte des Herstellers entsprechen.

Typ EFFICIENCY: EffizienzanforderungHier 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 PortierbarkeitsanforderungWelcher 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: SicherheitsanforderungZu 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 AnforderungWelche Standards und Gesetze müssen beachtet werden?Beispiel: Das Produkt muss die ISO 9000 Norm erfüllen.


Template für Lastenheft - DHBW Stuttgart€¦ · Web viewSubordinate use cases are create project,...

Documents

Transcript of Template für Lastenheft - DHBW Stuttgart€¦ · Web viewSubordinate use cases are create project,...