Development of technical specifications. LLC "Technical Documentation"

So, the technical specification, abbreviated as TK, has been serving for quite some time to formally describe what we actually want to see in the final product. The technical specifications for developing a web resource are no exception. At its core, this is the basis for website development. It specifies all provisions directly or indirectly related to the site.

The technical specification, as a rule, is attached to the main contract for the creation of a web resource, since it includes a complete list of all works that must be performed in order to eliminate possible disputes between the client and the contractor, which, as is known, still arise from time to time.

There is an opinion among some people, “beaten” by experience, that the TK should be written as if you will be present at the trial with it and use it as a defense. This may be an extreme, but nevertheless, it’s a reason to think again about the importance of a well-written and detailed technical specification .

In terms of its volume, the technical specification can be a fairly large document. Web companies often offer assistance in drawing up technical specifications as a separate service, usually 10-20% of the cost of the entire website development.

The preparation of technical specifications is usually carried out by the project manager or directly by the programmer with the participation of the customer, who provides basic information.

How more detailed technical specifications (within reasonable limits, of course), the better for both parties - both the client and the performer of the work. Both win, so to speak:
— the client will be sure that everything he has planned in the project is clearly spelled out and must be implemented in accordance with the technical specifications.
- the performer is insured against many small or large adjustments and modifications, again based on the same technical specifications.

There is an opinion that you can do without technical specifications. For example, one of the arguments is that the task is too creative to fit into the terms of reference. This opinion likely masks a lack of experience and professionalism in the field. I think this opinion is wrong, since almost everything in website building can be formalized and presented in technical specifications and compiling it is rather a matter of experience.

• The simple truth is that the more complex the project, the more detailed the technical specifications should be.
• Among the possible options is the technical specification, which describes the main pages of the interface with the entire set of elements on it and a description of their behavior. Or it could be a laconic description of several pages for a business card website, etc.
• The technical specifications for the programmer should not mention the design of elements or express design wishes. The task is still for the programmer..
• Descriptions of tasks in individual parts of the technical specifications should be limited. What does it mean? It is necessary to clearly indicate the end of a specific task item. The technical specifications should not contain abstract phrases like “there should be easy navigation.” These are all subjective signs - it’s convenient for some, it’s not convenient for others, and it can be difficult to understand whether this point has been fulfilled due to the vagueness of the provisions of the technical specifications. That is, it needs to be controlled.
• For simple sites where you need to describe some functional module, so as not to reinvent the wheel, you need to analyze sites with similar functionality, so to speak, conduct an analysis of competitors; save hyperlinks to pages with the required interface elements and functions, and include them in the statement of work with extended explanations of what exactly to do. It is also necessary to take screenshots from the necessary pages in case the site becomes unavailable after a while. At the same time, you can put your own marks on the images (fortunately, there are now a lot of tools for this - Clip2net, Joxi, Awesome Screenshot and others).
• If there is no design for the pages or it is not so important within the framework of some project, say, the customer decided to save on the design of the site’s admin panel, in this case the programmer may well use prototypes.

Reference

A prototype is a graphical layout of interface elements. Roughly speaking, a page drawn in a special program with all the elements.

There is a lot of software for drawing prototypes, including both desktop applications and online services, as well as extensions for browsers with more modest capabilities. Software with both free and paid licenses.

Popular ones include:
— among the free ones: iPlotz, MockFlow, Mockup Builder, Cacoo;
— among paid ones: Creately, ProtoShare, Adobe Fireworks, Axure. In general, there are many possibilities - choose, master, draw...

General structure of technical specifications. From abstraction to specificity

One of the possible site structures, I emphasize the possible ones, might look something like this:

1. General information about the site.
2. Functional purpose of the site.
3. Concepts and terms
4. Description of site modules
5. Functional characteristics
6. Description of pages.
7. Redundancy and reliability.
8. Hosting for the site.

1. General information about the site
A few sentences are enough here to introduce you to what kind of site or module will be developed and its purpose in general. Written in free style.

2. Functional purpose of the site
Here is a short list of what technical means or tools a site should have, based on the overall goal. Let me explain with an example. For a business card website, this can be trivial, a feedback form, a list of main pages, for example, “about the company”, “contacts” and others.

3. Concepts and terms
This section should ensure that both parties understand the domain-specific concepts that are important to understanding and developing the site. Can be entered by both parties.

