Skip to content

[Epic] Absenderinformationen [RICE 36,5]

Pitch

Outcome:

Auf welches strategische Ziel zahlt das Feature ein? Was ändert sich, wenn das Feature verfügbar ist?

  • Weiterentwicklung: Transparenz für Sender und Empfänger

Zielgruppe:

Wer profitiert von diesem Feature?

  • Verwaltungssysteme wissen genauer, wer Ihnen eine Submission gesendet hat und können damit die Vertrauenswürdigkeit beurteilen.

Opportunity:

Welches Problem lösen wir bei unserer Zielgruppe?

  • Die ClientID des Senders einer Submission hat keinen Informationsgehalt.
  • Die optionalen Daten über den Absender in den Metadaten unter author sind eine reine Selbstauskunft.
  • Der Empfänger hat also keine verlässlichen Informationen über den Sender

Kurzbeschreibung:

Was ist sonst noch wichtig zu wissen?

  • Im SSP wird zu jedem Onlinedienst (Sender-Client) in einem Textfeld eine als öffentlich markierte Information zum sendenden System eingetragen: "Bezeichnung Absender"
  • Daneben wird der Organisationsname aus der Elster-Anmeldung angezeigt und darüber informiert, dass diese zusammen mit der Bezeichnung des Absenders dem Empfänger jeder Submission bekannt gemacht wird.
  • Der Empfänger einer Submission kann über die Submission-API diese Informationen abrufen.
  • Ggf. kann diese Information auch bei der eIntragung des Sender-Clients in die Liste der erlaubten Sender zu einem Zustellpunkt angezeigt werden.
  • Der Empfänger verfügt damit über folgende Information: Ein Vertreter der Organisation "XY" (verlässlich, da aus der Elster-Anmeldung) hat zum dieser Submission die Angabe gemacht, dass sie von "ABC" versendet wurde.

Entscheidungen:

Gibt es Entscheidungen, die jetzt schon getroffen werden sollten? Sind Beschaffungen notwendig?

  • Wer darf diese Information einsehen? Nur der Empfänger eine Submission oder ale Accounts im SSP (für die Absenderbeschränkung) -> Der Empfänger einer Submission in jedem Fall, andere Nutzer im SSP z.B. für die Konfiguration der Absenderbeschränkung nicht per Suche, sondern so wie bisher durch die Übergabe der SenderClientID.
  • Muss noch etwas bzgl. Datenschutz / Nutzungsbedingungen bedacht werden? Informationen über eine Organisation wären nicht personenbezogen.

(Externe) Deadline:

Gibt es externe Deadlines die berücksichtigt werden müssen?

Prioritätsbewertung:

Wie gewichten wir die RICE Faktoren auf einer Skala von 1 bis 10?

  • Reach: 5,1
  • Impact: 5,1
  • Effort: 5,1
  • Confidence: 7,2
  • RICE-Gesamtscore: 36,5

Vorbereitung Epic Refinement

  • Wer kümmert sich darum, dass ein Epic "refinement ready" gemacht wird?
  • Welche Teams werden perspektivisch am Feature arbeiten? Welche Devs aus den Teams sollten jetzt schon eingebunden werden?
  • Bei welchem Epic Refinement kann dieses Feature voraussichtlich besprochen werden?

Persona

Name und Rolle:

User Story:

Jobs

Pains

Gains

Epic Ausarbeitung

User Story

Warum

Wenn ein Endpunkt über die API abgefragt wird, sollte dieser den Namen der Behörde und weitere Metadaten zurückliefen, um in einer Konfigurationsoberfläche angezeigt zu werden. Dies würde Vertrauen schaffen, dass Informationen an den richtigen Empfänger gesendet werden.

--> Prozessunterstützung bring Absender-Destinations. Ggf. könnte man Daten aus dem Elster-Zertifikat liefern.

Links, Hinweise, Bemerkungen

  • Attribut zu Sender-Client / Zustellpunkt (selbstgepflegt)
  • Verlässlichkeit kann durch Kombi mit Owner-Organisation aus dem Elster-Zertifikat beurteilt werden.
  • Datenschutz? Wer darf die Info abrufen?

Stories

Akzeptanzkriterien

  1. ...
  2. ...
  3. ...

Mögliche Folgeaktivitäten (vom Entwickler zu ergänzen)

Edited by Andreas Aschauer