Technical specifications for the modernization of ventilation in the research institute. Technical specifications for the modernization of ventilation in the research facility Technical specifications for the modification of the storage server

Why is the technical specification needed?

Example of technical specifications for a programmer

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 specifications (TOR, PRD) are dead. We have to partly agree with this - when developing a product from scratch, prototyping looks much more interesting and effective than volumes of customer notes, which are sometimes very unprofessional. However, if we are talking about finalizing the basic system, then things take a completely different turn. We are faced with both modifications and custom development, so the technical specification is a dog-eat-dog, if the chef is not lying to us. In general, today we are talking about those classic technical tasks that are written to finalize the purchased and installed software. In short, about painful things.

Facets of interaction

Resources- people, machines, equipment, development environment, time and money that must be used in the process of implementing the requirements. Resources require clear planning and assessment at the stage of approval of technical specifications. Proper prioritization on the part of the customer and distribution of labor resources on the part of the vendor allows one to avoid missed deadlines and minimize other risks.

Possibilities- in short, this is what the vendor (performer) can actually do. Let's look at the example of our RegionSoft CRM. The client buys the system and draws up a technical specification for modification: it is necessary to create integration with the website and link events in the CRM to the order number of the online store. This is a realistic requirement, we have the resource and the ability to do it. You also need to develop and attach a CMS, a website content management system, to the CRM. 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 for us to allocate 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. But about the “greed” of TK later.

Restrictions- a set of obstacles that make performing tasks from the technical specifications difficult or impossible: budget, technology stack, licensing problems, legislative prohibitions, hardware configurations, etc.

Thus, all four essences are closely intertwined and determine the success of the project as a whole. Let's look at each element and try to highlight the critical points that need to be kept in mind when working on the technical specifications.

Requirements collection and analysis

No one knows your company better than you and your employees. This means that collecting and analyzing 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, find out what to look for and get started. By the way, a good assistant can be your employee who is well versed in the specialized topic and has a rough idea of ​​the software architecture and is familiar with the development process - he can act as an analyst and internal expert, overseeing the process of creating technical specifications and communicating with the vendor.

There are very simple circuit collecting requirements.

1. Create a working group of managers and experienced specialists from departments who will use CRM. Tell us about the solution you intend to choose, provide access to the demo version.
2. Members of the working group should convey information to employees and ask for their suggestions for new program in a completely 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 department then identifies what the CRM doesn't have or doesn't measure up to and aggregates the information.
4. The working group analyzes the collected requirements, checks and eliminates intersections. For example, often the sales department and the marketing department order the same report, but the requirements may have different names for fields and entities, although the data behind them is the same. Accordingly, we need to come to a unified form.
5. The working group creates a list of requirements and sets priorities. At this stage, you can involve 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 with completely different deadlines; priority is very important here.

Anatomy of a technical specification

• Identifying - defining requirements, finding problems that need to be solved.
• Analysis - analysis of requirements, identification of key needs, generalization.
• Adaptation - assessing requirements in the context of CRM capabilities and existing business processes.
• Documentation - formal and detailed description requirements, approval of technical specifications.
• Communication with the vendor (developer) - iterative interaction with the vendor regarding improvements in accordance with the compiled technical specifications.
• Implementation is the work of the vendor to create the necessary functionality. It is better if the vendor is constantly in touch with the customer - this way the final product will most closely correspond to 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 compliance with the modification and technical specifications, and the operability of the system with the changes.

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

User or user group level. At this level, tasks to refine the existing interface are implemented. For example, a user might 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 many of them - for example, several requirements from the marketing, logistics and technical support.

Functionality level. It is often difficult to separate it from the previous one; a formal criterion works here - improvement is not at the level of displaying something in the interface, but at the level of finalizing the system logic. This may 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 be included in new builds with fixes. These are tasks related to system response speed, operation under high load, and security. IN ideal The vendor should not have such modifications - corporate software should not slow down, lose data, collapse forms and distribute access rights of the same level. But if a requirement appears, and it is not related to the customer’s personal paranoia or problems on the side hardware, it is worth paying special attention to it.