4. Description of site modules
This section includes a list of modules that are used on the site. For example, this could be the feedback form (FOF) mentioned above. But, what is very important, you cannot simply write “FOS must be present.” Each entity requires defining its attributes! In this case, the attributes could be:

• Field “Your name”;
• Field “Your e-mail”;
• “Your question” field;
• Captcha input field to protect against spam robots.

And all this should be clearly stated so that questions do not arise later: « ...where is the list for selecting a question category?» Or something like that.

5. Functional characteristics
This may include, for example, a list of browsers where the site should display and work correctly. For example, some customers may require that their site work correctly in the well-known Internet Explorer 6, so as not to lose, albeit a small, but a share of possible visitors.
If you plan to create a high-load website, this also needs to be indicated. A highly loaded website requires a different approach when developing and setting up the server.

Also, the functional characteristics include the presence or absence of a mobile version of the site, but this, as a rule, either goes into a separate section of this specification or is written separately altogether.

6. Description of site pages
This is a fairly extensive item where all the pages of the site are drawn and comments on their work are written.
The general structure of the site pages may also be given. So-called “high-level” prototypes. For example, for a simple directory site this could be:

For each specific page, prototypes can be drawn with detailed comments on each of the interface elements and their behavior.
Pages used for the admin panel are usually listed separately from public pages. These two sections, in turn, can be grouped into their own separate subsections. Here it is worth making sure that the prototypes do not conflict with their description, and that no contradictions arise. An example of a prototype for a specific website page could be:

Other pages

We will not consider the last two sections of the technical specification in detail; I will briefly say that one of the reliability requirements may include setting up a database backup.

Hosting requirements may include available physical memory for the site, bandwidth, support for the database used and a number of other requirements for the site to function correctly.

At the end of the TOR it is mandatory to include information that all work not described in this TOR performed at the discretion of the programmer for obvious reasons. This is our “little guarantee” against possible modifications and alterations that go beyond the scope of the technical specifications.

Conclusions: It must be said that this structure of sections of the technical specifications does not pretend to be completely complete (at least for large strategic projects), but it still covers the main points.

It should be emphasized that all of the above are only recommendations based on the experience of people working in the field of website development and are in no way a strict requirement for writing technical specifications.

Good luck with your projects and human understanding!

In most large organizations, intra-company user-IT relationships are inevitable, especially when creating work applications that the user needs on an ongoing basis. The complexity of this relationship can be due to many factors, but most often it is a misunderstanding that arises because the parties speak different “languages” with different terminology. The user understands what he wants, but cannot formulate it; the IT specialist understands the user, but is afraid that the result will come out differently than the first one sees. Most often, the problem begins with the fact that the user is not ready for dialogue: he demands “for it to work”, “for a one-button report”, “for it to be displayed in a minute”, “for dates not to appear in Excel”, and so on. At the same time, he is not at all interested in how this is done and what mechanisms work. The user does not respond to statements about the load on the server, requests to draw a diagram of the desired result, or discuss solutions, believing that a real professional will handle everything. The results of such misunderstanding harm the entire production process: deadlines for solving problems are delayed, errors and gaps arise in systems that the user needs, a server overloaded with incorrect actions suffers, and work speed decreases.

One of the ways to resolve such a conflict is to write a project assignment - a technical specification, which involves a complete and accurate statement of the requirements of the in-house customer and is a kind of instruction for an IT specialist. However, not every user is able to express their thoughts competently and intelligibly.
I will give some tips for writing a correct task for the user, which can be worked on and which forms the basis of the relationship between the customer of the solution and the specialist.

1. Before drawing up technical specifications, the user must understand what exactly he wants to receive. You should determine the purpose of the task, the key features of the desired result, draw (write, create a table) for yourself the desired output of the work.

2. Collect documentation, according to which you perform work for which an application (program) is needed. Read it carefully, with a pencil, noting features and subtleties.

3. It should be understood what parameters should be set at the input, what is the frequency of working with the desired program (report, application, utility), how much data will approximately be obtained as an output and whether all of it is needed (for example, if you need the amount of revenue from sales of five categories of products in categories without names, you should not require the creation a million-line report showing each sale with detailed characteristics). Not every specialist needs the most detailed information, the processing of which creates a significant load on computing systems.

