Sie sind auf Seite 1von 17

Campus Gummersbach

Informatik und Ingenieurwissenschaften

Lastenheft
SeminarIS
<Dieses Dokument ist strukturell eng angelehnt an [Ebert 2014]. Das Fallbeispiel stammt aus
[Balzert 2012]. Es dient als Beispiel für ein Lastenheft nach [DIN 69901-5] zur Verwendung in
Lehrveranstaltungen des Instituts für Informatik am Campus Gummersbach der TH Köln. Ggfs.
sind zusätzliche Angaben zur Lehrveranstaltung, dem Semester, den Dozenten/Betreuern etc.
auf dem Deckblatt notwendig. Beachten Sie den Einsatz von Textmarken zur Verlinkung inner-
halb des Dokumentes (in MS Word:
Datei->Optionen->Anzeige->Alle Formatierungszeichen anzeigen)!>

Titel: Lastenheft SeminarIS


Autor(en): Prof. Dr. Mario Winter

Studiengang Alle Informatik-Bachelor-Studiengänge


Lehrveranstal-
tung
Semester
Version: 1.1 vom 2018-10-10 Anzahl Seiten: 17
Status: in Bearbeitung (in Bearbeitung/fertig gestellt/geprüft/freigegeben)

Auftraggeber: TH Köln, Campus GM, PM-Team


Lastenheft SeminarIS 2 / 17

Änderungshistorie

Version Datum Bearbeiter Änderung, Bemerkung


0.0 2011-12-01 Christof Ebert Vorlage Lastenheft
0.1 2017-09-18 Mario Winter SeminarIS Initialversion
1.0 2017-10-10 Mario Winter SeminarIS nach Review
1.1 2018-10-10 Mario Winter Konkurrenzanalyse zugefügt

 2018, Lastenheft_SeminarIS_V1_1.docx Version 1.1 vom 2018-10-10


TH Köln, Campus GM, PM-Team
Lastenheft SeminarIS 3 / 17

Inhalt
Änderungshistorie ................................................................................................................. 2
Inhalt ........................................................................................................................................ 3
1 Einführung ................................................................................................................... 4
1.1 Zweck ................................................................................................................................... 4
1.2 Marktanforderungen ............................................................................................................. 4
1.3 Glossar .................................................................................................................................. 4
1.4 Referenzen ............................................................................................................................ 6
1.5 Systemübersicht .................................................................................................................... 7
2 Beschreibung .............................................................................................................. 8
2.1 Produktsicht .......................................................................................................................... 8
2.2 Funktionen ............................................................................................................................ 8
2.3 Benutzer ................................................................................................................................ 9
2.4 Einschränkungen ................................................................................................................... 9
2.5 Qualitätsvorgaben ................................................................................................................. 9
2.6 Annahmen ............................................................................................................................. 9
3 Spezifische Anforderungen ..................................................................................... 10
3.1 Produktfunktionen .............................................................................................................. 10
3.1.1 Kundenverwaltung........................................................................................................ 10
3.1.2 Seminarverwaltung ....................................................................................................... 10
3.1.3 Zahlungsverkehr ........................................................................................................... 10
3.1.4 Informationsbetrieb....................................................................................................... 10
3.1.5 Systemverwaltung ........................................................................................................ 10
3.2 Produktdaten ....................................................................................................................... 11
3.3 Produktschnittstellen ........................................................................................................... 11
3.4 Detaillierte Funktionsbeschreibungen ................................................................................ 11
3.5 Architektur .......................................................................................................................... 12
3.6 Einschränkungen ................................................................................................................. 12
3.7 Qualitätsanforderungen und Abnahmekriterien .................................................................. 13
Abnahmekriterien ............................................................................................................................ 14
3.8 Lieferumfang ...................................................................................................................... 14
3.9 Standards............................................................................................................................. 15
3.10 Weitere Quellen .................................................................................................................. 15
Anhänge ................................................................................................................................ 16
A. Konkurrenzanalyse ............................................................................................................. 16
B. Prozessmodelle ................................................................................................................... 16
Index ...................................................................................................................................... 17

 2018, Lastenheft_SeminarIS_V1_1.docx Version 1.1 vom 2018-10-10


TH Köln, Campus GM, PM-Team
Lastenheft SeminarIS 4 / 17

1 Einführung

1.1 Zweck

