Terms of reference for revision. Terms of reference for the modernization of ventilation in research institutes

09.03.2022

Registration

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

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

Why is a specification needed?

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

Get 267 1C video lessons for free:

What should the terms of reference contain?

Those. The assignment must include:

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

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

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

Examples and samples of TK for 1C

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

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 really 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 need to be kept 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.

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.
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.
Each division then determines what the CRM does not or does not match and aggregates the information.
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.
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. It is often 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:
Description of the requirement of each mechanism and each functionality

Description of the implementation of this functionality

The cost of work for each of the stages separately

The total cost of work on this technical task

Deadlines for the execution of work with a breakdown by stages and an indication of the order of priority

Description of installation and testing conditions

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.

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 TK inhuman, about IEEE standards, which are a little better, about prototypes and TK that complements them. But in the end, I would like to confine 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 development. 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.

Many are faced with the fact that it is quite difficult to explain briefly and clearly what we want in everyday life. And when you need to give a task to a specialist to write a program for an organization or individual entrepreneur, taking into account the features and your own wishes for functionality, then you can generally “hang”.

Who should write the TOR?

Of course, the terms of reference must be provided by the customer, because he certainly knows his needs and capabilities. But, as practice shows, the vast majority of customers are not competent in the field of 1C. That is why the performer himself is often forced to delve into the needs of the customer, understand what final product he needs, and accordingly arrange all this in writing for the programmer.

Why is a specification needed?

In an ideal situation, with one or another refinement in the 1C software product, a technical task is necessary. First of all, the tasks, deadlines and method of execution should be spelled out.

This is an important document, because in the event of any controversial issues, the competent development of terms of reference will become the starting point in negotiations.

It is up to everyone to decide whether to draw up a TOR or not, but this will definitely not be superfluous: it will simplify communication with the client and give the work a businesslike and concrete character.

Let's designate a list of the most important items that should be in the terms of reference:

1. Purpose / Task. Formulate what should be implemented in the end.

2. Description. Briefly describe the content of the planned improvements.

3. Method of implementation. Describe in detail the methods by which the goal is to be achieved. It is necessary to register all the features of the task in the programming language: registers, directories (create or edit them); interface design, etc. For those who are unfamiliar and have only heard something about a specific programmer language, we advise you not to make unnecessary attempts to “speak” in a technical language. Because Ideally, a description is a dry statement that excludes ambiguity and the possibility of unnecessary questions. In addition, this paragraph may include an example of how such programming has already been done somewhere.

4. Evaluation of work. This item is very important - it needs to describe labor costs.

Two more important points: there are approved standards for writing technical specifications - GOSTs. They are rarely used now, but some clients may ask to use them in the old fashioned way.

And secondly, when the work is handed over, such a thing may arise - “but we kind of asked you to do this and that then ...”. There is a chance that you will have to start doing everything from the very beginning.

Therefore, we repeat that a well-written TOR will be useful for both the customer and the contractor.

Example of TOR for a programmer

Terms of reference 1C for the revision of external processing

Target
It is necessary to set up uploading data from 1C to the bank's AWP.

Description

In connection with the transition of the organization to the configuration 1C “Salary and personnel of a state institution”, it is required to develop other processing that would carry out similar functionality on the new configuration.

Uploading data should be based on the documents "Application for Opening Personal Accounts of Employees" and "Statement for Paying Salaries to the Bank".

Initial data

Available processing for the 1C configuration “Salary of a budgetary institution”, which uploads data from the document “Application for Opening Personal Accounts of Employees” and other directories and registers to a DBF file for data exchange with a standard bank AWP.

Processing unloads data into the TAB_N, NAME, SERNUM, PASSCODE, PDAT, PWHR, BIRTHDAY, POSTINDEX, COUNTRY, CITY, STREET, REGION, BUILDING, CORP, FLAT, BPLACE, CITIZEN fields the relevant information from the 1C configuration previously entered in the specified document and other accounting tables. The personnel number, full name of the employee, his passport and address data, birthday and citizenship are uploaded.

