If you go through foreign sites with the request “product requirements document”, you can find creative and convincing articles about the fact that the technical task (TOR, PRD) is dead. In part, we have to agree with this - when developing a product from scratch, prototyping looks much more interesting and efficient than volumes of customer records, sometimes very unprofessional ones. However, if we are talking about finalizing the basic system, then things take a completely different turn. We are faced with both revision and custom development, so the dog was eaten at the TK, if the cook does not lie to us. In general, today - about those very classic technical tasks that are written to finalize the purchased and installed software. In short, about the sore.

Facets of Interaction

Before proceeding to the preparation of the process of creating a technical task, let's talk about the quadrangle, which the contractor and the customer fall into when starting the project.

Requirements- the desired behavior of the system, as described by the customer or process holder, to be implemented. As a rule, requirements are formed on the basis of experience, representation of the correct behavior of the program. This is key information for the developer (vendor), however, it is at the stage of collecting requirements that the largest number of collisions, errors, redundant requests, etc. occur.

Resources- people, machines, inventory, development environment, time and money to be used in the process of implementing the requirements. Resources require clear planning and evaluation at the stage of approval of terms of reference. Competent prioritization on the part of the customer and the distribution of labor resources on the part of the vendor make it possible to avoid missed deadlines and minimize other risks.

Opportunities- in short, this is what a vendor (performer) can actually do. Consider our RegionSoft CRM as an example. The client buys the system and draws up a technical task for revision: it is necessary to create an integration with the site and link events in CRM to the order number of the online store. This is a realistic requirement, we have the resource and the ability to do it. And you also need to develop and tie to CRM CMS, a site content management system. Theoretically, we can do this, but we do not have the opportunity to do it cheaply, and the client does not have the opportunity to pay us enough to transfer human and time resources to the task. As a result, the customer refuses this requirement - and he doesn’t really need a CMS, everything is fine anyway. But about the "greed" of TK - later.

Restrictions- a set of obstacles that make it difficult or impossible to complete tasks from the TOR: budget, technology stack, licensing problems, legal prohibitions, hardware configurations, etc.

Thus, all four entities are closely intertwined and determine the success of the project as a whole. Let's consider each element and try to highlight the critical points that you need to keep in mind when working on the terms of reference.

Collection and analysis of requirements

This is a very important internal corporate process, during which it turns out what potential users want from the program (hereinafter, we will take CRM, but the methods work with other types of software). If you contact a large vendor such as SAP or a system integrator, then with a high degree of probability you will be offered the services of a business consultant (he is also a personal manager, he is also an account manager, he is also “now your representative in our company”). In fact, in most cases, this is an ordinary well-trained salesman who has two tasks: to wind up the cost of the project and not let you off the hook.

He's been here for an hour and hasn't even touched the whiteboard. He's not a real systems analyst

Nobody knows your company better than you and your employees. This means that the collection and analysis of requirements is exclusively your task, in which the vendor can help and guide, but in no case interfere with the process. Ask the developer about such implementations, specify what to look for and proceed. By the way, your employee who is well versed in the profile topic and roughly represents the software architecture and is familiar with the development process can be a good assistant - he can act as an analyst and internal expert, close the process of creating technical specifications and communicating with the vendor.

There is a very simple scheme for collecting requirements.

1. Create a working group of managers and experienced specialists of departments who will use CRM. Tell us about the solution you are going to choose, provide access to the demo version.
2. Members of the working group must convey information to employees and ask them for wishes for a new program in an absolutely free form. If one of the employees has never encountered such software and is not ready to talk about future use, you need to ask him to describe his periodic tasks, this is a universal approach.
3. Each division then determines what the CRM does not or does not match and aggregates the information.
4. The working group analyzes the collected requirements, checks and eliminates intersections. For example, it is not uncommon for a sales department and a marketing department to order the same report, but fields and entities may be named differently in the requirements, although the data behind them is the same. Accordingly, it is necessary to come to a single form.
5. The working group forms a list of requirements and sets priorities. At this stage, you can connect the vendor, since he is responsible for the resources. For example, you can ask to create a custom report for RegionSoft CRM, or you can order integration with the site. These are tasks that are completely different in terms of time, priority is very important here.

After the requirements are collected, analyzed and agreed with employees and management, you can begin to create terms of reference. You can either ask the vendor for the form or create it yourself - in any case, there are a few ironclad rules that will save both you and your CRM provider a headache.

Anatomy of a Terms of Reference

If we talk about the process of creating a technical task, then there are several stages. Their consistent passage leads the customer to the desired improvement. Here they are.

• Identification - definition of requirements, search for problems that need to be solved.
• Analysis - analysis of requirements, identification of key needs, generalization.
• Adaptation - assessment of requirements in the context of CRM capabilities and existing business processes.
• Documentation - a formal and detailed description of requirements, approval of technical specifications.
• Communication with the vendor (developer) - iterative interaction with the vendor regarding improvements in accordance with the compiled TOR.
• Implementation - the work of the vendor to create the necessary functionality. It is better if the vendor is constantly in touch with the customer - so the output product will most closely match the client's vision.
• Testing - checking the functionality by the vendor's employees, the client's internal experts and end users in order to establish the compliance of the revision with the TOR, the system's operability with changes.