<Hier wird der Gegenstand des Projekts beschrieben. Das können Ziele an das Produkt sein, eine His-
torie des Produkts, oder eine kurze Übersicht zum Projekt>
Es ist ein Seminar-Informationssystem (SeminarIS) zu erstellen, das die Planung und Durchführung von
Seminaren sowie die Kundenverwaltung unterstützen soll. Die Seminarveranstaltungen sind entweder
öffentlich, also für jedermann belegbar, oder speziell auf die Belange einer bestimmten Firma zuge-
schnitten, wobei dann auch nur Mitarbeiter der Firma teilnehmen dürfen. Die Seminare werden in der
Regel von freiberuflich tätigen Dozenten gehalten, die sich anhand von Veröffentlichungen und nach-
gewiesener Projekterfahrung als Experten auf dem jeweiligen Gebiet ausgewiesen haben.
Öffentliche Seminare werden langfristig geplant und müssen in Anbetracht der wirtschaftlichen Lage
und der starken Konkurrenz effektiv beworben werden, um zu einer kostendeckenden Teilnehmerzahl
zu kommen. Firmenseminare sind dahingegen oft kurzfristig durchzuführen, was aber oft an der Ver-
fügbarkeit kompetenter Dozenten scheitert.
Durch das Seminar-Informationssystem, das die Seminarverwaltung und die Bearbeitung von Anfragen
der Kundenbetreuer unterstützt, erhofft sich der Auftraggeber Erleichterungen für seine Angestellten.
Außerdem erwartet er eine verbesserte Kundenbetreuung und eine Steigerung der Produktivität. Rech-
nungskopien werden an ein zentrales Fakturierungssystem übermittelt und von diesem weiter bearbeitet
und verfolgt.

1.2 Marktanforderungen

<Die Marktanforderungen werden einzeln identifizierbar beschrieben. Das beinhaltet Markt, Bedarf,
Design, Alleinstellungsmerkmale, etc. Nicht immer passt eine einheitliche Schablone, denn auch Rand-
bedingungen und Kenngrößen des Markts, der Mitbewerber, konkurrierender Lösungen sollen beschrie-
ben werden.>
Kerngeschäft des Auftraggebers ist die [M10] Konzeption, Planung und Durchführung von Seminar-
veranstaltungen in allen Bereichen der Informatik. Zielgruppe des Produkts sind die Seminar- und Kun-
densachbearbeiter des Auftraggebers. Das System wird in den Zweigstellen des Auftraggebers einge-
setzt, wobei eine [M20] zentrale Datenhaltung vorzusehen ist.
In der bisher manuell abgewickelten Seminarverwaltung muss die [M30] Unterstützung der Angestell-
ten und insbesondere der Kundenbetreuer des Auftraggebers verbessert werden. [M40] Informationen
über Personen und ihre bisher belegten Seminare müssen derzeit mühsam aus einzelnen Akten extrahiert
werden. Schon einfache Anfragen über freie Plätze in Seminaren können vom Kundenbetreuer oft nicht
schnell genug erledigt werden. [M50] Darüber hinaus ist die Zahlungsmoral einiger Teilnehmer schlecht
und sollte bei der Belegung von Seminaren berücksichtigt werden können.

1.3 Glossar

<Alle verwendeten Definitionen, Akronyme, Abkürzungen werden beschrieben. Das Glossar sollte hier
gepflegt werden, kann aber aus einer Datenbank extrahiert sein.>

Begriffe

Adresse
Typ Attributbündel
Beschreibung Informationen für die postalische Zustellung.
 2018, Lastenheft_SeminarIS_V1_1.docx Version 1.1 vom 2018-10-10
TH Köln, Campus GM, PM-Team
Lastenheft SeminarIS 5 / 17

Struktur Straße, Hausnummer, Postleitzahl, Ort, Landesteilkürzel, Landeskürzel


Beispiel Steinmüllerallee, 1, 51643, Gummersbach, NRW, DE
Kontext Seminarverwaltung, Kundenverwaltung, Dozentenverwaltung
Synonyme Postadresse, Zustelladresse
Homonyme Adresse in der Datenbank
Verw. Begriffe -
Referenzen Lastenheft [M10] [M20] [M40] [F10] [F20] [F40] [F50] [F60] [D10]

Person
Typ Natürliche Person
Beschreibung Eine Person, die im Kontext der Seminarveranstaltungen eine Rolle
spielt.
Struktur Name, Vorname, Titel, Geburtsdatum, Adresse, Telefon, Fax, ...
Beispiel
Kontext Kundenverwaltung, Dozentenverwaltung
Synonyme Interessent
Homonyme -
Verw. Begriffe Teilnehmer, Dozent
Referenzen Lastenheft [F10] [F30] [D10]