Technology level- last on the list, but ahead of the rest in importance and complexity. These could be platform related customer requirements, operating system or devices. For example, a request to build for MacOS. It will be great if such requirements gradually develop into releases, but it is imperative to have fixes for them. It was from customer requests at this level that we built 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 a technical specification is simple, at least in skeletal form. Mandatory parts of the technical specification help the customer to focus on the problem and formulate the task correctly, and the contractor to understand what they want from him. By the way, about understanding. Of course, at the beginning of the post we lied a little, denying business consultants as a class. The point is this: each vendor has been working on the market for several years (we are not talking about one-day CRMs), or even decades, which means they have a set of cases in almost every industry. Accordingly, engineers, programmers, and sales people are familiar with the specifics of implementation in each type of company. But again, it is important to focus specifically on your business.

For whom? In this section, you need to describe who will be the end user of the improvement, what tasks are planned to be solved and with what frequency.

Let me give you an example. One company was implementing CRM and 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 uploading of these records at a “daily” frequency. Naturally, such a report, with hundreds of users working simultaneously, loaded the system - solutions were found to optimize the process. Already during the work, it turned out that the salesman had played it safe and needed the report only at the end of the month, and then it could be run on a schedule at night. Needless to say, time and money were wasted.

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

What should it do? The most informative block - it describes the requirements and expectations from the system. And here the very pearls, miracles and collisions happen that 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 subreason - the user cannot formulate requirements. And here the task of the developer (working group, analyst, if there is one) is to help formulate the need correctly, select an appropriate requirement, and fit the task into the context of the system’s operation. In the same block you need to mention the expected result.

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

Ideally, the technical specification is 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. Cost of work for each stage separately
4. The total cost of work for this technical specification
5. Time frames for completing work, broken down by stages and indicating priority
6. Description of installation conditions and testing of modifications
7. Reservations regarding the exhaustive nature of the terms of reference and other conditions

10 rules written in the tears of a developer

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

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

The 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 will be spent on this or that task. Believe me, it is not beneficial for a developer to waste time and increase deadlines - it is beneficial for him to complete as many projects as possible and do it well, so as not to suffer a blow to his reputation. As for realism, it’s easy to avoid requests to upgrade CRM to the level of a collider management system: you should include in the requirements what is really needed for this moment and in the foreseeable future.

For example, RegionSoft CRM is a desktop program; we do not 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 development for one company. No, of course, everything has its price, but again - in the general case, the requirement is impossible to fulfill.

This should not be confused with the situation when we are talking about custom development and the idea and logic of the application is radically changed; in fact, the creation of new software “for yourself” is sponsored. But that's another story.

The terms of reference must be detailed. It is necessary to indicate all the significant details of the future project: from the frequency of use of 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 detail if you work in a specific industry (medicine, insurance, banks) - a detailed presentation of the nuances of interaction between 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, which must be included in the logic of CRM operation ( for example, calculation of dealer bonuses), these formulas must be written with a full explanation of their designations and calculation logic.

The technical specification must be unambiguous and precise. Vague formulations, implementation options, unclear requirements - all this is a path to a dead end. It happens that a client, out of good intentions, writes in the technical specification several options for the behavior of the system, close but not equivalent. In this case, he is sure that he is helping, prompting 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 characteristics of the system and the stack of technologies used.

The technical specification must be written in human language. And this is important, no, IMPORTANT. I will highlight two situations when language problems lead to delays in project implementation.