In general, the terms of reference can be created based on the requirements of several levels, which may overlap and cooperate in the creation of the project or not interact at all.

Business level- the most global level at which complex and priority tasks are solved. This level includes integration, refinement and modeling of business processes, development of new functional modules. As a rule, this is a resource-intensive development, with serious consultations and close collaboration with the customer. For example, at one time in RegionSoft CRM, warehouse accounting, cash register and production were such custom modifications. Gradually, the changes entered the release, and later allowed the creation of a new product for wholesale, retail stores and hypermarkets - RegionSoft Retail.

User or user group level. At this level, tasks are implemented to refine the existing interface. For example, a user may want a window with the number and status of the last order to appear when hovering over a customer, or a custom report with a special grouping of data. Improvements at this level take less time, but there can be a lot of them - for example, several requirements from the marketing, logistics and technical support departments.

functionality level. Often it is difficult to separate it from the previous one, a formal criterion works here - refinement is not at the level of displaying something in the interface, but at the level of refinement of the system logic. These include requirements for various kinds of sorting, chat integration, and telephony capabilities.

Service level- in fact, the requirements of this level should be the first to get into new builds with fixes. These are tasks in terms of system response speed, work under high load, and security. Ideally, the vendor should not have such improvements - corporate software should not slow down, lose data, collapse forms and distribute access rights of the same level. But if a requirement has appeared, and it is not related to the personal paranoia of the customer or problems on the hardware side, it is worth paying special attention to it.

Technology level- the last in the list, but ahead of the rest in importance and complexity. These can be client requirements related to the platform, operating system, or devices. For example, a build request for MacOS. It's great if such requirements gradually develop into releases, but it is necessary to have their fixes. It was from the requests of clients at this level that we made the assembly of RegionSoft CRM for MacOS and added remote access using TRM technology as a temporary solution to a rare, but existing request for a mobile version.

The anatomy of the terms of reference is simple, at least in the form of a skeleton. Mandatory parts of the terms of reference help the customer to focus on the problem and formulate the task correctly, and the performer to understand what they want from him. By the way, about understanding. Of course, at the beginning of the post, we were a little cunning, denying business consultants as a class. The point is this: each vendor has been operating on the market for several years (we are not talking about one-day CRMs now), or even decades, which means that it has a set of cases in almost every industry. Accordingly, both engineers, programmers, and salespeople are familiar with the specifics of implementation in each type of company. But again, it is important to focus on your business.

For whom? In this section, you need to describe who will be the end user of the revision, what tasks and how often it is planned to solve.

I'll give you an example. One company implemented CRM, it was supposed to work on a fairly large array of data (several tens of millions of records per month, several hundred thousand records per day). The head of the sales department requested a report on the upload of these records with a frequency of "daily". Naturally, such a report, while hundreds of users were working simultaneously, loaded the system - solutions were found to optimize the process. Already in the course of work, it turned out that the salesman was playing it safe and he needed the report only at the end of the month, and then it could be launched according to the schedule at night. Needless to say, time and money were wasted.

What for? Justification of the need for improvement and its place in the business process. This item is more needed by the customer himself, but it is also useful for the vendor to know what other processes will be affected. Sometimes it helps to find an alternative solution.

What should be done? The most informative block - it describes the requirements, expectations from the system. And here the very pearls, miracles and collisions happen, which are just right to send to the bashorg, and which, well, make life very difficult. There is only one reason - the user does not know what he wants, what needs to be done. There is another small sub-reason - the user cannot formulate requirements. And here the task of the developer (working group, analyst, if any) is to help formulate the need correctly, select an appropriate requirement, and fit the task into the context of the system. In the same block, you need to mention the expected result.

Terms of reference parameters- deadlines, stages of implementation, responsible from all parties, necessary contacts, etc. In fact, this is a set of important formal things that make the document a technical task. The terms of reference must be agreed upon and signed by the parties in order to avoid numerous changes during development (they will still be, but in a smaller volume).

Ideally, the terms of reference are drawn up with the active participation of the vendor, and its result is approximately the following structure:

1. Description of the requirement of each mechanism and each functionality
2. Description of the implementation of this functionality
3. The cost of work for each of the stages separately
4. The total cost of work on this technical task
5. Deadlines for the execution of work with a breakdown by stages and an indication of the order of priority
6. Description of installation and testing conditions
7. Reservations on the exhaustive nature of the terms of reference and other conditions

10 Rules Written in Developer's Tears

Terms of reference for revision should be TOR for revision, and not a 300-page description of the CRM that the client needs. Before drawing up requirements, you should carefully familiarize yourself with the system interface, its capabilities, documentation - most likely, most of the "Wishlist" is already in the basic package. As a second step, I would recommend paying attention to the built-in refinement tools (report designers, configurators, etc.) - perhaps a full-time programmer will be able to make the necessary changes (many companies have them).