Teilnehmer
Typ Natürliche Person
Beschreibung Eine Person, die mindestens eine Seminarveranstaltung belegt hat.
Struktur Name, Vorname, Titel, Geburtsdatum, Adresse, Firma, Telefon, Fax, ...
Beispiel
Kontext Kundenverwaltung
Synonyme Seminarteilnehmer, Kunde
Homonyme -
Verw. Begriffe Person
Referenzen Lastenheft [F10] [F30] [D10]

 2018, Lastenheft_SeminarIS_V1_1.docx Version 1.1 vom 2018-10-10


TH Köln, Campus GM, PM-Team
Lastenheft SeminarIS 6 / 17

Seminarveranstaltung
Typ Sachverhalt
Beschreibung Eine Veranstaltung zu einem Seminartyp, die an einem bestimmten Ort zu
einer bestimmten Zeit von einem Seminarleiter und ggfs. einem oder meh-
reren Begleitdozenten durchgeführt wird.
Struktur Seminartitel, Beginn, Ende, Ort, TeilnehmerMax, ...
Beispiel UML für Anfänger, 20.10. 2017, 23.10.2017, Erlangen, 20, …
Kontext Seminarverwaltung, Kundenverwaltung
Synonyme Seminar
Homonyme -
Verw. Begriffe Seminartyp
Referenzen Lastenheft [F40] [F50] [F30] [D30]

Abkürzungen

Kürzel Begriff / Referenz


GoBD Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Bü-
chern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum
Datenzugriff ([GoBD 2014])
SV Seminarveranstaltung
ST Seminartyp
USV Unterbrechungsfreie Stromversorgung

1.4 Referenzen

<Referenzen zu Gesetzen, Verordnungen, Standards, externen Dokumenten etc. werden hier zusammen-
gefasst. Unbedingt auch URLs und Zugangsmöglichkeiten angeben.>

[GoBD 2014] Bundesministerium der Finanzen: Grundsätze zur ordnungsmäßigen Führung und
Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer
Form sowie zum Datenzugriff. Berlin, 2014
http://www.bundesfinanzministerium.de/Content/DE/Downloads/BMF_Schrei-
ben/Weitere_Steuerthemen/Abgabenordnung/Datenzugriff_GDPdU/2014-11-14-
GoBD.pdf?__blob=publicationFile&v=1

 2018, Lastenheft_SeminarIS_V1_1.docx Version 1.1 vom 2018-10-10


TH Köln, Campus GM, PM-Team
Lastenheft SeminarIS 7 / 17

1.5 Systemübersicht

<Das Gesamtsystem mit Kontext sowie die Kontextabgrenzung werden beschrieben.>



Dem System liegt eine Client/Server-Architektur zugrunde. Die fest installierten Desktop-Clients basie-
ren auf einem MS-Windows-Betriebssystem ab Windows 7. Mobile Clients sind für iOS und Android
vorgesehen. Der Server muss Hersteller-unabhängige Schnittstellen für die Clients anbieten. Entspre-
chende graphische Benutzungsoberflächen in gängigem Standard sind zu integrieren (z. B. Java-Swing,
Eclipse RCP, responsive Web-Applikation). Alle Personen- und Seminardaten sind auf einem vorhan-
denen Linux-Server in einem relationalen Datenbankmanagementsystem (RDBMS) mit JDBC-Schnitt-
stelle zu verwalten. Der Datentransfer erfolgt unter TCP/IP.. Abb. 1 zeigt den Einsatzkontext des Sys-
tems.

Abb. 1 SeminarIS Kontextdiagramm (nach: [Winter 2005])

 2018, Lastenheft_SeminarIS_V1_1.docx Version 1.1 vom 2018-10-10


TH Köln, Campus GM, PM-Team
Lastenheft SeminarIS 8 / 17

2 Beschreibung

2.1 Produktsicht

<Das Produkt mit Systemschnittstellen, Benutzung, HW-/SW-Schnittstellen etc. wird beschrieben>


