Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
W
web3dscans1
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 17
    • Issues 17
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • Web3DScans
  • web3dscans1
  • Wiki
  • User Stories

Last edited by Sophia Apr 30, 2022
Page history

User Stories

Anhang (Überarbeitete User-Storys vom 25.11.2021)

  • Im Rahmen der Anforderungsanalyse wurden ausgehend von den Vorgesprächen mit R. Lehné (HLNUG) und D. Heß (TU Darmstadt) seitens der Studierenden mehrere User-Storys formuliert. Unterschieden wurden dabei mehrere Nutzerrollen (s. u.). Der besseren Übersicht halber wurden die User-Storys in neun Gruppen eingeteilt.

Rollen (Übersicht)

  • Unterschieden werden aktuell folgende Nutzerrollen:
    • Nutzer (als übergeordnete "Super-Rolle" für die nachfolgenden speziellen Rollen)
    • Administrator
    • Archivar
    • Geologe
    • Geologie-Student
    • Schüler/Laie
    • ( Lehrer )
    • ( Ingenieurbüro )

Gesprächsergebnis:

  • Die Rollen Lehrer und Ingenieurbüro sind im gegenwärtigen Projektstadium zunächst von untergeordneter Bedeutung. (Sie können jedoch zukünftig wieder aufgegriffen werden.)
  • Bem.: Für eine erste genauere Beschreibung der Rollen siehe Protokoll Nr. 6 des Projektgruppentreffens vom 15.11.2021: projektinterner Link

1. Interaktive 3D-Ansichten für Betrachtungsobjekte

Story 1 (3D-Ansicht):

  • Als Nutzer möchte ich das Abbild eines Betrachtungsobjekts (3D-Scan, z. B. eines Handstücks, Bohrkerns oder Aufschlusses) von allen Seiten und in allen Zoomstufen betrachten können, um eine genauere Vorstellung von dem Betrachtungsobjekt zu bekommen und auch um kleinere Strukturen erkennen und untersuchen zu können. Dabei sind besondere Ansprüche an Modell- und Darstellungsqualität zu stellen. Die Dateien, in denen die Abbilder der Betrachtungsobjekte (3D-Scans) abgelegt sind, können dabei bzgl. ihres Datenumfangs sehr groß werden.

Gesprächsergebnis:

  • Der ursprünglich in der Story verwendete Begriff 3D-Scan wurde weitgehend ersetzt durch den Begriff Betrachtungsobjekt.
  • Prinzipiell liefert ein 3D-Scan ein (digitales) Abbild eines (physikalisch vorhandenen) Betrachtungsobjekts.
  • Bem.: Bei den Handstücken kann es sich um Steine, Fossile, Knochen etc. handeln.

2. Ergänzende Information zu Betrachtungsobjekten

  • Als Nutzer möchte ich zu einem Betrachtungsobjekt weitere Information erhalten (z. B. Fundort, Größenangaben, Gesteinsart, Besonderheiten, ...), um diese in Beurteilungen und Überlegungen mit einbeziehen zu können. Diese kann z. B. in Form ...

Story 2a (Steckbriefe):

  • ... textueller Information (als "Steckbrief" = "Überschriften + textuelle Inhalte") vorhanden sein, um allgemeine Information zu einem 3D-Scan zu erhalten.

Story 2b (Maßstabsleiste):

  • ... einer Maßstabsleiste (zur Veranschaulichung von Größenverhältnissen) vorhanden sein.

Story 2c (Kartendarstellung):

  • ... einer Kartendarstellung (für den Fundort) vorhanden sein.

Story 2d (Hyperlinks):

  • ... von Hyperlinks zu mit dem 3D-Scan in irgendeiner Form verknüpften Dokumenten (z. B. zugehörige Fachartikel, weitere am gleichen Ort verfügbare Bohrkerne, etc.) vorhanden sein.

Gesprächsergebnis:

  • Bei den Storys 2a bis 2d geht es prinzipiell um eine "Anreicherung" eines eigentlichen 3D-Scans.
  • Die Reihenfolge der Storys wurde gegenüber der ursprünglichen Fassung vertauscht, so dass sie nun gemäß ihrer Relevanz aufgelistet sind (höchste Priorität hat 2a, die niedrigste die Story 2d).
  • Bem.: Story 2d ist noch vage formuliert. Zukünftig lassen sich darüber hinaus evtl. weitere Storys 2e, 2f, ... entwickeln.
  • Hinweis für die Bochumer Projektgruppe: Im Protokoll Nr. 7 des Treffens vom 22.11.2021 sind insofern 2b und 2c zu tauschen: projektinterner Link

3. Teilen von Daten

Story 3a (Steckbrief-Download):

  • Als Nutzer möchte ich Zusatzinformationen als eine Art Steckbrief auf den lokalen Arbeitsrechner herunterladen. (Der Steckbrief ist somit auch dann verfügbar, wenn kein Internet verfügbar ist.) ...

Story 3b (Steckbrief-Ausdruck):

  • Der Steckbrief lässt sich formatiert ausdrucken (z. B. als PDF).

