The composition and content of the terms of reference. How to write a technical task yourself

How to buy what you need without violating antitrust laws? The key to success in this business is a well-written technical task. Read in the article what implicit violations are committed by customers.

In the general case, when drawing up a procurement specification, the customer must monitor the complete impersonality of the described object, that is, it should not contain any requirements and even hints at specific trademarks, manufacturers, or even the country of origin of the goods.

In fact, it is quite difficult to correctly prepare a description of the procurement object, the terms of reference for 44-FZ, without special knowledge in a particular area. Some customers even create a procurement for the provision of services for the preparation of terms of reference. But it is also quite realistic to do this on your own if you carefully study the requirements for the objects of procurement, compare them with your needs and strictly follow the rules for describing the object of procurement according to 44-FZ.

It must be borne in mind that some characteristics are encrypted in the labeling of products. For example, the terms of reference provide for the material "paving slabs" marked "Classico 1KO.4", the terms of reference do not set any requirements for the thickness of the tile. According to the decoding of the marking, its thickness is 4 cm (the last digit of the marking indicates the thickness in cm). However, during the execution of the contact, it turned out that a 6 cm thick tile was required. The load that it can withstand depends on the thickness of the tile. Illiterately drafted terms of reference led to the purchase of material that does not meet the necessary requirements. Therefore, it is necessary to carefully check the labeling of all materials in the terms of reference and indicate all the basic, important requirements for materials.

Desirable do not copy product descriptions from different sites. The information in the description may not be reliable and it turns out that not a single product meets the stated requirements. There is a good chance that only one product fits this description. This can be regarded as a restriction of competition.

All performance requirements should not be ambiguous. Otherwise, there will be a lot of requests for clarification. It often happens that with a lot of requests, the customer cannot have time to respond to them on the merits in a timely manner and there may not be time to adjust the terms of reference. Based on this, sometimes the customer in the explanation indicates that it is enough to submit only consent, without indicating the materials. In turn, this reduces the chances of purchasing exactly what is needed, since it is not clear from the application what materials will be used in the execution of the work.

It is better to write instructions for preparing an application after describing the requirements for technical characteristics. The instruction should not confuse the participant, but specify the requirements of the terms of reference, in order to avoid many requests from the participants. The inconsistency of the terms of reference with the instructions, which creates an obstacle to the preparation of the application, may provoke the submission of complaints to the OFAS by potential procurement participants.

What other requirements are important to specify in the terms of reference:

• By the warranty period of goods, work, services and (or) the scope of providing guarantees of their quality. The customer in the terms of reference must establish a warranty period not less than the manufacturer's warranty period.
• To the warranty service of the goods.
• To the cost of operating the product.
• Compulsory installation and commissioning of the goods.
• To the training of persons involved in the use and maintenance of the goods.

Main Rules

1. When preparing procurement documentation, pay attention to the codes of the All-Russian Product Classifier (OKPD2) related to the object of procurement. It is necessary that the code used matches the specific procurement object.
2. In addition to the provisions of 44-FZ, when developing the terms of reference, one should also keep in mind the requirements of other legal acts, antimonopoly authorities, technical norms and standards (GOST, TU, SNiP, etc.).
3. The goods and materials requested by the customer in the terms of reference must correspond to the object of the purchase and the estimate documentation (if any).
4. When purchasing for a construction contract, it is also necessary to attach a defective statement, an estimate, and in the case of capital construction (reconstruction, overhaul), project documentation must also be attached.
5. Indicate that you want to purchase new goods and materials (i.e. they have not been used, have not been repaired, restored, have not been restored). Otherwise, the customer may receive used goods.

Common Questions

Question: Is it possible to prescribe the indication "original" for the supply of spare parts?
Answer: It is possible if we are talking about a product that is under warranty, or there is a need to ensure the interaction of such goods with goods used by the customer, as well as in the case of the purchase of spare parts and consumables for machinery and equipment.