Die Benutzungsoberfläche muss die Grundsätze der Dialoggestaltung nach [DIN 9241-110] erfüllen.
Das System muss seine Ausgaben auf handelsüblichen Druckern auch ohne Postscript-Fähigkeit vor-
nehmen können.
Das System besitzt keine integrierte Buchhaltung, sondern soll nach dem EDIFACT-Standard ([DIN
ISO 9735]) mit dem zentralen Fakturierungssystem verbunden werden, welches die Rechnungsdaten
erhält und Zahlungsverzüge meldet.

2.2 Funktionen

<Hier werden die wesentlichen Funktionen als Übersicht beschrieben. Typische Darstellungsformen
sind strukturierter Text, Feature-Bäume oder Use-Cases>

Abb. 2 zeigt wichtige Anwendungsfälle des Systems. Zur Vereinfachung ist der DB-Server nicht dar-
gestellt.…

Abb. 2 Wichtige Anwendungsfälle (nach: [Winter 2005])


 2018, Lastenheft_SeminarIS_V1_1.docx Version 1.1 vom 2018-10-10


TH Köln, Campus GM, PM-Team
Lastenheft SeminarIS 9 / 17

2.3 Benutzer

<Beschreibung verschiedener Benutzergruppen, Profile/Personae, ggfs. Szenarien>



Benutzer von SeminarIS sind ausschließlich Mitarbeiter des Auftraggebers (Sachbearbeiter, Sekretärin,
Assistent/-in), die sich in drei Gruppen einteilen lassen:
• Kundensachbearbeiter
• Seminarsachbearbeiter
• Administratoren
Sie haben die folgenden Profile und typische Funktionen:
Kundensachbearbeiter sind geschulte IT-Anwender, die bereits seit Jahren mit Standard-Software (Text-
verarbeitung, Tabellenkalkulation etc.) arbeiten. Sie bearbeiten die Funktionen [F10] bis [F30] und
[F60] bis [F80] und dürfen nur auf die dazu nötigen Daten zugreifen. Dazu sind entsprechende Zugriffs-
rechte einzurichten.
Seminarsachbearbeiter sind geschulte IT-Anwender, die bereits seit Jahren mit Standard-Software
(Textverarbeitung, Tabellenkalkulation, Präsentationssoftware etc.) arbeiten. Sie bearbeiten die Funkti-
onen [F40] und [F50] sowie [F70] und [F80]. Sie dürfen nur auf die dazu nötigen Daten zugreifen.
Entsprechende Zugriffsrechte sind einzurichten.
Administratoren sind IT-Spezialisten (System- und Netzwerkadministration), die für die regelmäßige
Sicherung und Wartung des lokalen Datenbestandes verantwortlich sind [F90], Backups und [F100],
Löschen. Außerdem verwalten sie die Benutzer und ihre Zugriffsrechte [F110] und kümmern sich um
technische Probleme.

2.4 Einschränkungen

<Zusammenfassende Darstellung der wesentlichen externen Vorgaben, z.B. Protokolle, Hardware, Al-
gorithmen>
Als Betriebssystem kommt auf dem Server Linux zum Einsatz. Als Datenbanksystem wird mySQL ein-
gesetzt. Fremdsysteme sind über WebServices im SOAP-Format [URL SOAP] auf Basis von HTTPS
anzubinden (s. [IF10]).

2.5 Qualitätsvorgaben

<Zusammenfassende Darstellung der wesentlichen externen Vorgaben, z.B. Zuverlässigkeit, funktionale


Sicherheit, Performanz>
Die Wartezeit zwischen einer Eingabe eines Benutzers bis zur ersten Reaktion darf 0,5 Sekunden, bis
zur ersten Ausgabe 5 Sekunden nicht überschreiten.

2.6 Annahmen

<Beschreibung aller Annahmen, die nicht durch den Kunden definiert wurden, aber für die Realisierung
relevant sind, z.B. Stromversorgung, Klima>
Es existiert keine USV.

 2018, Lastenheft_SeminarIS_V1_1.docx Version 1.1 vom 2018-10-10


TH Köln, Campus GM, PM-Team
Lastenheft SeminarIS 10 / 17

3 Spezifische Anforderungen

3.1 Produktfunktionen

<Hier werden die konkreten Funktionen einzeln identifizierbar skizziert>


Die Produktfunktionen lassen sich zunächst grob in die fünf Funktionsbereiche Kundenverwaltung, Se-
minarverwaltung, Zahlungsverkehr, Informationsbetrieb und Systemverwaltung unterteilen:

3.1.1 Kundenverwaltung

