Development and approval of technical specifications. Terms of reference: formation and coordination. Stages of development of technical specifications

Preparation for laboratory work

To get acquainted with the lecture material on the topic “Life Cycle Software Models. Life cycle stages in accordance with GOST 19.102-77. Statement of the problem "of the discipline" Development and standardization of software systems and IT ".

1. Study the relevant sections in the publications.

Theoretical part. Development of technical specifications

Technical task is a document that formulates the main development goals, requirements for a software product, defines the terms and stages of development and regulates the process of acceptance tests. Both representatives of the customer and representatives of the contractor participate in the development of the technical task. This document is based on the initial requirements of the customer, analysis of advanced technological advances, the results of research work, pre-design studies, scientific forecasting, etc.

The procedure for the development of technical specifications

The development of technical specifications is carried out in the following sequence. First of all, a set of functions to be performed is established, as well as a list and characteristics of the initial data. Then a list of results, their characteristics and presentation methods are determined.

Further, the operating environment is specified. software: specific configuration and parameters technical means, the version used operating system and, possibly, versions and parameters of other installed software with which the future software product will interact.

In cases where the developed software collects and stores some information or is involved in the management of any technical process, it is also necessary to clearly regulate the actions of the program in the event of equipment and power failures.

1. General Provisions

1.1. The terms of reference are drawn up in accordance with GOST 19.106-78 on sheets of A4 and A3 in accordance with GOST 2.301-68, as a rule, without filling out the fields of the sheet. The sheet (page) numbers are placed at the top of the sheet above the text.

1.2. The approval sheet and the title page are drawn up in accordance with GOST 19.104-78. The information part (annotation and content), the change registration sheet is allowed not to be included in the document.

1.3. To make changes and additions to the technical background at the subsequent stages of the development of a program or software product, an addendum to it is released. Coordination and approval of the addition to the terms of reference is carried out in the same order that is established for the terms of reference.

1.4. The terms of reference should contain the following sections:

Introduction;

Name and scope;

Basis for development;

Purpose of development;

Technical requirements to the program or software item;

Technical and economic indicators;

Stages and stages of development;

Control and acceptance procedure;

Applications.

Depending on the features of the program or software product, it is allowed to clarify the content of the sections, introduce new sections or combine individual ones. If necessary, it is allowed to include applications in the terms of reference.

2.1 The introduction should include brief description areas of application of the program or software product, as well as the object (for example, a system) in which they are supposed to be used. The main purpose of the introduction is to demonstrate the relevance of this development and to show what place this development occupies among similar ones.

2.2. In the section "Name and scope" indicate the name, a brief description of the scope of the program or software product and the object in which the program or software product is used.

2.3. In the "Basis for Development" section, the following should be indicated:

The document (documents) on the basis of which the development is carried out. Such a document can be a plan, order, contract, etc .;

The organization that approved this document and the date of its approval;

Name and (or) symbol development topics.

2.4. The section "Purpose of development" should indicate the functional and operational purpose of the program or software product.

2.5. The section "Technical requirements for a program or software product" should contain the following subsections:

Requirements for functional characteristics;

Reliability requirements;

Operating conditions;

Requirements for the composition and parameters of technical means;

Requirements for information and software compatibility;

Requirements for labeling and packaging;

Transportation and storage requirements;

Special requirements.

2.5.1. The subsection "Requirements for functional characteristics" should indicate the requirements for the composition of the functions performed, the organization of input and output data, time characteristics, etc.

2.5.2. The subsection "Requirements for Reliability" shall specify the requirements for ensuring reliable operation (ensuring stable operation, control of input and output information, recovery time after failure, etc.).

2.5.3. In the subsection "Operating conditions", the operating conditions (ambient temperature, relative humidity, etc. for the selected types of data carriers) must be specified, under which the specified characteristics must be ensured, as well as the type of service, required amount and staff qualifications.

2.5.4. In the subsection "Requirements for the composition and parameters of technical means" indicate the required composition of technical means with an indication of their technical characteristics.

2.5.5. In the subsection “Requirements for information and software compatibility,” the requirements for information structures at the input and output and methods of solution, source codes, programming languages must be indicated. Protection of information and programs should be ensured where necessary.

2.5.6. In the subsection "Requirements for marking and packaging" in general case indicate the requirements for the labeling of the software product, options and methods of packaging.

2.5.7. In the subsection "Requirements for transportation and storage", the conditions of transportation, storage locations, storage conditions, storage conditions, storage times under various conditions must be indicated for the software product.

2.5.8. In the section "Technical and economic indicators" should be indicated: approximate economic efficiency, estimated annual demand, economic advantages of the development in comparison with the best domestic and foreign samples or analogs.

2.6 In the section "Stages and stages of development", the necessary stages of development, stages and content of work are established (a list of program documents that must be developed, agreed and approved), as well as, as a rule, the timing of development and determine the performers.

2.7. In the section "Procedure for control and acceptance", the types of tests and General requirements to the acceptance of the work.

2.8 In the annexes to the terms of reference, if necessary, give:

The list of research and other works justifying the development;

Algorithm diagrams, tables, descriptions, justifications, calculations and other documents that can be used in the development;

Other sources of development.

In cases where the customer does not make any requirements stipulated by the terms of reference, it is necessary to indicate in the appropriate place “Requirements are not presented”.

Examples of the development of technical specifications are given in Appendices B and C.

Control questions

1.Give the concept of a model life cycle ON.

2. Give the stages of software development.

3. What does the statement of the problem and pre-project research include?

4. List the functional and performance requirements for the software product.

5. List the rules for developing technical specifications.

6. What are the main sections of the terms of reference.

Appendix A

Job options

Laboratory works Nos. 1-5 are performed for the same variant.