Question: Is it obligatory to prescribe the procurement identification code in the terms of reference?
Answer: The procurement identification code is indicated in the procurement plan, schedule, notice of procurement, invitation to participate in the determination of the supplier (contractor, performer) carried out by a closed method, procurement documentation, in the contract, as well as in other documents provided for by this Federal Law . It is not necessary to specify it in the TOR.

Question: It is necessary to purchase a device for scientific research to an existing system of 3 devices from one manufacturer. It is necessary to completely combine everything in the work. An equivalent is not desirable. Can I not write the equivalent and indicate the manufacturer? The system is highly customizable and expensive.
Answer: If your case fits under “... except in cases of incompatibility of goods on which other trademarks are placed, and the need to ensure the interaction of such goods with goods used by the customer ...) - you can, in other cases - you can’t.

Question: Is it possible to indicate narrow indicators in the terms of reference for the overhaul, for example, the color of the walls with a specific color scheme, attach an example of a plasterboard composition on the ceiling, a specific collection of tiles without an equivalent, referring to aesthetic preferences?
Answer: When forming the terms of reference, customers must be guided by the requirements of Article 33 of Law No. 44-FZ. The color of the walls is the choice of the customer, this is his need, not limiting the number of suppliers. A layout, a sketch of a plasterboard composition on the ceiling is also the customer's need, all performers will be able to repeat the layout given in the documentation. A collection of tiles without an equivalent is a violation of paragraph 1 of Article 33 of Law No. 44-FZ: “The procurement documentation may contain an indication of trademarks if, in the performance of work, the provision of services, it is supposed to use goods, the supply of which is not the subject of the contract. At the same time, a prerequisite is the inclusion of the words “or equivalent” in the description of the procurement object.

The terms of reference are important for both the contractor and the client. It helps the contractor to better understand what the customer wants, to insure against sudden "wants" on the part of the client, to speed up the work on the task. To the client - to tell exactly what he wants, to simplify quality control, to get the exact cost of the service. We will tell you how to properly draw up a TOR and what to do with it later.

What is a technical task

Terms of Reference - a document that reflects all the requirements for a future product. It describes all the technical requirements. Usually, TK is compiled in the form of a text document, rarely in other formats.

TK is used by all website developers. For typesetters, programmers, designers, it helps to better understand the requirements of the client and make a resource that meets his expectations. In addition, TK is used in all other areas, for example - in:

• application development;
• house design;
• writing texts and others.

If you work according to the terms of reference, the risk of disputes and protracted litigation is minimized.

How to draw up a technical task: the structure of the technical specifications for the site

Before starting work:

• Decide who will write the terms of reference
• Explain terms
• Avoid subjective terms

At first glance, it seems that the technical specifications for the site should be made by the client, because he orders a resource and makes demands on it. In fact, both should participate in the process: the client voices the requirements, and the performer writes them down specifically, accurately and clearly. For example, the client says that he wants a site adapted to all users, and the developer prescribes adaptability requirements for 4 available sizes - PCs, laptops, tablets, smartphones.

Definition of terms is very important. It is advisable to explain all highly specialized terms at the very beginning - clients do not always know what a basement (footer), CMS, fish is. The simpler and clearer the explanations are, the clearer the TOR will be for both parties.

Subjective terms can cause unnecessary controversy. Do not write "design should be beautiful" - the concept of beauty is different for everyone. The same applies to the quality adjectives “convenient”, “easy to use”, “large”. Use specific numbers and parameters: for example, describe the color scheme or the arrangement of elements.

The structure of the technical task can be any. As an example, we offer a simple structure of TOR for the site.

Describe the site

Tell us what type of site you need, who will use it, what it is created for. For example, write that you need an online store, a landing page for selling a product, or a business card site with 10 pages. Indicate the approximate number of pages if you do not know the exact number.

If the project has a specific target audience, describe it. This will help create a resource that will appeal to customers - for example, using appropriate language in articles or design that appeals to young people or older people.

Tell me about the structure