The technical task should not be greedy. Often, a business overestimates its capabilities or wants to get "everything at once." This approach is not justified either from the point of view of money or from the point of view of business. A vendor, as a rule, does not exist for a couple of weeks (in the case of RegionSoft - 15 years), and you can contact him after a while, when you really understand what is missing in CRM.

A vivid example of redundancy literally from yesterday: a client bought the ERP of a well-known Russian company, thinking that since accounting works, then the ERP of this vendor will be good. ERP turned out not to be not very good in itself, but very unsuitable for business. But RegionSoft CRM with warehouse accounting and production is suitable. There is a solution: forget about ERP, cry, integrate 1C accounting with the new CRM and enjoy the convenient implementation. But the swollen money is a pity! And the client demands to integrate CRM with ERP. We didn’t do that, but why such a waste, why two relatively similar systems?

Terms of reference must be realistic and achievable- both in terms of requirements and deadlines. Here it is important to listen to the opinion of the vendor, since he knows exactly how much time it will take for a particular task. Believe me, it is not profitable for a developer to play for time and wind up the deadline - it is beneficial for him to complete as many projects as possible and do it well so as not to get a blow to his reputation. As for realism, avoiding requests to finish CRM to the level of a collider control system is simple: you should include in the requirements what is really needed at the moment and in the foreseeable future.

For example, RegionSoft CRM is a desktop program, we don't have a browser client. Asking us to create a web application for one company is pointless, this is a major development, it is currently underway and is not a possible refinement for one company. No, of course, everything has its price, but again - in the general case, the requirement is impossible.

It should not be confused with the situation when it comes to custom development and the idea and logic of the application changes radically, in fact, the creation of new software “for oneself” is sponsored. But that's another story.

The specification must be detailed. It is necessary to indicate all the significant details of the future project: from the frequency of using the program to wishes for the interface. The more detailed the requirements are, the easier and faster the implementation and testing will be. It is especially worth paying attention to details if you work in a specific industry (medicine, insurance, banks) - a detailed presentation of the nuances of the interaction between the business and the program will ensure that the vendor understands the task and quickly adapts the system to your company.

Be sure to pay attention to number formats, field names, the presence or absence of drop-down lists, the behavior of buttons and hints, and data types. If the customer uses his own formulas that need to be included in the CRM logic ( for example, the calculation of dealer bonuses), these formulas must be written with a full explanation of their designations and calculation logic.

Yes, corporate software looks something like this, and there are a lot of important little things in it.

The terms of reference must be unambiguous and precise. Vague wording, implementation options, fuzzy requirements - all this is a path to a dead end. It happens that a client, out of good intentions, writes in the TOR several options for the behavior of the system, which are close, but not equivalent. In this case, he is sure that he helps, prompts the programmer, but in fact, the road to hell is paved with good intentions; the developer must understand what exactly is needed, and he will choose how to do it himself, based on the features of the system and the stack of technologies used.

This year you can make one wish again. Just please don't waste it on something that even I can't fulfill, like clear business requirements!

The terms of reference must be written in human language. And this is important, no, IMPORTANT. I will single out two situations when problems with the language lead to a delay in the implementation of the project.

