What do programmers program?
In fact, this question will be more interesting to system analysts than to programmers.
It's not about programming, but about how to make productions (technical tasks) for programmers.
Although, if you are a programmer and find the information useful, then of course you can give your analyst a couple of interesting ideas. :-)
')
So, imagine that you need to write a technical task for the software.
How would you do it? Surely they would begin to describe the internal structure and functions of the system, right?
Yes, as a whole so. But the devil, as you know, is in the details ...
Usually TK is an enumeration of functions: the system must perform that ..., the system must do this ..., such and such characteristics must be provided ...
However, let's understand the essence. What is the Terms of Reference? ..
After being a bit of an analyst, imagine yourself for a minute as a programmer who needs to program a very simple thing: open an empty window by pressing a button on the screen:
Let's ask ourselves: what exactly is a programmer programming here?
The answer is obvious: it programs the action to open the window, i.e. system response to user pressing a button.
This is a basic principle. Whatever the programmer programming, all his tasks can be reduced to programming the system's response to user actions.
It can be not only button presses, but also data entry into text fields, mouse clicks, selections from the list, etc.
Moreover, to such a form it is possible to reduce in general any tasks of a programmer, even if we are talking about programming some internal module, for example, launching something with a robot or sharing information with other systems.
Those. it turns out that if you need to give a task to a programmer, then in the technical task it is best to list:
Something like this.
It turns out that programmers actually program the system interface. And the technical task as a matter of fact should be, first of all, a description of the interface.
The method of compiling TK based on the description of interfaces is the main use cases (use cases), which will be discussed in other articles.
Such an approach was proposed at the time by the classics of the theory of Use Cases - Craig Larman and Alistair Coburn , whose works are worthy to get acquainted with them.
Describe the interfaces in your technical specifications and make such documents for which programmers will be grateful to you!
It's not about programming, but about how to make productions (technical tasks) for programmers.
Although, if you are a programmer and find the information useful, then of course you can give your analyst a couple of interesting ideas. :-)
')
So, imagine that you need to write a technical task for the software.
How would you do it? Surely they would begin to describe the internal structure and functions of the system, right?
Yes, as a whole so. But the devil, as you know, is in the details ...
Usually TK is an enumeration of functions: the system must perform that ..., the system must do this ..., such and such characteristics must be provided ...
However, let's understand the essence. What is the Terms of Reference? ..
After being a bit of an analyst, imagine yourself for a minute as a programmer who needs to program a very simple thing: open an empty window by pressing a button on the screen:
Let's ask ourselves: what exactly is a programmer programming here?
The answer is obvious: it programs the action to open the window, i.e. system response to user pressing a button.
This is a basic principle. Whatever the programmer programming, all his tasks can be reduced to programming the system's response to user actions.
It can be not only button presses, but also data entry into text fields, mouse clicks, selections from the list, etc.
Moreover, to such a form it is possible to reduce in general any tasks of a programmer, even if we are talking about programming some internal module, for example, launching something with a robot or sharing information with other systems.
Those. it turns out that if you need to give a task to a programmer, then in the technical task it is best to list:
- all possible user actions with the created interface and
- system response is not user action.
Something like this.
It turns out that programmers actually program the system interface. And the technical task as a matter of fact should be, first of all, a description of the interface.
The method of compiling TK based on the description of interfaces is the main use cases (use cases), which will be discussed in other articles.
Such an approach was proposed at the time by the classics of the theory of Use Cases - Craig Larman and Alistair Coburn , whose works are worthy to get acquainted with them.
Describe the interfaces in your technical specifications and make such documents for which programmers will be grateful to you!
Source: https://habr.com/ru/post/266659/
All Articles