1. To develop a program module "Accounting for student progress." The software module is designed for the operational accounting of students' progress in the session by the dean, deputy deans and employees of the dean's office. Information about the progress of students should be kept during the entire period of their study and used in the preparation of certificates of attended courses and diploma supplements.

2. Develop a program module "Students' Personal Files". The program module is designed to obtain information about students by employees of the dean's office, trade union committee and personnel department. The information should be kept for the entire duration of the student's training and used in the preparation of certificates and reports.

3. To develop a software module "Solution of combinatorial-optimization problems". The module should contain algorithms for finding a cycle of minimum length (traveling salesman problem), finding the shortest path, and finding a minimum connecting tree.

4. Develop a program module "Matrix processing". The module should contain algorithms for finding the sums and products of matrix elements by rows and columns, as well as calculating the average, minimum and maximum values in the matrix.

5. Develop Windows application"Organizer". The application is designed to record, store and search for addresses and phone numbers individuals and organizations, as well as schedules, meetings, etc. The application is intended for any computer user.

6. Develop a Windows application "Calculator". The application is intended for any user and must contain all arithmetic operations (with observance of priorities) and preferably (but not necessarily) several mathematical functions.

7. Develop a program module "Department" containing information about the staff of the department (full name, position, academic degree, disciplines, workload, social work, part-time job, etc.). The module is intended for use by employees of the personnel department and the dean's office.

8. Develop a program module "Laboratory" containing information about laboratory staff (full name, gender, age, marital status, presence of children, position, academic degree). The module is intended for use by employees of the trade union committee and the personnel department.

9. Develop a program module "Dry Cleaning". When registering for service, an application is filled out, which indicates the owner's full name, description of the product, type of service, date of receipt of the order and the cost of the service. After completing the work, a receipt is printed.

10. To develop a software module "Accounting for violations of rules road traffic". For each car (and its owner) a list of violations is stored in the database. For each violation, the date, time, type of violation and the amount of the fine are recorded. When all fines are paid, the car is removed from the database.

11. Develop a software module "Autoshop Card File" intended for use by the agency's employees. The database contains information about cars (brand, engine size, release date, etc.). When a purchase order is received, a search is made for a suitable option. If this is not the case, the client is entered into the client base and is notified when an option appears.

12. To develop a software module "ATS Subscriber Card". The card file contains information about phones and their owners. Fixes arrears on payments (subscriber and time-based). It is believed that the time wages of local telephone conversations already introduced.

13. To develop a software module "Autokassa", containing information about the availability of free seats on bus routes. The database must contain information about the flight number, route, driver, type of bus, date and time of departure, as well as the cost of tickets. Upon receipt of an application for tickets, the program searches for a suitable flight.

14. Develop a software module "Bookstore" containing information about books (author, title, publisher, year of publication, price). The buyer draws up an application for the books he needs, if there are none, he is entered into the database and is notified when the necessary books arrive at the store.

I am often asked: "How to develop a technical assignment for an automated system correctly?" The topic of developing a technical assignment is constantly discussed in various forums. This question is so broad that it is impossible to answer in a nutshell. So I decided to write great article on this topic. In the process of working on the article, I realized that it would not work to put everything in one article, because it will turn out under 50 pages and decided to split it into 2 parts:

In the first part " Development of technical specifications. What is it, why is it needed, where to start and how it should look? " I will try to answer in detail the questions of the topic, consider the structure and purpose of the Terms of Reference, and give some recommendations on the formulation of requirements.
Second part " Development of technical specifications. How to Formulate Requirements? " will be fully devoted to identifying and formulating the requirements for the information system.

First, you need to figure out what question really interests those who ask "How to develop a technical assignment?" The fact is that the approach to the development of technical specifications will also greatly depend on the purpose for which this is done, as well as by whom it will be used. What options am I talking about:

