doku/präsentationsSkript

Short demonstration of HeRA

This presentation script gives is the foundation for the demontration video.

Step 0: Preparation

  1. Open HeRA (Research Demo Configuration)
  2. Switch to UML (Simple) view
  3. Start video / presentation

Step 1: Create first UseCase

  1. Open new UseCase (via ContextMenu? or ProjectMenu?)
  2. Point out two errors
  3. Type in new title document functional requirements in use cases
  4. Show that error disappears
  5. Show that UML-view shows title - now we want to see the actor in UML view
  6. Go to main actor field
  7. Show that hint for this field is displayed
  8. Type in Analyst
  9. now to the main scenario. Resize window if needed
  10. add step to main success scenario
  11. type in
    1. "analyst adds new use case"
  12. show warning scenario is very short
  13. add two more steps to main success scenario
    1. "system analyses input"
    2. "system gives feedback"

Step 2: Short description critique

Pre: Open UseCase from step 1.

  1. Give this use case ID 1 - just in case.
  2. Add description "writing use cases"
  3. Show warning short description ProblemView? and CriticView?
  4. Show details of warning, comment "Switch content" - learn from others comments
  5. Cut description - Paste to title
  6. Cut old title - Paste to description
  7. Show that warning disappeared
  8. Improve title: writeing use cases --> write use case

Step 3: Add second UseCase

We need a second use case to show other features of HeRA.