1. The client is trying to demonstrate his technical literacy and makes constructions like: “implement a window with a hint into the body of the calendar with the ability to react to call events...” 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 book of complaints. You need to solve the problem, not describe it, paying attention to the fonts and forgetting about describing the requirements. The technical specification must contain not only the problem itself, but also its solution at the level of comprehension - then the developer will solve it at the code level. Compare “The sales department doesn’t plan well, it’s losing numbers, we’ve been struggling for a year now” And “it is necessary to create a report that will save the values ​​of the planned and actual sales monthly, broken down by product groups”.

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

   The terms of reference should not be bureaucratic. If you have ever drawn up this document, you probably felt how difficult it is to avoid the temptation to slide into bureaucracy, add introductory words, strict phrases and describe each point as an article of the Criminal Code (preferably with punishment for everyone for violation). Bureaucratic formulations mask an incomplete understanding of the purposes of creating technical specifications. The vendor's responsibility is specified in the contract, and the budget is also written there. You should not transfer these points into the technical specifications.

   The terms of reference must be technical specifications. It sounds paradoxical, but often instead of technical specifications we read letters, complaints, contracts, newly written instructions for CRM or minutes of a meeting. Of course, it is impossible to work according to such a document. To stay on top of form and content, use an old school trick: look at the term word by word. Technical means it dictates modification, technology, and is aimed at solving a problem by changing the software. This is what we need to talk about in the context of software. An assignment means posing a question, a problem, without advice, tips or preliminary assessments. Just a statement of the problem.

   The commandments are over, now the rebuke

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

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

   

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

   The client is unaware of the stack and technical limitations. And he shouldn’t know - this is the task of the vendor, it is he who evaluates the work after drawing up the technical specifications. The customer should not delve into technology and ask at every comma whether the vendor can do this or that thing. Draw up a comprehensive technical specification and the developer will choose a suitable architecture - often even better than you might think.

   Assess your budget and avoid unpleasant surprises- almost joint task number one. You shouldn’t push the vendor and demand from him an approximate assessment of the work (well, at least approximately, offhand, by eye, but as with others, well, in projects of this type, but from experience, well, within the margin of error). A full budget assessment is possible only after reading, analyzing and final approval of the terms of reference. If your developer acts differently, get ready for the fact that the revision will cost at least twice as much.

   Based on 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 the CRM/ERP of your dreams right away, do not demand from the vendor a “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 assignments; this is a real generator of not only memes and tales, but also headaches. You can talk about priorities and design rules, about GOST 1989, which makes technical specifications inhumane, about IEEE standards, which are a little better, about prototypes and technical specifications that complement them. But in the end I would like to limit myself to one, the most important rule: a technical specification is not a rule of law, not GOST and not a dogma, therefore, if you can improve it, improve it, if you can simplify it, simplify it, if you can do it gracefully and so that everyone likes it, do it. I’m sure that after this, no one will poke their nose at the technical specifications and say that it’s not written there. Or almost no one.

   Throughout December we are giving discounts on RegionSoft CRM and all our own software. From December 1 to December 15 - 15% and steep terms for installments and rentals. We don’t have -70% and -90%, because we keep the price for licenses economically justified, and don’t take it out of the blue.

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

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

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

I often attach page prototypes so that the client understands what his site will look like. Then I draw up 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 technical specification should be. When I participated in large projects, I saw technical specifications that were 30 pages long.

Guram Sipki, founder of digital studio Udix Media

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

The technical specification is drawn up by the project manager after communicating with the client and discussing the task with the designer.

Large customers often ask for very detailed technical specifications, which describe each button. Small companies, on the contrary, do not like meticulous 100-page documents.

An example of a technical task for website improvement

General information

Name of the automated system

"AS Sbyt"

Customer

Executor

Basis for the work

Planned dates for the start and end of work on creating the system

Start of work: 01.09.2010

Completion of work: 12/31/2010

Purpose and goals of creating the system

Purpose of the system

Under development automated system designed to automate enterprise sales processes..

Goals of creating the system

Goals of creating an automated system

The objectives of the development of "AS Sbyt" are:

1. 3. Characteristics of the automation object

3.1 Enterprise business processes

3.1. 1 Business process “Concluding an agreement”

It will become your shield; in this document, if anything happens, you will be able to point your finger at an unscrupulous developer and demand that your site be brought into compliance with it.

Technical task(in short, “TOR”) is a document that reflects the requirements for your future website in as much detail and unambiguously as possible.

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

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

The developer does everything that is not specified in the technical specifications at his own discretion.

· Administrator's Guide;

· Content Manager Guide;

· Installation Guide;

· Programmer's Guide.

2.20. Organizing and conducting 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 at the Prosecutor's Office Russian Federation consisting of no more than 10 people.

· Training must be conducted in Russian.

· Training premises are provided by the Customer.

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

Training must 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.

3.

Sample technical specifications for website improvement

Important

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

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

6.2. The procedure for further support of AS “SALES” tasks.

The TOR must indicate the complexity and cost of work to implement additional requirements.

6.2.2. The Contractor undertakes to maintain a telephone hotline for software support.