A commercial organization decided to implement an automated system. It does not have its own IT service and decided to do the following: The person concerned should develop the Terms of Reference and submit it to a third-party organization for development;
A commercial organization decided to implement an automated system. It has its own IT service. We decided to do this: develop the Terms of Reference, then coordinate it between the IT service and stakeholders, and implement it on our own;
The government agency decided to start an IT project. Everything is so muddy here, a lot of formalities, kickbacks, cuts, etc. I will not consider this option in this article.
An IT company is engaged in services for the development and / or implementation of automated systems. This is the most difficult case, because you have to work in a variety of conditions:
The client has his own specialists with their own views, and they make specific requirements for the Terms of Reference;
- The terms of reference are developed for our own developers (the client does not care);
- The terms of reference are developed for transfer to the contractor (i.e. a group of programmers located outside the company's staff, or an individual specialist);
- A misunderstanding arises between the company and the client regarding the result obtained, and the company again and again asks the question: "How should the Terms of Reference be developed?" Perhaps the latter case seems like a paradox, but it is true.
- Other, less common options are also possible;

I think the reader should now have some questions:

Why is it impossible to develop the Terms of Reference is always the same ?;
Are there any standards, methods, recommendations? Where can I get them?
Who should develop the Terms of Reference? Should this person have any special knowledge?
How to understand whether the Terms of Reference is well written or not?
At whose expense should it be developed, and is it necessary at all?

The list can be endless. I speak so confidently because I have been in professional software development for 15 years, and the question of Terms of Reference comes up in any development team with whom I have to work. The reasons for this are different. Raising the topic of the development of the Terms of Reference, I am perfectly aware that I will not be able to present it 100% for everyone interested in the topic. But, I will try, as they say, "put everything on the shelves." Those who are already familiar with my articles know that I do not use the "copy-paste" of other people's work, I do not reprint other people's books, I do not cite multi-page standards and other documents that you yourself can find on the Internet, passing them off as my brilliant thoughts. It is enough to type in the search engine "How to develop a technical assignment" and you can read a lot of interesting, but, unfortunately, many times repetitive. As a rule, those who like to be clever on the forums (try to search all the same!) Have never done a sensible Terms of Reference themselves, and continuously cite the recommendations of GOSTs on this issue... And for those who are really serious about the issue, usually there is no time to sit on the forums. By the way, we will also talk about GOSTs. In different years of my work, I had to see many options for technical documentation, compiled by both individual specialists and eminent teams and consulting companies... Sometimes I also do this activity: I set aside time for myself and search for information on a topic of interest from unusual sources (such a little intelligence). As a result, I had to see the documentation for such monsters as GazProm, Russian Railways and many other interesting companies. Of course, I abide by the privacy policy, despite the fact that these documents come to me from publicly available sources or the irresponsibility of consultants (scattering information on the Internet). Therefore, I immediately say: confidential information that belongs to other companies is not shared, regardless of the source of occurrence (professional ethics).

What is the terms of reference?

The first thing we are going to do now is to figure out what kind of beast this is, "Terms of Reference".

Yes, there really are GOSTs and standards in which attempts are made to regulate this part of the activity (software development). Once upon a time, all these GOSTs were relevant and actively used. Now there are different opinions about the relevance of these documents. Some argue that GOSTs were developed by very far-sighted people and are still relevant. Others say they are hopelessly outdated. Perhaps someone just now thought that the truth is somewhere in the middle. I would answer with the words of Goethe: “They say that there is truth between two opposite opinions. In no case! There is a problem between them. " So, there is no truth between these opinions. Because GOSTs do not disclose the practical problems of modern development, and those who criticize them do not offer alternatives (specific and systemic).

Note that the GOST clearly does not even give a definition, it only says: “The technical specification for the NPP is the main document that defines the requirements and procedure for the creation (development or modernization - further creation) of an automated system, in accordance with which the development of the AU and its acceptance is carried out upon commissioning into action ".

If someone is interested in what GOSTs I'm talking about, then here they are:

GOST 2.114-95 one system design documentation. Technical conditions;
GOST 19.201-78 Unified system of program documentation. Technical task. Requirements for content and design;
GOST 34.602-89 Information technology. A set of standards for automated systems... Terms of reference for the creation of an automated system.

A much more apt definition is presented in Wikipedia (true about TK in general, and not just for software): “ Technical task- this is the initial design document technical object. Technical task establishes the main purpose of the developed object, its technical and tactical specifications, quality indicators and technical and economic requirements, prescriptions for performing the necessary stages of creating documentation (design, technological, software, etc.) and its composition, as well as special requirements. A task as a source document for creating something new exists in all areas of activity, differing in name, content, order of registration, etc. (for example, a design task in construction, a combat mission, homework, contract for a literary work, etc.) "

And so, as follows from the definition, the main purpose of the Terms of Reference is to formulate the requirements for the object being developed, in our case for an automated system.

Precisely the main one, but the only one. The time has come to tackle the main thing: to sort everything out "on the shelves", as promised.

What do you need to know about the requirements? It is necessary to clearly understand that all requirements must be divided by type and by properties. Now we will learn how to do this. GOST will help us to separate the requirements by type. The list of types of requirements presented there is a good example what kinds of requirements should be considered. For example:

Functionality requirements;
Requirements for security and access rights;
Requirements for the qualifications of personnel;
…. Etc. You can read about them in the mentioned GOST (and below I will also consider them in a little more detail).

I think it is obvious to you that the key factor for a successful Terms of Reference is precisely well-formulated requirements for functionality. Most of the works and techniques that I talked about are devoted to these requirements. Requirements for functionality are 90% of the complexity of work on the development of the Terms of Reference. Everything else is often the "camouflage" that is put on these requirements. If the requirements are poorly formulated, then what a beautiful camouflage you shouldn't wear, successful project will not work. Yes, formally all the requirements will be met (according to GOST J), the TK has been developed, approved and signed, the money has been received for it. So what? And then the most interesting thing will begin: what to do? If this is a project on the State Order, then there are no problems - the budget there is such that it will not fit into any pocket, in the process of implementation (if there is one), everything will be clarified. This is exactly how most of the project budgets for State Orders are cut (they fired up the "TZ", they poured out ten million, but the project was not done. All formalities were followed, there are no guilty parties, a new car is near the house. Beauty!). But we are talking about commercial organizations where money is counted, and the result needs a different one. Therefore, let's deal with the main thing, how to develop useful and working Terms of Reference.

I said about the types of requirements, but what about the properties? If the types of requirements can be different (depending on the goals of the project), then with the properties everything is simpler, there are 3 of them:

The requirement must be understandable;
The requirement must be specific;
The requirement must be tested;

Moreover, the last property is impossible without the previous two, i.e. is a kind of "litmus test". If the result of fulfilling a requirement cannot be tested, then it is either not clear or not specific. Think about it. It is in the possession of these three properties of requirements that skill and professionalism lie. In fact, everything is very simple. When you figure it out.

On this, the story of what the Terms of Reference is, could be completed and move on to the main thing: how to formulate requirements. But not everything is so fast. There is one more extremely important point:

In what language (in terms of the complexity of understanding) the terms of reference should be written?
Should the specification of various functions, algorithms, data types and other technical things be described in it?
And what is technical design, which, by the way, is also mentioned in GOSTs, and how is it related to the Terms of Reference?

There is a very insidious thing in the answers to these questions. That is why disputes often arise about the sufficiency or lack of the necessary detailing of the requirements, about the clarity of the document by the Customer and the Contractors, about the redundancy, presentation format, etc. And where is the general border between the Terms of Reference and the Technical Design?

Technical task is a document based on requirements formulated in an understandable (ordinary, familiar) language for the Customer. At the same time, industry terminology that is understandable to the Customer can and should be used. There should be no bindings to the specifics of the technical implementation. Those. at the TK stage, in principle, it does not matter on which platform these requirements will be implemented. There are exceptions though. If we are talking about the implementation of a system based on an existing software product, then such a binding can take place, but only at the level of screen forms, report forms, etc. business analyst. And certainly not a programmer (unless he combines these roles in himself, this happens). Those. this person should speak with the Customer in the language of his business.

Technical project is a document that is intended for the technical implementation of the requirements formulated in the Terms of Reference. This document describes data structures, triggers and stored procedures, algorithms and other things that are required. technicians ... It is not at all necessary for the customer to delve into this (he may not understand such terms). The technical design makes System architect(it is quite normal to combine this role with a programmer). To be more precise, a group of AO specialists is led by an architect. The larger the project, the more people are working on the Terms of Reference.

What do we have in practice? It's funny to watch when the director is brought for approval by the Terms of Reference, which is replete with technical terminology, a description of data types and their values, database structure, etc. business requirements. Is this a familiar situation? And how does it end? As a rule, such TK is approved, then implemented, and in 80% of cases then it does not correspond at all to the fact of the work performed, because they decided to change, redo a lot of things, misunderstood, thought wrong, etc. etc. And then the series about the delivery of work begins. “But this is not the way we need it,” but “this will not work for us,” “this is too difficult,” “this is inconvenient,” etc. Sound familiar? !! That's familiar to me, I had to fill cones in due time.

So what do we have in practice? In practice, we have a blurred border between the Terms of Reference and the Technical Design. She floats between TK and TP in a variety of forms. And that's bad. And it turns out this way because the development culture has become weak. This is partly due to the competencies of specialists, partly with the desire to reduce budgets and deadlines (after all, documentation takes a long time - this is a fact). There is one more important factor affecting the use of the Technical Design as a separate document: the rapid development of rapid development tools, as well as development methodologies. But this is a separate story, just below I will say a few words about it.

Another small but important point. Sometimes the Terms of Reference is a small piece of requirements, simple and understandable. For example, to refine the search for an object according to some conditions, add a column to the report, etc. This approach is quite justified, why complicate life. But it is not used on large projects, but on minor improvements. I would say this is closer to the maintenance of a software product. In this case, a specific technical solution implementation of the requirement. For example, "Make such and such a change in the algorithm so and so", indicating a specific procedure and a specific change for the programmer. This is the case when the border between the Terms of Reference and Technical Projects is completely erased, because there is no economic feasibility inflate paperwork where it is not needed, but useful document is created. And it is right.

Do you need a technical task at all? What about the Technical Design?

Am I overheated? Is this possible, without at all Terms of Reference? Imagine it is possible (more precisely, it occurs), and this approach has many followers, and their number is increasing. As a rule, after young specialists read books about Scrum, Agile and other technologies of rapid development. In fact, these are wonderful technologies, and they work, only they do not say literally “no need to do technical specifications”. They say “a minimum of paperwork”, especially unnecessary, closer to the Customer, more specifics and faster to the result. But no one canceled the fixation of requirements, and it is clearly stated there. It is there that the requirements are fixed based on the three remarkable properties that I spoke about above. It's just that some people have such a structured consciousness that if something can be simplified, then let's simplify it to complete absence... As Einstein said “ Make it as simple as possible, but not easier. " ... Golden words, after all, are suitable for everything. So Technical task it is necessary, otherwise you will not see a successful project. Another question is how to compose and what to include there. In light of Rapid Development methodologies, you only need to focus on requirements, and all the "camouflage" can be dropped. In principle, I agree with this.

What about the Technical Project? This document is very useful and has not lost its relevance. Moreover, it is often impossible to do without it. Especially when it comes to outsourcing development work, i.e. on the basis of outsourcing. If this is not done, there is a risk of learning a lot of new things about how the system that you have conceived should look like. Should the Customer get to know him? If he wants, why not, but insist and assert this document there is no need, it will only restrain and interfere with work. It is almost impossible to design a system to the smallest detail. In this case, you will have to continuously make changes to the Technical Design, which takes a lot of time. And if the organization is highly bureaucratic, then in general, leave all the nerves there. It is precisely about the reduction of this kind of design that we are talking about in modern methodologies rapid development that I mentioned above. By the way, they are all based on classic XP (extreme programming) - an approach that is already about 20 years old. So make a high-quality Terms of Reference, understandable to the Customer, and use the Technical Design as an internal document for the relationship between the system architect and programmers.

An interesting detail about technical design: some development tools based on the principle of subject orientation (such as 1C and similar ones) assume that design (meaning the documenting process) is required only in really complex areas where interaction between whole subsystems is required. In the simplest case, for example, to create a reference book, a document, just correctly formulated business requirements are enough. This is evidenced by the business strategy of this platform in terms of training specialists. If you look at Examination ticket specialist (this is what he is called, and not a "programmer"), then you will see that there are only business requirements, and how to implement them in a programming language is the specialist's task. Those. that part of the task that the Technical Project is designed to solve, the specialist must solve "in the head" (we are talking about tasks of medium complexity), and here and now, following certain development and design standards, which are again formed by 1C for its platform. Thus, out of two specialists, whose work result looks the same, one can pass the exam, and the other cannot, because grossly violated development standards. That is, it is obviously assumed that specialists must have such qualifications that they can design typical tasks on their own, without involving system architects. And this approach works.

Let's continue the study of the question: "What requirements should be included in the Terms of Reference?"

Formulation of requirements for the information system. Structure of the Terms of Reference

Let's decide right away: we will talk specifically about the formulation of requirements for an information system, i.e. assuming that the work of developing business requirements, formalizing business processes and all prior consulting work has already been done. Of course, some refinements can be performed at this stage as well, but precisely refinements. The automation project itself does not solve business problems - remember this. This is an axiom. For some reason, some managers try to refute it, believing that if they buy the program, then order will come in a chaotic business. But the axiom is also an axiom that no proofs are required.

As with any activity, the formulation of requirements can (and should) be divided into stages. Everything has its time. This is hard intellectual work. And, if he treats it with insufficient attention, then the result will be appropriate. According to expert estimates, the cost of developing the Terms of Reference may be 30-50%. I am of the same opinion. Although 50 is probably too much. After all, the Terms of Reference is not the last document to be developed. After all, there should also be technical design. This spread is due to different automation platforms, approaches and technologies used by project teams during development. For example, if we are talking about development in a classical language like C ++, then one cannot do without detailed technical design. If we are talking about the implementation of the system on the 1C platform, then the situation with the design is somewhat different, as we saw above (although, when developing the system "from scratch", it is designed according to the classical scheme).

Despite the fact that the statement of requirements is the main part of Terms of Reference, and in some cases it becomes the only section of the TK, you should pay attention to the fact that this is an important document, and it should be drawn up accordingly. Where to begin? First of all, you need to start with the content. Compose your content, then start expanding it. Personally, I do this: first I sketch out the content, describe the goals, all the background information, and then I take on the main part - the formulation of requirements. Why not the other way around? I don’t know, it’s more convenient for me. Firstly, this is a much smaller part of the time (compared to the requirements), and secondly, while describing all the introductory information, you tune in to the main thing. Well, this is as you like. Over time, you will develop your own template for the Terms of Reference. To begin with, I recommend that you take exactly the one described in GOST as the content. It fits perfectly for the content! Then we take and begin to describe each section, not forgetting about the recommendations for adherence to three properties: clarity, concreteness and testability. Why am I so insistent on this? More on this in the next section. And now I propose to go all the way through the points of the TK, which are recommended in the GOST.

general information;
purpose and goals of creation (development) of the system;
characteristics of automation objects;
system requirements;
composition and content of work on the creation of the system;
the procedure for control and acceptance of the system;
requirements for the composition and content of work on the preparation of the automation object for putting the system into operation;
documentation requirements;
development sources.

In total, there are 9 sections, each of which is also divided into subsections. Let's analyze them in order. For convenience, I will present everything in the form of a table for each item.

Section 1. general information.

Recommendations according to GOST
full name of the system and its symbol;	Everything is clear here: we write what the system will be called, its short name
subject code or code (number) of the contract;	This is not relevant, but you can specify if required
the name of the enterprises (associations) of the developer and customer (user) of the system and their details;	indicate who (which organizations) will work on the project. You can also specify their roles. You can delete this section altogether (rather formal).
a list of documents on the basis of which the system is created, by whom and when these documents were approved;	Useful information. Here it is worth indicating the normative and reference documentation that was provided to you to familiarize yourself with a certain part of the requirements
the planned start and end dates for the creation of the system;	Requests for the timing. Sometimes they write about it in the TK, but more often such things are described in contracts for work
information about the sources and procedure for financing the work;	Likewise, as in the previous paragraph about the timing. More relevant for government orders (for public sector employees)
the procedure for registering and presenting to the customer the results of work on the creation of the system (its parts), on the manufacture and adjustment of individual means (hardware, software, information) and software and hardware (software and methodological) complexes of the system.	I do not see the need for this point, tk. the requirements for documentation are made separately, and in addition there is a whole separate section "Procedure for control and acceptance" of the system.

Section 2. purpose and goals of creation (development) of the system.

Recommendations according to GOST	What to do about it in practice
Purpose of the system	On the one hand, everything is simple with the appointment. But it is desirable to be specific. If you write something like “qualitatively automate inventory control in company X”, then you can then discuss the result for a long time at its completion, even regardless of the good formulation of requirements. Because The customer can always say that he meant something different by quality. In general, you can spoil each other a lot of nerves, but why? It is better to immediately write something like this: “The system is intended for maintaining warehouse accounting in company X in accordance with the requirements set forth in this Terms of Reference ".
Objectives of the system	Objectives are definitely an important section. If you really include it, then you need to be able to formulate these goals. If you have difficulties with the formulation of goals, then it is better to exclude this section altogether. An example of an unsuccessful goal: "Provide fast paperwork for the manager." What's fast? This can then be proven endlessly. If this is important, then it is better to reformulate this goal as follows: "The sales manager should be able to draw up a document" Sales of goods "of 100 lines in 10 minutes." A similar goal may appear if, for example, the manager currently spends about an hour on this, which is too much for this company and it is important for them. In such a formulation, the goal already intersects with the requirements, which is quite natural, since when expanding the tree of goals (i.e. splitting them into smaller related goals), we will approach the requirements anyway. Therefore, you should not get carried away.

In general, the ability to identify goals, formulate them, build a tree of goals is a completely separate topic. Remember the main thing: if you know how - write, you are not sure - do not write at all. What will happen if you do not formulate goals? You will work according to requirements, this is often practiced.

Section 3. Description of automation objects.

Section 4. System Requirements

GOST deciphers the list of such requirements:

requirements for the structure and functioning of the system;
requirements for the number and qualifications of the personnel of the system and the mode of their work;
destination indicators;
reliability requirements;
safety requirements;
requirements for ergonomics and technical aesthetics;
transportability requirements for mobile speakers;
operating requirements, maintenance, repair and storage of system components;
requirements for the protection of information from unauthorized access;
requirements for the safety of information in case of accidents;
requirements for protection from the influence of external influences;
requirements for patent purity;
requirements for standardization and unification;

Despite the fact that the main section will certainly be with specific requirements (functional), this section can also be of great importance (and in most cases it does). What can be important and useful:

Qualification requirements... Perhaps the system being developed will require retraining of specialists. These can be both users of the future system and IT specialists who will be needed to support it. Insufficient attention to this issue often develops into problems. If the qualifications of the existing staff are clearly insufficient, it is better to prescribe the requirements for the organization of training, training program, timing, etc.
Requirements for protecting information from unauthorized access. Comments are unnecessary here. These are precisely the requirements for the differentiation of access to data. If such requirements are planned, then they need to be described separately, in as much detail as possible according to the same rules as functional requirements (clarity, specificity, testability). Therefore, these requirements can be included in the section with functional requirements.
Requirements for standardization. If there are any design standards that are applicable to the project, they can be included in the requirements. As a rule, such requirements are initiated by the Customer's IT service. For example, the 1C company has requirements for the design of the program code, interface design, etc.;
Requirements for the structure and functioning of the system. Requirements for the integration of systems with each other can be described here, a description of the general architecture is provided. More often, the requirements for integration are generally singled out in a separate section or even a separate Terms of Reference. these requirements can be quite complex.

All other requirements are less important and need not be described. In my opinion, they only make the documentation heavier, and are of little practical use. And it is very difficult to describe the requirements for ergonomics in the form of general requirements; it is better to transfer them to functional ones. For example, the requirement "Get information about the price of an item by clicking only one button" can be formulated. In my opinion, this is still closer to specific functional requirements, although it relates to ergonomics. Requirements for the functions (tasks) performed by the system This is the main and key point that will determine success. Even if everything else is done perfectly, and this section is “3”, then the result of the project will be “3” at best, or even the project will fail altogether. We will deal with these in more detail in the second article, which will be included in the 5th issue of the mailing list. It is to this point that the "rule of three properties of claims", about which I spoke. Requirements for types of collateral

GOST distinguishes the following types:

Mathematical
Information
Linguistic
Software
Technical
Metrological
Organizational
Methodical
other…

At first glance, it might seem that these requirements are not important. In most projects, this is true. But not always. When to describe these requirements:

Decisions about which language (or which platform) will be used for development have not been made;
The system has requirements for a multilingual interface (for example, Russian / English)
For the system to function, a separate subdivision must be created or new employees hired;
For the system to function at the Customer, there must be changes in the methods of work, and these changes must be specified and planned;
Integration with any equipment is assumed and requirements are imposed on it (for example, certification, compatibility, etc.)
Other situations are possible, it all depends on the specific goals of the project.

Section 5. Composition and content of work on the creation of the system

Section 6. Procedure for control and acceptance of the system

General requirements for the acceptance of work by stages (list of participating enterprises and organizations, place and timing), the procedure for agreeing and approving acceptance documentation; I strongly recommend that you take responsibility for the procedure for delivering work and checking the system. This is what testable requirements are for, but even the presence of testable requirements may not be enough when the system is handed over, if the order of acceptance and handover of works is not clearly spelled out. For example, a common trap: the system is made, it is fully functional, but the Customer, for some reason, is not ready to work in it. These reasons can be any: once upon a time, goals have changed, someone quit, etc. And he says: “Since we are not yet working in new system, so we cannot be sure that it works. " So learn to correctly identify the stages of work, ways to check the results for these stages. Moreover, such methods should be clear to the Customer initially. If they are fixed at the level of the Terms of Reference, then you can always contact them, if necessary, and bring the work with the transfer.

Section 7. Requirements for the composition and content of work on the preparation of the automation object for putting the system into operation

There may be any other rules for entering information adopted by the company (or planned). For example, information about the contract was previously entered in a text line in an arbitrary form, but now the number is required separately, the date separately, etc. There can be many such conditions. Some of them can be perceived with resistance from personnel, so it is better to register all such cases at the level of requirements for the data entry procedure Changes that need to be made in the automation object

Creation of conditions for the operation of the automation object, under which the compliance of the created system with the requirements contained in the TZ is guaranteed. Any changes that may be required. For example, the company does not have the local network, an outdated fleet of computers on which the system will not work.

Perhaps some necessary information was processed on paper, and now it needs to be entered into the system. If this is not done, then any module will not work, etc.

Perhaps something was simplified, but now it is necessary to take into account in more detail, respectively, someone must collect information according to certain rules.

This list can be long, look at the specific case of your project. Creation of units and services necessary for the functioning of the system;

The timing and procedure for staffing and staff training We have already talked about this earlier. Perhaps the system is being developed for a new structure or type of activity that did not exist before. If there is no appropriate personnel, and even trained, then the system will not work, no matter how competently it is not built.

Section 8. Documentation requirements

Consider how the user manuals will be presented.

Perhaps the Customer has accepted corporate standards, so it is necessary to refer to them.

Ignoring documentation requirements very often leads to the most unexpected consequences on projects. For example, everything is done and everything works. Users also know how to work. We did not agree or talk about the documentation at all. And suddenly, when the work is handed over, one of the top managers of the Customer, who did not even participate in the project, but participates in the acceptance of the work, asks you: "Where are the user manuals?" And he begins to convince you that it was not necessary to agree on the availability of user manuals, this "by itself" is supposedly implied. And that's all, he doesn't want to take your job. At whose expense will you develop guidelines? Many teams have already fallen on this hook.

Section 9. Development sources

Recommendations according to GOST	What to do about it in practice
Documents and information materials (feasibility study, reports on completed research works, information materials for domestic, foreign analogue systems, etc.), on the basis of which the TK was developed and which should be used when creating the system, should be listed.	To be honest, this is closer to the lyrics. Especially when they talk about economic effect and other things that are practically impossible to count objectively. Those. it is possible of course, it will be rather on paper, purely theoretically.

Therefore, it is better to simply refer to the survey report, the requirements of the key persons.

And so, we have considered all the sections that can be included in the Terms of Reference. “May” and not “Obligated” precisely because any document must be developed to achieve a result. Therefore, if it is obvious to you that some separate section will not bring you closer to the result, then you do not need it and do not need to waste time on it.

But without the main thing: functional requirements, not a single technical assignment is complete. I want to note that in practice, such Terms of Reference are encountered, and how! There are figures who will be able to dilute water in all sections, describe the general requirements in general terms, and the document turns out to be very weighty, and there are many clever words in it, and even the Customer may like it (i.e. he will approve it). But working on it may not work, i.e. there is little practical benefit from it. In most cases, such documents are born when you need to get a lot of money specifically for the Terms of Reference, and it must be done quickly and without going into details. And especially if it is known that things will not go further, or completely different people will do it. In general, just for the development of the budget, especially the state.

In the second article, we will only talk about Section 4 "System Requirements", and specifically, we will formulate the requirements for reasons of clarity, specificity and testability.

Why requirements should be clear, specific, and testable.

Because practice shows: at first, most of the technical specifications that are developed by specialists either turn out to be not in demand (do not correspond to reality), or become a problem for the one who has to implement, because The customer begins to manipulate non-specific terms and requirements. I will give a few examples of what phrases were encountered, what this led to, and then I will try to give recommendations on how to avoid such problems.

Requirement type

Wrong wording

Development and approval of technical specifications for the creation of an AU - stage 3.1 of the technical specifications stage. Edition of 20.06.2018.

Development and approval of technical specifications for the creation of an AU

Created on 18.05.2018 11:24:34

From the explanatory dictionary

Development is construction, creation, approval - giving a document legal (legal) force. In the current one, this is filling out structural TK and obtaining an approving signature on its title page. And an affirmative seal imprint.

Terms and Definitions

Approval - An official certificate of an authorized official or that developed is put into effect. The certificate can be fixed on the approved document by direct or by reference to another document containing the approval decision (act, protocol, letter, etc.) [from clause 1.4.74 R 50-605-80-93].

Requirements of standards

On the title page, the customer, developer and approving organizations are placed, which are affixed with the official seal. If necessary, the title page is drawn up on several pages. Signatures of the developers of technical specifications for the AU and officials participating in the approval and consideration of the draft TK at the NPP are placed on the last sheet. The form of the title page of the TK at the AU is given in. The form of the last sheet of TK for the AU is given in [from clause 3.4 of GOST 34.602-89].

On 3.1 "Development and approval of technical specifications for the creation of the nuclear power plant" carry out the development, and, if necessary, technical specifications for parts of the nuclear power plant [from clause 7 of Appendix. 1 GOST 34.601-90].

Problem

The fact is that when there is a specific format, as well as a clear and intelligible definition of a term, then all the manipulations and substitutions of it for their own briefs, prototypes, questionnaires, descriptions and just incoming applications on the fly look, at least, unprofessional. Therefore, we begin with a scientific definition of our concept:

Terms of Reference - an initial document for the design of a technical object (product). The TK establishes the main purpose of the developed object, its technical characteristics, quality indicators and technical and economic requirements, instructions for performing the necessary stages of creating documentation (design, technological, software, etc.) and its composition, as well as special requirements. The terms of reference is a legal document - as an appendix is included in the contract between the customer and the contractor for carrying out design work and is its basis: it determines the procedure and conditions of work, including the goal, objectives, principles, expected results and deadlines. That is, there must be objective criteria by which it is possible to determine whether a particular item of work has been completed or not. All changes, additions and clarifications of the wording of the TK must be agreed with the customer and approved by him. This is also necessary because in the event that in the process of solving the design problem, inaccuracies or inaccuracies of the initial data are found, it becomes necessary to determine the degree of guilt of each of the parties participating in the development, the distribution of losses incurred in this connection. Terms of reference as a term in the field information technologies Is legally significant document containing comprehensive information necessary for setting tasks for contractors for the development, implementation or integration of a software product, information system, website, portal or other IT service.

We translate into an understandable language

1) Technical Assignment - it sets a task. This means that it should go before the prototype, sketch, test, design project, because any mindmap, data flow diagram, architecture is already the performance of a certain task, this is the answer to a question. And before the question itself has not yet been asked, formulated and signed by all parties - any answer will be a priori wrong, right? So, the beginning of any work on any project is a problem statement, and not a frantic search for sketches of a dozen options for its solution.

