erweiterte Kundenanforderung

IT- Charity Portal
Brücken bauen
Kundenanforderungsspezifikation
(Fassung vom 21.04.2005)
Inhaltsverzeichnis
1 Einleitung .......................................................................................................................3
1.1 Hintergrund ............................................................................................................3
1.2 Aufgabenstellung ..................................................................................................4
2 Anforderungen ............................................................................................................5
2.1 Nicht- funktionale Anforderungen ......................................................................5
2.1.1 Technisches:...................................................................................................5
2.1.2 Ergonomie: ......................................................................................................5
2.1.3 Internationalität ..............................................................................................5
2.2 Funktionale Anforderungen .................................................................................6
2.3 Rollen und Sicherheitskonzept ............................................................................6
2.3.1 Karitative Einrichtung ....................................................................................6
2.3.2 Freiwillige Helfer ............................................................................................6
2.3.3 Staatlich anerkannte Prüfstelle .....................................................................7
2.3.4 Administrator ..................................................................................................7
2.3.5 Benutzer in Rollen..........................................................................................7
2.3.6 Allgemeine Anforderungen ...........................................................................8
2.4 Einige Use- Cases...................................................................................................8
2.4.1 Öffentliche Informationen abrufen ..............................................................8
2.4.2 Karitative Einrichtung anmelden ..................................................................8
2.4.3 Freiwilligen Helfer registrieren .....................................................................9
2.4.4 Projekt eintragen und verwalten ..................................................................9
2.4.5 Projekt suchen und auswählen ....................................................................9
2.4.6 Projektzustimmung ........................................................................................9
2.4.7 Projekt/Stammdatenverwaltung ...................................................................9
2.4.8 Löschung eine CO........................................................................................10
2.5 Datenhaltung .......................................................................................................10
2.5.1 Karitative Einrichtung (CO).........................................................................10
2.5.2 Freiwilliger Helfer (VO)................................................................................10
2.5.3 Staatlich anerkannte Einrichtung (GO)......................................................10
2.5.4 Benutzer ........................................................................................................10
2.5.5 Projekt ............................................................................................................11
3 Klarstellungen aus dem Kundengespräch (und sonst gestellten Fragen).........11
2
1 Einleitung
1.1 Hintergrund
Die Firma Microsoft Deutschland GmbH versteht sich selbst als ein so genannter
Corporate Citizen in Deutschland. Wie viele andere Unternehmen hat auch
Microsoft erkannt, dass es neben kurzfristigen positiven Imageeffekten
langfristig wichtig für ein Unternehmen ist, in den Standort selbst zu
investieren. Denn die wirtschaftliche und soziale Infrastruktur eines Standortes
ist enorm wichtig für die Leistungsfähigkeit der Mitarbeiter und des
Unternehmens in einem nationalen und internationalen Markt. Diese Faktoren
können u.a. auch entscheidend für die Investitionen eines Unternehmens oder
von dessen Industriepartnern in das jeweilige Land sein. Ein Beispiel hierfür
wäre die Einrichtung des European Microsoft Innovation Centers in Aachen, bei
dem sich der Standort Deutschland im internationalen Vergleich gegen andere
Länder durchsetzen konnte. Entscheidend hierbei war die Infrastruktur.
Im Rahmen seiner Verantwortung als „Bürger“ fördert Microsoft auch die
Initiativen von Mitarbeitern, um soziale Verantwortung zeigen zu können. So
entstanden die Projekte IT- Charity und auch IT- Brücke, die beide zum Ziel
haben, Projekte karitativer Einrichtungen mit Know- How und auch mit
finanziellen Ressourcen zu unterstützen. Natürlich können Einzelne aber auch
ein Unternehmen alleine nicht die Vielzahl an sozialen und karitativen
Einrichtungen gebührend unterstützen. Die Idee beider Projekte war hier eine
ganz einfache: Biete eine Plattform, bei der karitative Projekte an freiwillige ITProfessionals, Software- Entwickler, Hochschulen oder Studenten, die hier helfen
wollen, vermittelt werden. Auf diese Weise kann man Einrichtungen, die sich aus
Spenden finanzieren, einen echten Mehrwert bieten. Denn gerade in der IT- Welt
sind die Kosten für Hardware etc. um ein Vielfaches kleiner als die Kosten für
das „Know- How“ bzw. die Planung, Erstellung und Einrichtung einer ITUmgebung.
3
1.2 Aufgabenstellung
Es soll auf Basis von ASP.NET ein webbasierter Online- „Marktplatz“ entwickelt
werden, auf dem karitative Einrichtungen und ehrenamtliche Helfer sich finden
können.
Karitative oder auch kulturelle Einrichtungen sollen in der Lage sein, sich selbst
und ihre gewünschten Projekte darstellen zu können, um interessierte freiwillige
Helfer zu finden. Dabei soll es einen entsprechenden Registrierungsprozess
geben, bei dem eine staatlich anerkannte Stelle den karitativen Status einer
solchen Einrichtung überprüft, bevor diese ins System aufgenommen wird. Eine
karitative Einrichtung soll auch mehrere Projekte mit den jeweiligen
Ansprechpartnern verwalten können.
Die freiwilligen Helfer sollen in der Lage sein sich als Hilfswillige zu registrieren
und anonym die unterschiedlichen Projekte zu begutachten und bei Interesse
ggf. auch anonym weitere Fragen zum Projekt stellen zu können. Fall das
Projekt unterstützt werden kann, soll dies durch die freiwilligen Helfer
angegeben werden und die karitative Einrichtung kann entscheiden, mit welchen
Helfern sie zusammenarbeiten will.
Sowohl die freiwilligen Helfer als auch die karitativen Einrichtungen sollen ihre
Projekte in einem eigenen Bereich verwalten können. Dabei soll es möglich sein
einen Projektstatus (z.B. läuft, Abnahmephase, Abgeschlossen) zu verwalten.
Dieser sollte von der karitativen Einrichtung verwaltet werden können.
Außerdem sollte es einen ungeschützten Bereich geben in dem neben
allgemeinen Infos über das Projekt die teilnehmenden karitativen Einrichtungen
genannt werden und Case- Studies der abgeschlossenen Projekte sichtbar sind.
Es ist angedacht, das System später um Funktionalitäten wie User- Rankings,
Project- Workspaces, Project- Management, Messaging etc. zu erweitern. In der
ersten Phase ist es jedoch zunächst wichtig sein, auch für unbedarfte Benutzer,
einfach zu bedienendes, webbasiertes System mit den entsprechenden
Prozessabläufen und Datenmodellen zu haben.
Der Kreativität bei der Implementierung von zusätzlichen Funktionalitäten ist
hier jedoch keine Grenze gesetzt.
Die besten Vorschläge für ein solches System werden von Microsoft prämiert,
und es ist geplant, diese nach einer Testphase in den Realbetrieb zu
überführen. Daher ist eine ausführliche Dokumentation des erstellten Systems
von großer Wichtigkeit.
4
2
Anforderungen
2.1 Nicht - funktionale Anforderungen
2.1.1 Technisches:
Die resultierende Software soll auf den Betriebssystemen Windows XP und
Windows Server 2003 mit .NET- Platform lauffähig sein (es genügt, Windows XP
zu testen).
Die Anwendung soll webbasiert (ASP.NET) sein und die Microsoft .NET
Technologie nutzen. Als Programmiersprache ist C#.NET zu nutzen. Die
Applikation ist als 3- Tier Architektur auszulegen. Daten müssen in einer
Datenbank vom Typ Microsoft SQL Server abgelegt werden.
Das webbasierte Frontend sollte in den Standardbrowsern (z.B. IE6.0, Mozilla,
Firefox) lauffähig sein. Zusätzlich kann auch Webservice- Funktionalität
angeboten werden. Dies ist aber nicht notwendig.
2.1.2 Ergonomie:
Die Software soll eine ergonomische Benutzerschnittstelle bieten, d. h. die
Daten sollen sinnvoll gegliedert und strukturiert dargestellt werden, die
Webseiten ihrem Zweck angepasst sein. Es ist auch darauf zu achten, dass das
System den unterschiedlichen Anforderungen der Benutzergruppen gerecht wird
und diese, durch auf ihre Bedürfnisse abgestimmte GUI- Elemente, unterstützt.
Insbesondere ist zu vermeiden, dass die Daten in unstrukturierten Tabellen
präsentiert werden, die so breit sind, dass sogar horizontale Scrollbars benötigt
werden.
2.1.3 Internationalität
Da die Anwendung in späteren Ausbaustufen potentiell auch im Ausland
eingesetzt werden wird, sollte bei der Implementierung Englisch als Sprache für
die Bezeichnungen der Klassen, Methoden, Variablen etc. verwendet werden.
Eine begleitende Dokumentation in Englisch wäre wünschenswert, ist aber nicht
Pflicht.
Gegebenenfalls ist bei der Erstellung der Datenmodelle auch auf
Mehrsprachigkeit zu achten. (z.B. Einstellen der bevorzugten Sprache,
Ländereinstellungen etc.) Dies ist jedoch ebenfalls nicht verpflichtend.
Das Frontend für die karitativen Einrichtungen und die freiwilligen Helfer soll
aber auf deutsch sein.
5
2.2 Funktionale Anforderungen
2.3 Rollen und Sicherheitskonzept
Das zu entwickelnde System unterscheidet in der ersten Phase
unterschiedliche Benutzergruppen / Rollen
• Karitative Einrichtungen (CO) (charitable organizations)
• freiwillige Helfer (VO) (volunteers)
• staatlich anerkannte Prüfstelle (GO) (governmental organization)
• Administratoren (ADM)
vier
Jede dieser Rollen hat unterschiedliche Möglichkeiten der Interaktion mit dem
System. Besonderes Augenmerk ist hierbei auf die Privacy- Aspekte zu legen.
Neben dem Schutz vor unberechtigtem Zugriff auf die Benutzerdaten von außen
ist es z.B. auch wichtig, dass der Anbahnungsprozess für ein Projekt zunächst
anonym verläuft. Damit soll u.a. vermieden werden, dass eine karitative
Einrichtung einen potentiellen Helfer „verhaften“ und ihn vorab unter Druck
setzen könnte, ein Projekt zu übernehmen.
Daher muss ein freiwilliger Helfer der Projektteilnahme zustimmen und danach
die karitative Einrichtung entscheiden, ob sie diesen Helfer annehmen will.
Bei der Entwicklung ist darauf zu achten, dass die Berechtigungen entsprechend
restriktiv gesetzt werden, falls diese nicht in diesem Pflichtenheft definiert sind.
2.3.1 Karitative Einrichtung
Die karitative Einrichtung ist die einzige Rolle, die neue Projekte anlegen kann.
Sie muss neben der Verwaltung ihrer eigenen Stammdaten in der Lage sein, die
ihr zugeordneten Projekte mit den dazugehörigen Beziehungen zu den
freiwilligen Helfern zu verwalten. Sie kann die üblichen Operationen auf die ihr
zugeordneten Daten ausführen (Set, Update, Delete etc.). Außerdem ist sie in
der Lage, ab dem Zeitpunkt der Annahme der Projektzustimmung eines
freiwilligen Helfers dessen Stammdaten lesen (aber natürlich nicht ändern) zu
können. Mit dem Projektende bleibt dieses Recht bestehen. Der freiwillige Helfer
kann dann aber die Löschung über seine Stammdaten (z.B. über einen Dialog
Projekthistorie) durchführen. Hier sollen zu einem späteren Zeitpunkt auch
gegenseitige Ratings etc. möglich werden.
2.3.2 Freiwillige Helfer
Der freiwillige Helfer (VO) ist die einzige Rolle, die der Teilnahme an einem
Projekt zustimmen kann und somit die Beziehung Projekt – Projektteilnehmer
instanziert oder erweitert, falls es mehrere Projektteilnehmer bei größeren
Projekten geben sollte. Die Beziehung ist aber erst dann gefestigt, wenn die
karitative Einrichtung den Helfer auch haben will. Der VO muss neben der
Verwaltung seiner eigenen Stammdaten in der Lage sein die ihm zugeordneten
Projekte mit den dazugehörigen Beziehungen zu den karitativen Einrichtungen
6
zu verwalten. Der VO kann die üblichen Operationen auf die eigenen
Stammdaten ausführen (Set, Update, Delete etc.). Außerdem ist der VO in der
Lage ab dem Zeitpunkt der Projektzustimmung einer CO deren Stammdaten
sowie die Projektdaten lesen (aber natürlich nicht ändern) zu können. Mit dem
Projektende bleibt dieses Recht bestehen. Eine Löschung ist nicht vorgesehen.
2.3.3 Staatlich anerkannte Prüfstelle
Die staatlich anerkannte Prüfstelle (GO) ist die einzige Rolle, die eine
Registrierung von karitativen Einrichtungen genehmigen, sowie bestehende
Konten von COs wieder inaktiv setzen kann.
Die GO erhält bei jeder neuen Registrierung eine Benachrichtigung mit der
Aufforderung, die Stammdaten der CO einzusehen und eine Prüfung
vorzunehmen. Der Zeitpunkt der Anerkennung oder Aberkennung des
karitativen Status ist in den Stammdaten der CO zu hinterlegen. Die GO soll
sonst nur lesend die Projektdatenbank einsehen können, aber keine
Änderungen machen können. Weitere Zugriffsmöglichkeiten soll die GO nicht
haben.
2.3.4 Administrator
Der Administrator (ADM) hat vollen Zugriff auf die Daten im System. Er soll alle
Daten einsehen und möglichst alle verwalten bzw. ändern können, sofern dies
sinnvoll ist.
Dafür sollen ihm die notwendigen Masken für die Verwaltung der Daten und
Beziehungen zur Verfügung stehen.
2.3.5 Benutzer in Rollen
Es ist zu beachten, dass in jeder Rolle mehrere Benutzer (=Accounts) vorhanden
sein können. Es sollte also evtl. mehrere Administrator - Accounts geben, ebenso
sollte eine CO (z.B. das Rote Kreuz) mehrere Accounts haben dürfen. Dasselbe
gilt auch für einen VO (z.B. mehrere Uni- Mitarbeiter) oder auch für die GO (etwa
mehrere Mitarbeiter im bayrischen Sozialministerium). Der häufigste Fall ist
natürlich trotzdem der Fall, in dem es nur einen Benutzer in einer Rolle gibt.
Dieser Fall sollte einfach zu bedienen sein (also nicht: Auswahl des Benutzers
aus einer einelementigen Liste).
Jede Rolle sollte einen ausgezeichneten Benutzer haben, der als
Ansprechpartner fungiert (z.B. sollte die GO den Ansprechpartner der CO
kontaktieren, um die Zulassung zu erteilen) . Bei den freiwilligen Helfern und
karitativen
Einrichtungen
sollte
auch
pro
Projekt
ein
zuständiger
Ansprechpartner vorhanden sein. Ein Benutzer sollte in der Lage sein, neue
Benutzer in derselben Rolle anzulegen, zu ändern oder zu löschen (sofern
dadurch die Rolle und die Zuständigkeit für ein Projekt nicht leer werden). Es
sollte auch möglich sein, die Zuständigkeit für ein Projekt an einen anderen
Benutzer in derselben Rolle weiterzugeben. Die Möglichkeit einer noch feineren
Granularität, etwa dass nur bestimmte Accounts einer Rolle einem Projekt
7
zugeordnet sind und es ändern dürfen, oder dass es einen CO- Admin gibt, der
solche Zugriffsrechte ändern darf, sollte angedacht werden, sie muss aber im
Rahmen des Sopra nicht realisiert werden.
2.3.6 Allgemeine Anforderungen
Eine kritische Frage für den Entwurf des IT- Charity Portals ist, welche Daten
offen oder nur Beteiligten zugänglich sind. Prinzipiell gibt es 3 Möglichkeiten:
Eine Information kann offen (ohne Anmeldung), oder nur für angemeldete
Benutzer, oder nur für die an einem Projekt Beteiligten zugänglich sein. Wie in
den folgenden Use- Cases dargestellt, sind die Beteiligten typischerweise
zunächst vorsichtig, welche Informationen zugänglich sein sollen. Andererseits
ist es sowohl für die Beteiligten als auch für den Erfolg des Portals interessant,
dass Daten z.B. über erfolgreiche Projekte offen zugänglich gemacht werden
können. Das Portal sollte also so flexibel entwickelt
werden, dass die
Zugänglichkeit mindestens der Projektdaten geändert werden kann.
2.4 Einige Use- Cases
2.4.1 Öffentliche Informationen abrufen
Ein beliebiger Nutzer möchte sich über Internet über IT- Charity informieren. Er
möchte sehen, welche karitativen Einrichtungen daran teilnehmen, wie viele
Projekte es gibt und wie viele bearbeitet werden. Außerdem möchte er sehen,
was das für Projekte sind. Hierzu möchte er Name und Beschreibung sehen. Er
soll aber nicht sehen, welche Einrichtung sich dahinter verbirgt. Dazu muss er
sich erst als VO registrieren.
Eine Historie über abgeschlossene Projekte mit Information zu den karitativen
Einrichtungen und ggf. einem passenden „Dankesschreiben“ der Einrichtung soll
er ebenso sehen können.
2.4.2 Karitative Einrichtung anmelden
Eine CO meldet sich auf der Website an und bittet um Aufnahme in das Portal.
Die GO erhält daraufhin eine Email mit einem Link, der zur Verwaltungsseite der
offenen Anfragen geht. Dort kann die GO die Daten der CO einsehen und die
Aufnahme gestatten oder (evtl. mit Angabe von Gründen) ablehnen. Die CO
erhält in beiden Fällen eine entsprechende Email. Bei Gestattung wird die
karitative Einrichtung aufgenommen und kann ab diesem Zeitpunkt Projekte
eintragen und verwalten. Hierbei muss durch Klick auf einen Link in der
Antwortmail die Validierung der Emailadresse stattfinden.
8
2.4.3 Freiwilligen Helfer registrieren
Ein VO registriert sich über ein Formular. Durch Klick auf einen Link in der
automatischen Antwortmail findet die Validierung der Emailadresse statt. Ab
diesem Zeitpunkt kann der VO Projekte und die Informationen über die
dahinterstehenden COs einsehen.
2.4.4 Projekt eintragen und verwalten
Eine validierte CO kann nun neue Projekte anlegen und die Daten verwalten
oder ggf. Löschen. Bei der Verwaltung von Projekten kann die CO auch
Hilfsangebote von VOs ohne Begründung annehmen oder mit Begründung
ablehnen. Die CO kann zu jedem Zeitpunkt bereits angenommene VOs aus
einem Projekt löschen bzw. ablehnen.
2.4.5 Projekt suchen und auswählen
Ein VO kann über eine Suchfunktion die Projektbeschreibungen nach
bestimmten Schlüsselwörtern durchsuchen. Alternativ kann der VO auch über
eine Liste der CO alle Projekte einer bestimmten CO anzeigen lassen.
Die Kontaktdaten des Ansprechpartners der CO werden hierbei aber nicht
weitergegeben. Lediglich Projektinformationen und der Name der CO sind zu
diesem Zeitpunkt einsehbar.
Sollte der VO ein interessantes Projekt gefunden haben, muss er anonym eine
Frage zu dem Projekt stellen können, dessen Antwort ihm zugeht. Außerdem
muss er die Möglichkeit haben, ein Projekt anzunehmen. Bevor er jedoch zum
Mitglied des Projektes wird, muss die CO zustimmen.
2.4.6 Projektzustimmung
Sollte ein VO ein Projekt angenommen haben, so erhält der Kontakt der CO eine
Email mit einem entsprechenden Link zur Projektverwaltungsseite. Dort kann
der CO- Kontakt dann die Daten der VO- Annahmen einsehen und bestätigen
bzw. ablehnen.
Dort wird jedoch lediglich der Vor- und Nachname sowie die Expertise des VOs
angezeigt, aber noch keine weiteren Kontaktdaten.
Ab dem Zeitpunkt der Annahme erhalten beide Parteien die kompletten
Kontaktdaten der jeweils anderen Partei zur Abstimmung und Durchführung des
Projektes.
2.4.7 Projekt /Stammdatenverwaltung
Alle Benutzer des Portals sollen ihre eigenen Daten sowie ihre
Projektbeziehungen Rollenspezifisch einsehen und verwalten können. So soll ein
VO z.B. sehen können, welche Projekte er schon durchgeführt hat und welche
gerade laufen, incl. Der zugehörigen CO und den Kontaktdaten. Eine CO aber
muss z.B. Ihre eigenen Projekte verwalten können, z.B. wenn Änderungen in den
Beschreibungen notwendig sind.
9
2.4.8 Löschung eine CO
Sollte aus einem wichtigen Grund eine CO durch eine GO aus dem System
entfernt werden, so müssen alle Beteiligten aus bestehenden und vergangenen
Projektbeziehungen via Email über die Löschung sowie den Grund der Löschung
informiert werden.
2.5 Datenhaltung
Die Erstellung eines Objektmodells ist Teil der Aufgabenstellung. Im Folgenden
werden einige Hinweise auf Daten gegeben, die vorhanden sein sollten.
2.5.1 Karitative Einrichtung (CO)
Für karitative Einrichtungen sollte mindestens gespeichert werden: vollständige
Adresse der CO, ein Link auf die Satzung der CO, ein Link zur Webseite der CO,
sowie der zentrale Ansprechpartner. Zur Verwaltung ausserdem das
Anmeldedatum, sowie wann
und durch wen (bei der GO) der Zugang genehmigt wurde. Dazu optional ein
Logo der CO, die Tel. und Fax. Nummer einer Telefonzentrale.
2.5.2 Freiwilliger Helfer (VO)
Da ein VO sowohl eine Einzelperson als auch eine Organisation (Uni, Firma etc.)
sein kann, ist hier nur der Hauptansprechpartner Pflicht, sowie zur Verwaltung
wieder das Datum der Anmeldung. Daten einer Zentrale (Adresse, Tel. + Fax
einer
Zentrale, Firmen- oder Uni- Adresse, Logo) sind optional.
2.5.3 Staatlich anerkannte Einrichtung (GO)
Die Daten einer GO sind analog zu denen einer CO (ausser der Genehmigung
durch
GO).
2.5.4 Benutzer
Für einen Benutzer sollten Adresse (Default: Adresse der Rolle), Passwort und
Mail- Adresse vorhanden sein. Dazu kommen
Tel. Nr. und Fax- Nr (beide
optional), Web- Seite (optional, wenn seine Rolle eine Seite hat, sonst Pflicht),
sowie ein optionales Bild.
10
2.5.5 Projekt
Für ein Projekt sollte ein Name, ein Erzeugungsdatum, eine HTML- Beschreibung
und einen optionalen Link zu weiterführender Information enthalten sein. Zur
Verwaltung sollten das Erstellungsdatum, sowie Links zu am Projekt beteiligten
VOs vorhanden sein, die je ein Datum der Zustimmung durch VO und CO
enthalten. Ausserdem sollte eine Liste von Fragen und Antworten verwaltet
werden (s. Use Cases, Punkt 2.4.5).
3 Klarstellungen aus dem Kundengespräch (und sonst
gestellten Fragen)
1. Es gibt verschiedene CO’s (Rotes Kreuz, Caritas, etc), verschiedene VOL’s
(verschiedene Firmen, Sopra- Gruppen oder auch Einzelpersonen),
verschiedene GOV’s (bayrisches Sozialministerium, badenwürttembergisches etc.) und Microsoft als Organisation der Administratoren.
Jede dieser Organisationen kann verschiedene Accounts für ihre Mitarbeiter
haben. Im Spezialfall einer Einzelperson als VOL ist die Zahl der Accounts
einfach 1 (und der Fall 1 ist auch sonst häufig). In jedem Fall sollte es pro
CO, VOL, GOV, und bei Microsoft einen Account als Ansprechperson geben,
der bei Fragen oder Problemen z.B. vom Admin (oder umgekehtrt als „der“
Admin) angesprochen werden kann (im Fall nur eines Accounts gibt es also
natürlich keine echte Wahl, wer diese Person ist). Ein Mitarbeiter einer
Organisation (z.B. rotes Kreuz) kann neue Mitarbeiter bei derselben
Organisation eintragen oder löschen.
2. Für die WWW-Seiten sollten style sheets verwendet werden
3. Es soll mehrere GOV’s geben. Welche GOV’s welche CO’s genehmigen, kann
offen bleiben. Eine mögliche spätere Lösung wäre, dass die Zuständigkeit
nach Postleitzahl in der Adresse geregelt wird (das bayrische
Sozialministerium ist für bayrische karitative Organisationen zuständig etc.)
4. Die GOV muss neben den Daten der CO auch die Daten des
Ansprechpartners der CO bekommen, sonst könnte sie ja gar nicht prüfen,
ob sich nicht jemand einfach für das Rote Kreuz registriert hat.
5. Die Kommunikation vor Zustandekommen eines Projekts soll anonym sein,
d.h. persönliche Daten von Mitarbeitern der CO / VOL sollen zu diesem
Zeitpunkt geheim sein. Die allgemeinen Daten von CO / VOL dürfen
einsehbar sein.
6. GOV’s können CO’s die Zulassung auch wieder entziehen
7. Das inaktiv setzen von Daten, die evtl. wieder aktiviert werden können, ist
der endgültigen Löschung meist vorzuziehen
8. Wenn die Stammdaten einer CO gelöscht werden, muss natürlich auch deren
Assoziation zu einem Projekt beseitigt werden
9. Die Möglichkeit, sich für ein Projekt anzumelden, soll mit dem Beginn des
Projekts (der also durch einen entsprechenden Status repräsentiert werden
muss) enden.
11
10. Die Projektleiterrolle kann an einen anderen Mitarbeiter derselben CO oder
auch an einen Volunteer übergeben werden.
11. Benötigt wird ein Profil von VOL’s (hat Fähigkeiten x,y,z; ein sinnvoller
Katalog kann vom System vorgegeben werden) und auch von Projekten zum
Suchen (die in 2.4.5 angesprochene Suchfunktion kann z.B. davon
profitieren).
12. Der Administrator hat vollen Zugriff auf die DB, die Aussage, dass er nicht
beliebig Daten ändern darf, bezieht sich darauf, dass dafür kein Interface zu
erstellen ist.
13. Das Datenvolumen der einzelnen VO’s, CO’s kann auf 100MB beschränkt
werden, um Missbrauch zu verhindern
14. Es ist sinnvoll Benutzer eindeutig zu machen, und den Benutzern Nicknames
zu geben, mit denen sie sich einloggen können. Die email eines Benutzers
sollte änderbar sein, ohne dass sich die Identität ändert (Hinweis: es war von
Benutzer - IDs die Rede. Beachten Sie, dass Objekte immer bereits eine
eindeutige Identität haben!).
12