Das Buch beschreibt eine Methode zum Schreiben eines Teils einer Problemstellung, nämlich die Use-Case-Methode.
Was ist das? Dies ist eine Beschreibung des Benutzerinteraktionsszenarios mit dem System (oder mit dem Unternehmen). In diesem Fall fungiert das System als Blackbox (und dies ermöglicht die Aufteilung der komplexen Entwurfsaufgabe in die Gestaltung der Interaktion und die Sicherstellung dieser Interaktion). Gleichzeitig werden Notationsstandards eingeführt, die eine einfache Lesbarkeit auch für Nichtteilnehmer gewährleisten und einige Überprüfungen auf Vollständigkeit und Übereinstimmung mit den Zielen des Stakeholders ermöglichen.
Anwendungsbeispiel
So sieht das Szenario am Beispiel der Autorisierung auf der Website per E-Mail aus:
(System) Melden Sie sich auf der Website an, um auf Ihr persönliches Konto zuzugreifen. ~~ (Meeresspiegel)
Kontext: Ein nicht autorisierter Kunde meldet sich auf der Website an, damit die Website ihn erkennt und persönliche Informationen für ihn anzeigt: Browserverlauf, Kaufhistorie, aktuelle Anzahl an Bonuspunkten usw., wobei er E-Mail als Login verwendet.
Stufe: Benutzerziel
Hauptfigur: Kunde (Besucher unseres Online-Shops)
Umfang: Kundeninteraktion mit der Website des Online-Shops
Stakeholder und Interessen:
- Der Vermarkter möchte, dass die größtmögliche Anzahl von Seitenbesuchern identifiziert wird, um eine größere Reichweite persönlicher Mailings zu erzielen.
- Der Sicherheitsspezialist möchte sicherstellen, dass es zu keinem unbefugten Zugriff auf die persönlichen Daten des Besuchers kommt, einschließlich Versuchen, das Passwort für ein Konto zu erraten oder nach einem Konto mit einem schwachen Passwort zu suchen.
- Der Angreifer möchte sich Zugang zu den Boni des Opfers verschaffen.
- Konkurrenten möchten negative Bewertungen zu Produkten hinterlassen,
- Das Botnetz will den Kundenstamm des Shops erbeuten und mit einem Angriff die Seite funktionsunfähig machen.
Voraussetzungen: Der Besucher darf nicht autorisiert sein.
Mindestgarantien: Der Besucher erfährt, ob der Autorisierungsversuch erfolgreich war oder nicht.
Erfolgsgarantien: Der Besucher ist berechtigt.
Hauptszenario:
- Der Client initiiert die Autorisierung.
- Das System bestätigt, dass der Kunde nicht autorisiert ist und die Anzahl der erfolglosen Autorisierungsversuche einer bestimmten Sitzung (Suche nach einem schwachen Passwort für mehrere Konten) gemäß „Sicherheitsregel Nr. 23“ nicht überschreitet.
- Das System erhöht den Zähler für die Anzahl der Autorisierungsversuche.
- Das System zeigt dem Kunden ein Autorisierungsformular an.
- Der Kunde gibt seine E-Mail-Adresse und sein Passwort ein.
- Das System bestätigt die Anwesenheit eines Kunden mit einer solchen E-Mail im System und dass das Passwort übereinstimmt und die Anzahl der Anmeldeversuche für dieses Konto gemäß „Sicherheitsregel Nr. 24“ nicht überschritten wird.
- Das System autorisiert den Kunden, fügt den Browserverlauf und den Warenkorb dieser Sitzung zur letzten Sitzung dieses Kundenkontos hinzu.
- Das System zeigt eine Erfolgsmeldung für die Autorisierung an und geht zu dem Skriptschritt über, bei dem der Client für die Autorisierung unterbrochen wurde. In diesem Fall werden die Daten auf der Seite unter Berücksichtigung der persönlichen Kontodaten neu geladen.
Erweiterungen:
2.a. Der Kunde ist bereits autorisiert:
2.a.1. Das System benachrichtigt den Kunden über die Tatsache der zuvor durchgeführten Autorisierung und bietet an, entweder das Skript zu unterbrechen oder mit Schritt 4 fortzufahren. Wenn Schritt 6 erfolgreich abgeschlossen wurde, wird Schritt 7 mit Klarstellung ausgeführt:
2.a.7. Das System deaktiviert den Kunden unter dem alten Konto und autorisiert den Kunden unter dem neuen Konto, während der Browserverlauf und der Warenkorb dieser Interaktionssitzung im alten Konto verbleiben und nicht auf das neue Konto übertragen werden. Fahren Sie als Nächstes mit Schritt 8 fort.
2.b Die Anzahl der Autorisierungsversuche hat den Schwellenwert gemäß „Sicherheitsregel Nr. 23“ überschritten:
2.b.1 Gehen Sie zu Schritt 4, auf dem Autorisierungsformular wird zusätzlich ein Captcha angezeigt
2.b.6 Das System bestätigt die korrekte Captcha-Eingabe
2.b.6.1 Captcha falsch eingegeben:
2.b.6.1.1. Das System erhöht auch für dieses Konto den Zähler der fehlgeschlagenen Autorisierungsversuche
2.b.6.1.2. Das System zeigt eine Fehlermeldung an und kehrt zu Schritt 2 zurück
6.a. Es wurde kein Konto mit dieser E-Mail gefunden:
6.a.1 Das System zeigt eine Meldung über den Fehler an und bietet die Möglichkeit, entweder mit Schritt 2 fortzufahren oder zum Szenario „Benutzerregistrierung“ zu gehen und die eingegebene E-Mail zu speichern.
6.b. Das Passwort für das Konto mit dieser E-Mail stimmt nicht mit dem eingegebenen überein:
6.b.1 Das System erhöht den Zähler erfolgloser Anmeldeversuche für dieses Konto.
6.b.2 Das System zeigt eine Fehlermeldung an und bietet die Möglichkeit, entweder zum Szenario „Passwortwiederherstellung“ oder zu Schritt 2 zu wechseln.
6.c: Der Anmeldeversuchszähler für dieses Konto hat den Schwellenwert für „Sicherheitsregel Nr. 24“ überschritten.
6.c.1 Das System zeigt eine Meldung über die Blockierung der Kontoanmeldung für X Minuten an und fährt mit Schritt 2 fort.
Was ist toll
Überprüft die Vollständigkeit und Einhaltung der Ziele, d. h. Sie können Anforderungen einem anderen Analysten zur Überprüfung übergeben und so bei der Problemformulierung weniger Fehler machen.
Durch die Arbeit mit einem Black-Box-System können Sie die Entwicklung und Abstimmung mit dem Kunden dessen, was automatisiert werden soll, von den Implementierungsmethoden trennen.
Es ist Teil des Weges des Analysten, einer der Hauptbestandteile der Benutzerfreundlichkeit. Das Szenario des Benutzers definiert die Hauptpfade seiner Bewegung, was die Wahlfreiheit für Designer und Kunde erheblich einschränkt und dazu beiträgt, die Geschwindigkeit der Designentwicklung zu erhöhen.
Ich bin sehr zufrieden mit der Stelle in der Beschreibung, an der Ausnahmen für jeden Interaktionsschritt aufgeführt sind. Ein vollständiges IT-System muss eine Art Ausnahmebehandlung ermöglichen, einige manuell, andere automatisch (wie im obigen Beispiel).
Die Erfahrung zeigt, dass eine schlecht durchdachte Ausnahmebehandlung ein System leicht in ein furchtbar unbequemes System verwandeln kann. Ich erinnere mich an die Geschichte, als man zu Sowjetzeiten mehrere Genehmigungen von verschiedenen Diensten einholen musste, um eine Entscheidung zu erhalten, und wie schmerzhaft es ist, wenn der letzte Dienst sagt: „Aber Ihr Antrag lautet auf den falschen Namen oder es liegt ein anderer Fehler vor.“ Interpunktion, alles wiederholen und alles neu koordinieren.
Ich stoße oft auf Situationen, in denen die Betriebslogik eines Systems, die nicht für Ausnahmen gedacht war, eine erhebliche Überarbeitung des Systems erforderte. Aus diesem Grund wird der Löwenanteil der Arbeit des Analysten für die Ausnahmebehandlung aufgewendet.
Durch die Textnotation können im Gegensatz zu Diagrammen mehr Ausnahmen identifiziert und abgedeckt werden.
Ergänzung zur Methode aus der Praxis
Der Use Case ist im Gegensatz zur User Story kein unabhängig priorisierter Teil der Aussage.
Betrachten Sie im obigen Szenario die Ausnahme „6.a. Es wurde kein Konto mit dieser E-Mail gefunden.“ und der nächste Schritt „6.a.1 Das System zeigt eine Fehlermeldung an und fährt mit Schritt 2 fort.“ Welche negativen Dinge blieben hinter den Kulissen? Für den Kunden ist jede Rückgabe gleichbedeutend mit der Tatsache, dass die gesamte Arbeit, die er mit der Dateneingabe geleistet hat, auf einer Mülldeponie landet. (Es ist im Skript einfach nicht sichtbar!) Was kann getan werden? Erstellen Sie das Skript neu, damit dies nicht passiert. Ist das möglich? Sie können sich als Beispiel das Google-Autorisierungsskript ansehen.
Szenariooptimierung
Das Buch spricht von Formalisierung, sagt aber wenig über Methoden zur Optimierung solcher Szenarien aus.
Es ist jedoch möglich, die Methode durch die Optimierung von Szenarien zu stärken, und die Formalisierungsmethode für Anwendungsfälle ermöglicht dies. Insbesondere müssen Sie über jede auftretende Ausnahme nachdenken, die Ursache ermitteln und das Skript neu erstellen, um die Ausnahme zu beseitigen oder die Customer Journey zu minimieren.
Wenn Sie eine Bestellung in einem Online-Shop aufgeben, müssen Sie den Lieferort angeben. Es kann vorkommen, dass das Geschäft die Waren nicht in die vom Kunden gewählte Stadt liefern kann, weil es dort nicht liefert, weil es Größenbeschränkungen gibt oder weil im entsprechenden Lager keine Waren vorhanden sind.
Wenn wir einfach das Szenario der Interaktion in der Registrierungsphase beschreiben, können wir schreiben: „Informieren Sie den Kunden, dass die Lieferung unmöglich ist, und bieten Sie an, die Stadt oder den Inhalt des Warenkorbs zu ändern“ (und viele unerfahrene Analysten hören hier auf). Wenn es jedoch viele solcher Fälle gibt, kann das Szenario optimiert werden.
Als Erstes müssen Sie nur die Stadt auswählen, in die wir liefern können. Wann ist das zu tun? Vor der Auswahl eines Produkts auf der Website (automatische Erkennung der Stadt per IP mit Klärung).
Zweitens müssen wir nur die Waren auswählen, die wir dem Kunden liefern können. Wann ist das zu tun? Im Moment der Auswahl – auf der Produktkachel und der Produktkarte.
Diese beiden Änderungen tragen wesentlich dazu bei, diese Ausnahme zu beseitigen.
Anforderungen an Messungen und Metriken
Wenn Sie die Aufgabe der Minimierung der Ausnahmebehandlung in Betracht ziehen, können Sie eine Berichtsaufgabe festlegen (der Anwendungsfall wird nicht beschrieben). Wie viele Ausnahmen es gab, in welchen Fällen sie auftraten und wie viele eingehende Szenarios erfolgreich bestanden wurden.
Aber leider. Die Erfahrung zeigt, dass Berichtspflichten für Szenarien in dieser Form nicht ausreichen, sondern es müssen Berichtspflichten für Prozesse berücksichtigt werden, die überwiegend nicht in Form eines Anwendungsfalls beschrieben werden.
Zugriff auf Benutzerfreundlichkeit
In unserer Praxis haben wir das Anwendungsfallbeschreibungsformular um eine Beschreibung spezifischer Attribute von Entitäten und Daten erweitert, damit der Kunde eine Entscheidung treffen kann, was die spätere Benutzerfreundlichkeit verbessert.
Für das Usability-Design haben wir einen Eingabebereich hinzugefügt – Anzeigedaten.
In einem Szenario mit Autorisierung ist dies die Tatsache, dass der Client im System autorisiert ist. Wenn der Kunde vorab autorisiert ist, wird nach erfolgreicher Autorisierung eine Warnung angezeigt, dass der Navigationsverlauf und der Warenkorb auf das neue Konto umgestellt werden sollen.
Im Allgemeinen handelt es sich dabei um eine Anzeige der notwendigen Informationen für den Kunden, damit er je nach Szenario über sein weiteres Vorgehen entscheiden kann (Sie können fragen, ob diese Daten für den Kunden ausreichen, was sonst noch benötigt wird, welche Informationen er bewirken kann). der Klient muss Entscheidungen treffen).
Es lohnt sich auch, die eingegebenen Informationen in Eingabefelder aufzuteilen, wenn sie separat und unter Bildung unterschiedlicher Ausnahmen verarbeitet werden.
Wenn Sie im Beispiel mit der Client-Autorisierung die eingegebenen Informationen in Login und Passwort aufteilen, lohnt es sich, das Autorisierungsskript zu ändern, um die Schritte der Eingabe eines separaten Logins und eines separaten Passworts hervorzuheben (und dies geschieht in Yandex, Google, aber Dies ist in den meisten Online-Shops nicht der Fall).
Erreichen der erforderlichen Datentransformationen
Sie können auch Anforderungen für Datenkonvertierungsalgorithmen aus dem Skript extrahieren.
Beispiele:
- Um eine Entscheidung für den Kauf eines Produkts in einem Online-Shop zu treffen, muss der Kunde auf der Produktkarte die Möglichkeit, die Kosten und die Lieferzeit dieses Produkts in seine Stadt kennen (die vom Algorithmus basierend auf der Verfügbarkeit des Produkts in berechnet werden). Lager und Lieferkettenparameter).
- Beim Eingeben einer Phrase in die Suchzeile werden dem Kunden Suchvorschläge gemäß dem Algorithmus angezeigt (die vom Algorithmus generiert werden ...).
Insgesamt
Im Allgemeinen ist nach der Lektüre des Buches leider nicht klar, wie man vom Analysten über Geschäftsprobleme bis hin zu einer formalisierten technischen Spezifikation für einen Entwickler gelangen kann. Das Buch erzählt nur einen Teil des Prozesses, wobei die Eingabeschritte und die nächsten Schritte unklar sind. Der Anwendungsfall selbst ist für den Entwickler meist keine vollständige Aussage.
Dennoch ist dies eine sehr gute Möglichkeit, Szenarien der Interaktion zwischen einem Objekt und einem Subjekt zu formalisieren und zu verarbeiten, wenn die Interaktion eine Veränderung von etwas im Subjekt bewirkt. Es ist eine der wenigen Schreibmethoden, die überprüfbare Anforderungen mit expliziten Ausnahmesuchpunkten ermöglicht.
Das Buch ist eine Pflichtlektüre für Analysten, die mit dem Schreiben überprüfbarer Stücke beginnen möchten.
Source: habr.com