January 15, 2018 at 19:45Twenty years with user cases: squeezing practical experience
At QIWI, we regularly hold meetings of analysts and project managers, where we tell each other about our experience, share knowledge and useful techniques. At one of these meetings, I talked about the Use Case methodology and my experience with it. The story was greeted with a bang, and I decided to share it with the habrasociety.
I will use the colloquial "user case" instead of the clumsy tracing case "use case." I hope the respected public will forgive me for this.
Yuzkeys became widely known from the bookAlistair Coburn, one of the authors of the Agile manifesto. The Russian translation of the book was published in 2002. In fact, the author of the technique is Ivar Jacobson. He published it in the mid-80s, and began to develop it since the late 60s. Subsequently, Ivar Jacobson, Grady Butch and James Rambo combined their approaches to the description of information systems, and UML was born.
My relationship with user cases began in 1996 and at first it didn't work out very well. I then worked at a communications enterprise, and I had free internet. According to the dailap, I surfed the Internet at that time through a 9600 baud telephone modem in search of a technique that would help me describe the functionality of the enterprise’s integrated information system.
The fact is that the automation of business processes there was implemented on isolated desktop applications with isolated databases. Up to the point that accounting of physical subscribers and settlements with them was in one database, and accounting of corporate subscribers in another. And nowhere, for example, was a pool of free telephone numbers. The task was to combine all this into a single accounting system for all services. What is now called billing.
I did not know how to start formulating requirements for such a large system, and began to look for a suitable way. I came across the UML specification version 0.9, which then just came out. In full delight, with burning eyes, I read it from cover to cover. I liked everything wildly, I understood all the UML schemes and how to use them. Except for one: Use Case diagrams. It was not clear what it was, why it was, and how to use it. Below I will explain why this happened.
In the end, they solved the billing problem - they bought it from a third-party vendor, then they introduced it for several years. But by that time I was already far away. The Yuzkeys did not learn to write then and, in general, did not feel much discomfort.
In 2004, I came to work as a systems analyst at one of the large outsourcing companies, where my real acquaintance with user cases took place. The development standard there was the Rational Unified Process, all functional requirements in all projects were supposed to be formulated only in the form of user cases. This, of course, is a radical approach, and even then it seemed strange to me, and now I know for sure that it’s impossible. Nevertheless, after listening to a couple of trainings and reading Coburn, I figured out the technique and began to apply it. Since then, case studies have been my favorite tool for analyzing and developing requirements.
There are different definitions, they at first glance vary greatly. Coburn finds the most slurred; he defines the case as "an agreement on the behavior of the system in question." True, Coburn had a whole book to reveal and clarify his definition.
And here is the definition from the UML glossary (my translation).
A Yuzkeys is a description of a set of sequences of actions of a system, including variants of such sequences, which result in an observable result that has some value for one of the participants in the process.
What definition do I try to keep in mind when writing a user case? It should tell me what I should do, about which I should not forget to write:
Usecase is a text that
describesscenario of
interaction with the system ,
leading to a significant result .
It is short and that’s good. But there are several implicit defaults in it. Which I also remember when developing a user case. Here's the full version: A
usercase is a text that
describes a scenario (possibly not one) of an
interaction (who or what?) With the system,
leading (possibly not leading)
to a significant (for whom?) Result .
This definition tells me that from the description of the user case it should be clear:
For example, I’ll give a user case from a real project. In 2012, QIWI Wallet became a multicurrency, and conversion rates were first set on the basis of Central Bank rates. But then they decided to install them on the market, and the project was dedicated to this transition. The user case is pretty simple. A trader puts up courses in ABS - an automated banking system. The director of the treasury or his deputy must confirm them just in case. Suddenly, the trader will make a mistake: the hand will tremble, press the wrong number. The price of error is great. If something is wrong, the director rejects the application, and the trader does the work again.
Setting Courses for QIWI Wallet Users
Basic Scenario
Application Rejection
Coburn does not hide the fact that his favorite username case is Fully Dressed (how is it in Russian, embarrassed?). In addition to the main and alternative scenarios, sections are included in it:
In my experience, none of this is necessary. All this only prevents you from starting to read the script and understand the essence. I’ve never had to write completely embarrassed user cases. The closest thing to this was one project that had been done for two years, and it never took off.
When developing a user case, you should not impose premature design restrictions. Take a look at the user case above. There are no details of screen forms and control elements of the interface. Will the user choose an option from the drop-down list, by selecting an option or by clicking a button? It doesn’t matter now; decisions of this level should be postponed until later. Do not do the work of a designer, he will make it better than you.
You will say: well, how do you say that the director receives an email notification. And why not via SMS or in some other way? Because we with users at that time already agreed on the option with e-mail. If I wrote in an abstract, then they would be perplexed: how is it, haven't we decided that it will be an e-mail? Something has changed? Having described the user interface in a little more detail than it should be according to the methodology, I took care of the reader so that he would not stumble while reading the user case.
In general, when choosing information to include in a user case, the main criterion should be ease of perception . For her, you can sacrifice rules, detail, sometimes even accuracy. The main thing is that the user case is understandable on the go. If it’s hard to understand right away, this is a bad user case.
What else is missing in the above example? There is nothing about how courses are transferred from the ABS to the QIWI Wallet processing system. Because it is the subject of a different interaction and a different user case. If, due to some kind of malfunction, the courses do not reach processing, this is not the trader's concern. For him, the result has been achieved: courses are appointed and approved.
Do not try to stuff everything into one user case. Delineate them based on user goals.
One of Coburn’s basic requirements is the absence of branching in the script. If there is an alternative scenario, it is supposed to describe it separately. Any arbitrarily complex block diagram with branches and loops can be represented as a set of linear sections.
I do not always follow this rule. I admit, I tweaked my user case before posting it here as an example. And in the original, he looked like this. The differences begin with paragraph 3.
Course setup script
I believe that if a scenario has one or two branches, small and without nested conditions, then using a conditional sentence will only improve readability.
How to combine the conciseness of the user case with the many details that are usually needed to design the user interface and develop the code? To do this, I accompany the user case with a list of business rules that should be considered when implementing the scenarios.
Here are the business rules that were applied to the user case from the example.
If you look closely, almost each of the rules can give rise to another alternative scenario, or even a whole user case. For example: “The director did not manage to approve the application.” But if I had painted all the alternatives, as it should be according to Coburn, the user case would have become worse. It would be more difficult to understand and highlight the essence.
You should always carefully evaluate which details should be included in the script and which should be included in the list of business rules.
One of the central concepts in the topic of user cases is the “system under consideration” (SuC, System under Consideration, or SuD, System under Development). According to the classical approach, there is a system that we are developing, and it has a border. Everything in the Universe is divided into what is inside the system and what is outside of it. And we consider exclusively those interactions that go across the boundary of the system. Knowing that at the input and at the output we can decide how it should work inside.
This approach can be called "unicellular." We focus on what happens in the cell membrane, and ignore everything else for the time being.
But in reality, we live in a multicellular organism. The company has many systems, they interact with each other and jointly implement many business functions. In almost every project, we must satisfy the next need of the company by introducing changes, as minimal as possible, into several systems.
Kobern provides for this, there is the option "organization - a transparent box." But he had something casual about it. Basically, the story is about how to describe the only system in question in the form of a black box.
I prefer not to distinguish between the systems to which we set the requirements and the external actors in my user cases. Each of the systems that we modify is considered the same participant in the interaction, like all the others. From the point of view of the classical methodology, this is not so: the system is what is inside, actors are what are outside.
But my approach allows me to extract a set of functional requirements for each system individually. We take all the steps of the user cases in which this system participates. We look whether this functionality is new or existing, or with some changes. We throw out the steps in which there are no changes. What remains is passed on to the system development team for a detailed technical study. We repeat for each of the systems participating in the user cases of the project.
From time to time in scenarios one has to meet such phrases: “data is stored in the database”, “SMS is sent to the user”. There are no actions that are performed on their own. They are always performed by someone or something.
I completely agree with Coburn's recommendation on the sentence structure in the script. Each step of the user case must begin with the subject - who or what performs the action. Then the predicate - what action. Then everything else. The predicate must be in the present tense and in the active voice. “The user selects the locality”, “The application shows a list of goods.”
Having glanced through the initial words of the steps, it is easy to put together a list of participants. I prefer not to write separately the list of participants at the beginning of the user case, this slows down the reader and prevents him from quickly moving on to reading the script.
Sometimes projects forget to foresee cases when something goes wrong. For example, a customer made a purchase, and then wanted to return it. If you did not think about this in advance, then you have to urgently finish the code after launch. And in severe cases - to throw everything away and organize the interaction of systems in a different order.
The usercase technique helps (though not guaranteed) to avoid such complications. After writing the main scenario, think: what can go wrong at each step? What can happen elsewhere after everything is already over here? Each variant deviation found must be written out, to begin with at least one phrase. Then, if necessary, work through the steps.
If the project describes only the main scenarios of user cases, then the risk is great that you forgot something important.
Use cases should be based on a domain model that all project participants understand the same. Recall the first step of our example: “A trader creates an application for setting courses . The application contains all the initial purchase and sale rates for the list of quoted currencies , as well as the date and time of their entry into force (see application form). ” In one paragraph, five concepts are used. Some of them are new, appeared only in this project.
The most famous domain introduction tool is the glossary. Only those words that might not be clear to anyone should be included in the glossary. If you start explaining everything, then after the first three points the reader will become bored and he will close the glossary, not reaching the important.
You can write short articles explaining new concepts. Here is an example - excerpt from the documentation of the same project:
Supported currencies
There is a list of supported currencies. This list is divided into two parts:
The list of supported currencies can expand over time, payment currencies become wallet currencies.
It is also known for each currency whether it is quoted against the ruble or the US dollar. "Quoted" in this case means "the rate is set by the Treasury."
(We believe that the dollar is quoted against the ruble, but not the ruble against the dollar, since the dollar is set in rubles, and not vice versa).
Another classic way to describe a domain model is an entity-relationship diagram in IDEF1 format or static structural UML diagrams.
In one recent project, in such pictures, hourly a day, for two weeks, I set out a domain model for the development team. As a result, all developers had a single picture of concepts, which helped us a lot during the project.
If the requirements are described in the form of user cases, then their list becomes a useful project management tool. For example, in the list of user cases you can prioritize implementation; you can measure progress by the number of user cases implemented. The list of user cases can exist in the form of the actual list (Use Case Survey) or in the form of a diagram of user cases.
Here is a list of user cases from another project, it is also about currency conversion. The payment system applies to the bank to exchange the currency for such an amount that is enough for holders of currency wallets and payees.
The same list, but in the form of a chart of user cases.
There is more information here: we see participants in the interaction and in what user cases they participate. Contrary to Kobern, the systems to which we put requirements (settlement system, ABS), as well as external immutable systems (exchange terminal, accounting system) and users are shown as participants.
Now I can explain to you why the user-case diagram remained incomprehensible to me when I first met UML. The fact is that all other UML diagrams model the system , they show it to us in different “perspectives”. A user-case diagram does not illustrate the system itself, but a set of functional requirements for it. A usercase diagram is therefore a model model. It was not so easy to immediately understand.
Yuzkeys are already quite an old methodology. Over 20 years, new approaches have emerged that have squeezed the methodology of user cases in those areas in which it was once the best. For example, user stories can more efficiently manage requirements in Agile projects. User experience design methods help develop products that are successful in the market. In my opinion, today, in comparison with more modern methods, user cases are in about the same position as the block diagrams used to be compared to user cases. Good old flowcharts - now Activity diagrams in UML - are still used. But once they were considered a universal way of designing and describing programs, and then their application narrowed with the advent of techniques such as Use Case, UML, BPMN.
Nevertheless, case studies still remain a good analysis tool, especially for systems that support business processes. Any analyst or project manager should know the methodology of user cases and be able to use it. About this, in fact, and my post.
I will use the colloquial "user case" instead of the clumsy tracing case "use case." I hope the respected public will forgive me for this.
Yuzkeys became widely known from the bookAlistair Coburn, one of the authors of the Agile manifesto. The Russian translation of the book was published in 2002. In fact, the author of the technique is Ivar Jacobson. He published it in the mid-80s, and began to develop it since the late 60s. Subsequently, Ivar Jacobson, Grady Butch and James Rambo combined their approaches to the description of information systems, and UML was born.
My relationship with user cases began in 1996 and at first it didn't work out very well. I then worked at a communications enterprise, and I had free internet. According to the dailap, I surfed the Internet at that time through a 9600 baud telephone modem in search of a technique that would help me describe the functionality of the enterprise’s integrated information system.
The fact is that the automation of business processes there was implemented on isolated desktop applications with isolated databases. Up to the point that accounting of physical subscribers and settlements with them was in one database, and accounting of corporate subscribers in another. And nowhere, for example, was a pool of free telephone numbers. The task was to combine all this into a single accounting system for all services. What is now called billing.
I did not know how to start formulating requirements for such a large system, and began to look for a suitable way. I came across the UML specification version 0.9, which then just came out. In full delight, with burning eyes, I read it from cover to cover. I liked everything wildly, I understood all the UML schemes and how to use them. Except for one: Use Case diagrams. It was not clear what it was, why it was, and how to use it. Below I will explain why this happened.
In the end, they solved the billing problem - they bought it from a third-party vendor, then they introduced it for several years. But by that time I was already far away. The Yuzkeys did not learn to write then and, in general, did not feel much discomfort.
In 2004, I came to work as a systems analyst at one of the large outsourcing companies, where my real acquaintance with user cases took place. The development standard there was the Rational Unified Process, all functional requirements in all projects were supposed to be formulated only in the form of user cases. This, of course, is a radical approach, and even then it seemed strange to me, and now I know for sure that it’s impossible. Nevertheless, after listening to a couple of trainings and reading Coburn, I figured out the technique and began to apply it. Since then, case studies have been my favorite tool for analyzing and developing requirements.
What is a user case?
There are different definitions, they at first glance vary greatly. Coburn finds the most slurred; he defines the case as "an agreement on the behavior of the system in question." True, Coburn had a whole book to reveal and clarify his definition.
And here is the definition from the UML glossary (my translation).
A Yuzkeys is a description of a set of sequences of actions of a system, including variants of such sequences, which result in an observable result that has some value for one of the participants in the process.
What definition do I try to keep in mind when writing a user case? It should tell me what I should do, about which I should not forget to write:
Usecase is a text that
describesscenario of
interaction with the system ,
leading to a significant result .
It is short and that’s good. But there are several implicit defaults in it. Which I also remember when developing a user case. Here's the full version: A
usercase is a text that
describes a scenario (possibly not one) of an
interaction (who or what?) With the system,
leading (possibly not leading)
to a significant (for whom?) Result .
This definition tells me that from the description of the user case it should be clear:
- The result is written in the header of the user case.
- What is the system in question
- Interaction participants (actors: people, external systems, who is the main participant?)
- Sequence of actions
- At every step: Who? What is he doing?
- What happens if something goes wrong?
For example, I’ll give a user case from a real project. In 2012, QIWI Wallet became a multicurrency, and conversion rates were first set on the basis of Central Bank rates. But then they decided to install them on the market, and the project was dedicated to this transition. The user case is pretty simple. A trader puts up courses in ABS - an automated banking system. The director of the treasury or his deputy must confirm them just in case. Suddenly, the trader will make a mistake: the hand will tremble, press the wrong number. The price of error is great. If something is wrong, the director rejects the application, and the trader does the work again.
Setting Courses for QIWI Wallet Users
Basic Scenario
- A trader creates an application for setting courses. The application gives all the initial purchase and sale rates on the list of quoted currencies, as well as the date and time of their entry into force (see application form).
- The Treasury Director receives an e-mail about the need to confirm the application.
- The director reviews the application and approves it (see the approval form).
- ABS saves courses for use in QIWI Wallet from the time specified in the application.
- Interested parties receive an e-mail message stating the new courses and the date / time of their entry into force.
Application Rejection
- In step 3, the director rejects the application.
- The trader receives an e-mail about the rejection of the application.
What you don’t need in a user case
Coburn does not hide the fact that his favorite username case is Fully Dressed (how is it in Russian, embarrassed?). In addition to the main and alternative scenarios, sections are included in it:
- Use context
- Scope
- Level
- The main character
- Members and Interests
- Precondition
- Minimum Warranty
- Trigger
- Extensions
- List of changes in technology and data
In my experience, none of this is necessary. All this only prevents you from starting to read the script and understand the essence. I’ve never had to write completely embarrassed user cases. The closest thing to this was one project that had been done for two years, and it never took off.
When developing a user case, you should not impose premature design restrictions. Take a look at the user case above. There are no details of screen forms and control elements of the interface. Will the user choose an option from the drop-down list, by selecting an option or by clicking a button? It doesn’t matter now; decisions of this level should be postponed until later. Do not do the work of a designer, he will make it better than you.
You will say: well, how do you say that the director receives an email notification. And why not via SMS or in some other way? Because we with users at that time already agreed on the option with e-mail. If I wrote in an abstract, then they would be perplexed: how is it, haven't we decided that it will be an e-mail? Something has changed? Having described the user interface in a little more detail than it should be according to the methodology, I took care of the reader so that he would not stumble while reading the user case.
In general, when choosing information to include in a user case, the main criterion should be ease of perception . For her, you can sacrifice rules, detail, sometimes even accuracy. The main thing is that the user case is understandable on the go. If it’s hard to understand right away, this is a bad user case.
What else is missing in the above example? There is nothing about how courses are transferred from the ABS to the QIWI Wallet processing system. Because it is the subject of a different interaction and a different user case. If, due to some kind of malfunction, the courses do not reach processing, this is not the trader's concern. For him, the result has been achieved: courses are appointed and approved.
Do not try to stuff everything into one user case. Delineate them based on user goals.
Conditional Constructions
One of Coburn’s basic requirements is the absence of branching in the script. If there is an alternative scenario, it is supposed to describe it separately. Any arbitrarily complex block diagram with branches and loops can be represented as a set of linear sections.
I do not always follow this rule. I admit, I tweaked my user case before posting it here as an example. And in the original, he looked like this. The differences begin with paragraph 3.
Course setup script
- A trader creates an application for setting courses. The application gives all the initial purchase and sale rates on the list of quoted currencies, as well as the date and time of their entry into force (see application form).
- The Treasury Director receives an e-mail about the need to confirm the application.
- The director reviews the application and approves or rejects it (see the approval form).
- If the application is rejected, the trader will receive an e-mail message about the rejection of the application.
- If the application is approved, then:
a. Courses are stored for use from the time specified in the application.
b. Interested parties receive an e-mail message stating the new courses and the date / time of their entry into force.
I believe that if a scenario has one or two branches, small and without nested conditions, then using a conditional sentence will only improve readability.
Business rules
How to combine the conciseness of the user case with the many details that are usually needed to design the user interface and develop the code? To do this, I accompany the user case with a list of business rules that should be considered when implementing the scenarios.
Here are the business rules that were applied to the user case from the example.
- The entry into force of the courses can only be 12:00:00, 16:00:00, 20:00:00.
- A trader is allowed to send an application for approval no later than 45 minutes before the entry into force of the courses.
- A trader can delete an order if it has not yet been submitted for approval or rejected.
- A trader can edit an unsent or rejected request and resend it for approval.
- A trader can create and send for approval at the same time several orders with different date and time of entry into force.
- Saving another application with the same date and time as the existing one is not possible.
- The director can approve the application no later than 40 minutes before the courses take effect.
- The director may delete the approved application, but no later than 60 minutes before the courses take effect. New courses indicated in the application, in case of its removal do not enter into force.
- When you delete an application, a message is sent to interested parties about the cancellation of the installation of new courses.
- It is necessary to save information in the journal about the following user actions: sending an application for approval, approving an application, deleting an application. For each of them, the following must be stored: date / time of the action, user, application data: initial courses, date and time of entry into force.
- If the QIWI Wallet processing could not download the courses at the right time according to the schedule, then in addition to notifying the operation specialists, a message should also be sent to the interested parties mailing list.
If you look closely, almost each of the rules can give rise to another alternative scenario, or even a whole user case. For example: “The director did not manage to approve the application.” But if I had painted all the alternatives, as it should be according to Coburn, the user case would have become worse. It would be more difficult to understand and highlight the essence.
You should always carefully evaluate which details should be included in the script and which should be included in the list of business rules.
When multiple systems
One of the central concepts in the topic of user cases is the “system under consideration” (SuC, System under Consideration, or SuD, System under Development). According to the classical approach, there is a system that we are developing, and it has a border. Everything in the Universe is divided into what is inside the system and what is outside of it. And we consider exclusively those interactions that go across the boundary of the system. Knowing that at the input and at the output we can decide how it should work inside.
This approach can be called "unicellular." We focus on what happens in the cell membrane, and ignore everything else for the time being.
But in reality, we live in a multicellular organism. The company has many systems, they interact with each other and jointly implement many business functions. In almost every project, we must satisfy the next need of the company by introducing changes, as minimal as possible, into several systems.
Kobern provides for this, there is the option "organization - a transparent box." But he had something casual about it. Basically, the story is about how to describe the only system in question in the form of a black box.
I prefer not to distinguish between the systems to which we set the requirements and the external actors in my user cases. Each of the systems that we modify is considered the same participant in the interaction, like all the others. From the point of view of the classical methodology, this is not so: the system is what is inside, actors are what are outside.
But my approach allows me to extract a set of functional requirements for each system individually. We take all the steps of the user cases in which this system participates. We look whether this functionality is new or existing, or with some changes. We throw out the steps in which there are no changes. What remains is passed on to the system development team for a detailed technical study. We repeat for each of the systems participating in the user cases of the project.
Predictable without subject
From time to time in scenarios one has to meet such phrases: “data is stored in the database”, “SMS is sent to the user”. There are no actions that are performed on their own. They are always performed by someone or something.
I completely agree with Coburn's recommendation on the sentence structure in the script. Each step of the user case must begin with the subject - who or what performs the action. Then the predicate - what action. Then everything else. The predicate must be in the present tense and in the active voice. “The user selects the locality”, “The application shows a list of goods.”
Having glanced through the initial words of the steps, it is easy to put together a list of participants. I prefer not to write separately the list of participants at the beginning of the user case, this slows down the reader and prevents him from quickly moving on to reading the script.
Unsuccessful scripts
Sometimes projects forget to foresee cases when something goes wrong. For example, a customer made a purchase, and then wanted to return it. If you did not think about this in advance, then you have to urgently finish the code after launch. And in severe cases - to throw everything away and organize the interaction of systems in a different order.
The usercase technique helps (though not guaranteed) to avoid such complications. After writing the main scenario, think: what can go wrong at each step? What can happen elsewhere after everything is already over here? Each variant deviation found must be written out, to begin with at least one phrase. Then, if necessary, work through the steps.
If the project describes only the main scenarios of user cases, then the risk is great that you forgot something important.
Domain Model
Use cases should be based on a domain model that all project participants understand the same. Recall the first step of our example: “A trader creates an application for setting courses . The application contains all the initial purchase and sale rates for the list of quoted currencies , as well as the date and time of their entry into force (see application form). ” In one paragraph, five concepts are used. Some of them are new, appeared only in this project.
The most famous domain introduction tool is the glossary. Only those words that might not be clear to anyone should be included in the glossary. If you start explaining everything, then after the first three points the reader will become bored and he will close the glossary, not reaching the important.
You can write short articles explaining new concepts. Here is an example - excerpt from the documentation of the same project:
Supported currencies
There is a list of supported currencies. This list is divided into two parts:
- Wallet currencies - where customers can open wallets.
- The rest (“payment currencies”) - customers cannot open wallets in them, but payment amounts can be indicated in these currencies.
The list of supported currencies can expand over time, payment currencies become wallet currencies.
It is also known for each currency whether it is quoted against the ruble or the US dollar. "Quoted" in this case means "the rate is set by the Treasury."
(We believe that the dollar is quoted against the ruble, but not the ruble against the dollar, since the dollar is set in rubles, and not vice versa).
Another classic way to describe a domain model is an entity-relationship diagram in IDEF1 format or static structural UML diagrams.
In one recent project, in such pictures, hourly a day, for two weeks, I set out a domain model for the development team. As a result, all developers had a single picture of concepts, which helped us a lot during the project.
User Case List
If the requirements are described in the form of user cases, then their list becomes a useful project management tool. For example, in the list of user cases you can prioritize implementation; you can measure progress by the number of user cases implemented. The list of user cases can exist in the form of the actual list (Use Case Survey) or in the form of a diagram of user cases.
Here is a list of user cases from another project, it is also about currency conversion. The payment system applies to the bank to exchange the currency for such an amount that is enough for holders of currency wallets and payees.
- Set RPM forecast
- Create conversion requests
- Send applications to the bank
- Complete conversion requests
- Take into account completed applications
The same list, but in the form of a chart of user cases.
There is more information here: we see participants in the interaction and in what user cases they participate. Contrary to Kobern, the systems to which we put requirements (settlement system, ABS), as well as external immutable systems (exchange terminal, accounting system) and users are shown as participants.
Now I can explain to you why the user-case diagram remained incomprehensible to me when I first met UML. The fact is that all other UML diagrams model the system , they show it to us in different “perspectives”. A user-case diagram does not illustrate the system itself, but a set of functional requirements for it. A usercase diagram is therefore a model model. It was not so easy to immediately understand.
Conclusion
Yuzkeys are already quite an old methodology. Over 20 years, new approaches have emerged that have squeezed the methodology of user cases in those areas in which it was once the best. For example, user stories can more efficiently manage requirements in Agile projects. User experience design methods help develop products that are successful in the market. In my opinion, today, in comparison with more modern methods, user cases are in about the same position as the block diagrams used to be compared to user cases. Good old flowcharts - now Activity diagrams in UML - are still used. But once they were considered a universal way of designing and describing programs, and then their application narrowed with the advent of techniques such as Use Case, UML, BPMN.
Nevertheless, case studies still remain a good analysis tool, especially for systems that support business processes. Any analyst or project manager should know the methodology of user cases and be able to use it. About this, in fact, and my post.