1. The client tries to demonstrate his technical literacy and fences constructions like: “implement a window with a hint in the body of the calendar with the ability to react to an event call ...” instead of “a window should pop up in the calendar in which you can mark the task as completed”. If you or your internal expert do not have the skills to write technical texts, do not google - write in ordinary words, we understand them.

   The terms of reference should not be a complaint book. We need to solve the problem, not describe it, paying attention to fonts and forgetting about the description of the requirements. The TOR should contain not only the problem itself, but also its solution at the level of understanding - then the developer will already solve it at the code level. Compare “the sales department plans poorly, loses numbers, we have been fighting for a year” And “it is necessary to create a report that will save the values ​​of the plan and the fact of sales on a monthly basis, in the context of product groups”.

   The terms of reference should be able to look to the future. Well, not exactly it, but the people behind it. If it is known that changes in business processes will soon take place, this must be taken into account in order not to pay for revision twice.

   Terms of reference should not be bureaucratic. If you have ever drafted this document, you must have felt how hard it is to avoid the temptation to slide into bureaucracy, to add introductory words, strict turns and describe each item as an article of the Criminal Code (preferably with punishment for everyone for violation). Bureaucratic wording masks an incomplete understanding of the goals of creating TK. The responsibility of the vendor is spelled out in the contract, the budget is also written there. You should not transfer these points to the technical task.

   The terms of reference must be the terms of reference. It sounds paradoxical, but often instead of technical specifications we read letters, complaints, contracts, newly written instructions for CRM or meeting minutes. Of course, it is impossible to work on such a document. In order not to get away from form and content, use the old school trick: look at the term word by word. Technical means that it dictates refinement, technique, is aimed at solving the problem by changing the software. That's the task in the context of software and you need to talk. A task means posing a question, a problem, without advice, hints and preliminary estimates. Just a statement of the problem.

   The commandments are over, now the rebuke

   In addition to the above rules, there are a few more things that are worth talking about. We are talking about goals, plans and expectations - all those leaving that make the project successful, and the relationship between the vendor and the client is almost friendly.

   Terms of reference need to be written quickly, even if you are faced with the task of automating the processes of a mobile operator or a large hypermarket. This is due to the fact that technologies are developing at a tremendous speed, and even the system that you are implementing can survive a major release (and sometimes two) in six months or a year, get new functionality. It may be necessary to reconsider the need for improvements and start the process again.

   

   
   Finally, he found time to finish the TK. But, alas, there are no developers left around to implement it.

   The client is unaware of the stack and technical limitations. And he should not know - this is the task of the vendor, it is he who evaluates the work after drawing up the terms of reference. The customer should not delve into the technology and ask each comma if the vendor can do this or that thing. Draw up a comprehensive TOR and the developer will choose the appropriate architecture - often even better than you might think.

   Estimate your budget and avoid unpleasant surprises- almost the number one joint task. You should not pull the vendor and demand from him an approximate assessment of the work (well, at least approximately, offhand, by eye, but like others, well, in projects of this type, but from experience, well, well, within the margin of error). A full budget estimate is possible only after reading, analysis and final approval of the terms of reference. If your developer does otherwise, get ready for the fact that the revision will cost at least twice as much.

   Proceed from the objective need for changes and expansions- I wrote above that the developer does not disappear and is ready to make changes and additions according to your requirements at any time. Therefore, do not try to create CRM / ERP dreams right away, do not demand from the vendor the “Everything works while I drink coffee” button - work in the system, identify critical comments for you and start collecting requirements and drawing up technical specifications.

   You can write endlessly about technical tasks, this is a real generator of not only memes and tales, but also a headache. You can talk about priorities and design rules, about GOST 1989, which makes the TK inhuman, about the IEEE standards, which are a little better, about prototypes and TK that complement them. But in the end, I would like to limit myself to one, the most important rule: the terms of reference are not a rule of law, not GOST and not a dogma, therefore, if you can improve - improve, you can simplify - simplify, you can do it gracefully and so that everyone likes it - do it. I am sure that after this no one will poke their nose into the TK and say that this is not written there. Or almost no one.

   Throughout December, we give discounts for RegionSoft CRM and all software of our own design. From December 1 to December 15 - 15% and cool installment and rental conditions. We do not have -70% and -90%, because we keep an economically justified price for licenses, and do not take it from the ceiling.

   Well, if you need a CRM system (with or without modification), then go to our website, there is a lot about CRM, its benefits and other corporate software.

   And yes, we are always looking for partners who are ready to sell CRM and other products, improve and sell CRM, sell software and train users. The division of income is fair and beneficial to the partner. Show, tell, teach. Write to [email protected]

   Slides, slides. Comics taken from http://www.modernanalyst.com/ and from Pinterest. If there is a better translation, we will be happy to include it in the post.

Our experts helped the customer to create Terms of reference for the modernization of the ventilation system.

More details under the cut..

Technical task

for the modernization of technological equipment for ventilation systems of laboratory building No. 451,452, building 17 at the address: Moscow

1. General Provisions

1.1. This terms of reference provides for the implementation of work on the modernization of technological equipment, control systems and automation of ventilation units of the building, laboratories No. 451,452 of building 17.

1.2. To perform the work, develop working documentation for the sections of the AOV, EM, KhS, AHS, AK brands, which should be agreed upon in the prescribed manner.

1.3. Perform work in compliance with the requirements of regulatory and technical documentation.

1.4. Upon completion of work, submit as-built documentation made in accordance with the requirements of GOST and SNiP.

1.5. Submit the completed work to the client.

1.6. Certain provisions of this Terms of Reference may be specified in the process of work in agreement with the Customer.

2. Technical requirements

2.1. Modernization of control units for heat and cold supply of ventilation units.

2.1.1. Nodes of regulation of heat supply.

Modernization is subject to:

· heat supply control units for the first heating of ventilation units K1, K2, K2a, K4 of the MIK-V, P2, P6 buildings of laboratory No. 452, P1 of the laboratory.

· heat supply control units for the second heating of ventilation units K1, K2, K2a of the MIK-V building.

Existing heat supply control units are subject to dismantling, while part of the equipment of control units (circulation pumps, shut-off valves), corresponding in condition and technical characteristics, is to be used in mounted control units.

The composition of the equipment of mounted control units, as well as the equipment used is indicated in Appendix No. 1.

Carry out hydraulic tests of the heating circuits and heaters of ventilation units with the execution of a hydraulic test report.

Carry out painting of pipelines and thermal insulation works.

2.1.2. Knots for regulating the refrigeration supply of ventilation units.

Refrigeration units for ventilation units K1, K2, K2a, K4 of the MIK-V, P2, P6 buildings of laboratory “452, P1 of laboratory No. 451 are subject to modernization.

