How to start writing a technical assignment?

Question

Books

how to compose it properly? After all, the result depends on the specification. With poor TK, the result of HZ.

Answer 1

It seemed to me that the person was asking how to describe the TK and not how to issue it according to GOST. If I'm right, then I advise you to take a piece of paper to write the main goal of the TK, then break this goal into subtasks and so on in the form of a tree to the lowest level that you can describe. This tree will be the basis of the TK, it can be conditionally imagined that each task is a point of the TK, a subtask is a sub-item, but here it depends on the level of immersion. The more detailed such a tree is, the better the final product will turn out, the rest with regard to design and structure is more formal.

Answer 2

See GOST 34.602-89 "TERMS OF REFERENCE FOR CREATING AN AUTOMATED SYSTEM" - www.rugost.com/index.php?option=com_content&view=a...
To get started, read the article "Documentation according to GOST 34* is easy" .
TK template - www.rugost.com/index.php?option=com_content&view=a...
Comments - it-gost.ru/content/view/101/51

Answer 3

protect.gost.ru/v.aspx?control=8&baseC=-1&page=0&m... - Have you already read 4 of these pages? 1 of them is the cover page, and the second is empty. The first paragraphs are "Basis for development", "purpose of development". In my opinion, if you cannot describe these 2 points, you don’t really understand what problem you are solving at all, and accordingly it will be difficult to write a specific technical task

Answer 4

First, you don't need TK, at least right away. We need FT (functional requirements). This is what the client wants with his language with some correction, since the customer is silent about a lot, since this is silent for him. You should be interested in user roles (guest, registered, admin, registered for this or that purpose, guest for this or that purpose). You should be interested in the structure of application screenshots / site pages (which can be adjusted due to usability needs). You should be interested in the data with which you will have to work and at what points. And that is not all. The order of events and their conditions.
But TK - this is for you. How do you build a technical solution and how often will you change it during the process of solving a problem.

Answer 5

If the TK for software, then GOST 19, if for the AU, then GOST 34.
Read here - chavalah.ru/?p=526 and here - https://habrahabr.ru/post/147858/

Answer 6

Course on intuit.ru on software development based on GOST 34. Very good
www.intuit.ru/studies/courses/620/476/info

Answer 7

From personal experience: most customers themselves do not know what they need. Naturally, in such cases, the TK is written by the developer. But, I advise you to write according to "official" templates, but in a simple accessible "human" language - the most important thing is for the customer to understand what he really needs, and not "drown" in incomprehensible terms. At first, it’s simpler, and when you feel that the customer wants and can (!) delve deeper, add separate additions to the TOR (ie, from simple to complex).

Answer 8

1. theory: Joy Beatty, Carl I. Vigers "Development of software requirements"
2. case studies: nota.media/yandex

Answer 9

1. Someone who understands both IT and business processes should write - this is ideal. But suitable for small companies with technically advanced staff.
2. In practice, this is a tandem of an IT specialist and someone who understands a particular business process (sometimes there are several people - for each process - their own). In fact, an IT specialist interrogates with prejudice different people related to the business process. And he writes down from their words, interpreting it into a technical language.
It is extremely important here that the interviewees do not blame the IT specialist. Like "you're an expert, you should know everything." I usually answer: "You want me to solve your problems or mine."
IT-shnik business to understand and translate into technical language. But in no case do not describe business processes yourself. The business process should be described by the person who does it.
And it's important!!!
Sometimes bosses are not very good at imagining the little things that will be important to those. tasks.
Therefore, you need to communicate with both management and with a simple employee who is affected by what is described in those. assignment.
In fact, TK is not always needed.
If the customer agrees to always pay the hourly rate - you can do it without TK.
This allows you to save a lot of time and quickly adapt to business changes.
But this is possible only if the customer can and agrees to pay without restrictions.
This is possible if the amount of money that is spent on the performer is a penny for the customer.
Or the customer unconditionally trusts the performer (and the contractor can afford the customer)
There is another option -
a primitive prototype MVP is made
https://en.wikipedia.org/wiki/Minimum_viable_product
the task is compiled / clarified.
But ordinary customers refuse to do such things,
only those who work with large and expensive things agree.
This seriously reduces their risks.
Don't make the mistake of writing in confusing words.
You need to write in normal human language.
TK is a much simpler thing than is usually imagined.
This is just a description in human language of all the nuances.