4. Describe in detail the required information, indicate its features, exceptions, and the required level of detail. You should think through all the little things: number format, rounding, fractions, rates, etc.

6. Discuss the written task with the direct executor, try to resolve all questions, carefully listening to the opinion of the interlocutor. Do not forget that you know your field of activity better and only you can explain exactly what tool you need to work effectively. An IT specialist knows his business and is not required to know the nuances of the work of each department in the organization.

7. Transfer assignment to work within a reasonable time before final implementation, so that there is an opportunity to test the result and correct possible errors.

8. If your subordinates will also use the application you created, try to use it yourself explain the features of working with the application– this will save an IT specialist from having to explain the same thing a hundred times.

9. Remember that your assignment will serve as a reference for you - you can always look at the description of the information in it and remember a forgotten requirement.

Of course, just the ability to write a technical specification will not eliminate all problems, but it will allow relations with the IT department to move into a serious level of cooperation, allow the user to increase their technical literacy and get what they need, and save the IT specialist from a number of problems and unnecessary questions.

In the technical specification, the customer must indicate all of his requirements for the proposed procurement object. In particular:

Advice:It is worth starting to prepare technical specifications in advance. This will reduce the risk that the deadlines for publishing procurement documentation in the Unified Information System will be missed. After all, the contract service (contract manager) needs from several days to several weeks to draw up a high-quality technical specification, depending on the technical complexity of the procurement object.

Advice: When drawing up technical specifications, it makes sense to be guided by:

• GOSTs. For example, when creating an automated system - GOST 34.602-89 “Information technology. Set of standards for automated systems. Technical specifications for the creation of an automated system";

• methodological instructions (recommendations) of the founder. For example, the Ministry of Culture of Russia has developed Guidelines on the procedure for developing technical specifications when conducting procurement within the framework of the target program “Culture of Russia (2012-2018)” (letter of the Ministry of Culture of Russia dated January 25, 2013 No. 446-01-56/10-NM) .

Creating a technical specification is a creative task that requires sufficient effort and time from the customer. However, an integrated approach to solving it, as well as careful attention to each purchase, is the main condition for effective procurement activities.

1. General information about the customer

In this section you should indicate the following customer data:

• Name;

• location of the customer;

• schedule.

Indicating the location and operating hours of the customer is relevant when, under the terms of the contract, the participant must deliver goods (perform work, provide services) to the customer’s territory.

This section can also include information on joint or centralized procurement, as well as on the involvement of an expert (expert organization).

2. General information about the purchase

Here it is worth specifying:

• full name of the procurement object,

• the chosen method of determining the supplier (contractor, performer),

• source of financing.

This section may also contain information about terms and abbreviations used in the technical specification. This information can be presented, for example, in the form of a table.

3. Description of the procurement object

This section should describe the following as fully and accurately as possible.

1. Qualitative, technical and functional characteristics. The quality of the product must comply with both legal requirements and the terms of the contract.

In this case, the customer must use standard indicators (requirements, symbols and terminology) when describing technical and quality characteristics. To do this, you need to be guided by mandatory requirements, in particular, GOSTs, SNiPs, and civil legislation (Articles 469, 721 of the Civil Code of the Russian Federation). For example, the requirements for food quality are established in Federal Law No. 29-FZ of January 2, 2000.

If standard indicators cannot be taken from technical regulations, standards (other legislative acts on technical regulation), then it is necessary to justify the use of other indicators (requirements, designations, terminology).

Advice: You should not use exact values ​​of indicators. It is better to replace them with conditions with maximum and/or minimum values, as well as values ​​that cannot change. That is, such indicators that will allow participants to determine whether the purchased goods (works, services) meet the established requirements. For example, when purchasing a system unit, it would be more correct to indicate in the technical specifications “Hard disk capacity - no less 500 GB" and not "Hard disk capacity - 500 GB".

This is stated in Part 2 of Article 33 of Law No. 44-FZ and explained in the letter of the Ministry of Economic Development of Russia dated December 10, 2014 No. D28i-2796.

2. Performance characteristics (if necessary).

3. Total quantity of goods (volume of work, services). When this is not possible, the customer can indicate the price of a unit of work (service).

4. Packaging requirements. This is an additional requirement. In the technical specifications, you can indicate, for example, that the packaging of the product must ensure its safety during transportation and storage.