[F10] Personen bearbeiten (Angestellte des Auftraggebers sind als Seminarteilnehmer zugelassen),
gezielte Werbung.
[F20] Firmen bearbeiten, bei denen Personen angestellt sind.
[F30] Seminarbelegungen bearbeiten inklusive Teilnehmer-Benachrichtigung (Anmeldung, Abmel-
dung, Änderung, Rechnung), ggf. Firmen-Benachrichtigungen, falls Firma Rechnungsemp-
fänger.
[F35] Firmenseminare („in-House“) bearbeiten inklusive Teilnehmer-Benachrichtigungen (Anmel-
dung, Abmeldung, Änderung, Rechnung),

3.1.2 Seminarverwaltung

[F40] Seminarveranstaltungen und -typen bearbeiten.


[F50] Dozenten bearbeiten sowie Zuordnung zu Seminarveranstaltungen und -typen.

3.1.3 Zahlungsverkehr

[F60] Erstellen von Rechnungen und Gutschriften. Kopien der Datensätze werden über das Netz an
das Fakturierungssystem gemeldet. Dieses meldet seinerseits auftretende Zahlungsverzüge an
SeminarIS zurück.

3.1.4 Informationsbetrieb

Folgende Arten von Listen und Anfragen müssen unterstützt werden:


[F70] Erstellung verschiedener Listen und Bescheinigungen (Teilnehmerliste, Teilnahmebescheini-
gungen, Umsatzliste pro Jahr/Person/Firma).
[F80] Anfragen der folgenden Art sollen möglich sein: Wann findet das nächste Seminar X statt?
Welche Teilnehmer sind im Zahlungsverzug? Wieviel Teilnehmer kommen aus bestimmten
Wohnorten?

3.1.5 Systemverwaltung

Die Systemverwaltungskomponente unterstützt die Administratoren von SeminarIS durch Funktionen


folgender Art:
[F90] Erstellen von Backups des kompletten Datenbestandes.
[F100] Löschungen von Daten wie z. B. veraltete oder stornierte Seminare, Personendaten, etc.. Lö-
schungen müssen aus Sicherheitsgründen protokolliert und genehmigt werden.
[F110] Einrichten und Ändern von Benutzern.
[F120] Updates müssen über das Web automatisch geladen und installiert werden.

 2018, Lastenheft_SeminarIS_V1_1.docx Version 1.1 vom 2018-10-10


TH Köln, Campus GM, PM-Team
Lastenheft SeminarIS 11 / 17

3.2 Produktdaten

<Hier sind die wesentlichen Daten zu skizzieren, wobei die Einträge im Glossar detaillieren können.>
[D10] Es sind relevante Daten über die Personen zu speichern.
[D20] Gehört eine Person zu einer Firma, sind über die Firma relevante Daten zu speichern.
[D30] Es sind relevante Daten über Seminarveranstaltungen, -typen und Dozenten zu speichern.
[D40] Belegt ein Teilnehmer eine Seminarveranstaltung, dann sind entsprechende Belegungsdaten
zu speichern.
[D50] Ist ein Teilnehmer im Zahlungsverzug, dann sind die Höhe des Zahlungsverzugs und der Stich-
tag zu speichern, an dem der Zahlungsverzug eingetreten ist.

3.3 Produktschnittstellen

<Hier werden Anforderungen an die externen Schnittstellen aufgeführt, z.B. Standards, Protokolle, …>
[IF10] Die Anbindung von Fremdsystemen wie z.B. dem Fakturierungssystem erfolgt über WebSer-
vices im SOAP-Format [URL SOAP] auf Basis von HTTPS.

3.4 Detaillierte Funktionsbeschreibungen

<Hier werden die konkreten Funktionen einzeln identifizierbar mit der Anforderungsschablone be-
schrieben, z.B. Gültigkeitsprüfungen, Use-Cases, Abnahmekriterien>

[UC07] Person erfassen
Quellen [F10]
Spezifikation ~/uc/spec/kunden/UC07
Beschreibung Die Daten einer Person werden erfasst. Das System prüft während der Erfas-
sung, ob die Daten bereits in der Datenbank vorliegen, und schlägt ggfs. ent-
sprechende Einträge vor.
Inputs Personendaten
Outputs Speicherbestätigung
Sequenz 1. Der Benutzer gibt die Personendaten ein.
2. Das System schlägt entsprechende vorhandene Einträge vor.
3. Der Benutzer akzeptiert oder verwirft die Vorschläge.
4. Das System prüft die vollständige Eingabe auf Plausibilität und Korrekt-
heit und gibt eine Bestätigung aus.
Ausnahmen -
Vorbedingung -
Nachbedingung Die Personendaten sind konsistent und aktualisiert.
Einschränkungen -
Testfälle ~/qs/akzeptanztest/kunden/UC07
~/qs/unittest/kunden/UC07

 2018, Lastenheft_SeminarIS_V1_1.docx Version 1.1 vom 2018-10-10