Way of implementation

These will be external reports and processing using the extension mechanism, if the current database compatibility parameters and platform capabilities allow it. When changing the database configuration, you should create: directories, documents, registers.

Job evaluation

P 5 working days of the programmer's work are required.

I often attach page prototypes so that the client understands how his site will look like. Then I compose a separate task for the layout designer - with technical details and explanations that will help in his work.

The more complex the task, the more detailed the TOR should be. When I participated in large projects, I saw terms of reference and 30 pages.

Guram Sipki, founder of digital studio Udix Media

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.

An example of a technical task for finalizing a site

General information

Name of the automated system

"AS SALES"

Customer

Executor

Basis for work

Scheduled dates for the start and completion of work on the creation of the system

Start of works: 01.09.2010

Completion of works: 31.12.2010

Purpose and goals of creating the system

Purpose of the system

The automated system being developed is designed to automate the sales processes of an enterprise.

The goals of creating a system

Goals of creating an automated system

The goals of AS SBYT development are:

3. Characteristics of the automation object

3.1 Business processes of the enterprise

3.1. 1 Business process "Conclusion of the contract"

It will become your shield, in this document you, in which case, you can point your finger at an unscrupulous developer and demand that your site be brought into line with it.

Technical task(shortly “TOR”) is a document that reflects the requirements for your future site in the most detailed and unambiguous way.

The site is created on the basis of TK. The more detailed and unambiguous it is, the more your new site will meet your expectations.

Terms of reference for the creation of the site - as a law, should not allow interpretations and discrepancies.

Everything that is not spelled out in the TOR, the developer does at his own discretion.

· Administrator's guide;

· Content Manager Guide;

· Installation guide;

· Programmer's guide.

2.20. Organization and conduct of training for specialists of the Investigative Committee under the Prosecutor's Office of the Russian Federation

The following training requirements apply:

· The Contractor must conduct training for employees of the Investigative Committee under the Prosecutor's Office of the Russian Federation, consisting of no more than 10 people.

· Training should be conducted in Russian.

· The room for training is provided by the Customer.

· Place and time of training must be agreed with the Customer.

Training should be conducted on all functionality of the System.

As part of the training, it is necessary to carry out the information content of one pilot site of the Ring of Sites of the Investigative Committee under the Prosecutor's Office of the Russian Federation.

Sample terms of reference for website development

Important

During the implementation process, the Contractor shall provide assistance to the Customer within the framework of the Implementation Schedule.

6.1.11. In the event of poor preparation of the Customer's personnel for implementation and the need for additional assistance by the Contractor for the successful implementation of the software, an additional protocol for agreeing on contractual prices for the provision of information and consulting work should be drawn up.

6.2. The procedure for further support of the tasks of AS "SALES".

After the software is put into operation, additional improvements and wishes of the Customer can be implemented according to the TOR agreed with the Customer.

The TOR should indicate the labor intensity and cost of work to implement additional requirements.

6.2.2. The Contractor undertakes to maintain a telephone "hot line" for software maintenance.

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.

These include requirements for various kinds of sorting, chat integration, and telephony capabilities.

Attention

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.

Microsoft World or Microsoft Excel.

Personally, when developing a landing page, we use special software products.

With their help, you can quickly and easily draft even complex sites - this is, for example, Balsamiq. However, how we make the entire prototype has already been described in the article.

On the subject: Site prototyping: creation, tools and programs.

Pre-project design can be done jointly with the developer or completely shifted to his shoulders.
The main thing, do not forget, then agree on it and sign it by both parties.

LIFE HACKS FOR DEVELOPING TOR

These points apply equally to both filling out the brief and drafting the terms of reference.

And in them I will reveal to you some tricks on how to create a technical specification for the site and make the already difficult life of an entrepreneur easier:

1.

Make sure that the client and the performer understand each other correctly.

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.

Have you decided to order a website (aka a landing page)? As practice shows, it is not so simple. Hundreds of customers, having seen their finished site, find that it does not suit them: the design is not the same, the layout is lame, the texts are missing, they screwed in a bunch of unnecessary functions.

To avoid such consequences, you need a technical task for the development of the site.

DO I NEED IT?!

It does not matter who will be the executor of the site - you yourself, your relative, freelancers for a modest payment, a specialized company for a huge amount of money ...

The terms of reference for the site should be.

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.

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.

Full and short name of the information system

The full name of the system is the official website of the Investigative Committee under the Prosecutor's Office of the Russian Federation.

The short name of the system is "Site SKP", "System", "Site".

1.2. Name of the customer of the system and his details

Name: Investigative Committee under the Prosecutor's Office of the Russian Federation

Location: Mr.

Info

Moscow, Technical lane, building 2

Actual address: A

Contact person of the Customer:

Phone: (4, (4;

E-mail address

1.3. List of documents on the basis of which the System is created

State contract No. ________________ dated ___ ___________ 2010

1.4.

Planned start and completion dates for the creation of the System

Determined in accordance with the Agreement.

2. System requirements

2.1.

payment date

Payment number

Payment number in the payment system

Amount of payment

Select Data Transfer File Lines
Start Looping Through Lines of Data Transfer File
Read line of data transfer file
Get the contract code from the line of the data transfer file
Find the corresponding element by code in the "Agreements of counterparties" directory, if the element is not found, then display the message "The agreement with the code was not found ..."
If the element is found, then add a line to the table of values, where: "Agreement" - the found element, "Date" - "Data_plat", "Payment Number" - "Nomer_plat", "Amount" - "Summa_plat"
After receiving the last line of the data transfer file, end the loop
For each line of the table of values, create a document "Payment order receipt of funds".

When filling out a brief or compiling a specification for the design of the site, do not leave spaces in it.

You must understand that “At the discretion of the developer” means “what I want, I turn back” or “Everything that is not specified is done at the discretion of the performer”. And believe me, this is not just a loophole, but a whole window to Europe for the developer.

And of course, this is not always the case.

If you got a competent specialist, then you can not worry about the result.

But here another problem arises, he can really do it right, but you will not like it purely subjectively. And everything will be like in a joke known to many developers:

BRIEFLY ABOUT THE MAIN

You will definitely not regret the time spent on compiling and agreeing on the terms of reference for creating a website or landing page.

After all, this is your best tool for controlling and resolving disagreements that arise in the process.

When you click on a particular district, it should go to a page with a text description of this district.

· Block "Chairman's Blog"- should be a list of the last three topics created on the blog in the form of a topic name and the date it was published. The title of the topic will be a link, when clicked, it should take you to the blog page with a description of this topic. Also, this block should contain a video that can be played without leaving the main page. The video must have a "Comments" link, which is the number of comments on the video. The "Comments" link should lead to a blog page with comments on the submitted video.

The footer should contain a search field, copyright information, etc.

2.3.

brief- this is a questionnaire with questions about the content, design, technical capabilities of your future site.

Of course, a detailed brief, signed by both parties, can replace the terms of reference.

After all, this is practically the same, the only difference is that the brief is your vision, and the terms of reference is the final document based on your brief and the developer's comments themselves.

If certain points cause difficulties, then do not hesitate to ask the developer questions like “What does this mean?”, “How will this affect the operation of my site?”, Since not all developers understand the same thing as you.

Or in the column “Additional information” be sure to indicate all your wishes that were not included in the answers to the questions.

If this column is missing, just add them at the end of the brief.

VK, Google, Facebook.

3.2.2 In your personal account in the orders section, add a field for adding a promo code.

3.2.3 Instead of the page that comes to the user after a password recovery request (of the form name.com/bitrix/admin/index.php?change_password=yes&lang=ru&USER_CHECKWORD=), make a page (of the form name.com/login/forgot/change_password=yes&lang =ru&USER_CHECKWORD=), which will display the content of the site, will have the "Email during registration" field, a control string, a new password, a password confirmation, a button to send data.

3.2.4 When adding items to the cart, a message should be displayed stating that the item has been added to the cart.

3.2.5 Add a message that the password does not match the security settings when registering a new user.

automatedSALES system.Technical task On sheets Valid from "__" ____________ 2010

» _» ______________ 2010

Gradually, the changes were included in the release, and later allowed to create a new product for wholesale, retail stores and hypermarkets - RegionSoft Retail.

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.

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.

There is root access, private IP addresses, ports, filtering rules and routing tables.

Google PageSpeed Insights is a free recommendation service for websites to speed up page rendering in the user's browser (https://developers.google.com/speed/pagespeed/insights/).

Search engine optimization (or SEO) is a set of measures for internal and external optimization to raise the position of the site in the results of search engines for certain user requests.

External site optimization is site registration in search engines, promotion in social networks, link building by attracting links from other resources to the site being promoted, banner advertising, contextual advertising.

Internal site optimization is the optimization of text, URLs, editing the site structure, relinking, checking server responses.

Available materials Links to the sites you like, as well as booklets, magazines, photographs - anything, or maybe you have a ready-made brand book. Attached in a separate archive. Minimum resolution and display devices In this paragraph, specify the devices from which you intend to view the site - PCs, laptops, smartphones ... PC monitors from 19 to 27 inches; Notebooks from 15.6 to 17.3 inches; Smartphones from 3.5 to 6 inches; Tablets from 7 to 12 inches Do you need a mobile version? Yes FUNCTIONAL REQUIREMENTS Approximate set of modules (for users) In this section, you need to list all the functionality that you want to see on the site.

This can be a shopping cart, catalog filters by various parameters, the ability to place an online order, leave a request for a call back, subscribe to a newsletter, and any other options. Catalog filters by price, alphabetically, by manufacturer.
CRUпtCj9B:s»XVzhb╟▌╤└u╟J_■E╘Dj»J■╛EXHJya(gTT┬Pb╟▌╤└u╟╛#╜┘al+Kqяk3┴i≈²&F╒#┐╜╙┐█ ts╜IWA▓BOЬ└vOЗb╟▌╤└u╟╛#╜┘al+КaXG[ b:ьVzhb╟▌╤└u╟╛#╜┘al+КaXG[ b:ьVzhb╟▌╤└u╟╛#╜ . #╜┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:bVzhb╒▀┬y╥XuF ≈≈K&ОQТё╦▒'%[n╓≥Lk"[Ts(b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~y╚b╖~y ╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚bD'═\┘*NlkZ ⌡ . . ©OlM²K%j ┼╖`СsА≈K▐f²Yh▐Hd╟Fg╬lн∙╥е#⌡i<ТC▐╡И&d╨JГ!─Sj║·K,s┼#m ╓⌡JГн IOLЬ©h?ОeН╡▐┌ъHЙmwд$©aЗ$ёу°Н≤gт.bZ┐}Э1црn▄т≈фГ?TA<э:р▓T<кГ║2ic╖▀Иqf⌠Pсс▀32нЫ╘▌n-«÷0i╦▓Q:⌠^%5#⌡Н⌡│ вЬ└%N╙Оtб}8яца╨з≤[╖┐╕■╡╒4╞▄G√≥оЖNa╡vсM╔)9╘д≈ib╕╝■ i├{≈²5╨∙∙╣ф╒▓Цz²┌Ф╤I√HaО2┬б=└Б╦F∙P»гЙz&╔Р3{ ёS÷_н_g7⌡г$Н╜чk┐(ЗQэH▓З╨?.