Scope of work:

· replacement of thermostatic valves of refrigeration control units;

Dismantling/installation of the fan of the compressor-condensing unit K1;

· dismantling/installation of filters-driers of compressor-condensing units K1, K2;

Dismantling/installation of the evaporator of the ventilation unit K4;

· pressure testing in an inert gas environment, vacuuming, refilling of refrigeration circuits with freon;

Restoration of thermal insulation of pipelines.

2.1.3. Feed units for humidification circuits.

Install cold water purification filters at the feed units of the irrigation chambers of air conditioners K1, K2, K2a.

2.2. Cabinets for control and automation of ventilation installations.

Control cabinets for ventilation units K1, K2, K2a, K4, RU3, V1, V2, V3, V6, V7, V8 of the MIK-V, P2, P6, V1, V2, V3 buildings of laboratory No. 451, P1, V1 of laboratory No. 452.

The layout of the newly installed control panels:

SHUA K1 - control cabinet and automation of the ventilation unit and the compressor and condenser unit (KKB) of the air conditioner K1 (MIK-V);

SHUA K2 - control cabinet and automation of the ventilation unit and KKB air conditioner K2 (MIK-V);

SHUA K2 - control cabinet and automation of the ventilation unit and KKB air conditioner K2a (MIK-V);

SHUA K4 - control cabinet and automation of the ventilation unit and KKB air conditioner K4 (MIK-V);

SHUV - control cabinet for exhaust units RU3, V1, V2, V3, V6, V7, V8 (MIK-V);

ShUA P2, P6 - control cabinet and automation of ventilation units and compressor and condenser units P2, P6 (laboratory No. 452);

SHUV - control cabinet for exhaust units V1, V2, V3 (laboratory No. 452);

SHUA P1, V1 - control cabinet and automation of ventilation units P1, V1 (laboratory No. 451).

Modernized control cabinets should provide:

selection, from the front panel of the cabinet, of the ventilation unit control mode (manual/automatic);

· light signaling of regular and emergency modes of operation of technological equipment of ventilation units (operation/accident);

shutdown of ventilation systems in the event of a fire;

automatic operation of protections and blocking of equipment operation in case of emergencies.

Frequency converters for controlling electric motors of fans and pumps are to be further used.

2.3. Automation and dispatching system

The automation and dispatching system is designed to manage and control the operation of ventilation units, as well as to collect, process, present and store incoming information.

2.3.1. Automation system.

The automation system should ensure, in general, the autonomous operation of ventilation units, which does not require the intervention of maintenance personnel and the transition, if necessary, to manual control mode. With any control options and regardless of the state of the local controller, the condition for automatic shutdown of the general ventilation system in case of fire must be maintained. Shutdown must be carried out individually for each system while maintaining the power supply to the anti-freeze circuits.

Local automation of ventilation systems should include:

regulation of the temperature of the supply air at the outlet of the ventilation unit or, if necessary, the temperature of the exhaust air from the serviced premises;

regulation of supply air humidity;

stop fans and close air valves when a fire alarm is triggered;

Switching off the humidification of the air conditioner when its fan stops;

Opening and closing of the air valve, respectively, when starting and stopping the fan;

· automatic warming up of heaters before start of systems in the winter mode;

· protection against freezing of heaters by air and by water (turning off the fan, closing the air damper, opening the heating valve to 100%);

shutdown of the fan in the absence of pressure difference;

· control of pollution of filters of installations.

Remote impact on local automation with workstations is determined in the following volume:

· changing the settings of temperature and humidity controllers;

· enable/disable settings.

The existing peripheral equipment of the automation system is subject to verification, cleaning and further use in the following order:

· temperature and humidity sensors of ventilation units are subject to verification;

· Differential pressure switch sensors are to be checked, cleaned;

· Thermostats to protect air heaters from freezing must be replaced.

· Actuators of control valves of control units must be replaced in accordance with clause 2.1.1.

air valve actuators are subject to inspection and further use;

To control the recirculation of air conditioner K1, replace the on-off actuators of air valves with valves with a control signal of 0..10V.

2.3.2. dispatching system.

Include the following components in the dispatching system:

a complex of measuring devices, actuators and automation tools based on software and hardware tools "Honeywell";

· multifunctional cable system;

· a complex of software and hardware means of the control room.

For dispatching ventilation systems, provide for the display, archiving and logging of the following information:

· graphic representation of installations with temperature and humidity sensors, anti-freeze thermostats, differential pressure switches, control valves, air humidifiers, air valves;

installation numbers;

readings of temperature and humidity sensors;

readings of differential pressure relay sensors;

indications of the position of control valves 0..100%;

fan operation/stop mode;

· "work / stop" mode of pumps;

position of the air valves "open / closed";

stop systems when a fire alarm is triggered;

shutdown of systems when there is a threat of freezing of the heater;

shutdown of the unit in the absence of pressure drop across the fan;

Switching off the air humidifier when the air conditioning fan stops;