Without an understanding of the structure, it is impossible to develop a normal site. Describe what pages will be on the site, and show their nesting levels. You can do this in different ways:

• scheme
• table
• list

The main thing is that in the end it is clear which pages will be located in the menu, where they will lead, which parent page each section has. We recommend using flowcharts - they are simpler and easier to read than lists and tables, they help to evaluate the entire structure of the site in a few seconds.

Describe what will be on each page

Tell us how you see the pages of the site. It is desirable to do this in a prototype format in order to clearly demonstrate the location of each element. You can also describe the requirements with a list, for example, tell what will be in the header of the site, where the feedback form is located, what will be in the free side column.

If all pages of the site are approximately similar - for example, you plan to create a business card site, you can get by with two prototypes: for the main page and other sections. If there are several groups of similar pages - for example, sections in the catalog of an online store, a blog with articles and a description of delivery / assembly / installation services, it is better to make your own prototype for each group.

Make design demands

If there is a developed layout, great - you can simply insert it into the terms of reference. If not, you need to describe the requirements for colors, used images, logos. For example:

• Specify which corporate colors can be used in design, and which shades are absolutely not
• Provide a logo, which must be present in the header of the site
• Specify the fonts that you would like to use for the design of pages, menus, footers, content

If there are no clear requirements - that is, the client himself cannot formulate his vision of the site, you can offer him several standard layouts to choose from or develop a layout individually, and then agree on it. This must be done before the approval of the TOR, otherwise the difference in tastes can significantly delay the project.

Describe the requirements for tools, code, hosting, domain

This is necessary in order to know in advance which tools you can work with and which ones you can’t. Describe in a separate block:

• Which site should be on - WordPress, Joomla, Modex and so on
• What programming language can be used - PHP, JavaScript, HTML, others
• On what hosting and in what domain zone the site should be located, what domain name can be used
• What software platform can be used - .NET, OpenGL, DirectX
• And so on

If the client does not understand anything in the terms used, explain how WordPress differs from Modex, PHP from HTML, a domain in the .ru zone from a domain in the .com zone. Together, make the requirements so that they suit the client.

Specify site requirements

By default, the site should work for users of all devices, in different browsers, withstand hacker attacks and stay up when 1000 users visit at the same time. But it's better to write it in a separate block. Specify:

• Acceptable site loading speed for you or a standard value - 1–5 seconds
• Cross-browser compatibility - describe in which browsers the site should open
• Responsiveness - specify the screen sizes that the design should adapt to and the devices used
• Load resistance - how many people should be on the site at the same time so that it does not "lay down"
• Resilience to hacker and dDos attacks: the site must withstand small attacks

Write out scenarios for the site

Describe how the user should interact with the site, and what actions should occur on the resource in response. This can be done in the form of a simple numbered list or a branched algorithm if users have a choice between actions. If there are many interactive services, write a script for each of them.

Find out who is doing the content.

Some developers write texts themselves, someone orders them from copywriters, someone uses fish. Immediately clarify whether the provision of content is included in the development service. If so, you can immediately prescribe additional requirements, for example, to:

• - not less than 95% according to Advego, Text.ru, Content.Watch
• Nausea (spamming) - no more than 10% according to Advego or 65% according to Text.ru
• Points for Glavred - at least 6.5 or 7 points

Of course, different services are not a panacea, but they minimize the risk that it will be "watery" or spammed. In addition, this is how accurate criteria for assessing the quality of texts appear.

Specify terms

This is often forgotten. Most of the terms of reference must specify the terms, otherwise the development may drag on for several months, half a year, years. Do not use incorrect wording - for example, "in a month." Write the exact date: December 1, 2018, for example.

Life hack: it is better to draw up the terms of reference as an annex to the cooperation agreement. So you fix all the requirements for the development of the site, and in case of disputes you can win the case in court.

Remember: in each TK there should be several main blocks:

• Goals and objectives - about why you created the TK in general, what you want to do with the product
• What should be the product - a description in general terms
• Technical requirements - the area of ​​​​the house, the amount of text, the functionality of the application, and so on
• Deadlines - they are important to eliminate disputes.