2) Actually, a new one logically follows from the first point - the text of the TK itself must begin with the chapter "Goals and Objectives", which clearly formulates what business goals are pursued by this whole next attempt to increase entropy in the world. An aimless task that does not solve any problems, does not achieve anything and is done “out of boredom” - it is not officially considered a Technical Task, and from that moment it is in the status of “ordinary piece of paper”.

3) How do you understand whether the proposed design concept or an interactive prototype, or even a ready-to-use website, solves the above business problem? There is nothing to be done, we will have to return to the definition again: “determines ... the expected results and the time frame for implementation. That is, there must be objective criteria by which it is possible to determine whether a particular item of work has been completed or not. " That is, there can be no TK without clear measurable indicators in rubles, seconds, ton-kilometers or degrees Celsius. A brief can, or a prototype, or any other absurd piece of paper, but not a Technical Assignment.

From this we conclude that in this TK there must necessarily be a chapter "Procedure for acceptance and evaluation", when these same indicators are taken, measured, and the parties either shake hands or send the project for rework.

4) The technical assignment must necessarily agree with general business plan customer, with his business development strategy and market segment analysis. It is all this that will allow you to set the right goals, derive accurate metrics, according to which you can then adequately conduct the acceptance of the finished information product. The customer's lack of a business plan automatically guarantees the unprofessional execution of the Terms of Reference.