The operation of systems according to a given time schedule or without it;

· signaling of accidents and emergency situations in case of equipment malfunction, as well as - output of process parameters values ​​outside the specified ranges;

registration of accidents and emergency situations in the message log;

· parameter registration log for the current time indicating the name of controlled parameters, units of measure, controller number and input/output channel.

2.3.3. The power supply of the automation and dispatching system must be supplied from the AC mains with a voltage of 380/220 V, a frequency of 50 Hz using uninterruptible power supplies on batteries and provided as a power supply for power consumers of the first category

It directly depends on how accurately the terms of reference for finalizing 1C are drawn up, whether the tasks assigned to the developers will be solved. However, when working with such a document, there are some difficulties. In a broad sense, the TOR prescribes the norms for the creation and modernization of an automated system (AS), as well as the procedure for work. This also includes a set of project launch standards. This understanding of the role of the terms of reference is dictated by the requirements of GOST 19.201-78 and 34.602-89, according to which the TOR for 1C is being developed. There is another interpretation of the meaning of this document, closer to practice.

According to another definition, the terms of reference for finalizing 1C is a document that regulates the purpose and parameters of the future system, as well as the process of developing documentation and its list. This interpretation allows taking into account the interests of programmers and the customer.

What should be the TK?

Any technical task for the development of the 1C program is created by the contractor. But this is not a programmer, but an analyst. This is an important point, because the document must be written in a language that the client understands, without highly specialized technical terms. When all the nuances of the project are taken into account and the information is formulated correctly, the TOR is agreed with all customers. If it is accepted, programmers are involved in the work. At the same time, the desired result should be clearly outlined in the document. This helps developers set the right goal and check against it at different stages. Also, when drawing up the terms of reference for finalizing 1C, much attention should be paid to the wording. Care must be taken to ensure that they are sufficiently specific and do not imply other interpretations. This is the first thing to remember when working with TK. You also need to take a responsible approach to the design. This also applies to the title page of the document.

The main mistakes in the terms of reference for the development of 1C

The structure of the terms of reference is regulated by GOST 34.602-89. This document contains clear requirements for the number and sequence of blocks of information in the TOR. At the same time, there are no strict standards for presentation methods. This situation contains great potential for solving complex problems and at the same time can lead to many errors in the preparation of the document. The most common inaccuracies are:

1. Repetition of some sections in different interpretations.
2. The information is given randomly. Ideally, it should refer to a specific structure, such as business processes or system modules.
3. Information in different sections is presented with varying degrees of detail.

All this prevents the customer from understanding the information that is set out in the TOR. This complicates the process of cooperation, making it more time-consuming.

After viewing by the customer, the sample TOR for revision of 1C may change and not always for the better. This, in turn, usually prevents programmers from correctly perceiving information. This is especially true for specialists with little experience. At this stage, the following errors often occur:

1. The requirements of different sections contradict each other.
2. The formulas are inaccurate.
3. In some places, the information is too detailed.

Getting rid of all these errors is easy. It is necessary to focus, first of all, on the result, and not on carefully prescribing formulations. It is worth remembering that the TOR describes the functionality of the project, its main parameters and purpose.

How to avoid mistakes in the development of technical specifications?

The main rule, which applies to all subsequent recommendations, is that the wording should be specific. To do this, you need to use links to GOSTs, other regulatory documents. This allows the contractor and the customer to perceive information in the same way.

An example of a technical task for finalizing 1C involves the use of the language of the business industry for which the project is being implemented. This is necessary, first of all, for the customer. At the same time, you should not use any comparisons in the text, since they can be interpreted in different ways.

Basic rules when drawing up terms of reference for the development of a report and other elements of 1C:

1. TK is created jointly by the contractor and the customer.
2. Only objective requirements should be presented to the work of programmers. For successful project development, the subjective vision of the customer must be kept to a minimum.
3. It is necessary to describe in detail the result that the customer needs. At the same time, in the example of the terms of reference for the development of the 1C configuration, it is necessary to prescribe all the parameters by which the element should work. Otherwise, the result may be very different from the desired.
4. The risks of the contractor and the customer should be approximately equal and minimized.
5. You can not use terms that are used in business communication and are not used in a particular industry.

To create a TOR for the development of a report in 1C or another element, the analyst must know all the features of the customer's field of activity. In the requirements, you need to give only useful information that is useful to the performer. Given that special attention is paid here to the final tasks that the software must solve, there is no single example of a technical task.

The danger of incorrect preparation of TOR

The errors listed above can lead to an increase in the time it takes to create a system. This entails unnecessary costs and dissatisfaction. The terms of reference for the development of a database or other 1C configuration should be drawn up by experienced specialists. The benefit of all participants depends on how this document is understandable. The customer receives an effective automated system for solving business problems. At the same time, the contractor has another satisfied client. Business owners need to be as careful as possible when choosing 1C partner companies, because the effectiveness of the organization largely depends on how well the terms of reference for revision are drawn up.

Pavel Molyanov