An example of drawing up a technical specification for software

We need to create software. Technical requirements - below.

Description: a program for searching articles by keyword on all authoritative sites, you need to manually enter the addresses of authoritative sites.

What the software should do:after entering a keyword, it finds articles on sites that are entered in advance as authoritative sources, displays a list of matches in this format:

• Link
• Article title
• Lead paragraph

If there are more than 10 matches, you need to divide into pages - 10 on each.

Technical requirements:programming language - any, it doesn't matter. The main thing is that the program can then be finalized and brought out as an online service. Ideally, the service should search for 10 seconds.

Timing: until 15.09.2018.

Naturally, this TOR can be improved - we provided it as an example. And how do you think, how can the terms of reference be improved so that it becomes even clearer, simpler, more convenient?

In life, it often happens that a person cannot explain what he wants, even in everyday things. When it comes to explaining your “wants” to a programmer, a person simply falls into a stupor.

Ideally, the TK should be drawn up by the customer - only he knows what he needs. But in practice, due to the low competence of the customer in the field of 1C, this often has to be done by the contractor. The customer verbally voices his needs, and the programmer (consultant) formalizes this in writing.

Why is a specification needed?

Any, ideally, should be accompanied by a technical task. This is, firstly, a clear definition of the task, deadlines and method of implementation. Secondly, it is a document with the help of which all disputes in the future are resolved. It is, of course, up to you whether to write a technical specification or not; for me personally, a technical specification makes it easier to work and communicate with a client.

Get 267 1C video lessons for free:

What should the terms of reference contain?

Those. The assignment must include:

• target- the task that we will solve by implementing this TOR;
• description- a summary of upcoming improvements;
• implementation method- a detailed description of the methods for solving the goal. At this point, it is necessary to describe all the nuances of the task in the programming language: what, we create / edit, how the interface should look, etc. If you don't know the "programming language", but "heard something", it's better not to try to write in a technical language - it turns out to be quite fun. The description should be unambiguous and not cause questions. It may also contain an example of the implementation of a similar solution in another area;
• performance appraisal- a very important point, a description of labor costs.

There are also state standards for writing technical specifications - GOSTs. In practice, they are rarely used anywhere, but it happens that the customer insists on this.

From experience, when handing over work, situations like “we told you then…” very often arise, which is not very pleasant, and often you have to redo the work entirely. Therefore, a well-written TOR greatly facilitates the lives of both parties.

Examples and samples of TK for 1C

A small selection that I found freely available on the net. Starting from the simplest and most accessible, ending with fairly complex documents.

Many companies are not ready to involve contractors at the stage of writing the terms of reference, believing that each contractor will write a document understandable only to his employees, in fact guaranteeing himself a privileged position in the competition/tender.

This is partly true, but in many cases this phenomenon is connected not so much with the mercantile interests of contractors, but with differences in the approach to the implementation of this document.

The definition of the terms of reference on Wikipedia, in particular, states that this is “a document containing the customer’s requirements for the object of procurement, defining the conditions and procedure for its implementation to meet state or municipal needs, in accordance with which the delivery of goods, performance of work, provision of services and their acceptance.

In addition, there are a number of GOSTs, for example, 19.201-78, which spell out what and in what form should be contained in such a document.

However, as practice shows, the coveted abbreviation "TK" refers to documents that are completely different in essence, content, design and detail. Unfortunately, many customers are sure that after writing a couple of pages of requirements for a future system, they will receive from us an accurate estimate (with a maximum delta of 10-20%) with a work schedule. Once again, when I receive in the mail “TK, according to which by tomorrow it is necessary to evaluate and send the CP”, I always mentally prepare to see the next creation in the style of “the system must exchange all the necessary information with the site”.