TH Köln, Campus GM, PM-Team
Lastenheft SeminarIS 12 / 17

3.5 Architektur

<Darstellung und Beschreibung der Architektur. Im Lastenheft wird die Architektur zunächst aus Prob-
lemsicht beschrieben, z.B. extern vorgegebene Datenmodelle, Systemmodelle, Evolution des Systems>

Abb. 3 zeigt die Web-MVC-Architektur des Systems. Dem System liegt eine Client/Server-Architektur
mit einem lokalen Netz zugrunde. Die Clients basieren auf dem MS-Windows-Betriebssystem. Eine
graphische Oberfläche in gängigem Standard (z. B. Java-Swing, Eclipse RCP) ist zu integrieren. Alle
Personen- und Seminardaten sind auf einem Linux-Server in einem relationalen Datenbankmanage-
mentsystem (RDBMS) mit JDBC-Schnittstelle zu verwalten. Der Datentransfer erfolgt unter TCP/IP.

Abb. 3 Web-MVC-Architektur (Aus: [Balzert 2012])


3.6 Einschränkungen

< Interne und externe Einschränkungen werden detailliert dargestellt. Sie sollten messbar beschrieben
sein, damit klar ist, wie getestet wird, und wie intern geklärt werden kann, ob sie erfüllt sind. Falls
vorhanden werden Abnahmekriterien beschrieben. Einschränkungen sollten nur das nötigste beschrei-
ben, um den Lösungsraum nicht zu sehr einzuschränken.>

Entwicklungs- und Wartungsumgebung des Projektes ist ein Linux-Betriebssystem.

 2018, Lastenheft_SeminarIS_V1_1.docx Version 1.1 vom 2018-10-10


TH Köln, Campus GM, PM-Team
Lastenheft SeminarIS 13 / 17

3.7 Qualitätsanforderungen und Abnahmekriterien

<Interne und externe Qualitätsanforderungen werden detailliert dargestellt und priorisiert. Sie sollten
messbar beschrieben sein, damit klar ist, wie getestet wird, und wie intern geklärt werden kann, ob sie
erfüllt sind. Falls vorhanden werden Abnahmekriterien beschrieben.>
Qualitätsmerkmale (nach [ISO 25010])
Anwendungsbezogene Qualität
Merkmal Teilmerkmale Priorität
Effektivität Aufgabenerfüllung innerhalb der Genauigkeits- und Vollstän- Hoch
digkeitsgrenzen
Effizienz Aufgabenerfüllung innerhalb der Aufwandsgrenzen für Benut- Hoch
zer (Zeit, Kosten, ...)
Zufriedenheit Verwendbarkeit, Vertrauen, Begeisterung, Bequemlichkeit Mittel
Risikoabwe- Wirtschaftliche Risiken, Gesundheits- und Sicherheitsrisiken, Mittel
senheit Umgebungs- und Umweltrisiken
Kontextabde- Kontextuelle Vollständigkeit, Flexibilität Mittel
ckung

Produktqualität
Externe Qualität
Merkmal Teilmerkmale Priorität
Funktionalität Vollständigkeit, Richtigkeit, Angemessenheit Sehr Hoch
Performanz Zeitverhalten, Ressourcengebrauch, Kapazität Hoch
Kompatibilität Koexistenz, Interoperabilität Hoch
Benutzbarkeit Angemessenheit, Erkennbarkeit, Erlernbarkeit, Bedienbarkeit, Mittel
Fehlertoleranz, Ästhetik, Zugänglichkeit
Zuverlässig- Reife, Verfügbarkeit, Fehlertoleranz, Wiederherstellbarkeit Mittel
keit
Sicherheit Vertraulichkeit, Integrität, Nachweisbarkeit, Verantwortlich- Hoch
keit, Authentifizierbarkeit
Interne Qualität
Merkmal Teilmerkmale Priorität
Wartbarkeit Modularität, Wiederverwendbarkeit, Analysierbarkeit, Modifi- Mittel
zierbarkeit, Testbarkeit
Portierbarkeit Anpassbarkeit; Installierbarkeit, Austauschbarkeit Gering

 2018, Lastenheft_SeminarIS_V1_1.docx Version 1.1 vom 2018-10-10