Does an outsourced studio know the business goals and measurable performance of the business better than the owner? Obviously not, which means that the correct TK should be written by the representatives of the Customer, and not by the employees of the Contractor. It's absurd when a performer sets a task for himself, then he comes up with ways to evaluate it, and in the end he gives himself a final mark for the work done. Ideally, such "initiative" should not be, although in practice this is exactly what happens everywhere, as a result of which the Technical Assignment does not provide the help you need project, too often being essentially a fictitious document. Do not do like this.

5) Each amendment to the finished TK should cost money. It is impossible to edit the "Constitution of your project" for free and endlessly just because one of the parties changed its mind, did not get enough sleep, suddenly decided to save money, etc. The price of each change in the TK should also be clearly stated in advance in the relevant chapter.

By the way, in theory, every design change or changes to the list of pages or functions should have a clear price, which is paid in advance, before the start of this change. Personally, I propose to estimate any revision of the approved TK at 30% of the total project budget, but you can do otherwise.

Is it worth mentioning that the terms of reference simply need to indicate in advance the timing and total budget for development, as well as a list of all existing resources and restrictions? - No, it will be too obvious.

So: What are we doing? For what? How do we understand what we have done? How much does each pivot cost? - the answers to all these questions written on a piece of paper are the "silver bullet" capable of pulling out even the most failed project.