Facets of interaction Before we begin to dissect the process of creating a technical specification, let's talk about the quadrangle into which the contractor and the customer find themselves when starting the project. Requirements- the desired behavior of the system, described by the customer or process holder, to be implemented. As a rule, requirements are formed on the basis of work experience and an understanding 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, unnecessary requests, etc. arise.

Resources- people, machines, equipment, development environment, time and money that must be used in the process of implementing the requirements. Resources require clear planning and assessment at the stage of approval of technical specifications.

This may 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 be included in new builds with fixes. These are tasks related to system response speed, operation under high load, and security.

Attention

Ideally, the vendor should not have such modifications - corporate software should not slow down, lose data, collapse forms and distribute access rights of the same level. But if a requirement appears, and it is not related to the customer’s personal paranoia or problems on the hardware side, it is worth paying increased attention to it.

Technology level- last on the list, but ahead of the rest in importance and complexity.

Microsoft World or Microsoft Excel.

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

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

On the topic: Website prototyping: creation, tools and programs.

Pre-project design can be done jointly with the developer or completely transferred to his shoulders.
The main thing is, don’t forget, then it is agreed upon and signed by both parties.

LIFE HACKS FOR DRAFTING TOR

These points apply equally to both filling out the brief and drawing up technical specifications.

And in them I will tell you little tricks on how to draw up technical specifications for a website 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 quality adjectives: beautiful, reliable, modern. They cannot be clearly understood. Everyone has their own concepts of beauty and modernity.

Look. Someone thought this design was beautiful and allowed it to be used on their website:

The same thing happens with vague formulations that don’t mean anything in themselves:

• The customer must like the site. What if he is in a bad mood?
• The site should be convenient. What does it mean? Convenient for what?
• The site must withstand heavy loads. 10 thousand visitors? Or 10 million?
• High-quality expert content. Well, you get the idea.

Check for ambiguities in the text. If there is, rewrite it.

Have you decided to order a website (aka landing page)? As practice shows, it is not so simple. Hundreds of customers, having seen their finished website, discover that it does not suit them: the design is wrong, the layout is lame, the texts are wrong, a bunch of unnecessary functions have been added.

To avoid such consequences, you need technical specifications for website development.

DO I NEED IT?!

It doesn’t matter who will run the site - you yourself, your relative, freelancers for a modest pay, a specialized company for a huge amount of money...

There must be technical specifications for the site.

For example, you can ask to create a custom report for RegionSoft CRM, or you can order integration with the site. These are tasks with completely different deadlines; priority is very important here. After the requirements have been collected, analyzed and agreed upon with employees and management, you can begin to create a technical specification.
You can ask the vendor for the form or create it yourself - in any case, there are several ironclad rules, the observance of which will save you and your CRM supplier headaches.

Anatomy of a technical specification

If we talk about the process of creating a technical specification, there are several stages. Their sequential 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 will be spent on this or that task. Believe me, it is not beneficial for a developer to waste time and increase deadlines - it is beneficial for him to complete as many projects as possible and do it well, so as not to suffer a blow to his reputation.

As for realism, avoiding requests to upgrade CRM to the level of a collider management 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 do not 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 development for one company.

Full and short names 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 “SKP Site”, “System”, “Site”.

1.2. Name of the system customer and his details

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

Location:

Info

Moscow, Tekhnicheskiy lane, building 2

Actual address: A

Customer contact person:

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.

Determined in accordance with the Agreement.

2. System requirements

2.1.

payment date

Payment number

Payment number in the payment system

Amount of payment

1. Select data transfer file lines
2. Start looping through the lines of the data transfer file
3. Read data transfer file line
4. Get the contract code from the data transfer file line
5. Find the corresponding element by code in the “Counterparty Agreements” directory; if the element is not found, then display the message “An agreement with the code was not found...”
6. 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”
7. After receiving the last line of the data transfer file, end the cycle
8. For each row of the value table, create a “Payment order for receipt of funds” document.

When filling out a brief or drawing up terms of reference for a website design, do not leave any gaps in it.

You must understand that “At the discretion of the developer” means “I do what I want” 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 doesn't always happen.

If you come across a competent specialist, then you don’t have to worry about the result.