5. Security requirements for the procurement object.

6. Terms and procedure for delivery of goods, performance of work, provision of services. In particular, it is necessary to determine the place of delivery of goods (performance of work, provision of services). In this case, you can specify:

• specific delivery address;

• range (alternative) of delivery locations, within which the participant must indicate a specific address in the application (for example, within the boundaries of Moscow).

This is necessary so that when submitting applications, participants have an idea of ​​where they need to deliver the goods (in which place to provide a service or perform work). Then, when deciding to submit an application, they will understand whether they can fulfill the order in this particular place. The customer, in turn, will protect himself from the risk that the winning bidder will refuse to perform.

7. Warranty period and warranty service(Part 4 of Article 33 of Law No. 44-FZ). The warranty period must be set in days, months and years.

After this, it is important to specify the terms of warranty service, that is, a complete list of actions of the supplier (contractor, performer) to maintain or bring the procurement object to the condition required by the customer.

For example, when purchasing an air conditioner, it is worth establishing a warranty period of at least two years, during which the supplier will be obliged to inspect the equipment free of charge within three days from the moment the breakdown is detected and eliminate any identified violations in its operation.

8. Other characteristics that are important when describing a specific type of product, work, service. Thus, when purchasing a product, the customer must indicate in the technical specifications that it must be new and free from the rights of third parties. That is, no one has used or repaired the product before. Otherwise, the customer risks receiving a used product. This is stated in paragraph 7 of part 1 of article 33 of Law No. 44-FZ.

If necessary, the terms of reference should also include additional requirements for the procurement object. It can be:

• employee training;

• installation and commissioning requirements;

• service maintenance;

• matching the sample, etc.

The list of information and requirements may vary depending on each specific procurement item.

An example of a description of a procurement object

In accordance with the schedule of the State Institution "Alpha", the purchase of a batch of paper for office equipment is planned for May 2016. In preparation for the electronic auction, contract manager A.S. Glebova began preparing procurement documentation, in particular, she compiled technical task .

Attention! The participant has the right not to take into account and not implement data about the object that is not reflected in the technical specifications.

If the product (work, service) offered by the winner does not suit the customer, but at the same time corresponds to the technical specifications, he does not have the right to refuse to conclude the contract.

Advice:As a source of information you should use:

• previously executed contracts,

• publicly available sources (catalogs, price lists, advertising brochures, etc.),

• commercial offers,

• information from the Internet.

All this will help to reflect in the technical specifications exactly those characteristics of the product (work, service) that the customer needs.

Attention! If the customer indicates information in the procurement documentation that may lead to a limitation on the number of participants, then there will be a risk of incurring administrative liability. Thus, officials (contract manager, contract service employees) may be fined in the amount of 1 percent of the initial (maximum) contract price (NMCP), but not less than 10,000 rubles. and no more than 50,000 rubles. (Part 4.1 of Article 7.30 of the Code of Administrative Offenses of the Russian Federation).

Attention!When describing the procurement object, you cannot indicate the names of manufacturing organizations, trademarks, service marks, etc. This will lead to a restriction of competition and, as a consequence, a violation of procurement legislation. Exceptions - the technical specification may contain a mention of trademarks, if necessary:

• indicate the means of labor used in the performance of work or services, but not as the subject of the contract. In this case, a mandatory condition is to indicate the wording “or equivalent”;

• purchase goods necessary to interact with goods used by the customer (for example, updating installed software);

• purchase spare parts or consumables for the customer’s machines and equipment.

This is stated in paragraph 1 of part 1 of Article 33 of Law No. 44-FZ.

Attention! It is impossible, within the framework of one purchase (one lot), to purchase diverse products (goods, works, services) that are technologically and functionally unrelated to each other. This will limit the number of participants. For example, the following services cannot be combined within one purchase:

• for the protection of the facility using fire alarm systems and

• for maintenance of the alarm itself.

FAS Russia clarified that this applies to different service markets. After all, security organizations, as a rule, do not service alarms. And if you include such services in one purchase, this will lead to a limitation on the number of participants.

This follows from Part 3 of Article 17 of the Federal Law of July 26, 2006 No. 135-FZ and is explained in letters of the Ministry of Economic Development of Russia dated March 10, 2015 No. D28i-442, FAS Russia dated May 21, 2014 No. AC/20578/14 .

