Diagram of usage scenarios in the software development process

For several years now, as an analyst, I have quite widely used use cases (SIs) and SI diagrams in my work to document requirements. In general, use cases have different names. They are called use cases, use cases and even use cases. I remember how in the mid-2000s, on some analytical resources, there was a heated discussion of how to translate the term use case into Russian. Then this terrible word “precedent” appeared, and even more so, some comrades claimed that the Russian language was flawed and did not allow us to convey all the subtleties of the concept of use case. But as time has shown, the concept of a use case (or use case) is quite suitable for itself and quite pleasant by ear.

Having only positive experience with SI, I was very surprised when, when communicating with colleagues from other companies, I found out that they did not use them and, moreover, even tried to convince me that drawing little men, ovals and sticks between them was empty waste of time. Therefore, I decided to share my experience and demonstrate how SI diagrams help me in my work.

First, what is a use case? A use case is a coherent story about the behavior of a system when it interacts with someone (or something) from the external environment. Someone or something may be a user of the system, it may be some kind of information system or device. And this someone or something is called the Acting Person (DL). And the use case itself is a sequence of steps that describe the actions of the DL and the reaction of the system to them.

For example, a script for registering on a website might look like this:

1. The user gives a command to register.
2. The site displays the registration form.
3. The user fills in the form fields and confirms the registration.
4. The site confirms the correctness of filling out the form.
5. The site sends an e-mail with a request to confirm registration.
6. User confirms registration.
7. The site registers the user.

As you can see, the actions of the user and the system alternate among themselves, as if they are playing the ball, making passes to each other. You can read more about SI here: ru.wikipedia.org/wiki/User script

But the corrosive reader can rightly object that such a scenario should not be given to development. And he will be right! After all, we now looked at the system from a height of probably a 5-story building, when the general behavior is already clear, but there are no detailed requirements yet. Therefore, the usage scenario should be, at a minimum, supplemented by alternative threads of execution (what is presented above is called the main thread and describes the actions of the system when everything goes as it should). Alternative streams are streams that describe the reaction of the system to erroneous user actions or exceptional situations, or alternative cases of user actions if he wanted, for example, to register using an account on a social network. Also, a document with a use case can be supplemented with user interface details, data validation rules, various business rules, and error messages. But non-functional requirements are usually described in a separate document, since they are usually applicable to the whole system, and not to specific SI.

If you go even higher and look at the system from a greater "height", then it will look like a set of services provided by the system to the user (use cases can also be considered as high-level requirements for the system). Here we come to the point that it would be nice to visualize these requirements, and the corresponding UML diagram: a diagram of usage scenarios is great for this. A piece of the chart is shown below. It consists of actors, usage scenarios, and various relationships between them.


For developers and testers, it, at first glance, carries even less benefit than the use cases themselves. But it is intended for another!

The SI chart is usually drawn by the analyst at the very beginning of the project in order to cover the entire planned functionality of the project with wide strokes and coordinate it with the customer. And after that, each SI is already detailed using steps and detailed requirements. SI help to look at the system from the point of view of the services provided by the system and not to dig in in particular.

I usually use a SI chart to solve the following problems:

• Assessment of the complexity of the project;
• Work schedule planning;
• Identification of missed requirements;
• "Contents" for project documents.

Let's see how SI helps solve these problems.

Assessment of the complexity of the project

As experience and practice shows, the assessment is obtained the more accurately, the more detailed is the list of upcoming works. Indeed, the task of “writing an article” is much more difficult to evaluate than the task of “finding 5 pictures for illustrations”. So, use cases are the first iteration of breaking down the system into individual elements. Moreover, these elements have good connectivity (in this case, functional) and can be evaluated separately from each other. If this is not enough, then each SI can be decomposed into main / alternative streams or even tasks that the programmer needs to perform to implement a separate scenario.

Here quite often, the possibility of reusing previously created artifacts also manifests itself. For example, if a system requires user registration functionality, then plus / minus it will work the same in many systems, which immediately reduces the degree of uncertainty during the evaluation.

Even there is a special assessment method based on SI - Use Case Points . In this case, the characters and scenarios are distinguished, according to certain rules, they determine the complexity, set some correction factors that take into account the professionalism of the team and the complexity of the subject area, and a ready assessment appears on the output. That is, ideally, you do not even need to involve developers and testers in the evaluation.

Work schedule planning

In projects with a fixed budget, the sequential stages of design, development and testing (as in the waterfall model) are usually clearly distinguished. But in reality, testing already partially begins even before the completion of the design stage, since testers will connect to a review of the developed requirements and begin to write a test design. And if it’s not difficult for an analyst and, say, an architect, to make a work schedule, since the activities of these roles begin with the start of the project, then it becomes more difficult to determine when and what task it is worth connecting testers with developers. Indeed, because the input data for them are prepared and agreed documents with the requirements. And to solve this problem, SI is again well suited. Since each scenario contains a complete description of a process, it is easier to coordinate them with customers and, accordingly, you can quite accurately establish key points in the schedule for coordinating requirements documents. And already from these points to plan the work of the rest of the team.

Identify Missed Requirements

It is not surprising that when the customer somehow voices the requirements for the future system, then in his description he focuses on useful functionality and does not mention, for example, the system configuration functions or the user account management functions, although without them the system would not be fully work. Very often, after receiving such requirements, the team begins to carry out an assessment. In practice, there have been cases when a team immediately rushed into battle and evaluated what the customer described, leaving behind the unremarked, but, nevertheless, mandatory functions of the system.

There is also another situation where in the description of the system there are requirements that in the process of working, users must create some kind of entity. In the vast majority of cases, all CRUD (Create, Read (or also Retrieve), Update, Delete) operations, which are also sometimes forgotten, are applicable to such entities. What is the use of the SI model here? And just in the graphical representation of the requirements. When the eye covers the whole picture, it is much easier to notice the missing elements than when the requirements are formulated in plain text.

Contents for project documents

Very often, the customer asks with the system to transfer a set of project documentation. At our company, we write project documentation in the form of use cases. If the customer requires documents in accordance with GOST, then use scenarios are first written, and then GOST documents are formed on their basis.

We use at least two approaches to documentation: when each SI is described in a separate document, and when several SIs are described in one document that are related to the same subsystem. Often this or that approach is determined based on the adopted process or the habits of the customer.

It was said above that the first version of the list of use cases is already being formed at the stage of assessment and planning of the work schedule. In the future, this list can be supplemented and adjusted, but with a certain degree of accuracy, it is already possible to agree with the customer about which documents the project team will provide.

Conclusion

After these explanations, I hope that the benefits that the use of the SI diagram provide have become clear. Despite its simplicity and even redundancy directly for developers, it gives a pretty good impetus to the start of any project. And it must be considered first of all in this vein. Alistair Coburn, in her book, “Modern Methods for Describing the Functional Requirements for Systems,” also writes that he does not see the point in drawing sticks and ovals, since they do not bring the reader closer to understanding how the system should work. But he, too, is already talking about the stage of detailed elaboration of requirements, which follows after defining a set of scenarios.