Remember Murphy's Law? If you can be misunderstood, you are bound to be misunderstood. This is true not only in communication between people, but also in the creation of sites. The client wanted a second Facebook, but got a forum for young dog breeders. The developer did not guess the customer's Wishlist - he wasted his time.

In this guide, I will tell you what and why you need to write in the terms of reference. At the same time, I’ll show you how not to write so that the creation of a technical specification does not turn into wasted time.

The article will be useful:

• Everyone who is related to the creation of sites: developers, designers, layout designers.
• Project managers.
• Heads of digital studios.
• Entrepreneurs who plan to order the development of the site.

To make the material workable, I collected comments from several developers, designers, project managers and owners of digital studios. The most valuable ones are added to the end of the article. Let's go figure it out.

What is a specification and why is it needed

The terms of reference is a document in which the requirements for the site are fixed. The clearer and more detailed these requirements are, the better all participants in the process understand how it should be. This means that the chance that everyone will be satisfied with the result is growing.

The main goal of the terms of reference is to make sure that the client and the performer understand each other correctly.

There are many benefits of technical specifications. Each side has its own.

Benefit for the client:

• Understand what he pays money for, and what the site will be like. You can immediately see the structure, understand what will work and how. Figure out if everything suits you. If not - no problem to change before the start of development.
• See the competence of the performer. If the terms of reference are understandable and clear, the confidence in the developer increases. If porridge is written there, it might be worth running and not looking back.
• To insure against dishonesty of the performer. When the site is ready, it can be checked according to the terms of reference. Are there inconsistencies? The developer must fix them. If you cooperate officially and entered into an agreement, you can even be forced through the courts.
• Simplify the replacement of performers. If the client and the developer quarreled and fled, the creation of the site can take a long time. When there is a detailed terms of reference, it can be transferred to a new team - it will get involved in the work many times faster.
• Find out the cost of developing a complex product. It is impossible to estimate the exact timing and cost of developing a complex web service right off the bat. First you need to understand how the service will work, and what functions it will have. To do this, you need to prepare a technical task.

Benefits for the performer:

• Understand what the customer wants. Dozens of questions are asked to the client, examples are shown, solutions are offered. Then everything is written down in a single document and coordinated. If everything is OK - cheers, you understood correctly.
• To insure against sudden Wishlist of the client. Sometimes there are customers who want to change the task halfway through. If you agreed and signed the TOR, you are not afraid of this. In which case, even the court will be on your side.
• Show your competence. A well-prepared terms of reference will show the client the expertise of the developers. If the company doubted whether to trust you with the development of the site, doubts are likely to be dispelled.
• To earn money. Some studios and developers offer the preparation of technical specifications as a separate service.

• Facilitate and speed up the development process. A good TOR indicates the structure of the site, the necessary functions and elements on each page. When all the requirements are already in front of your eyes, it remains only to design and write the code.

Now let's figure out how to write a good TOR that performs all these functions.

The terms of reference are made by the performer

In general, anyone can make a technical task. “We need a business card website for a dental clinic” - this is already a technical task. But will it do its job? Hardly.

A good TOR is always made by a performer: a project manager or a developer. Obviously, a web developer understands more about creating websites than the owner of a cafe or a dental clinic. Therefore, he will have to describe the project.

This does not mean that the client disappears and appears at the very end to write: "Zbs, I approve." He must also participate in the process:

Of course, the customer can sketch out his own version of the TK. Perhaps this will speed up the process of creating the final terms of reference. And perhaps it will turn out to be garbage, which is quietly thrown into the trash.

Write clearly and precisely

This advice follows from the main goal of the terms of reference - "Make sure that the client and the contractor correctly understood each other."

The terms of reference should not contain high-quality adjectives: beautiful, reliable, modern. They cannot be clearly understood. Everyone has their own concepts of beauty and modernity.

Look. After all, someone thought this design was beautiful and allowed it to be used on their website:

The same thing - with slurred wording that does not mean anything by itself:

• The site must be liked by the customer. What if he's in a bad mood?
• The site must be user friendly. What does it mean? Convenient for what?
• The site must withstand heavy loads. 10 thousand visitors? Or 10 million?
• Quality expert content. Well, you get the idea.

Check for ambiguities in the text. If there is - rewrite. Your wording must be clear and precise:

• The site must load quickly → Any page of the site must have more than 80 points in Google PageSpeed ​​Insights.
• Large loads → 50 thousand visitors at the same time.
• The main page displays a list of articles → The main page displays a list of the last 6 published articles.
• Minimalistic user-friendly subscription interface → Leave an e-mail field and Subscribe button → *drawn sketch*.

We figured out the wording, let's go over the structure.

Enter general information

All team members must correctly understand what the company does and who its target audience is. So that no one gets confused, it is better to prescribe it at the very beginning of the terms of reference.

And it’s also worth indicating the purpose of the site and describing its functionality in a nutshell - so as not to get an online store instead of a blog.

Explain difficult terms

