Business analyst: “How to write a list of system requirements correctly?”, Alistair Coburn, review part 1

The book in my opinion is very interesting, I’ll secretly share that I didn’t read it from the beginning, but rather from the end to the beginning, since all the most interesting, including the dictionary and the scope of the requirements collection, is all written at the end of the book . Clear recommendations are given on how to make a list of requirements and describe the system with varying degrees of detail, ranging from the general concept of how the application should work to page-based scripting.
What is it for? To better understand what business intelligence analysts are doing when they receive a request, I want a website, as there is a link.


Perhaps this book is worth trying to still read in the original, because in Russian translations it was often unclear to me in general what was discussed.

Basic concepts:

Use Case is a sequence of steps that usually defines all the interactions between a role / function (in UML referred to as “ctor”) and a system to achieve a specific goal.
Actor is in this case either a person who interacts with the system, or some kind of external system that can run some actions in our system. Simply put, Use cases are all variants of scripts, everything that happens on the page.
Goals - goal, Goal failure - respectively, unachieved goal.
A good use case should be written in simple and understandable language so that the information can be easily and simply understood by another person.
The main characteristics are described:
Scope - what is a project or part of a project,
Primary Actor (the main actor or element of the system, initiating interaction with the system within the framework of the main goal) a description of who (users / admins) or what will work on this page and
Level - the level at which everything happens;
Preconditions and Guarantees - what should be before and after the launch of the Use case;
Main success scenario - the main scenario that should be executed successfully;
Extensions - various options when the system deviates from the main scenario.
From myself I would like to note, I really liked the link to Steve Edolf, “use the <dive and ascend> method. Create a basic high-level model that describes how you think a new system could work. Aim for simplicity, as this is uncharted territory. Think up how the main scenario could look like, play it with specialists on the old system. Then immerse yourself in one of your new Use Cases. Just ask yourself what is happening, in reality, without going into formal requirements <..> Finally, go back to the surface, what has changed after you have gotten into the details? Adjust the model, and then repeat the dive for the next Use case ... "
')

General rules

Worth it, perhaps, to quote them in full:

1. the system description should be readable;
2. you should always start with a general concept, and go to the sub-levels,

For each step:

First, you should describe what the process consists of (step by step), allowing you to achieve the goal and describe Actor's intentions, rather than go into the details of the user interface. (where Actor is not an actor, as people like to write in Russian translations, it can be a person, or a system that performs the sum of calculations, actions and operations at a given application level or on a given page).
Then you should indicate the information that should identify actor, by what criteria, or in what way the check of updates by statuses should occur. Following this, you should write a comment about what happens between the various steps, or if these steps are missing.
After this, it is worth wondering what goal is being achieved at the next higher level using this step.

For data descriptions:

Enter in the description Use case only the corresponding level of detail.
Level of Detail 1: Data Name
Level of Detail 2: Data fields that are associated with the name
Level of detail 3: Field types, field length, and exactly how validation of the entered data occurs.

What is not included in the use case, but is always somehow connected with it and needs to be taken into account: data formats, input / output protocols, performance requirements and requirements for the user interface, user interface design, business rules.

There are several stages of accuracy:
1. Actors and Objectives: List the actors and each of the objectives that the system will pursue. Analyze the correctness and completeness of this list. Prioritize and share goals between development teams and versions. You now have functional requirements for the first level of accuracy.
2. A brief summary of the Use case or the main scenario: for the Use case, you have chosen to follow the main scenario in general terms. View it in the form of an outline to ensure that the system truly meets the requirements of the participants you care about. This is the second level of accuracy of the functional requirements. This material is quite easy to type, unlike the two following levels.
3. Failure conditions: Complete the main scenario and consider what failures may occur. List them before you decide how the system should handle them. The description of the failure handling process is more laborious than the listing of failures. <...>
4. Failure handling: Write how the system should respond to each failure. This is often a complicated, tedious and unpredictable process, since it may reveal new actors, or new goals, which the system must ensure.

To be continued.