Story 3c (Permalinks für Steckbriefe):

  • Der Steckbrief ist mit einem Permalink versehen, so dass der 3D-Scan/Datensatz wissenschaftlich referenzierbar ist.

Gesprächsergebnis:

  • Die beiden Storys werden als wichtig erachtet. Anzumerken ist zunächst, dass es der Funktionalitäten 1. und 2. (s. o.) bedarf, um zu 3. zu gelangen. Bei den Storys 3a und 3c geht es letztlich um die Langzeitarchivierung von (mitunter aufwändig erlangtem) Wissen!
  • Hingewiesen wurde in diesem Zusammenhang nochmals auf den Urheberaspekt: Bereitsteller der Daten und Dateneigentümer ist das HLNUG. Das HLNUG beabsichtigt hierbei, seine Inhalte öffentlich zu teilen. Die bereitgestellten Inhalte sind mit dem Haus "HLNUG" in Verbindung zu bringen.
  • Bem.: Aus den ursprüngl. zwei Storys wurden nunmehr drei gemacht (alt 3a wird neu 3b, alt 3b wird neu 3c, neu 3a wurde explizit nummeriert).

4. Datenzugang

Story 4a (Suche nach Schlagworten):

  • Als Nutzer möchte ich durch Eingabe von Suchbegriffen ("Tags") nach Betrachtungsobjekten suchen können.
    • -> Hier geht es um die "Tag-Nutzung".

Story 4b (Verschlagwortung):

  • Als Archivar (oder auch als Geologe?) möchte ich 3D-Scans durch Eingabe von "Tags" verschlagworten, so dass das System später danach durchsucht werden kann.
    • -> Hier geht es um die "Tag-Bereitstellung".

Story 4c (räumlich-thematische Suchen):

  • Als Nutzer möchte ich räumlich-thematische Suchen nach Daten durchführen können. Die Raumangabe kann in Form von Geokoordinaten ("BBOX") oder durch Ortsbezeichnungen ("Gazetteer") erfolgen.

Story 4d (differenzierte Suche nach Betrachtungsobjekten):

  • Als Archivar, Geologe, Ingenieurbüro, ... möchte ich spezielle Suchfunktionen nutzen können, um Datensätze zu finden, die zur Bearbeitung Rollen-spezifischer Aufgabenstellungen benötigt werden (z. B. veraltete Datensätze finden, für die Anfertigung eines Gutachtes benötigte Daten suchen, ...).

Gesprächsergebnis:

  • Die durch diese Storys angesprochenen Aspekte betreffen einen recht breites Thema ("ein dickes Brett"). Insofern wären die Storys dieser Gruppe sicherlich noch weiter zu verfeinern. Jedoch zeigen sie in eine sehr interessante Entwicklungsrichtung!
    • Keywords: Metadatenmodelle, Maschinenlesbarkeit, ...
  • Bem.: In der ursprüngl. Fassung der Storys ist vermerkt, dass u. U. Zielgruppen-spezifische Tags sinnvoll sind (z. B. erwarten Laien möglicherweise andere Tags als der Geologe). Weiterhin wurde ursprüngl. zu 4a ein Szenario beschrieben, in dem ein Lehrer das System durchsucht, um für verschiedene Lehreinheiten geeignete Objekte zu finden. Diese Aspekte werden zunächst nicht weiterverfolgt und würden zum gegenwärtigen Zeitpunkt den Projektrahmen sprengen (stattdessen Konzentration auf wesentlichere Systemaspekte).
  • Eine Anfrage an das System könnte z. B. wie folgt lauten: "Ich suche ein Handstück, das das Tertiär beschreibt im Landkreis X."
  • Auch die (noch unscharf formulierte) Story 4d wirkt zunächst recht speziell. Allerdings lässt sie sich perspektivisch weiter in die Richtung "Datenqualität" entwickeln. So könnte z. B. eine weitere interessante Anfrage an das System lauten: "Wo finde ich eine gute Buntsandsteinprobe bzw. Referenzscans, Referenzbohrungen, ...?" Deutlich wird in der Diskussion zunächst: Neben Schlagworten ("Tags") ist auch Metainformation zu den Betrachtungsobjekten mitzuführen (vgl. Punkt 2.!), z. B. Datum der Entstehung des Betrachtungsobjekts und des 3D-Scans (Abbilds), Technik zur Gewinnung des Betrachtungsobjekts, Aufnahmetechnik sowie insb. besondere Qualitätsmerkmale! Resümee: Im Weiteren könnte es sich lohnen, mittelfristig den Qualitätsaspekt weiter in die Entwicklungsaktivitäten hineinzubringen!
    • Keywords: Qualitätsmerkmale von Betrachtungsobjekten, Datenqualität
  • Also: Die durch diese Story-Gruppe angesprochenen Aspekte sollten erstmal mit untergeordneter Priorität weiterverfolgt werden, jedoch auf Grund der hohen Anwendungsrelevanz während der weiteren Entwicklungsaktivitäten nicht außer Acht gelassen werden.

5. Karten-Komponente