But here another problem arises: he can actually do it right, but you won’t like it purely subjectively. And everything will be as in the joke known to many developers:

BRIEFLY ABOUT THE MAIN THINGS

You definitely won’t regret the time spent on drawing up and agreeing on the terms of reference for creating a website or landing page.

After all, this is your best tool for monitoring 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 “Blog of the Chairman”- should be a list of the three most recent topics created on the blog in the form of the title of the topic and the date of its publication. The name of the topic will be a link that, when clicked, should take you to a blog page describing this topic. This block should also contain a video that can be played without leaving home page. The video should have a "Comments" link, which represents the number of comments on the given video image. The “Comments” link should lead to a blog page with comments on the submitted video.

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

2.3.

Brief is a questionnaire with questions about content, design, technical capabilities Your future website.

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

After all, this is practically the same thing, the only difference is that the brief is your vision, and the technical specification 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.

Either 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, simply add them at the end of the brief.

VK, Google, Facebook.

3.2.2 V personal account in the orders section, add a field to add a promo code.

3.2.3 Instead of the page that the user receives after a password recovery request (like name.com/bitrix/admin/index.php?change_password=yes&lang=ru&USER_CHECKWORD=), make a page (like name.com/login/forgot/change_password=yes&lang =ru&USER_CHECKWORD=), which will display the site content, will have the “Email upon registration” field, a control line, a new password, password confirmation, and a send data button.

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

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

"_" ______________ 2010

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

User or user group level. At this level, tasks to refine the existing interface are implemented. For example, a user might 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.

Rework at this level takes less time, but there can be many 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 - improvement is not at the level of displaying something in the interface, but at the level of finalizing the system logic.

If it says porridge, perhaps you should run and not look back.

• Insure against the performer's dishonesty. When the site is ready, it can be checked according to the technical specifications. Are there any inconsistencies? The developer is obliged to fix them. If you are collaborating officially and have entered into an agreement, you can even force it through the courts.
• Simplify the replacement of performers. If the client and the developer quarreled and ran away, the creation of the site can take a lot of time. When there is a detailed technical specification, it can be transferred to a new team - they will get involved in the work many times faster.
• Find out the cost of developing a complex product. It is impossible to immediately estimate the exact timing and cost of developing a complex web service. First you need to understand how the service will work and what functions it will have.

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

Google PageSpeed ​​Insights is free service recommendations for websites to speed up page display 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 increase the site’s position in search engine results for specific user requests.

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

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

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

