The book describes one method for writing part of the problem statement, namely the use case method.
What it is? This is a description of the scenario of user interaction with the system (or with the business). The system thus acts as a black box (and this makes it possible to divide the complex task of design into interaction design and ensuring this interaction). At the same time, notation standards are introduced, which ensures ease of reading, including by non-participants, and allows you to do some checks for completeness and compliance with the goals of the stakeholder.
use case example
How the script looks like, using the example of authorization on the site via email:
(System) Log in to the site to access your personal account. ~~ (sea level)
Context: An unauthorized client logs in to the site so that the site recognizes him and shows his personal information: browsing history, purchases, the current number of bonus points, etc., using email as a login.
Level: user goal
Main character: client (visitor of our online store)
Scope: Interaction of the client with the site of the online store
Stakeholders and Interests:
- the marketer wants the maximum number of site visitors to be identified for greater coverage of personal mailings,
- the security specialist wants to ensure that there are no cases of unauthorized access to the visitor's personal data, including attempts to guess the password for one account or search for an account with a weak password,
- the attacker wants to get access to the victim's bonuses,
- competitors want to leave negative reviews for products,
- The botnet wants to get the customer base of the store and use the attack to make the site inoperable.
Preconditions: the visitor must not be logged in.
Minimum guarantees: the visitor learns the fact of a successful or unsuccessful authorization attempt.
Success Guarantees: the visitor is authorized.
Main Scenario:
- The client initiates authorization.
- The system confirms that the client is not authorized and does not exceed the number of unsuccessful authorization attempts from this session (search for a weak password for many accounts) according to "Security Rule No. 23".
- The system increments the counter for the number of authorization attempts.
- The system displays an authorization form to the client.
- The client enters an email and a password.
- The system confirms the presence of a client with such an email in the system and the password match and not exceeding the number of attempts to enter this account according to the βSecurity Rule No. 24β.
- The system authorizes the client, adds the browsing history and basket of this session with the last session of this client account.
- The system displays an authorization success message and proceeds to the script step from which the client aborted for authorization. In this case, the data on the page is reloaded taking into account the personal data of the account.
Extensions:
2.a. The client is already authorized:
2.a.1. The system notifies the client about the fact of the earlier authorization and offers to either interrupt the script or go to step 4, and if step 6 is successfully completed, then step 7 is performed with clarification:
2.a.7. The system deactorizes the client under the old account, authorizes the client under the new account, while the browsing history and basket of this interaction session remain in the old account and do not transfer to the new one. Then proceed to step 8.
2.b The number of authorization attempts exceeded the threshold according to "Security Rule No. 23":
2.b.1 Go to step 4, captcha is additionally displayed on the authorization form
2.b.6 The system confirms the correct captcha entry
2.b.6.1 Captcha entered incorrectly:
2.b.6.1.1. the system increases the counter of unsuccessful authorization attempts for this account as well
2.b.6.1.2. the system displays a failure message and returns to step 2
6.a. No account found with this email:
6.a.1 The system displays a message about failure and offers a choice of either going to step 2, or going to the "User registration" scenario, saving the entered email,
6.b. The password for the account with this email does not match the one you entered:
6.b.1 The system increases the counter of unsuccessful login attempts to this account.
6.b.2 The system displays a message about failure and offers a choice of either going to the βPassword Recoveryβ scenario or going to step 2.
6.c: The counter of attempts to enter this account has exceeded the threshold according to "Security Rule No. 24".
6.c.1 The system displays a message about blocking account login for X minutes and proceeds to step 2.
What's great
Checks for completeness and compliance with goals, that is, you can give requirements for verification to another analyst, making fewer errors at the stage of setting the task.
Working with a black box type system allows you to separate the development and agreement with the customer of what will be automated from the implementation methods.
It is part of the analyst's journey, one of the main parts of usability. The user's scenario sets the main paths of his movement, which greatly reduces the freedom of choice for the designer and the customer and helps to increase the speed of design development.
It is very pleasing in the description of the place where the exceptions of each step of the interaction are revealed. A complete IT system should provide for some kind of exception handling, some in manual mode, some in automatic mode (as in the example above).
Experience shows that ill-conceived exception handling can easily turn a system into a terribly awkward system. I remember the story when in Soviet times to get a decision it was necessary to get several approvals from different services, and how painful it is when the last service says - and you have a statement in the wrong name or some other punctuation error, redo everything and reconcile everything.
I often encounter situations where the logic of the system, which was not thought out for exceptions, required a significant reworking of this system. Because of this, the lion's share of the analyst's work is spent on exception handling.
Text notation, unlike diagrams, allows you to identify and cover more exceptions.
Addition to the method from practice
The use case is not an independently prioritized part of the setup, unlike the user story.
In the above scenario, consider the exception β6.a. No account found with this email. and the next step β6.a.1 The system displays a failure message and proceeds to step 2β. What was left behind the scenes from the negative? For the client, any return is tantamount to the fact that all the work that he has done entering data is thrown into a landfill. (It just doesn't show up in the script!) What can be done? Rearrange the script so that this doesn't happen. Is it possible to do so? You can - as an example, look at the authorization script in Google.
Scenario Optimization
The book talks about formalization, but tells little about methods for optimizing such scenarios.
But it is possible to strengthen the method with script optimization, and the way the use case is formalized allows this to be done. Specifically, each exception that occurs needs to be thought about, the cause determined, and the script redesigned to get rid of the exception or minimize the client path.
When ordering an online store, you need to enter the city of delivery. It may turn out that for the city chosen by the client, the store cannot deliver the goods because it does not deliver there, due to size restrictions, or due to the lack of goods in the corresponding warehouse.
If you simply describe the interaction scenario at the checkout stage, then you can write βinform the client about the impossibility of delivery and offer to change the city or composition of the basketβ (and many novice analysts stop there). But if there are a lot of such cases, then you can optimize the scenario.
The first thing to do is to let us choose only the city where we can deliver. When to do it? Before the moment of choosing a product on the site (auto-detection of the city via ip with clarification).
Secondly, we need to give a choice only of the goods that we can deliver to the client. When to do it? At the time of selection - on the product tile and product card.
These two changes greatly eliminate this exception in practice.
Requirements for measurements and metrics
Considering the task of minimizing exception handling, you can set the task for reporting (use case is not described). How many exceptions there were, in what cases they occurred, plus how many scenarios passed successfully from the incoming ones.
But alas. Experience has shown that reporting requirements for scenarios in this form are not enough, it is necessary to consider reporting requirements for processes that are described mainly not in the form of a use case.
Access to Usability
In our practice, we have extended the use case description form with a description of specific attributes of entities and data for the client to make a decision, which enhances subsequent usability.
For usability design, we have added an input section - the displayed data.
In an authorization scenario, this is the fact that the client is authorized in the system. If the client is pre-authorized, then display a warning about switching navigation history and cart to a new account after successful authorization.
In the general case, this is a display of the necessary information for the client so that he can decide on his further actions according to the scenario (you can ask if this data is enough for the client, what else is needed, what information is needed for the client to make decisions).
It is also worth dividing the input information into input fields if they are processed separately and with the formation of different exceptions.
In the example with client authorization, if you separate the information you enter into a login and password, then you should change the authorization script with the separate steps for entering a separate login and a separate password (and this is done in Yandex, Google, but not done in most online stores).
Output to the required data transformations
From the script, you can also extract the requirements for data conversion algorithms.
examples:
- In order to make a decision to purchase a product in an online store, a client needs to know the possibility, cost, delivery time for this product to his city (which are calculated by the algorithm based on the availability of goods in warehouses and supply chain parameters) on the product card.
- When entering a phrase in the search string, the client is shown search hints according to the algorithm (which are formed by the algorithm ...).
Total
In general, after reading the book, unfortunately, it is not clear how to go all the way as an analyst from business problems to a formalized TOR for a developer. The book only tells part of the process, with the inputs vaguely articulated and the next steps vaguely shown. By itself, use case is most often not a complete setting for a developer.
Nevertheless, this is a very good way of formalizing and processing scenarios of interaction between an object and a subject, when something changes in the subject during the interaction. It is one of the few notations that allows verifiable requirements with explicit exception lookup points.
The book is a must-read for analysts to start writing verifiable plays.
Source: habr.com