At one time, in the department where I worked, the following division was adopted: the Terms of Reference was a document describing the requirements for the system in a language understandable to business users, and the Technical Design was a document drawn up on the basis of the Terms of Reference, more detailed, describing in detail all the functions , but already in a language understandable mainly to developers.

To me, this characterization, although not correct from a formal point of view, seems to be very fair for small companies that do not have extra budgets, but there are tasks that require urgent solutions. The main thing for them is the compilation of technical specifications by their employees and its distribution, for example, to several franchisee firms. And it is natural that no one will write a huge sheet containing an incredible amount of technical information.

So how to make a technical specification, according to which in the end it will turn out exactly what was laid down by its author (s), and not what “the typical configuration functionality can do”?

I will not describe the fundamental requirements for the structure of the document, such as: the objectives of the project should be described in the TOR, functional requirements should be contained, there should be a list of abbreviations and a table of contents, everything should be written in the most simple and short phrases, etc. I think this is known to everyone who has read the technical specifications at least a few times.

The documents that I had to deal with, and on the basis of which the results were obtained as close as possible to the idea, had the following properties:

1. TK as an instruction. The document in its structure resembles a user manual, where it is written step by step in which case what actions the user needs to perform in order to obtain the desired result. Those. these were documents without a continuous list of required functions, but with a logical breakdown into separate processes with a description of their specifics

2. More visualization. The more layouts/screenshots/mockups/flowcharts a document contains, the less likely it is to get a system that seems to perform the necessary functions, but has a completely different logic/design/interface.

3. usability. From the two previous points, there is a simple consequence - the clear logic of work and the maximum visualization of the future system will eventually help to put in the TOR the required number of notes / points regarding the usability of the system. For systems that low-skilled employees work with, this can be a decisive factor in the success of the project (however, this parameter is also extremely important for top management who does not want to deal with "these accounting programs"). For example, the TOR for a retail system did not specify that the search for an article should take no more than three seconds. If the system were implemented through a typical configuration search, then this could lead to critical situations in real operation, because taking into account the number of items, this search took up to 30 seconds, which is unacceptable when working with retail customers, where every second counts.

4. Links to popular solutions. Often, for everyone, for example, the company's sales managers, the phrase "transactional functionality" means about the same thing, but for the contractor's employees, this phrase means absolutely nothing. But add a couple of words to this phrase, and from the option “deal card similar to that in Bitrix24 (or 1C: CRM)”, it is already clear what the Customer expects from this very card.

5. Primary Feedback. I repeat once again - for the successful implementation of the TK, it is not necessary to write it in accordance with GOST. There is no need to write a document intended only for technical specialists. The terms of reference, first of all, should be clear to the colleagues of its originator, and then to those who will implement it. It is critical to get positive feedback from fellow business users before forwarding a document to potential contractors or internal development. A document that is extremely clear to one person, but not understandable even to the closest environment, has no chance of successful implementation.

Of course, there are different points of view on the requirements for the preparation of TOR. However, in the absence of the proper amount of time, resources and competencies, it is the terms of reference written in the most understandable language for business users that has the above properties that will have the maximum chances for successful implementation.

Don't want to be completely disappointed when accepting a site from a developer? Then read this article carefully!

But maybe it's not his fault? After all, not only the performer, but also the customer is responsible for the result of any delegation.

To get the maximum desired result, you need to know how to correctly draw up a technical task for creating a website.

WHY DO YOU NEED THE TASK?

• Contractor a competent technical specification for the development of the site will help to estimate in advance the amount of work, its complexity and cost. To understand whether he will cope with such a task on his own, or whether it is worth taking assistants. And then do exactly what the customer expects from him.
• Customer the terms of reference gives confidence that he has documented his wishes for the future site, clearly outlined the deadlines that the contractor must meet, prescribed the requirements for the site. And if the result is unsatisfactory, you can make a valid claim: "Does not meet the TOR!"

WHAT DO THEY WRITE IN THE TERMS OF REFERENCE?

The assignment addresses the following questions:

• Why and for whom is the site created?
• What will it be filled with?
• How will this all function?
• Who will work on the project and how, who is responsible for what?
• What will be the output?