Therefore, when planning a purchase and drawing up documentation, the customer needs to analyze this point and, if necessary:

• split the purchase into separate lots,

• For each lot, draw up a separate technical specification.

4. Requirements for the supplier (contractor, performer)

The terms of reference must include a requirement that procurement participants must comply with Russian legislation. This could be, for example, information about the availability of a license for a certain type of activity.

In addition, in some cases, the Government of the Russian Federation may establish additional requirements for procurement participants, in particular, the availability of financial and material resources, work experience similar to the subject of the contract (Part 2 of Article 31 of Law No. 44-FZ). Thus, in the Decree of the Government of the Russian Federation of February 4, 2015 No. 99 there are additional requirements for participants in procurement for work on the preservation of cultural heritage sites. The participant in such a purchase must provide information about the contract that he has performed without penalties over the past three years. The amount of such a contract must be at least 20 percent of the NMCC for the conclusion of which the procurement is being carried out.

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

In general, when drawing up a procurement specification, the customer must ensure that the object being described is completely impersonal, that is, it should not contain any requirements or even hints at specific trademarks, manufacturers, or even the country of origin of the product.

In fact, it is quite difficult to competently prepare a description of the procurement object, technical specifications under 44-FZ, without special knowledge in a specific area. Some customers even create purchases for the provision of services for the preparation of technical specifications. But it’s quite possible to do this yourself if you carefully study the requirements for procurement objects, compare them with your needs and strictly follow the rules for describing the procurement object according to 44-FZ.

It must be borne in mind that some characteristics are encrypted in the product labeling. For example, the technical specifications provide for the material “paving slabs” marked “Classico 1KO.4”; the technical specifications do not make any requirements for the thickness of the tiles. According to the decoding of the marking, its thickness is 4 cm (the last digit of the marking indicates the thickness in centimeters). However, when making the contact, it turned out that a 6 cm thick tile was required. The thickness of the tile determines the load that it can withstand. An illiterate technical specification led to the purchase of material that did not meet the necessary requirements. Therefore, you need to carefully check the labeling of all materials in the technical specifications and indicate all the basic, important requirements for the materials.

Preferably do not copy product descriptions from different sites. The information in the description may not be reliable and it may turn out that not a single product meets the stated requirements. There is a high probability that there is only one product that fits this description. This may be regarded as a restriction of competition.

All performance requirements must be unambiguous. Otherwise there will be a lot of requests for clarification. It often happens that with many requests, the customer cannot respond to them in a timely manner and there may not be time to adjust the technical specifications. Based on this, sometimes the customer indicates in an explanation 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 draw up instructions for preparing an application after describing the requirements for technical characteristics. The instructions should not confuse the participant, but specify the requirements of the technical specifications, in order to avoid many requests from participants. Inconsistency of the technical specifications with the instructions, which creates an obstacle to the preparation of the application, may provoke the filing of complaints by potential procurement participants with the Federal Antimonopoly Service.

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

• To the warranty period of a product, work, service and (or) the scope of providing guarantees of their quality. The customer must establish a warranty period in the technical specifications that is no less than the manufacturer’s warranty period.
• For product warranty service.
• To the costs of operating the product.
• To the obligatory implementation of installation and adjustment of the product.
• To train persons involved in the use and maintenance of the product.

Main rules

1. When preparing procurement documentation, pay attention to the All-Russian Product Classification (OKPD2) codes related to the procurement object. It is necessary that the code used matches the specific procurement object.
2. In addition to the provisions of 44-FZ, when developing technical specifications, 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 technical specifications must correspond to the procurement object and 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, major repairs), it is also necessary to attach design documentation.
5. Indicate that you want to purchase new goods and materials (i.e. they have not been used, have not been repaired, restored, or restored). Otherwise, the customer may receive used goods.

Common Questions

Question: Is it possible to specify “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 necessary to include 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 a supplier (contractor, performer) carried out in a closed way, procurement documentation, in the contract, as well as in other documents provided for by this Federal Law . It is not necessary to indicate it in the technical specification.

Question: You need to purchase a device for scientific research to complement your existing system of 3 devices from the same manufacturer. It is necessary to completely combine everything in the work. An equivalent is not desirable. Is it possible not to write the equivalent and indicate the manufacturer? The system is highly customizable and expensive.
Answer: If your case fits “...except for 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...) - it is possible, in other cases - it is not possible.