Pre: Use Case from step 1 opened.

  1. Go to the third step system gives feedback
  2. Press the chain symbol to link this step to another use case
  3. show the options Create new Use Case and 1. write use case
  4. choose Create new Use Case and press OK
  5. show that the step is underlined and linked to the new use case.
  6. show the error in the problem view
  7. show the new use case in the UML Overview.
  8. do a double click on the new use case to switch content of the use case editor
  9. change title from gives feedback to give feedback and show that system is already set. (check, if actor is set in UML Diagram #154. Otherwise, set focus on main actor field and leave it again)
  10. show that the text in the use case link has been changed (and can be changed here again)

Step 4: Introducing - The Glossary

Pre: Use case project from previous steps opened, UML Overview is visible in the simulation view, use case 1 is visible

  1. switch simulation view to Glossary and explain list
  2. swith to use case 2 and show that glossary proposals differ
  3. explain numbers (same in both use cases - this is the total number of occurances in whole project)
  4. explain differences (only terms used in current use case)
  5. add Feedback to glossary and explain what happened
  6. click on use case folder in project tree and show total list (show all in the glossary view)
  7. add use and explain problem with words composed of several words.
  8. edit glossary term use to use case and show that case is no longer in the proposal list.
  9. show that glossary terms are highlighted
  10. add and ignore some more terms.
  11. show glossary term statistics and search function

Step 5: Deriving the implied business process

Pre: Use case project from previous steps opened

  1. switch to the Business Process' view in the SimulationView?.
  2. minimize the critique view to gain more space.
  3. focus on the first use case and generate long version of use case.
  4. generate project epc
  5. in the first use case specify
    • precondition = "Project has started",
    • success guarantee = "use case exists"
    • trigger = "stakeholder wishes exist".
  6. in the second use case set
    • precondition = "use case changed",
    • success guarantee = "feedback given",
    • trigger = "use case changed".
  7. re-generate epc and show that use cases are independent
  8. change success guarantee of use case 1 by adding a new line with "use case changed"
  9. re-generate epc
  10. add more links when needed ("project started" to precondition of use case 2).

Step 6: Effort Estimation

Pre: Use case project from previous steps opened

  1. switch to effort estimation view in SimulationView?
  2. show TCF and tool-tips, change things
  3. show ECF, change things
  4. change level of use cases to Function and explain why only functions are considered here.
  5. show, how the numbers change
  6. show overview and explain, why use case 3 cannot be seen (no steps in that use case).
  7. add a step to use case 2 and show the changed numbers
  8. add a step to use case 1 and show the changed numbers
  9. change one of the actors in use case 1 and show, how this changes effort.

Step 7: Change/add Heuristic Feedback

Pre: Use case project from previous steps opened

  1. add third use case
    • ID = 3
    • Title = "publish use case over internet"
    • Description = "user logs in with password and user name"
  2. open experience base editor
  3. explain gui
  4. choose experience "use cases should not specify GUI elements"
  5. duplicate
  6. change new title to "possible security relevant requirement found"
  7. change decription to "please refine.".
  8. change parameter to "internet" and show the immediate reaction of HeRA (warning and tooltip)
  9. add a comment in the CriticView? like "...but how", "Please give some idea, how to refine security requirements."
  10. show and explain the ignore dialog

Kurzvorstellung HERA

Diese Seite enthält ein kurzes Skript.

Allgemein

Idee / Witz

Während man an einem Use Case schreibt, überprüft HERA die Eingabe und macht gegebenenfalls Verbesserungsvorschläge.

Installation

  • Runterladen
  • 1-2 Erweiterungen installieren, Erweiterungskonzept motivieren
    • Kritik
    • UML

Arbeiten mit HERA

  • Use-Case anlegen
  • Kritiken demonstrieren
    • Motivation: Fehler früh erkennen, Nachbesserung vermeiden (Siehe: literatur:merep2007)
    • Motivation: Überblick waren, Schwachstellen entdecken
    • Beispiel: Passiv, GUI, ungefähr, Use Case mit falscher Abstraktion

Architektur, Aufbau der SW

  • Kernprogramm und Erweiterungen So ist es einfacher, Studentische Arbeiten unabhängig von einander durchzuführen.
  • Use Cases haben keine statische Datenstruktur Dadurch ergeben sich einige Schwierigkeiten, aber Benutzer können neue Attribute hinzufügen.

Kritiksystem

Wegen literatur:kitzmann2007 aus der Hauptkomponente ausgelagert.

Idee / Witz

Enthält alles, was HERA braucht, um die Benutzereingabe kritisieren zu können.

Außerdem erlaubt es dem Benutzer, neue Kritiken anzulegen, bzw. bestehende anzupassen.

Installation

  • Kritiksystem herunterladen.
  • Im HERA Programmverzeichnis entpacken.
  • HERA (neu) starten.

Arbeiten mit Kritiken

  • Kritiken ignorieren
  • ignorierte Kritiken wieder anzeigen
  • eigene Kritik erstellen (Wizard!)

Architektur, Aufbau der SW

Kritiken haben bestehen aus:

  • Teaser
  • Kategorie (aus Info, Warnung, Fehler)
  • längere Erläuterung
  • gegebenfalls Javascript, dass auf Änderungen an HERAs Java-Objekten reagieren kann.

Glossar

Idee / Witz

  • Erstellung und Verwaltung eines Glossar während der Erhebung von Anforderungen.
  • Die Vorschläge zur Aufnahme in ein Glossar werden mit einfachen Methoden erstellt. Es wurde bewusst auf komplexe Techniken wie Korpuslinguistik, Ontologien, ... verzichtet

Installation

  • Glossar-Plugin herunterladen
  • Im HERA Programmverzeichnis entpacken
  • HERA (neu) starten

Arbeiten mit einem Glossar

  • Einen Begriff mittels Kontextmenü im Projektbaum neu aufnehmen
  • Einen Begriff mittels Klick in die Vorschlagsliste aufnehmen
  • Einen Begriff aus einem Use Case mittels Rechtsklick aufnehmen
  • Einen aufgenommenen Begriff im Text verwenden: Der Begriff wird unterkringelt
  • Einen unterkringelten Begriff rechtsanklicken um so zum entsprechenden Glossareintrag zu gelangen.
  • Einen Begriff aus der Vorschlagsliste ignorieren.
  • Den Filter ignore ausschalten

Architektur, Aufbau der SW

  • Das Plugin besteht aus zwei unterschiedlichen Teilen. Einer enthält den Kern um ein Glossar zu erstellen und zu verwalten. Der andere Teil dient zu r Einbindung in HERA.
  • Zur Grundformenbildung werden die OpenOffice-Wörterbücher benutzt.

Domain Model-Erweiterung

Idee / Witz

  • Erstellung und Verwaltung Domain Models zur Unterstützung des Anforderungsprozesses.
  • Domain Models werden mit Hilfe der Notation von UML-Klassendiagrammen dargestellt.
  • Durch die Integration des Kritiksystems lassen sich sowohl das Domain Model an sich prüfen, als auch die Konsistenz zum Use Case sicherstellen.

Installation

  • Domain-Model-Plugin herunterladen
  • Im HERA Programmverzeichnis entpacken
  • HERA (neu) starten

Arbeiten mit dem Editor

  • Domain Model zum Projekt hinzufügen
  • Zwei Entitäten hinzufügen
  • Ein Kommentarfeld hinzufügen
  • Referenzen zwischen den Entitäten und dem Kommentarfeld einfügen
  • Referenzen anpassen

Architektur, Aufbau der SW

  • Das Plugin besteht aus einem Teil, greift dabei aber sowohl auf das Kritiksystem von HeRA, als auch auf die Glossarerweiterung zu. Beide sind aber nicht zwingend notwendig, sondern erweitern lediglich den Funktionsumfang.
  • Bei der grafischen Darstellung der Elemnente im Editor wird auf JGraph zurückgegriffen.

Handbuch

Weitere Erweiterungen

Idee / Witz

  • Use Case Points - Feedback zum Projektumfang. Geeignet, um ausführlichkeit der Dokumentation zu vereinheitlichen.
  • Requirements - Gut zum Testen, da es einen Import für Doors-XML-Exports gibt. Damit bekommt man viele Daten in Hera.
  • UML 2.0 - Funktioniert noch nicht recht. Soll aber das Editieren der Use-Case-Diagramme erlauben.

Installation

Arbeiten mit den Erweiterungen

Architektur, Aufbau der SW