MAIN SECTIONS OF THE TERMS OF REFERENCE FOR THE DEVELOPMENT OF THE SITE

1. Information about the customer, that is, about you

Provide as much detail as possible. Specify all sources where the developer can get the missing data. These can be leaflets, posters, electronic materials, links, contacts of people who can be asked questions.

2. Information about the project

What will it be: a business card site, a blog, an online store, a corporate portal, an electronic library?

3. Target audience of the site

Describe your target audience, tell what they need and how they can be interested.

4. Goals and tasks that the site should solve for the customer and for the audience

You must clearly understand why you need a website. To enhance the image? For direct sales? For news? Do you want to convert visitors into subscribers with your website? Do you want to make a resource to attract potential partners?

Specify the direct purpose of your site.

Think carefully about the individual tasks of a web resource. For example, it should provide up-to-date information about market news, showcase your products, allow visitors to contact you directly from the pages of the site, and so on.

5. Project framework (main functionality)

The site can have a huge number of functions: a user registration form, feedback, order buttons, a delivery calendar, a news feed, a product catalog with the ability to go to the basket, a built-in mailing script, closed sections for customers - whatever! Each of these functions in the terms of reference for the development of your site should be spelled out in the most detailed way.

Thus, the "Project Scope" section is something like a table of contents, listing functions without their meticulous description. You will need this section at the stage of searching for an artist. It will allow the potential creator of your site to see the big picture and give an approximate price, while you systematize your wishes for functionality.

6. Structure (map) of the site

The next paragraph of the TOR for the site will tell the contractor which pages will be on your site, which sections and subsections, how they will be connected to each other, how they will be displayed in the site menu.

Structure is easier to draw than to describe. In graphical form, it is easier to think about the relationship between areas of the site.

7. Individual pages

While you are drawing the sitemap, each page is just a square. But the performer needs to understand what and in what order will be located on this square (recall the examples of tables at the beginning of the article). What information blocks will there be? Will there be menus, sidebars on each page? (separate block with navigation), footer (lower block)? Do you want to see banners, pictures on the page? Will they be static or moving?

The more detailed you describe each element of each page of the future resource, the closer the output result will be to your ideas about the site.

8. Site design requirements

Decide on the color scheme, tell us what colors you prefer. Provide the developer with the available materials: logo, banners, color codes… Show him examples of working sites on the Internet that you like and want something similar. Tell us what colors you prefer. For example, you want to make a website dedicated to women's training, the designer will make it pink, but you like orange. A general description of the wishes will help you find a compromise between your vision and the professional look of the designer.

9. Working functionality of the site

Describe in detail what functionality you want to see on the site. Give the performer as much information as possible. Remember that he does not have the gift of telepathy and may not guess what you want to get when you write in the terms of reference for the site "subscription form" or "calendar".

What form? For what? What items should be in it? How does she look? The performer may not guess these nuances, in the end you will get something completely different from what you wanted. The money has been paid, the project complies with the TOR (you wrote "calendar"- here it is), and you will have to be content with what happened, although this is not at all what you wanted, or overpay for changes.

10. Description of content

If you order content simultaneously with the creation of the site, and you have one contractor (for example, an agency), the description of the content is a separate TOR for the copywriter. If you are going to create content yourself or order from another artist, the site developer should still have an idea of ​​what will be placed in which section and how it will look like. Where is the text, where is the video, how the pictures will be designed, whether the preview of the articles is needed, and what it will be, and so on.

11. Technical requirements

A difficult point for those who understand little in site building.

If you do not understand, turn on the logic.

For example, your site should:

• look equally good on monitors of different widths (responsive design);
• be SEO optimized for promotion;
• be able to resist viruses;
• have built-in seo functionality and so on.

Write only about what you are sure of, or consult with a specialist. It is better to consult in advance than to overpay for improvements later.

If you decide to contact us and you do not have your own terms of reference, you can download and fill out ours.