TH Köln, Campus GM, PM-Team
Lastenheft SeminarIS 14 / 17

Abnahmekriterien

Mindestens 90% aller Abnahmeprüffälle müssen fehlerfrei ablaufen. Während der Abnahme dürfen
keine schwerwiegenden Fehler auftreten. Es sind alle Vorgänge besonders kritisch, die Veränderungen
von Daten verursachen. Rechnungen müssen absolut korrekt bearbeitet und übertragen werden.
Bei den Sachbearbeiter-Tätigkeiten (Seminarbelegungen, Informationsbetrieb, Personen- und Seminar-
verwaltung) soll die durchschnittliche Bearbeitungsdauer gegenüber dem jetzigen Stand um mindestens
50% verkürzt werden:
[A10] Die Funktionen unter Punkt [F80] dürfen nicht länger als 5 Sekunden Interaktionszeit benöti-
gen, alle anderen Reaktionszeiten müssen unter 2 Sekunden liegen.
Das tatsächlich zu berücksichtigende Datenvolumen ergibt sich aus der Summe der minimalen Größen,
die zusätzlich mit dem Sicherheitsfaktor 2 multipliziert wird:
[A20] Es müssen minimal 50.000 Personen und minimal 3.000 Seminare verwaltet werden können.
[A30] 5 Prozent aller Teilnehmer sind erfahrungsgemäß im Zahlungsverzug.
Folgende Funktionssequenzen müssen fehlerfrei möglich sein:
[T10] Teilnehmeranmeldung, Ersterfassung, Abmeldung, Neuanmeldung, Rechnung, Zahlungsver-
zug.
[T20] Absage bzw. Änderung einer Belegung.
[T30] Stornierung eines Seminars, Gutschriften erstellen.
[T40] Belegungen eines Seminars eintragen, Rechnungen erstellen.
[T50] Durchführung eines Seminars eintragen, Teilnehmerliste und Teilnahmebescheinigungen dru-
cken.
[T60] Backup und Restore des gesamten Datenbestandes.
Folgende Datenkonsistenzen sind einzuhalten:
[T70] Eine Seminarbelegung kann nur vorgenommen werden, wenn sowohl die Person als auch eine
entsprechende Seminarveranstaltung vorhanden sind und die Seminarveranstaltung noch nicht
ausgebucht ist.
[T80] Eine neue Seminarveranstaltung kann nur eingetragen werden, wenn ein entsprechender Se-
minartyp und ein Dozent vorhanden sind.
[T90] Eine Seminarbelegung kann nur vorgenommen werden, wenn der Teilnehmer nicht im Zah-
lungsverzug ist.

3.8 Lieferumfang

<Hier sind materielle und immaterielle zu liefernde Dinge (Artefakte, Dienstleistungen) aufzuführen>
Das System inkl. elektronischer Handbücher ist auf einem nicht-wiederbeschreibbaren Datenträger
(DVD-ROM, BlueRay) installationsfähig zu liefern. Updates sind über das Web zu liefern.
Um die Datenbeschaffung kümmert sich der Auftraggeber. Sie ist nicht Gegenstand des Projekts.
Die Erstellung schließt eine einjährige Garantie ein. Anschließend ist über Wartungsverträge zu verhan-
deln.

 2018, Lastenheft_SeminarIS_V1_1.docx Version 1.1 vom 2018-10-10


TH Köln, Campus GM, PM-Team
Lastenheft SeminarIS 15 / 17

3.9 Standards

<Standards mit spezifischen Anforderungen werden hier detailliert. Sie sollen nicht abgeschrieben wer-
den, sondern als wesentliche Anforderungen beschrieben werden. In stark regulierten Bereichen, z.B.
Telekommunikation, sind Standards häufig die wesentliche Quelle aller Anforderungen.>