Question: Is it possible to specify narrow indicators in the terms of reference for major repairs, 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 technical specifications, customers must be guided by the requirements of Article 33 of Law No. 44-FZ. The color of the walls is the customer’s choice, it is his need, which does not limit the number of suppliers. A layout, a sketch of a plasterboard composition on the ceiling is also a 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, when performing work or providing services, it is intended to use goods the supply of which is not the subject of the contract. In this case, a mandatory condition is to include the words “or equivalent” in the description of the procurement object.

The main purpose of the technical specification is to clearly define and record the requirements for the procurement object. At the same time, the law establishes that the name of the purchase is indicated in accordance with (Part 4 of Article 23). The catalog was approved by Government Decree No. 145 dated 02/08/2017.

If there is a description of the purchased products in KTU, the customer is obliged to:

• describe the procurement object as provided by the KRU;
• include a written justification in the description (if the description differs from that provided in the KTR).

The Rules approved by GD dated June 05, 2015 No. 555 provide for the customer’s obligation to indicate the name of the item of purchase during the justification process.

The customer formulates the requirements based on the rules for describing the procurement object (Article 33). Let's highlight some mandatory conditions:

• indication of equivalent;
• validity by regulations or other regulatory documents;
• availability of specifications, plans, drawings, sketches, images (if necessary);
• new condition of the goods (if the customer has no other need);
• requirements regarding the provision of a guarantee.

What to include in the technical specifications

• general information;
• information about the purchased object;
• requirements for suppliers;
• conditions ;
• applications (allowed at the discretion of the customer).

Stages of drawing up technical specifications

1. Make a list of terms, definitions and abbreviations that will be used in the document.

2. Provide complete information about the customer:

• name (official name of the organization indicating its legal form);
• address (of the organization or unit that is responsible for public procurement);
• working hours in accordance with internal labor regulations.

3. Provide the following information in the procurement information:

• or not, and if yes - the rights and obligations of each customer (PP dated November 28, 2013 No. 1088);
• centralized procurement, information about the authorized body (Part 1, Article 26 of Law No. 44-FZ);
• involvement of experts, the procedure for their work.

4. List information about government procurement:

• method for determining the supplier (part 1 of article 24);
• justification for the chosen method of determining the supplier (Part 5 of Article 24).

5. List the requirements for participants: business reputation, availability of production facilities.

6. Indicate the initial conditions: reference, production, experimental information that influence the execution of the contract. For example, it is possible to service purchased equipment only in the morning.

7. Provide information about the features of the customer’s production process or architectural object that will affect the contract execution process. For example, when drawing up a technical specification, you may need to indicate that during delivery it is necessary to climb to the third floor manually due to the lack of an elevator.

8. Indicate the exact location of the object, and, if necessary, its full description. This may be required, for example, for designing utilities or for accurately calculating the cost of repairs.

9. Provide the desired results (what problem the customer wants to solve) and the goals of public procurement (Article 13 44-FZ).

10. Indicate the source of funding.

11. Establish a requirement for participants to comply with a certain regulatory framework, including those related to the subject of the contract, conditions of performance, terms, and warranty obligations.

12. Determine the conditions of public procurement (Part 1, Article 19).

13. Indicate the name and justification of the public procurement object.

14. Describe the object of public procurement as accurately and in detail as possible (Article 33).

15. Determine the environmental features of the purchased object.

16. Specify the volume of goods purchased, as well as the frequency and delivery time.

17. Determine the warranty period and the scope of the guarantees provided.

18. Establish requirements for packaging, labeling, what symbols and special symbols should be on it.

19. Oblige to provide confirmation of a new product or the need for a product of a different condition.

20. Determine operating costs.

21. Decide whether installation and adjustment are needed.

22. Establish the procedure for delivery and acceptance.

23. Indicate the need to conduct testing and training of persons who will use the purchased product.

Samples of technical specifications for goods, works, services in 2019

Remember that a universal sample technical specification for Federal Law-44 has not been developed; each purchase requires an individual approach. This is the only way to take into account all the needs and characteristics of the customer. As a guide, you can use this example of a technical specification according to 44-FZ (sample).

Below is a sample technical specification for the supply of goods under 44-FZ.

You can also find a sample technical specification for performing work under Federal Law-44 in our material about or systems.