v1.1 1 Anforderungen der Projektadministration 1.1 Zentrale Installation und Administration von Projekten

Transkript

1 v1.1 1 Anforderungen der Projektadministration 1.1 Zentrale Installation und Administration von Projekten Alle projektweiten Informationen müssen an einer Stelle gehalten und geändert werden Eine Historie der Veränderungen muß zur Verfügung stehen Aufzeichnung der Administrationshistorie Administrative Tätigkeiten wie z.b. Verwalten von Usern/Gruppen und Vergabe von Rechten sollten in einer Historie dokumentiert werden 1.2 Benutzer, Rollen und Rechte Das RMT muß über ein fein aufgelöstes System zur Verwaltung von Benutzern, Benutzergruppen, Benutzerrollen, Rechten für Benutzer und Rechten für Benutzerrollen verfügen Benutzermanagement Der Administrator muß die Benutzeraccounts und Gruppenzuordnungen zentral verwalten Die Benutzer und Gruppen müssen Projektübergreifend definiert Rechteverwaltung Das RMT muß eine feingranulare und flexible Vergabe von Zugriffs- und Schreibrechten ermöglichen. Mehrseitige, also auf sich überschneiden könnenden Gruppen basierende Sicherheit ist der Mehrschichtigen ("Multi-Level") vorzuziehen. Die Rechtevergabe darf nicht durch eigene Erweiterungen (API-Programmierung, Skripte) kompromittiert werden Rechtevergabe umfaßt z.b. Zugriffsschutz be konkurrierenden Zulieferern Rollenabhängige Rechtevergabe Zugriffsrechte müssen in Abhängigkeit von den Benutzern zugewiesenen Rollen vergeben werden Ein Benutzer muß auch mehrere Rollen wahrnehmen Granularität bis auf Objekt- und Attributebene Die Rechte müssen sich bis auf Objekt- und Attributebene einrichten lassen. Es muß gezielt zwischen Sichtbarkeit, Vorschlagsrecht und Änderbarkeit unterschieden werde 1.3 Größenbeschränkungen Es dürfen keine Obergrenzen für Datenbankgröße und die Anzahl der Requirements, Benutzer, Gruppen, etc. bestehen. Bestehen sie müssen sie exakt bekannt Die Datenbank muß auch extrem große Projekte handhaben Die Feldgrößen der Attribute sollten keine feste Beschränkung haben Maximalgröße einer Anforderung Die maximale Größe eines Requirements oder einzelner Attribute eines Requirements darf nicht beschränkt Maximalzahl der Requirements Das RMT darf keinen Beschränkungen unterliegen was die mögliche Zahl der Requirements in einem Prokekt, einem Modul, einer Datenbank etc. betriff Maximalzahl der Benutzer Die Anzahl der anlegbaren Benutzer darf nicht beschränkt Maximalzahl der Benutzergruppen Die Anzahl der anlegbaren Benutzergruppen und -Rollen sollte nicht beschränkt Maximale Datenbankgröße Die Gesamtgröße der Datenbank darf nicht beschränkt 1.4 Workflowsupport Das RMT kann die Systementwicklung in Form eines administrierbaren, organisierbaren und steuerbaren Prozesses, genannt Workflow, unterstützen. Informationen könnten in Abhängigkeit vom aktuellen Arbeitsschritt gezielt zur Verfügung gestellt werden Prozeßschrittabhängige Rechtevergabe Rechte könnten abhängig vom aktuellen Prozessschritt vergeben werden. 2 Anforderungen der Entwickler 2.1 Informationsmodell Das RMT muß es dem Anwender erlauben ein Informationsmodell frei zu definieren. Dies kann zum Beispiel in Form eines Klassenschemas oder eines Entity-Relationship Modells geschehen. Dabei müssen Objekte eindeutig identifizierbar sein, das Informationsmodell muß jederzeit änderbar sein, grafisch darstellbar sein und Wiederverwendung bzw. Vererbung ermöglichen. Außerdem sollten bekannte RE-Prozeßstandards modelliert werden können Eindeutige Identifikation von Objekten Jedes Objekt in der Datenbank muss über eine über die Objektlebenszeit unveränderliche Objekteigenschaft eindeutig identifizierbar Ist eine hierarchische Identifizierung vorhanden, so muß diese unabhängig von der eindeutigen sein und sich bei Änderungen der Hierarchie automatisch anpassen Informationsmodell jederzeit änderbar Das Informationsmodell muß auch nach Beginn des Projektes noch veränderbar oder erweiterbar (Zentrale Änderbarkeit: siehe Vererbung und Wiederverwendung Vererbung und Wiederverwendung sollte für alle Klassen, Typen und Attribute möglich Grafische Darstellung des Informationsmodelles Es könnte möglich sein, das Informationsmodell grafisch zu definieren und zu konfigurieren Standards Das RMT könnte Informationsmodelle unterstützen die für die Anwendung der Standardvorlagen (z.b. MIL-STD-490, DoD-2167A, INCOSE/Volere oder IEEE ) benötigt werden. Für die bekannten RE-Prozesse sollten Projekt-Vorlagen mitgeliefert werden die diese Standards modellieren 2.2 Sichten Das RMT muß verschiedene Sichten auf den Datenbestand unterstützen. Eine Sicht ist die Möglichkeit, eine frei definierte Zusammenstellung von Ausschnitten der Daten von mehreren Projekten oder Modulen in einer frei definierten Darstellung betrachten und ändern zu Diese Sichten müssen sowohl zentral vordefiniert als auch Benutzerspezifisch definiert werden Grafische Sichten auf den Datenbestand sollten möglich sein Dokumentorientierten Sichten Die Anforderungen müssen dokumentorientiert angezeigt werden können (als sequentieller Text mit Überschriften etc.). Die Sichten müssen frei definierbar sein (inkl. komplexer Filter auf Objekten, Attributen und Relationen inkl. einer mehrstufigen Verfolgung von Relationen) und die Objekte müssen änderbar RM-Tool Kriterien EvaluationTemplate v1.1 TU, Anforderungen an RM-Tools, Seite 1 von 5, gedruckt am

2 2.2.2 Informationsmodellorientierte Sichten Die Anforderungen müssen informationsmodellorientiert angezeigt werden können (z.b. durch sortierte und gefilterte Tabellen oder durch Formulare angezeigt). Die Sichten müssen frei definierbar sein (inkl. komplexer Filter auf Objekten, Attributen und Relationen inkl. einer mehrstufigen Verfolgung von Relationen) Grafische Sichten auf den Datenbestand Das RMT sollte grafische Sichten des Datenbestandes ermöglichen Projektweites Sichtenmanagement für Benutzerrollen Dokument- und Datenbanksichten sollten projektweit bestimmten Benutzerrollen zugeordnet werden Im Verlauf eines Projekts sollten diese Sichten und Ihre Zuordnung zentral änderbar sein Benutzerspezifische Sichten Jeder Benutzer muß die ihm zugewiesenen Sichten noch persönlich anpassen 2.3 Formatierung, Multimedia und Fremdformate Der Text der Requirements muß formatiert und mit Objekten in Fremdformaten angereichert werden Nicht-Text-Objekte sollten entweder in der Datenbank gespeichert werden oder zumindest in einem Konfigurationsmanagementsystem verwaltet werden und direkt im RMT betrachtbar oder aufrufbar Formatierungsmöglichkeiten Das RMT sollte grundlegende Textformatierungeen unterstützen. Ein RMT sollte die wissenschaftlichen und fremdsprachlichen Zeichensätze unterstützen. Das RMT sollte eine Möglichkeit bieten mathematische Formeln in den Beschreibungen zu verwenden Direkte Einbindung von Objekten anderer Formate Objekte anderer Formate müssen direkt in der RM-Datenbank verwaltet werden und müssen voll von der Versions- und Rechteverwaltung abgedeckt sein (Alternativ: 2.3.3) Kontrollierte Verknüpfung externer Dateien Das RM-Tool muß Objekte anderer Formate außerhalb der Datenbank durch Referenz einbinden können (Alternativ: 2.3.2). Mindestbedingungen sind: - Die Objekte werde in einem Konfigurationsmanagement-Werkzeug verwaltet, mit welchem das RM-Tool zusammenarbeitet. - Die Objekte können entweder über einen Previewer im RM-Tool oder die native Applikation direkt und zügig aufgerufen werden. Änderungen werden in das Konfigurationsmanagement übernommen 2.4 Änderungsmanagement Das RMT muß eine Möglichkeit zur Verwaltung formaler Änderungsanträge besitzen. Die Funktion sollte an den jeweils praktizierten Änderungsprozess anpassbar (Verwandt: 1.4) Verwaltung von Änderungsanträgen Das RMT muss eine Möglichkeit zur Verwaltung formaler Änderungsanträge besitzen Dazu gehört das Einstellen von Änderungsanträgen, Review durch bestimmte Benutze oder Benutzerrollen und die direkte Übernahme bei Zustimmung Statusinformationen Es muss die Möglichkeit geben, der beantragten Änderung einen Status zuzuweisen (beantragt, genehmigt, umzusetzen, umgesetzt, etc.) Kommentare und Diskussionsbeiträge Benutzer könnten außerhalb des formalen Änderungsmanagements Kommentare zu Requirements hinterlassen und zu Requirements eine themensortierte Diskussion führen. Benutzer könnten Kommentare zu jeder Änderung hinterlassen um die Änderung zu begründen 2.5 Dokumentation der Historie Alle Änderungen müssen in der Datenbank abgelegt werden und müssen jederzeit abgefragt, analysiert und rückgängig gemacht werden können Versionierung von Objekten Die Objekte im RMT müssen versioniert werden. Dabei muß zwischen Major- und Minorversionen unteschieden werden Die Version sollte bei bestimmten Änderungen automatisch erhöht werden Exakte Verfolgung bis auf Attributniveau Änderungen müssen bis in die unterste Verfeinerungsebene mitgeführt werden Visualisierung von Änderungen Die Historie sollte vom Tool geeignet visualisiert werden Änderungsberichte Das RMT sollte frei konfigurierbare Änderungsberichte zu generieren. Diese sollten insbesondere auf Sichten, Baselines und generierte Dokumente bezogen werden 2.6 Baselining Das RMT muß Baselines unterstützen. Eine Baseline ist der Inhalt der Requirements- Datenbasis, der zu einem bestimmten Zeitpunkt festgeschrieben wird. Im Gegensatz zur Versionierung von Objekten handelt es sich bei einer Baseline um einen Daten(- teil)bestandes, der aus einer Vielzahl von Objekten besteht. Der mit Hilfe einer Baseline gesicherte Entwicklungsstand ist Basis für die weitere Entwicklung. 2.7 Traceability Requirements müssen untereinander (auch projektübergreifend) verknüpfbar Requirements müssen mit externen Objekten verknüpfbar Die Links sollten in ihrer Richtung und Anzahl unbeschränkt sein, Statusattribute haben, automatisch erstellbar sein, durch Regeln erzwungen werden können und visualisierbar Die Linkstruktur könnte automatisch analysiert werden Automatisches Tracing Traces müssen beim Erstellen beziehungsweise Ändern eines Requirements nach definierten Regeln automatisch vom RMT erstellt bzw. geändert werden können um z.b. bei Änderungen Links suspekt zu markieren Bidirektional gerichtete Links Die Links müssen gerichtet sein und ein Objekt muss gleichzeitig Quelle und Ziel sein Außerdem müssen die Links sowohl von der Quelle zum Ziel als auch umgekehrt eingetragen werden Es muß möglich sein, Links direkt in beiden Richtungen folgen zu können Links haben Attribute Links müssen mit Attributen versehen werden können um zum Beispiel verschiedene Typen von Links definieren zu Verknüpfungspflicht Bestimmten Klassen oder Typen von Requirements sollte vorzuschreiben sein daß sie mindestens über Links zu bestimmten anderer Klassen oder Typen verfügen Projektübergreifende Verknüpfungen Links müssen Projekt- / Modulübergreifend definiert werden RM-Tool Kriterien EvaluationTemplate v1.1 TU, Anforderungen an RM-Tools, Seite 2 von 5, gedruckt am

3 2.7.6 Traceability zu externen Objekten Links müssen auch zu externen Objekten definiert, verwaltet und im RM-Werkzeug sichtbar gemacht werden. Mit Hilfe dieser Links muß zu den externen Objekten navigiert werden Die Klärung der Zugriffsrechte auf externe Objekte muss berücksichtigt werden. Die Links sollten auf die kleinsten Strukturen des externen Objektes möglich sein, z.b. auf ein Attributes einer Klasse (Sehr verwandt: 2.9) Visualisierung der Traces Das RMT muss eine praktikable, nutzerfreundliche und übersichtliche grafische Darstellung (Matrizen, Bäume, Graphen, etc.) und Navigation bzw. Filterung der Traces haben. 2.8 Analysefunktionen Das Tool sollte Requirements analysieren Dazu gehört zum Beispiel die linguistische Analyse, die Analyse der Linkstruktur, die Beobachtung des Projektfortschritts und Analysen zum Risikomanagement Entscheidungsunterstützung Das RMT sollte im Sinne eines OLAP-Systemes Informationen über den Status eines Projektes zur Verfügung stellen Analyse der Traces Das RMT sollte über Analysefunktionen verfügen welche Inkonsistenzen oder Lücken in den Traces aufdecken (Siehe auch 2.7) Linguistische Analyse Das Tool könnte die Bescheibungstete der Requirements nach definierbaren Regeln analysieren und den Benutzer auf ungeeignete Sprache oder falsch verwendete Terminologie hinweisen. 2.9 Werkzeugintegration Das RMT muß mit anderen Tools im Entwicklungsprozess zu verbinden sein und Informationen gegenseitig im jeweiligen Tool sichtbar machen. Hierbei sollte keine Datenredundanz entstehen. Die verwendeten Schnittstellen sollten offen Idealerweise sollte es sich um standardisierte Schnittstellen handeln (Eng verwandt: 2.7.6) Konfigurationsmanagement Das RMT muß eine dichte Integration in die gängigen Konfigurationsmanagement- Tools erlauben Modellierung & Design Das RMT sollte an Modellierungstools anbindbar sein und Requirements mit Modellelementen verknüpfen Die Anbindung muß in beiden Tools transparen Test, Validierung & Verifizierung Das RMT muß an Test-Tools anbindbar sein und Requirements mit Testfällen und Testschritten verknüpfen Die Anbindung muß in beiden Tools transparent Performanceanalyse Das RMT könnte an Tools zur Performanceanalyse anbindbar sein und Requirements mit bestimmten Analysen verknüpfen Die Anbindung muß in beiden Tools transparent Projektmanagement Das RMT könnte an Projektmanagement-Tools anbindbar sein und z.b. Requirements oder Gruppen von Requirements mit Aufgaben im Projektmanagement verknüpfen Die Anbindung muß in beiden Tools transparent Kommunikation Das RMT sollte an die Kommunikationssysteme der Kunden, insbesondere , anbindbar sein um Benachrichtigungen über Ereignisse im RMT verschicken zu Problem Tracking Das RMT könnte an Tools zur Problemverfolgung anbindbar sein und Probleme bestimmten Requirements oder Gruppen von Requirements zuordnen Die Anbindung muß in beiden Tools transparent sein Aktive Schnittstellen Die Schnittstellen der Toolintegration sollten aktiv sein, d.h. die Synchronisation bzw. Änderungsbenachrichtigung sollte automatisch stattfinden oder automatisch angestoßen werden ("Push") Unterstützung offener Toolintegrationsplattformen Ein RM Tool sollte offene Toolintegrationsplattformen, wie z.b. ECLIPSE von IBM, unterstützen Textübernahme Das RMT sollte bestehende Spezifikationsdokumente (z.b. aus MS Word) mitsamt ihrer Struktur übernehmen können Automatische Textübernahme Das Werkzeug sollte Textmarken, Formatierungen, Zeileendezeichen, grammatische Stuktur oder Schlüsselworte erkennen, die es als Beginn und Ende von Requirements- Texten interpretiert Halbautomatische Textübernahme Das RMT sollte eine halbautomatische, d.h. interaktive Übernahme von Requirements aus bestehenden Dokumenten unterstützen 2.11 Dokumentengenerierung Die Dokumente für ein Angebot oder eine Spezifikation müssen automatisch generiert werden Dazu muß ein Dokumentengenerator zur Verfügung stehen, der mit Vorlagen für die Dokumente arbeitet und die aktuellen Informationen aus der Datenbank ausliest. Dokumentengenerierung unterscheidet sich vom Sichtenmanagement (siehe 2.2) dadurch daß die generierten Dokumente nicht mehr an die Datenbank gebunden sind (d.h. Änderungen nicht zurückgeschrieben werden) und eine eigenständige Dokumentdatei entsteht Flexible Konfiguration und Formatierung Die Auswahl der Daten die exportiert werden wollen muß flexibel konfigurierbar Das gleiche gilt für die Formatierung und Positionierung im generierten Dokument Erzeugen von Standardkonformen Dokumenten Der Dokumentengenerator könnte bestimmte Standarddokumentformate (siehe auch 2.1.5) erzeugen. Die Vorlagen für diese Formate könnten mitgeliefert werden Ausgabe von Metainformationen Neben den reinen Daten müssen auch Metainformationen zu diesen Daten exportiert werden, wie z.b. Änderungsinformationen Einbeziehen externer Objekte in die Dokumente In den Requirements abgelegte oder referenzierte externe Objekte in Fremdformaten müssen in die generierten Dokumente einbezogen werden Standardformate Das erzeugte Dokument muß in einem Standardformat gespeichert werden RM-Tool Kriterien EvaluationTemplate v1.1 TU, Anforderungen an RM-Tools, Seite 3 von 5, gedruckt am

4 Geschwindigkeit und Hintergrundbetrieb Der Generator muß auch sehr umfangreiche Dokumentationen mit vielen eingebundenen Fremdobjekten schnell erzeugen und muß automatisiert ablaufen Die Dokumenterzeugung sollte im Hintergrund ablaufen Erweiterbarkeit der Dokumentengenerierung Der Dokumentengenerator muß durch eine vom Werkzeug zur Verfügung gestellte Programmierschnittstelle o.ä. erweiterbar (siehe auch Gemeinsames Arbeiten auf einem Entwicklungsgegenstand Es muß möglich sein, dass mehrere Anwender auf einem Entwicklungsgegenstand arbeiten. Von mehreren gleichzeitig auf einem Objekt arbeitenden Benutzern darf nur einer in der Benutzeroberfläche Änderungen vornehmen Wird ein Objekt von einem Benutzer geändert sollte es in den Benutzeroberflächen der anderen Benutzer sofort und automatisch aktualisiert werden Bedienungsfreundlichkeit und Benutzerunterstützung Das Tool muß intuitiv bedienbar sein, stabil und schnell laufen, gut dokumentiert sein und die Einarbeitungsdauer muß kurz User Interface Standards Das Tool muß bekannten User Interface Standards folgen und die Paradigmen der verwendeten Umgebung (z.b. Fenstermanager) befolgen Stabilität Die Software muß stabil laufen, auch wenn der Benutzer sie falsch verwendet oder wenn nicht-fatale Fehler in der Systemumgebung auftreten Geschwindigkeit Die Clientanwendungen müssen auf einem typischen Client ohne merkliche Verzögerungen arbeiten und auch Interaktionen mit dem Server dürfen keine den Benutzern unangenehm vorkommende Verzögerung verursachen Undo-Funktion Das RMT sollte über eine Undo-Funktionalität verfügen. Im Falle von Client-Server Systemen darf diese auf die Zeitspanne zwischen Bearbeitung des Objekts im Client und Synchronisation mit dem Server beschränkt Einführung (Tutorial) Das Hilfessytem oder die gedruckte Dokumentation sollte über einen speziell für Erstbenutzer ausgerichteten Teil verfügen der diesen systematisch und schrittweise die wichtigsten Funktionen erläutert Hilfesystem Das RMT sollte über ein Hilfesystem verfügen, welches die vollständige Funktionalitä erläutert und sowohl aus einem Kontext als auch strukturiert aufrufbar ist Gedruckte Dokumentation Die Dokumentation des RMT, insbesondere das Installations- und Datenbankmanagementhandbuch sollte auch in gedruckter Form verfügbar Für die Clients sollte diese auch in mehrfacher Ausführung beziehbar Herstellerunterstützung Der Hersteller sollte den Lizenznehmer sowohl bei der Einführung als auch während des Betriebes in vollem Umfang unterstützen 3 Systemumgebung 3.1 Datenbank Die vom RMT verwendete Datenbanktechnologie muß technologisch geeignet, skalierbar und zuverlässig (siehe auch 1.3.5) Datenbanktechnologie Das RMT sollte eine objektorientierte oder hierarchische Datenbank benutzen da dieser zur Speicherung der Strukturen von Requirements besser geeignet ist als eine relationale Datenbank Verfügbarkeit Die Datenbank muß 24 h * 365 Tage verfügbar Wartungsarbeiten an der Datenbank müssen im laufenden Betrieb durchgeführt werden können Transaktionssicherheit Das verwendete Datenbanksystem muß transaktionssicher Überprüfbare Datenintegrität Die Datenbank muß über eine Konsistenzanalyse / Datenintegritätsprüfung verfügen und Fehler reparieren können Arbeit mit verteilten Datenbanken Die Datenbank des RMT muß verteilte Datenbanken unterstützen. Der Synchronisationsmechanismus verteilter Datenbanken muß mit unterschiedlichen Tool- Versionen (auch unterschiedliche Major-Versionen) zuverlässig funktionieren Datenbank unabhängig vom Tool administrierbar Um die Datensicherheit zu erhöhen muß das RMT auf eine Datenbank zurückgreifen welche unabhängig vom Tool selbst ist Backup & Restore für Teilinhalte Ein Backup und Restore der gesicherten Daten muß auch selektiv für Teilinhalte möglich sein und dies im laufenden Betrieb Export / Import in Standardformaten Es muss möglich sein, alle Projektdaten auszulagern und an einem anderen Ort, in einem anderen Werkzeug und zu einem anderen Zeitpunkt wieder einzulesen. Die Daten müssen in einem universellen Format gespeichert werden. 3.2 Verschlüsselung Die Daten in der Datenbank müssen verschlüsselt gespeichert werden können und die Datenübertragung zwischen Server und Client sollte verschlüsselt stattfinden Verschlüsselte Datenhaltung Die in der Datenbank des RMT gespeicherten Informationen dürfen von Systemadministratoren oder Eindringlingen nicht offen gelesen werde können Verschlüsselte Datenübertragung Die Datenübertragung zwischen Server und Client muß verschlüsselt stattfinden. 3.3 Zugriff über Webschnittstelle Das RMT sollte eine Webschnittstelle haben. 4 Kosten und Investitionssicherheit 4.1 Erweiterbarkeit Das RMT muss über Skriptsprachen, API oder ähnliches erweiterbar Die Erweiterungen müssen in das Benutzerinterface integriert werden Es sollten standardisierte Sprachen verwendet werden Erweiterbarkeit über ein API Das RMT muß über ein offenes und wohldokumentiertes API verfügen welches den Zugriff auf alle Funktionen und Daten des RMT erlaubt. Das API muß die Rechtevergabe konsistent durchsetzen Beständigkeit des API Das API muß auch über Major-Versionen hinweg beständig sein oder zumindest abwärtskompatibel bleiben. RM-Tool Kriterien EvaluationTemplate v1.1 TU, Anforderungen an RM-Tools, Seite 4 von 5, gedruckt am

5 4.1.3 Erweiterbarkeit über eine Skriptsprache Das Tool muß mit Hilfe einer Skriptsprache anpassbar und erweiterbar Die Sprache könnte eine Standardsprache Zukunftssicherheit Auschecken von Lizenzen Hersteller und Tool müssen zukunftssicher Indikatoren für die Zukunftssicherheit der Investition in ein Softwareprodukt sind zum Beispiel der Grad der aktiven Fortentwicklung durch den Hersteller, die Wahrscheinlichkeit daß der Hersteller die Nutzungsdauer des Produktes überlebt, die Strategische Position des Produktes im Portfolio des Herstellers und die Verbreitung der Software. Basiert ein Softwareprodukt stark auf Standards ist auch dies ein Indikator für die Zukunftssicherheit. Dasselbe gilt für die Erweiterbarkeit des Produktes (siehe 4 1) Clientlizenzen müssen zum Arbeiten an Mobilen Offline-Rechnern auscheckbar 4.5 Skalierbarer Einsatz der Funktionalität Das Werkzeug könnte in Versionen mit unterschiedlich abgespeckter Funktionalität (und unterschiedlichem Preis) verfügbar 5 Systemvoraussetzungen 5.1 Softwareumgebung Server Auf welchen Rechnerplattformen kann der Server betrieben werden. Optimal wäre mindestens eine UNIX- und eine Microsoft-Plattform 5.2 Hardwarevoraussetzungen Server Über welche Leistungsdaten muß der Server verfügen. 5.3 Softwareumgebung Client Auf welchen Rechnerplattformen kann der Client betrieben werden. Ein Microsoft Windows Client sollte auf jeden Fall vorhanden sein, für die Vielzahl anderer Plattformen ist vermutlich ein Web- oder Java-basierter Client optimal 5.4 Hardwarevorraussetzungen Client Über welche Leistungsdaten muß der Client verfügen. 6 Lizensierung 6.1 Preis Einzellizenz Preis für eine Lizenz für einen Arbeitsplatz bzw. einen Benutzer. Beinhaltet Serverund Clientlizenz falls nötig. 6.2 Preis Netzwerklizenz Die Preisgestaltung für den Netzwerkbetrieb des Systems. Kann eine Pauschale, Benutzeraccountorientierte oder an gleichzeitig aktiven Nutzern orientierte Preisgestaltung Kann bestehen aus: Server-Grundpreis Preis pro Clientinstallation (evtl unterschiedlich je Plattform) Preis pro Benutzeraccount Prei für x gleichzeitig arbeitende Benutzer 6.3 Turnus der Lizenzerneuerung Turnus der Lizenzerneuerung, eventuelle Verpflichtungen zum Systemupgrade. 6.4 Upgrade / Update - Politik Wie häufig werden Bugfixes und Versionen veröffentlicht. Wie lange werden alte Versionen unterstützt? RM-Tool Kriterien EvaluationTemplate v1.1 TU, Anforderungen an RM-Tools, Seite 5 von 5, gedruckt am