Control questions

And here I will list the answers to the most frequently asked questions from customers:

1) So, can there be an official GOST for writing Technical Assignments? - Yes, even a few.

2) What, the Technical Assignment does not include a description of the required pages, the number of buttons, used libraries, guidelines, etc.? - In the TK itself, there is no, but you can put all this in the Appendices, of course, adjusting all this with the above goals, restrictions and ways of further assessing the achieved result. Post at least all future content, at least a description of typical characters - but not instead of a clear statement of the problem, but after it.

3) So maybe I don’t need it? - Perhaps today thousands of sites are made without TK at all, just as thousands of people in the world live beautifully, being blind from birth. But if you want to see where you are going in general, make decisions consciously and independently evaluate the results obtained, then you cannot do without TK.

4) So you and Wikipedia write that the technical specification is created by the customer. But I do not know how / I have no time / I just do not want to do it myself. How to be? - To hand over the development of the technical specification to a third party who is quite familiar with your business, its tasks, target audience and needs, and at the same time thoroughly aware of all stages of web development. This third party will become a kind of "web notary", that is, the guarantor that the contractor will not underestimate the indicators you need or delay the deadlines, and that the customer will set achievable metrics and at the final acceptance will not subjectively evaluate the created product, changing the previously recorded requirements.

5) And what if the TK is a legal document, then I can sue the outsourcer, not pay him, force him to redo everything for the tenth time? - If the document is drawn up correctly, the goals and methodology for assessing their achievement are indicated; if the document is signed by the parties and is mentioned in the Agreement (the Technical Specification itself is not an agreement), then of course you can. But with the usual brief, prototypes, art-creative layout, Safe deal on FL is no longer there.