Story 5a (Übersichtskarte):

  • Als Nutzer möchte ich eine Übersichtskarte mit den Orten, für die Betrachtungsobjekte vorliegen, angezeigt bekommen.

Story 5b (Feature-Info):

  • Als Nutzer möchte ich in der Kartendarstellung auf ein Punktsymbol klicken können, um die interaktive 3D-Ansicht des zugehörigen Betrachtungsobjektes zu öffnen.
    • Anmerkung seitens der Projektgruppe der Hochschule Bochum: Hier lassen sich alternative technische Ansätze zur technischen Umsetzung diskutieren, z. B. Umsetzung basierend auf einer einfachen JSON-Datei, Nutzung eines OGC-WMS mit FeatureInfo, Nutzung eines OGC-WFS, "Clustering", ...

Gesprächsergebnis:

  • Diese Storys werden weiter betrachtet.

6. Systemadministration

Story 6a (Datenbereitstellung):

  • Als Archivar möchte ich einen 3D-Scan mit zugehörigen Steckbrief (und evtl. mehr???) in das System einstellen können.

Story 6b (Datenmanagement):

  • Als Archivar möchte ich einen Überblick über alle hochgeladenen Dateninhalte erhalten und Möglichkeiten haben, Daten zu aktualisieren.
    • Bem.: Diese Story wäre u. U. zu konkretisieren.

Gesprächsergebnis:

  • entfällt, da diese Storys nicht weiter diskutiert wurden. Der Vollständigkeit halber dürfen sie allerdings nicht fehlen.

7. Rollenkonzept

Story 7:

  • Als Administrator möchte ich innerhalb des Systems verschiedene Rollen zur Datenpflege und Nutzung der Daten vergeben können, um den Rollen verschiedene Funktionen entsprechend ihrem Anwendungsbereich zuweisen zu können.

Gesprächsergebnis:

  • entfällt, da die Storys nicht weiter diskutiert wurde. Der Vollständigkeit halber darf allerdings auch diese Story nicht fehlen.

8. Zusatzmaterialien

Story 8a:

  • Als Laie möchte ich begleitende Hinweise und erläuternde Zusatzmaterialien bereitgestellt bekommen, um die Betrachtungsobjekte bzw. die zugehörigen 3D-Scans besser "lesen" und verstehen zu können und zusätzliches Fachwissen zu erlangen.
    • Bem.: Diese Story wäre zu präzisieren; hier aber erstmal nicht Fokus.

Story 8b:

  • Als Laie möchte ich ein Glossar aufrufen können, um wesentliche und grundlegende Fachbegriffe nachschauen zu können.

Gesprächsergebnis:

  • Die Storys wird während der weiteren Entwicklungsaktivitäten nicht weiterverfolgt. Der Vollständigkeit halber darf aber auch sie nicht fehlen. Angemerkt sei, dass in diesem Bereich auch andere Akteure "unterwegs" sind, z. B. das BGR (?).

9. Citizen-Science-Idee

Story 9:

  • Als Geologe möchte ich zu den 3D-Scans interessante Aspekte kommentieren können, z. B. in Form von textlichen Anmerkungen, grafischen Annotationen zu interessanten Stellen innerhalb der 3D-Scans o. ä. Weiterhin möchte ich ergänzte Kommentare mit anderen Geologen diskutieren können (z. B. unterstützt durch eine Chat-Funktion o. ä.).

Gesprächsergebnis:

  • Hier geht es darum, Systemnutzer die Interaktion mit anderen Nutzern mit fachlicher Expertise zu ermöglichen und Kommunikationskanäle zu schaffen! Das ist eine interessante zukünftige Perspektive. Aktuell würde es aber den Projektrahmen deutlich sprengen, so dass diese (festhaltenswerte!) Story nicht weiterverfolgt wird.

Nicht-funktionale Anforderung/Randbedingungen:

Datenhoheit

  • Das HLNUG möchte die Datenhoheit über die Daten behalten, um zu wissen, dass die Daten auf einem Server bleiben und nicht in der Welt verteilt werden.

UX

  • Das System sollte ein gutes Nutzererlebnis ermöglichen (UX-Aspekt; Nutzerakzeptanz).

Responsive Design

  • Die Anwendung sollte möglichst unabhängig vom konkreten Endgerät lauffähig sein, um eine breite Anwendungsakzeptanz zu schaffen.

Gesprächsergebnis:

Die beiden Randbedingungen "Datenhoheit" und "UX" wurden bestätigt. Ergänzt wurde nach dem heutigen Gespräch der Punkt "Responsive Design".

(Zurück zum Inhalt des Endberichts)

Clone repository
  • 3.3 3D Viewer
  • 3D Darstellungsparameter
  • 3D Formate
  • 3D Viewer Komponente
  • 3D Viewer
  • Anzeigefenster
  • Arbeitsumgebung
  • Aufgabenbeschreibung
  • BOM
  • Bohrprofil Anzeige
  • CrossReferencer
  • Desktop und mobile Version
  • Endbericht
  • Generierung der 3D Modelle
  • Geodatengrundlage beim HLNUG
View All Pages