This could be a shopping cart, catalog filters based on various parameters, the ability to place an online order, leave a request for back call, subscribe to the newsletter and any other options Catalog filters by price, alphabetically, by manufacturer.
CRUпtCj9B:s»XVzhb╟▌╤└u╟J_■E╘Dj»J■╛EХHJя(gTT┬Pb╟▌╤└u╟╛#╜┘al+Ka Kqяk3┴i≈²&F╒#┐╜╙ ┐█ ts╜IWA▓BOь└vOZb╟▌╤└u╟╛#╜┘al+KaXG[ b:ьVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:ьVzhb╟▌╤└u╟╛#╜ ┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜│ts&V█7┬m3aqNYJy╕°Vzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:bVzhb╟▌╤└u╟ ╛ #╜┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:bVzhb╒▀┬y╥XuF ≈≈K&ОQТе╦▒'%[н╓≥Lк"[Ц(b╖~ы╚б╖~ы╚б╖~ы╚б╖~ы╚б╖~ы╚б╖~у╚б╖~у ╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚bD'═\┘*NлkZ ⌡ ┐©Tw╦|╒T⌠ZZA╙┼r≤⌠ьЧ≈D7i$╔≥ И∙?БjЛ?Ч╜∙╤SQ≥╒°еNFх═с┬├6ыСыиЪ╖Bl╢╡ LeOь/РЯE∙rrм VC╪ ┬7┴+iSo(╦°rБ╒┴■E4SCg┬╨ z╖ ┘╤m°с÷Уm╦Wыmdр'%R^&╔gt╖yхDA]zт╪L╝i▌▀s_2╫J)E+H ©OlM²K%j ┼╖`СsА≈K▐ф²Yч▐Hd╟Fг╬lн∙╥е#⌡и<Т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▓З╨?.

Remember Murphy's law? If you can be misunderstood, you will certainly be misunderstood. This is true not only in communication between people, but also in creating websites. The client wanted a second Facebook, but got a forum for young dog breeders. The developer did not guess what the customer wanted - 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 technical specifications does not turn into wasted time.

The article will be useful:

• For everyone involved in website creation: developers, designers, layout designers.
• Project managers.
• Heads of digital studios.
• Entrepreneurs who are planning to order website development.

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

What is a technical specification and why is it needed?

A technical specification is a document that sets out the requirements for the site. The clearer and more detailed these requirements are, the better all participants in the process understand what it should be like. This means that the chance that everyone will be satisfied with the result increases.

The main goal of the technical specification is to make sure that the client and the contractor understand each other correctly.

There are many benefits from technical specifications. It is different for each side.

Benefits 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, it’s no problem to change it before development begins.
• See the competence of the performer. If the terms of reference are clear and precise, confidence in the developer increases. If it says porridge, perhaps you should run and not look back.
• Insure against the performer's dishonesty. When the site is ready, it can be checked according to the technical specifications. Are there any inconsistencies? The developer is obliged to fix them. If you are collaborating officially and have entered into an agreement, you can even force it through the courts.
• Simplify the replacement of performers. If the client and the developer quarreled and ran away, the creation of the site can take a lot of time. When there is a detailed technical specification, it can be transferred to a new team - they will get involved in the work many times faster.
• Find out the cost of developing a complex product. It is impossible to immediately estimate the exact timing and cost of developing a complex web service. First you need to understand how the service will work and what functions it will have. For this you need to prepare technical specifications.

Benefits for the performer:

• Understand what the customer wants. The client is asked dozens of questions, shown examples, and offered solutions. Then they write everything down in a single document and agree on it. If everything is ok - hurray, you understood correctly.
• Insure yourself against the client’s sudden wishes. Sometimes you come across customers who want to change the task halfway through. If you have agreed and signed the terms of reference, you are not afraid of this. If something happens, even the court will be on your side.
• Show your competence. A well-prepared technical specification will show the client the expertise of the developers. If the company doubted whether to trust you with website development, doubts will most likely 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 technical specification indicates the structure of the site, the necessary functions and elements on each page. When all the requirements are already before your eyes, all that remains is to design and write the code.

Now let's figure out how to create a good technical specification that performs all these functions.

The terms of reference are drawn up by the performer

In general, anyone can draw up technical specifications. “We need a business card website for a dental clinic” - this is already a technical task. But will it fulfill its functions? Hardly.

A good technical specification is always prepared by the executor: a project manager or a developer. Obviously, a web developer understands more about creating websites than the owner of a cafe or 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 should also participate in the process:

Of course, the customer can sketch out his own version of the technical specifications. Perhaps this will speed up the process of creating the final technical specifications. Or perhaps the result will be garbage that will be secretly thrown into the trash.

Write clearly and accurately

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

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

Look. Someone thought this design was beautiful and allowed it to be used on their website:

The same thing happens with vague formulations that don’t mean anything in themselves:

• The customer must like the site. What if he is in a bad mood?
• The site should be convenient. What does it mean? Convenient for what?
• The site must withstand heavy loads. 10 thousand visitors? Or 10 million?
• High-quality expert content. Well, you get the idea.

Check for ambiguities in the text. If there is, rewrite it. Your wording should be clear and precise:

• The site must load quickly → Any page on the site must have more than 80 points in Google PageSpeed ​​Insights.
• Heavy 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 your e-mail” field and “Subscribe” button → *drawn sketch*.

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

Please provide 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 write this down at the very beginning of the terms of reference.

It’s also worth indicating the purpose of the site and describing its functionality in a nutshell - so as not to end up with an online store instead of a blog.

Explain difficult terms

The first rule of the terms of reference is that it must be understandable 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 clear language, not copy-paste from Wikipedia.

Describe tools and hosting requirements

Imagine that you spent 2 months creating a cool website. Each stage was coordinated with the client - he was delighted. And now it's time to hand in 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, indicate your hosting requirements. You never know, you will do it in PHP - and the client has a server in .NET.

List the requirements for the operation of the site

The site must work in all current browsers and on all types of devices. Yes, this is obvious to any developer and any customer. But it’s better to write to protect the client from work done in bad faith.

Write here the requirements for site loading speed, load resistance, protection from hacker attacks and similar things.

Specify the site structure

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

Talk to the customer and find out what he needs. Gather developers, SEO specialists, marketers, editor-in-chief - and decide what pages are needed on the site. Think about how they will be connected to each other, from which one you can switch to.

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

This is one of the most important stages of working 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- a more visual and unambiguous way. The contractor draws sketches of each page and attaches them to the terms of reference. The client sees what the interface of his future website will look like and says what he likes and what needs to be changed.

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

Describe the 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 execution team and the client understand how visitors will use the site. Scripts are great for this. The scenario diagram is very simple:

• User action.
• Site response.
• Result.

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

Read more about use cases in Wikipedia.

Determine who is responsible for the content

Some developers create a website with content right away. Others place fish. Still others can write texts, but for an additional fee. Agree on this on shore and write down in the terms of reference what content you should prepare.

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

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

Describe the design (if you can)

As with text, it is difficult to come up with objective criteria for assessing website design. If you and the client have agreed on a color scheme, write it down. If he has a brand book in which the fonts are specified, indicate them too.

There is no need to write about beautiful and modern design. It doesn't mean anything, has no power and generally ugh.

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

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

• Information about the company and target audience, goals and objectives of the site.
• A glossary of terms that may not be clear to the client.
• Technical requirements for the layout and operation of the site.
• Description of the technologies used and a list of hosting requirements.
• Detailed site structure.
• Prototypes of pages or descriptions of 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 Software Requirements Specification. SRS is the next step in the evolution of the technical specifications. Needed for large and complex projects.
• Standards and templates of technical specifications for software development. Descriptions of various GOSTs and methodologies for creating technical specifications.

This is the end of the part that I wrote. But there is another one - comments from specialists who helped make the guide. Read it, it's interesting too.

Developer Comments

I talked to several developers to find out how they create technical specifications. I pass the microphone to them.

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

The technical specification is drawn up by the project manager after communicating with the client and discussing the task with the designer.

Large customers often ask for very detailed technical 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 of 10–15 pages.

We indicate:

• Information about the company and the purpose of the site.
• Requirements for design, color scheme.
• Technologies and CMS used.
• Who produces the content - us or the client.
• The structure of the site 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 are the ones who provide an understanding of what the site will be like and how it will work.

A very important point - you can’t just give the terms of reference to the developers and hope that they will do everything well. Technical specification is a list of requirements for the site; it cannot replace communication. It's important to make sure that each team member understands the overall goal and isn't just doing tasks on the fly. If something is unclear, it is necessary to explain, discuss, and give detailed comments.

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 technical specifications should be drawn up by the customer - only he knows what he needs. But in practice, due to the customer’s low competence in the 1C field, this often has to be done by the contractor. The customer verbally voices his needs, and the programmer (consultant) puts it in writing.

Why do you need technical specifications?

Any, ideally, should be accompanied by technical specifications. This is, firstly, a clear definition of the task, deadlines and method of implementation. Secondly, this is a document with the help of which all controversial issues in the future are resolved. Whether to write technical specifications or not is, of course, your business; for me personally, technical specifications make my work and communication with the client easier.

Get 267 video lessons on 1C for free:

What should the terms of reference contain?

Those. the assignment must contain:

• target— the problem that we will solve by implementing this specification;
• description— a summary of upcoming improvements;
• implementation method— a detailed description of methods for solving the goal. At this point, it is necessary to describe all the nuances of the task in the programmer’s language: what kind of tasks we are creating/editing, what the interface should look like, etc. If you do not speak “programmer language”, but “have heard something”, it is better not to try to write in a technical language - it turns out to be quite fun. The description should be unambiguous and not raise questions. It may also contain an example of implementing a similar solution in another area;
• performance evaluation- 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, but sometimes the customer insists on it.

From experience, when handing in work, situations very often arise like “we told you then...”, which is not very pleasant, and often you have to redo the entire work. Therefore, a well-written technical specification makes life much easier for both parties.

Examples and samples of technical specifications for 1C

A small selection that I found freely available on the Internet. Starting from the simplest and most accessible to quite complex documents.