6) I am told that the work will be carried out according to some sort of Scrum, or Ajail; which means that I no longer need archaic TK. This is true? - Judge for yourself: they call you an incomprehensible word, obviously something disguising, and now, on the basis of an unfamiliar term, they offer you to abandon a legally literate document filled with goals and metrics. Agile itself cannot set any goals like “to achieve at least 10,000 visits by the end of the year”, or “to reach more than 25 orders from the site in a month”, it cannot set, it’s just a way of holding meetings and reorganizing negligent employees. Think a few times: "Isn't it being spurred on to you?" In fact, professional TK cannot harm any newfangled Scrum, but help is a must.

Technical task (hereinafter referred to as TK) - this document serves as a foundation, a starting point for the creation of any project or product. TK indicates the main criteria, principles and purpose of the object. Technical and software requirements, quantitative and qualitative indicators, design requirements and compliance with GOST standards and much more can be specified in the TK.

TK is legal document, which is part of the contract (usually as an annex) between the customer and the contractor for the performance of certain works, production or rendering of services. In the terms of reference, the tasks, goals, principles, terms, procedure and expected results of all work are described most fully. As a result, it is the TK that serves as a document according to which the conformity of the work performed for each item is assessed.

Changes to any of the points of the technical assignment must go through the process of agreement with the customer and are approved by him. This is dictated by the fact that if inaccuracies, deviations or errors in the initial data arise in the course of work, one or another party may incur losses, and it is the TK that will regulate the degree of guilt of one or another party.