The first rule of the terms of reference is that it should be clear to everyone for whom it is intended. If you are going to use terms that your client - the owner of a children's toy store - may not understand, be sure to explain them. In plain language, not copy-paste from Wikipedia.

Describe tools and hosting requirements

Imagine that you have been making a cool website for 2 months. Each stage was coordinated with the client - he is delighted. And now it's time to hand over the work. You show the admin panel, and the client shouts: “What is this? Modex?! I thought you would do it on WordPress!”

To avoid such problems, describe the tools, engines and libraries used. At the same time, specify the requirements for hosting. You never know, you will do it in PHP - and the client has a server in .NET.

List the requirements for the site

The site should work in all browsers of current versions and on all types of devices. Yes, this is obvious to any developer and any customer. But it is better to write in order to protect the client from dishonestly performed work.

Write down the requirements here. site loading speed, resistance to loads, protection from hacker attacks and similar things.

Specify the site structure

Before drawing the design and layout, you need to agree on the structure of the site with the client.

Chat with the customer, find out what he needs. Gather developers, SEOs, marketers, editor-in-chief - and decide which pages are needed on the site. Think about how they will be interconnected, from which to which you can switch.

You can show the structure as a list, you can draw a block diagram. As you prefer.

This is one of the most important stages of work on the site. Structure is the foundation. If it is unsuccessful, the site will turn out to be crooked.

Explain what will be on each page

The client must understand why each page is needed and what elements will be on it. There are two ways to show this.

Prototype- more visual and unambiguous way. The contractor draws sketches of each page and attaches them to the terms of reference. The client sees how the interface of his future site will look like and says what he likes and what should be changed.

Enumeration of elements is a lazy alternative to prototype. Just write what blocks should be on the page and what they do.

Write down scenarios for using the site

If you are making some kind of non-standard interface, just showing the structure and page thumbnails is not enough. It is important that the entire implementation team and the client understand how visitors will use the site. Scripts are great for this. The script outline is very simple:

• User action.
• Website response.
• Result.

Of course, if you are making a standard business card or landing page, you do not need to write scripts. But if there are some interactive services on the site, it is very desirable.

Read more about use cases on Wikipedia.

Determine who is responsible for the content

Some developers make a site immediately with content. Others put the fish. Still others can write texts, but for an additional fee. Agree on this on the shore and fix in the terms of reference what content you have to prepare.

It is quite difficult to come up with objective criteria for assessing the quality of texts. Better not write anything other than "High-quality, interesting and selling content that is useful for the target audience." It's rubbish, no one needs it.

Specifying that all content must be unique is helpful. Another protection of the client from unscrupulous performers.

Describe the design (if you can)

As with the text, objective evaluation criteria site design hard to come up with. If you and the client have agreed on a color scheme, write it down. If he has a brand book in which fonts are registered, indicate them as well.

It is not necessary to write about beautiful and modern design. It doesn't mean anything, has no power, and generally fu.

Instead of a conclusion: the structure of the terms of reference

For different tasks, the structure of the TOR will be different. It’s stupid to make the same technical specifications for a new social network and a landing page for wholesale carrots. But in general, you need sections like this:

• Information about the company and target audience, goals and objectives of the site.
• Glossary of terms that may not be understood by the client.
• Technical requirements for the layout and operation of the site.
• Description of technologies used and list of hosting requirements.
• Detailed site structure.
• Prototypes of pages or descriptions of the elements that should be on them.
• Scenarios for using a non-standard interface (optional).
• List of content that the developer makes.
• Design requirements (optional).

• Rules for compiling the Software Requirements Specification. SRS is the next step in the evolution of terms of reference. Needed for large and complex projects.
• Standards and templates of TOR for software development. Descriptions of various GOSTs and methodologies for creating technical specifications.

This is the end of the part I wrote. But there is another one - the comments of experts who helped to make the guide. Read it, it's also interesting.

Developer Comments

I spoke with several developers to find out how they write specs. I pass the microphone to them.

First of all, the client needs TK - so that he understands what his site will be like and what the money is spent on. If something is done wrong, he can refer to the TK and ask to redo it.

The TOR is compiled by the project manager after communicating with the client and discussing the task with the designer.

Large customers often ask for very detailed specifications, which describe each button. Small companies, on the contrary, do not like meticulous 100-page documents. It's a long read and it's easy to miss something important. More often we make concise technical specifications for 10-15 pages.

We indicate:

• Information about the company and the purpose of the site.
• Design requirements, colors.
• Used technologies and CMS.
• Who is engaged in the content - we or the client.
• Site structure down to each page.
• Descriptions of each page. We don't make prototypes, but we specify what elements should be on the page and how they should work.

The last 2 sections are the most important. They provide an understanding of what the site will be like and how it will work.

A very important point - you can not just give the terms of reference to the developers and hope that they will do everything well. TK is a list of requirements for the site, it cannot replace communication. It is important to make sure that each team member understands the common goal, and not just performs tasks on the flow. If something is not clear - it is necessary to explain, discuss, give detailed comments.