[ISO 25010] ISO/IEC 25010: Systems and Software Engineering – Systems and software Quality
Requirements and Evaluation (SQuaRE) – System and software quality models. ISO,
Genf, 2011
[DIN 69901-5] DIN 69901-5: Projektmanagement - Projektmanagementsysteme - Teil 5: Begriffe.
Beuth Verlag, Berlin, 2009
[DIN 9241-110] DIN EN ISO 9241-110: Ergonomie der Mensch-System-Interaktion - Teil 110:
Grundsätze der Dialoggestaltung. Beuth Verlag, Berlin, 2008
[DIN ISO 9735] DIN ISO 9735-xx: Elektronischer Datenaustausch für Verwaltung, Wirtschaft und
Transport (EDIFACT) - Syntax-Regeln auf Anwendungsebene. Teile 1-10, Beuth-Ver-
lag, Berlin, 2004
[URL SOAP] SOAP Version 1.2 Part 1: Messaging Framework (Second Edition). W3C Recommen-
dation, 27 April 2007.
http://www.w3.org/TR/2007/REC-soap12-part1-20070427/

3.10 Weitere Quellen

[Balzert 2012] Balzert, H.: Lehrbuch der Softwaretechnik: Entwurf, Implementierung, Installation und
Betrieb. Springer Spektrum, Heidelberg, 2012
[Ebert 2014] Ebert, C.: Systematisches Requirements Engineering. dpunkt-Verlag, Heidelberg, 2014
[Winter 2005] Winter, M.: Methodische objektorientierte Softwareentwicklung. dpunkt.verlag, Hei-
delberg, 2005

 2018, Lastenheft_SeminarIS_V1_1.docx Version 1.1 vom 2018-10-10


TH Köln, Campus GM, PM-Team
Lastenheft SeminarIS 16 / 17

Anhänge
<Ggf. weitere, z.B. firmeninterne Dokumente, Hinweise/Analysen von existierenden Produkten/Syste-
men etc., die für die Anforderungen relevant sind.>

A. Konkurrenzanalyse

SimplyOrg
https://simplyorg.de/loesungen/seminarverwaltung-fuer-bildungsinstitute
Einstiegsinfo
SEMINARVERWALTUNG LEICHT GEMACHT
Die Komplettlösung für Ihr Seminarmanagement: Seminare planen, organisieren, verwalten und ver-
markten – zeit- und kosteneffizient mit einer zentralen Software
Als Anbieter von Seminaren und Weiterbildungen kennen Sie die Herausforderungen, die eine kom-
plexe Planung mit sich bringt. Ab 200 Kursen im Jahr führen unübersichtliche Arbeitsabläufe nicht nur
zu einem enormen Zeitaufwand, sondern letztlich auch zu suboptimaler Planung und Durchführung Ih-
rer Seminare.
Wie schön wäre es, wenn Sie sämtliche Prozesse zur Seminarverwaltung in einer einzigen Software
managen könnten, in der Sie jederzeit den Überblick haben und somit einen reibungslosen Ablauf, hohe
Qualität und optimale Wirtschaftlichkeit Ihrer Kurse garantieren können? Mit der simplyOrg Seminar-
verwaltungssoftware ist dies ganz einfach realisierbar.
• Rundum-Paket: Planung, Vorbereitung, Bewerbung sowie Auswertung und Abrechnung Ihrer
Seminare – alles in einem einzigen Tool
• Übersichtlichkeit und Transparenz: Jederzeit alles im Blick durch eine zentrale Software-Lö-
sung
• Zeitersparnis: Workflow Management zur Automatisierung wiederkehrender Aufgaben und
Prozesse in der Seminarverwaltung
• Qualitätsmanagement: Abarbeitung der Aufgaben via Checklisten, inklusive Abhängigkeiten,
Status und Fälligkeit
• Kostensenkung: Optimierung Ihrer Seminare bezüglich Auslastung und Qualität
• Einfachheit: Intuitiv bedienbare Seminarsoftware zur Digitalisierung aller Prozesse
• Maßgeschneidert: Funktionen und Schnittstellen ganz nach Ihren Bedürfnissen
Lizenz-Info und Kosten

B. Prozessmodelle

 2018, Lastenheft_SeminarIS_V1_1.docx Version 1.1 vom 2018-10-10


TH Köln, Campus GM, PM-Team
Lastenheft SeminarIS 17 / 17

Index

Adresse 4 Seminarverwaltung 4
Auftraggeber 4 ST Siehe Seminartyp
GoBD 6 SV Siehe Seminarveranstaltung
Person 5 Teilnehmer 5
Seminarveranstaltung 6

 2018, Lastenheft_SeminarIS_V1_1.docx Version 1.1 vom 2018-10-10


TH Köln, Campus GM, PM-Team