Initially, the TK is prepared and provided by the customer, but often the customer shifts this task to the contractor, providing only a number of technical conditions and wishes in a consumer language, far from professional language and subject terminology. It is necessary to avoid ambiguity and ambiguous interpretation of the TOR clauses, this may entail uncertainty for all participants and will not allow an objective assessment of the quality of the work done. Also, the contractor must be aware that the customer may not have a full understanding and knowledge of special requirements, which in no way relieves the contractor of the responsibility and obligation to comply with all norms and requirements of supervisory authorities, regardless of whether they were in the TOR or not. Thus, both the customer and the contractor are responsible for setting tasks in the TOR and the quality of the result.

In any case, the more painstaking and accurate the TOR will be drawn up and agreed upon, the fewer degrees of freedom and loopholes will remain for the contractor to perform his work in bad faith. Depending on how competently the terms of reference will be drawn up, the quality and speed of work will depend, this statement also works in the opposite direction.

A competently drafted technical specification increases the chances of a successful completion of a future project by 50%, and the time invested in the development of a technical specification is one of the best investments that a customer can make during the project period. Therefore, the preparation of the technical specification is entrusted to the most experienced and qualified specialists, because correcting any mistake made at the design stage of the technical specification can be very expensive after the conclusion of the contract, and in some cases even put an end to the project as a whole.

The Terms of Reference serves as a solid bridge of understanding between the customer and the contractor, helping to understand:

To the customer:

What exactly would he like to receive at the exit, relying on his current resources and capabilities;
Carry out internal coordination of requests between structural divisions;
Monitor the compliance of the work performed by the contractor.

For the contractor:

Understand the essence and details of the task;
Make plans for the execution of work;
Exclude additional work not described in the terms of reference, or require additional funding for this.

To all parties:

Understand the essence and appearance of the final product or service;
Check the work performed, conduct acceptance testing;
Minimize the number of errors and inaccuracies in the change process.

It might be helpful to read: