Correct technical specifications for software development are the secret of a successful project. Development of technical specifications. What is it, why is it needed, where to start and what should it look like? Task for the development of technical specifications

What is a technical specification? How to do it and what is it for? Examples, samples, tips and recommendations.

It would seem how great it is when someone understands you perfectly. You gave out a few phrases and here it is, exactly what you imagined. Unfortunately, it doesn't work that way.

The problem of information perception is eternal. The “broken phone” effect is a common occurrence. But what about if you simply don’t know how to set a task? Yes, this also happens and you need to work with it somehow, but how? To ensure that the results of the tasks you set meet your expectations, write a technical specification.

What is a technical specification

Technical specification (or TOR) is a document that contains the customer’s requirements for the products or services provided by the contractor. In simple words: I want to have seven mutually perpendicular lines, and also draw some in red, and draw some colorless (I recommend watching a video about this topic at the end of the material).

Design Bureau

This document can take up either one A4 page or a whole volume, it all depends on the tasks and wishes that are included in it. For example, you can write a technical specification for a small landing page (one-page website) or for complex software with machine learning and other features.

Why do you need technical specifications?

• To assign tasks to performers.
• To describe in detail what you want to get at the end.
• To agree on the order of work.
• To evaluate and accept the work after implementation.
• To...(add your options in the comments).

In fact, there are much more purposes and advantages of the technical specification than in the list above. For me personally, the main task that technical specifications solve is the implementation of what I need with minimal deviations from expectations (my expectations).

Thanks to technical specifications, you can always ask about implementation time, money and compliance with the declared characteristics of the final product or service.

In fact, this is a serious document that is drawn up by the customer and the contractor. To the extent that penalties and obligations of the parties are prescribed. There are a number of GOSTs, read more on Habré.

Development of technical specifications

If we are talking about a “grown-up” game, for example, a technical task for the development of a mobile application or website, then this is a separate job for which a lot of money is paid. You attract a person, usually a former or current Chief Technical Officer, and ask him to help you.

Having a beard is optional

Depending on the scope of the project/tasks, this person collects all your “wants”, translates them into technical language, maybe prepares sketches (what it should approximately look like) and gives you the finished document. Next, you hand over this document to the performers (a team within your company or outsourced), agree on money, deadlines, and get to work.

Tip: The CTO should be on your team, otherwise you will most likely miss something during the implementation process. You simply don’t have enough knowledge for everything. Whoever participated in writing the technical specifications checks it.

What does the technical specification consist of?

Everything will depend on the template you choose (a little further I will give some links to templates/examples), but there are basic blocks that are included in the technical specifications:

1. Description of the project/task. We briefly write what the project or task is that needs to be completed.
2. Purpose and goals. What are the goals for the project?
3. Requirements. Design, functions, technologies that are needed.
4. Description of work. What, when and how will be done.
5. Control and acceptance procedure. How the work will be accepted, what can be considered completed.
6. Applications. Sketches, sketches, prototypes.

The cost of the work is usually included in a separate appendix to the contract, but it happens when the parties specify the amounts in the technical specifications themselves.

Sorry to interrupt reading. Join my telegram channel. Fresh announcements of articles, development of digital products and growth hacks, everything is there. I'm waiting for you! Let's continue...

Examples of technical specifications

Despite the fact that the development of technical specifications is a complex process, it is very interesting. Your task is to recreate the picture of the final result, and then describe it in parts.

An example of one of my terms of reference for updating the Smart TV application. Tasks for more complex and complex products were compiled with the help of colleagues from the technical department. Do not hesitate to ask your teammates for help, involve them in the process as often as possible. And don't forget to give feedback! There is nothing worse than putting effort and time into something without knowing the results. Tell us how the person’s advice was useful in your work, otherwise, it’s a one-sided game.

Terms of reference for the development of an online store

Terms of reference for the development of a mobile application

Terms of reference for the site

Terms of reference for services/updates

If you need more samples, just Google it.

The main recommendation is to do this. The trouble is that mother laziness overcomes everyone and it is not easy to resist it. Gather all your willpower and start writing technical specifications, just write and don’t stop. Don’t worry that it doesn’t work out “perfectly”, I’ll tell you a secret, this never happens. Just write, it will get better and better every time.

This is how it should be

My first rudiments for writing technical specifications began to appear several years ago. I worked with designers and was tasked with creating creatives for advertising campaigns. I wanted it incoherently and it turned into a lot of wasted time and explanations. Over time, the setting of tasks began to turn into some kind of semantic blocks, and then into something like a technical specification.

For example, for the task “Like button on the site”:

1. Description: you need to create a “Like” button on our website.
2. Purpose and goals: user involvement, issuance/rating of materials based on the number of likes.
3. Requirements: the following design (example: a link to something similar), functionality (any user can rate the picture and like it, the site system takes into account the number of likes and changes the output of materials), technology (available on desktop and mobile versions of the site).
4. Description of work: draw 3 options for button layouts (date of completion: 10/01/17), develop a system for distributing materials based on likes (date: 10/14/17), function testing (date: 10/16/17), release (date: 10/17/17)
5. Acceptance of work: the user presses the like button, the system counts the click, and the delivery of materials changes.
6. Applications: sketches, sketches, examples of projects where a similar function works.

Leave for yourself those sections and parts of the structure that are needed for your tasks. For example, the sixth block “Applications” can be described in functional requirements. Basic advice: one way or another, describe the task according to the structure of the technical specifications. This way, you won’t miss important points and save yourself from unnecessary questions, while making life easier for your colleagues.

Here you go

We looked at what a technical task is and how to do it. Now you have the ability to clearly and clearly set tasks, convey your thoughts to other people and save time on additional explanations. I hope now you know what to do with all this.

Glossary

Other technical terminology is understood in accordance with current standards and recommendations of international bodies responsible for standardization issues on the Internet.

General provisions

Subject of development

The subject of development is the Internet site of the company "...", LLC, with a dynamic content management system based on a web interface.
Purpose of the site:
- providing information about the company LLC “...”;
- providing information about the activities of LLC “...”;
- etc.;
- pr.

The purpose of creating the site: ... .

Purpose of the document

This document provides a complete set of requirements for the implementation of the LLC "" website.
The signature of the Customer and the Contractor on this document confirms their agreement with the following facts and conditions:
1. The Contractor has prepared and developed this document, called the Technical Specifications, which contains a list of requirements for the work performed.
2. The Customer agrees with all the provisions of this Technical Specification.
3. The Customer has no right to demand from the Contractor, within the framework of the current Agreement, the performance of work or the provision of services not expressly described in this Technical Specification.
4. The Contractor undertakes to perform work in the scope specified in this Technical Specification.
5. The Customer has no right to demand that the Contractor comply with any formats and standards if this is not specified in this Technical Specification.
6. All ambiguities identified in this Terms of Reference after its signing are subject to bilateral agreement between the Parties. During the approval process, additional requirements may be developed, which are formalized in an additional agreement to the Agreement and assessed accordingly.

Requirements for website graphic design

Website design requirements

When developing a website, predominantly light styles should be used.
The main sections of the site should be accessible from the first page.
The first page should not contain a large amount of text information.

The site design should not include:
- flashing banners;
- a lot of merging text;
- etc.;
- pr.

The procedure for approving the design concept

The design concept is understood as a design option for the main page and the graphic shell of the internal pages, demonstrating the general visual (compositional, color, font, navigation) solution of the main pages of the site. The design concept is presented as a file (several files) in raster format or in printout as agreed by the parties.
If the design concept presented by the Contractor satisfies the Customer, he must approve it within five working days from the date of presentation. At the same time, he can send the Contractor a list of private improvements that do not affect the general structure of the pages and their style. These improvements are carried out in parallel with the development of software modules for the site. Changes to the design concept after its acceptance are permitted only by additional agreement of the parties.
If the presented concept does not satisfy the Customer’s requirements, the latter provides a reasoned refusal to accept the concept, indicating the details that served as an obstacle to the acceptance of the concept and a clearer formulation of the requirements.
In this case, the Contractor develops a second version of the design concept. The Contractor accepts obligations to develop the second version of the design concept only after agreeing and signing an additional agreement to extend the design concept development stage for a period of at least five working days.
Additional (third and subsequent) options are developed by the Contractor for a fee based on additional agreements.

Functional Requirements

Requirements for website presentation

Requirements for the presentation of the main page of the site The main page of the site should contain a graphical part, a site navigation menu, as well as a content area so that the site visitor from the first page can receive introductory information about the company, as well as get acquainted with the latest company news.
The content area of ​​the first page should be divided into the following sections:
- an introductory article about the company with a “more details” link leading to the “About the company” section;
- news - contains 3 latest news (announcements) in the format: date, title, summary;
- brief contact information - telephone number and e-mail of the company;
- a lightweight navigation bar is displayed at the top of the page, which provides transition to the main menu items of the site (About the company, News, etc.);


- counters and a link to the link exchange page.

Rice. 1. An example of placing elements on the main page.

Graphic shell of internal pages (common for all subsections)
The graphical shell of internal pages should be divided into the following sections:
- graphic header
- site navigation menu (navigation panel 2 provides transition to the main site menu items);
- search field - designed to perform a full-text search on the site;
- language selection field - Russian\English;
- “Home” link;
- navigation panel for subsections of the selected section of the site;
- a field for displaying the content of the selected site page;
- at the bottom of the page - brief contact information - phone number and e-mail of the company;
- “For Printing” button - provides output of the content area in the form cut out for printing on A4 sheets;
- “Ask a question” button – provides a transition to the “Ask a question” form.

Rice. 2. An example of placing elements of the internal pages of the site.

Requirements for the site structure
All site section names given below are conditional and can be adjusted by agreement with the Customer during the design process.
The initial structure of the site should look like this:
- About the company

a. Company history
b. Diplomas and certificates
c. Our partners
d. Our clients
e. Our coordinates
f. ...

2. News
3. etc.
4. ave.

Requirements for a content management system

General requirements for the administrative part
To gain access to the administrative part of the site, you must specify a specific address in the browser line and go through authorization.
The main page of the administrative part should contain the following menu items:
- Site pages (in accordance with the first level of the site structure):

About the company
- News
- etc.;

Rice. 3. Layout of the form of the main page of the administrative part of the site.

Requirements for managing website sections
To manage sections of the site, the following functions should be provided:
- creation of a subsection of level 1;
- creation of subsection 2 (and further) level;
- editing page content;
- deleting a section;
- moving a section up in the list;
- moving a section down in the list;
- a sign of showing (show) or not showing (hide) the page in the client part of the site;
- displaying a list of subsections of the selected level.

Website content management
To manage the content of the site, the following blocks should be provided:
1. content element field, can be one of the following types:
- line;
- date;
- link to the file;
- multi-line text;
2. content element - consists of a set of content element fields;
3. list of content elements - consists of a set of content elements.

Rice. 4. Content element fields.

The Text content element field must be edited on a separate page in a multi-line text editor (this editor allows images to be included in the text).

Rice. 5. Multiline text editor in the administrative part.

For each content element, the required set of fields must be defined. For example, for the “News” element the following set of content fields is defined:

Rice. 6. An example of presenting the “News” content element in the administrative part.

The list of content elements should allow:
. go to editing list item fields;
. delete list element;
. determine the order of the output list elements in the client part;
. specify the hide\show attribute.

Rice. 7. An example of presenting a list of content elements in the administrative part and displaying them in the client part.

The list of elements should display all fields of the element, except for fields of the “Multiline text” type.

Manage site settings
Site settings should include:
- e-mail for...;
- etc.;
- pr.

Additional functions of the administrative part
Additional functions of the administrative part should include:
- …;

Requirements for sharing access

All published sections of the site must be open for read access without user authentication.
When attempting to enter a closed section, an unauthenticated user must be prompted for a login and password.
After authentication, the system must check the user's authority to access the requested section. If access is denied, the user should receive a message indicating that they cannot access the restricted section.

Requirements for types of collateral

Requirements for information support

Data storage requirements
All site data must be stored in a structured form under the control of a relational DBMS. Exceptions are data files intended for viewing and downloading (images, videos, documents, etc.). Such files are stored in the file system, and links to them are placed in the database.
The content of various sites, the functioning of which is supported by the same system installation, must be stored under the control of a single DBMS.
Programming language requirements
HTML 4.0 and CSS languages ​​must be used to implement static pages and templates. The source code must be developed in accordance with W3C standards (HTML 4.0).
To implement interactive elements of the client side, JavaScript and DHTML languages ​​should be used.
To implement dynamic pages, the PHP language must be used.
Requirements for organizing hyperlinks
All links on the site must be relative (with the exception of external links).

Requirements for illustrations
All drawings and photos larger than 1 kb (except for page design elements) must be made with alternative text. All drawings must be in gif or jpg format.
Requirements for the volume of one page
The average size of one standard loaded website page should not exceed 170 kb.
The size of the flash screensaver should not exceed 300 Kb.

Software requirements

Server software requirements
The following software is required for the site to function:
- Operating system - Windows XP and Windows Server 2003;
- Web server - Apache version no lower than 1.3.26;
- DBMS - MySQL version no lower than 3.23;
Client software requirements
The site must be fully functionally viewable using the following browsers:
. MS IE 5.0 and higher;
. Opera 6.0 and higher;
. Mozilla Firefox 1.0;
. Mozilla 1.7.
The site must be functional (the information located on it must be accessible) when Flash and JavaScript support is disabled in the browser.

Technical requirements

For the website to function, the following technical support with the following minimum characteristics is required:
- processor - Intel Pentium III 1 Ghz;
- RAM - 512 Mb RAM;
- hard drive - 20 Gb HDD.
- etc.;
- pr.

Requirements for linguistic support

The site must be in Russian and English. It should be possible to switch between Russian and English on any page of the site.

Requirements for ergonomics and technical aesthetics

The site should be optimized for viewing at a resolution of 1024*768, 1280*1024 without a horizontal scroll bar and without empty (white) fields for the main resolution types.
Control elements should be grouped in the same way - horizontally or vertically - on all pages.
Each page should display the company logo and contact information.
The interface of plug-in modules must be made in the same style as the system kernel interface and must provide the ability for the administrator to transparently move between system modules and use the same control procedures and navigation elements to perform the same type of operations.

Requirements for project acceptance and delivery

Requirements for filling information

General requirements for information content
As part of the work on this project, the Contractor ensures that sections of the site are filled with materials provided by the Customer in the manner specified in clause 6.1.2.
The Contractor ensures the processing of illustrations to bring them into compliance with technical requirements and the HTML layout of the prepared materials. Scanning, typing and editing-proofreading of texts, retouching, editing, translation and other work can be performed by the Contractor on the basis of an additional agreement (after reviewing the materials available to the customer).
After the system is put into operation, the information content of the sections is carried out on the basis of a site support agreement.
The volume of text and the number of illustrations in other types of sections are determined by the data structure provided for in this TOR and are clarified at the stage of approval of the design concept.
Procedure for providing information content
The customer provides materials in electronic form in a zip archive containing a tree of directories corresponding to the structure of the site.
Each directory contains a set of documents in MS Word format - one document for each information module, the information blocks of which are published in the corresponding section. It is not permitted to place text in the form of graphics or other non-text elements.
Images can be placed either in text inside the file or as a separate image. However, in the latter case, the text must contain a link to the image in the form of the path and name of the image file.
For each information module, the structure of the document must correspond to the templates provided by the Contractor before the start of the stage of providing materials.
Materials for the initial filling of sections must be fully submitted to the Contractor within the time limits established by the work schedule. It is allowed to transfer materials in parts, in several zip files that meet the above requirements.
The transfer of materials in the volume and format corresponding to this TOR is secured by signing the Certificate of Transfer of Information Content.
Any changes to the information content by the Contractor after signing this Act are permitted only on the basis of a separate agreement for an additional fee.
Information materials not provided by the Customer within the time limits established by the work schedule are posted by the Contractor according to the Contractor's letter of guarantee within 2 weeks after the project is handed over and accepted. This part of the information materials is also subject to the requirements for the presentation format set out above.

Personnel requirements

To operate the web interface of the dynamic content management system, the administrator should not require special technical skills, knowledge of technologies or software products, with the exception of general skills in working with a personal computer and a standard web browser (for example, MS IE 6.0 or higher).

Distribution provision procedure

Upon completion of development, the Contractor must provide the Customer with a system distribution kit consisting of:
-archive with source codes of all software modules and sections of the site;
- dump of the project database with up-to-date information.
The distribution is provided on a CD as a file archive.

The procedure for transferring the site to the customer’s technical means

After completion of site acceptance, within the framework of warranty support, the Contractor performs a one-time transfer of the developed software to the Customer’s hardware. Compliance of the software and hardware platform with the requirements of this document is ensured by the Customer.
Before the transfer, the Customer provides remote shell access to the web server and access to the site database.

And so, the main standards, methodologies and bodies of knowledge that mention TK or SRS (Software (or System) Requirements Specification):

GOST 34
GOST 19
IEEE STD 830-1998
ISO/IEC/IEEE 29148-2011
RUP
SWEBOK, BABOK, etc.

GOST 34

According to GOST 34, the technical specification must include the following sections:

1. General information
2. Purpose and goals of creation (development) of the system
3. Characteristics of automation objects
4. System requirements
5. Composition and content of work to create the system
6. Procedure for control and acceptance of the system
7. Requirements for the composition and content of work to prepare the automation object for commissioning of the system
8. Documentation requirements
9. Development sources

When developing technical specifications for government projects, Customers, as a rule, require compliance with this particular standard.

GOST 19

1. Introduction;
2. Reasons for development;
3. Purpose of development;
4. Requirements for the program or software product;
5. Requirements for program documentation;
6. Technical and economic indicators;
7. Stages and stages of development;
8. Procedure for control and acceptance;
9. Applications.

Naturally, GOST 34 (and 19) are already outdated, and I don’t like to use them, but with the correct interpretation of the standards, you can get good technical specifications, see Conclusion.

IEEE STD 830-1998

Describes the content and quality characteristics of a well-written software requirements specification (SRS) and provides several SRS templates. This recommended practice is intended to establish requirements for software under development, but can also be used to assist in the selection of proprietary and commercial software products.

According to the standard, the terms of reference must include the following sections:

1. Introduction

• 1. Purpose
• 2. Scope
• 3. Definitions, acronyms and abbreviations
• 4. Links
• 5. Brief overview

• 1. Product interactions (with other products and components)
• 2. Product features (brief description)
• 3. User characteristics
• 4. Limitations
• 5. Assumptions and dependencies

• 1. Requirements for external interfaces
  • 1. User Interfaces
  • 2. Hardware interfaces
  • 3. Software interfaces
  • 4. Interaction interfaces
• 2. Functional requirements
• 3. Performance requirements
• 4. Design Constraints (and References to Standards)
• 5. Non-functional requirements (reliability, availability, security, etc.)
• 6. Other requirements

In fact, it is quite difficult for a beginner to understand what should be contained in these sections according to the above structure (as in the case of GOST), so you need to read the standard itself, which. , however, in English. language.

Well, for those who read to the end, there’s a bonus: an example of technical specifications that I wrote many years ago (now I’ve not been working as an analyst for a long time, and other more successful examples are prohibited from being opened for public viewing by the NDA).

• Presentation by Yuri Buluy Classification of software requirements and its representation in standards and methodologies.
• Analysis of requirements for automated information systems. Lecture 11: Documenting requirements.
• Rules for drawing up Software requirements specification (read along with comments)
• Examples of technical specifications and other documentation for the development of AS for the Ministry of Economic Development
• GOST management style. Gaperton article on correct work with technical specifications according to GOST
• Business Analyst Document Templates from

I am often asked: “How to correctly develop technical specifications for an automated system?” The topic of developing technical specifications is constantly discussed in various forums. This question is so broad that it is impossible to answer in a nutshell. Therefore, I decided to write a long article on this topic. In the process of working on the article, I realized that it would not be possible to put everything in one article, because... It will be about 50 pages and I decided to break it into 2 parts:

• In the first part " Development of technical specifications. What is it, why is it needed, where to start and what it should look like? I will try to answer the questions of the topic in detail, consider the structure and purpose of the Terms of Reference, and give some recommendations on the formulation of requirements.
• Second part " Development of technical specifications. How to formulate requirements? will be entirely devoted to identifying and formulating requirements for an information system.

First, you need to figure out what question actually interests those who ask “How to develop a technical specification?” The fact is that the approach to developing the technical specifications will greatly depend on the purposes for which it is being done, as well as by whom it will be used. What options am I talking about:

• A commercial organization decided to implement an automated system. It does not have its own IT service and decided to do this: The interested party must develop a Technical Specification and submit it for development to a third party;
• A commercial organization decided to implement an automated system. It has its own IT service. We decided to do this: develop a Technical Specification, then agree on it between the IT service and interested parties, and implement it on our own;
• The government agency decided to start an IT project. Everything here is so murky, a lot of formalities, kickbacks, cuts, etc. I will not consider this option in this article.
• An IT company provides services for the development and/or implementation of automated systems. This is the most difficult case, because you have to work in a variety of conditions:

  The client has his own specialists with their own views, and they make specific requirements for the Technical Specifications;

  • The terms of reference are developed for in-house developers (the client doesn’t care);
  • The terms of reference are developed for transfer to the contractor (i.e. a group of programmers on staff of the company, or an individual specialist);
  • A misunderstanding arises between the company and the client regarding the result obtained, and the company again and again asks the question: “How should the Terms of Reference be developed?” The last case may seem like a paradox, but it is true.
  • Other, less common options are also possible;

I think the reader should now have questions:

• Why can’t the Technical Specifications always be developed in the same way?;
• Are there any standards, methods, recommendations? Where can I get them?
• Who should develop the Terms of Reference? Should this person have any special knowledge?
• How to understand whether the Terms of Reference are well written or not?
• At whose expense should it be developed, and is it even necessary?

This list can be endless. I say this with confidence because I have been in professional software development for 15 years, and the question of Technical Specifications comes up in any development team with whom I work. The reasons for this are different. Raising the topic of developing the Terms of Reference, I am well aware that I will not be able to present it 100% to everyone interested in the topic. But, I’ll try, as they say, “to sort everything out.” Those who are already familiar with my articles know that I do not use “copy-paste” of other people’s work, do not reprint other people’s books, do not quote multi-page standards and other documents that you yourself can find on the Internet, passing them off as your own genius thoughts. Just type in a search engine “How to develop a Technical Specification” and you can read a lot of interesting, but, unfortunately, repetitive things. As a rule, those who like to be clever on forums (just try searching!) have never made a proper Technical Specification themselves, and constantly quote GOST recommendations on this issue. And those who are really serious about the issue usually have no time to sit on the forums. By the way, we will also talk about GOST standards. Over the years of my work, I have seen many versions of technical documentation compiled by both individual specialists and eminent teams and consulting companies. Sometimes I also engage in such activities: I allocate time for myself and search for information on a topic of interest from unusual sources (such as a little intelligence). As a result, I had to see documentation on such monsters as GazProm, Russian Railways and many other interesting companies. Of course, I comply with the confidentiality policy, despite the fact that these documents come to me from publicly available sources or the irresponsibility of consultants (scattering information on the Internet). Therefore, I say right away: I do not share confidential information that belongs to other companies, regardless of the sources (professional ethics).

What is a technical specification?

The first thing we will do now is figure out what kind of beast this “Technical Specification” is.

Yes, there really are GOSTs and standards that attempt to regulate this part of the activity (software development). Once upon a time, all these GOSTs were relevant and actively used. Now there are different opinions about the relevance of these documents. Some argue that GOSTs were developed by very far-sighted people and are still relevant. Others say they are hopelessly outdated. Perhaps someone now thought that the truth was somewhere in the middle. I would answer in the words of Goethe: “They say that between two opposing opinions lies the truth. No way! There is a problem between them." So, there is no truth between these opinions. Because GOSTs do not reveal the practical problems of modern development, and those who criticize them do not offer alternatives (specific and systemic).

Note that GOST clearly does not even give a definition, it only says: “TK for a nuclear power plant is the main document defining the requirements and procedure for creating (development or modernization - then creation) of an automated system, in accordance with which the development of a nuclear power plant is carried out and its acceptance upon commissioning into action."

If anyone is interested in what GOSTs I’m talking about, here they are:

• GOST 2.114-95 Unified system of design documentation. Technical specifications;
• GOST 19.201-78 Unified system of program documentation. Technical specifications. Requirements for content and design;
• GOST 34.602-89 Information technology. A set of standards for automated systems. Terms of reference for the creation of an automated system.

A much better definition is presented on Wikipedia (though about technical specifications in general, and not just for software): “ Technical specifications- this is the original design document technical object. Technical specifications establishes the main purpose of the object under development, its technical and tactical-technical characteristics, quality indicators and technical and economic requirements, instructions for completing the necessary stages of creating documentation (design, technological, software, etc.) and its composition, as well as special requirements. A task as an initial document for the creation of something new exists in all areas of activity, differing in name, content, order of execution, etc. (for example, a design task in construction, a combat task, homework, a contract for a literary work, etc.). d.)"

And so, as follows from the definition, the main purpose of the Technical Specification is to formulate the requirements for the object being developed, in our case, for an automated system.

It is the main thing, but the only one. The time has come to get down to the main thing: to put everything “on the shelves”, as promised.

What do you need to know about the requirements? It is necessary to clearly understand that all requirements must be divided by type and properties. Now we will learn how to do this. To separate requirements by type, GOST will help us. The list of types of requirements that is presented there is a good example of what types of requirements should be considered. For example:

• Functionality requirements;
• Security and access rights requirements;
• Requirements for personnel qualifications;
• …. Etc. You can read about them in the mentioned GOST (and below I will also consider them in a little more detail).

I think it is obvious to you that the key factor in a successful Technical Specification is precisely well-formulated functionality requirements. Most of the works and techniques that I spoke about are devoted to these requirements. Functionality requirements are 90% of the complexity of the work on developing the Terms of Reference. Everything else is often a “camouflage” that covers these requirements. If the requirements are formulated poorly, then no matter what beautiful camouflage you put on them, a successful project will not come out. Yes, formally all requirements will be met (according to GOST J), the technical specification has been developed, approved and signed, and money has been received for it. And what? And then the most interesting part begins: what to do? If this is a project on the State Order, then there are no problems - the budget there is such that it won’t fit into anyone’s pocket, and during the implementation process (if there is one) everything will be clarified. This is exactly how the majority of project budgets are spent on State Orders (they scribbled “TZ”, lost tens of millions, but did not do the project. All formalities were observed, there were no culprits, a new car is near the house. Beauty!). But we are talking about commercial organizations where money is counted, and a different result is needed. Therefore, let's understand the main thing, how to develop useful and working Technical specifications.

I said about the types of requirements, but what about properties? If the types of requirements can be different (depending on the goals of the project), then with properties everything is simpler, there are 3 of them:

1. The requirement must be understandable;
2. The requirement must be specific;
3. The requirement must be test takers;

Moreover, the last property is impossible without the two previous ones, i.e. is a kind of “litmus test”. If the result of a requirement cannot be tested, it means that it is either unclear or not specific. Think about it. It is in the mastery of these three properties of requirements that mastery and professionalism lie. It's actually very simple. When you figure it out.

This concludes the story about what a Technical Specification is and moves on to the main thing: how to formulate requirements. But it's not that fast. There is one more extremely important point:

• In what language (in terms of difficulty of understanding) should the technical specification be written?
• Should it describe the specifications of various functions, algorithms, data types and other technical things?
• What is technical design, which, by the way, is also mentioned in GOSTs, and how is it related to the Technical Specifications?

There is a very insidious thing hidden in the answers to these questions. That is why disputes often arise about the sufficiency or lack of necessary detail of requirements, about the understandability of the document by the Customer and Contractors, about redundancy, presentation format, etc. Where is the line between the Terms of Reference and the Technical Project?

Technical specifications- this is a document based on requirements formulated in a language that is understandable (ordinary, familiar) to the Customer. In this case, industry terminology that is understandable to the Customer can and should be used. There should be no connections to the specifics of the technical implementation. Those. at the technical specification stage, in principle, it does not matter on which platform these requirements will be implemented. Although there are exceptions. If we are talking about implementing a system based on an already existing software product, then such a connection can take place, but only at the level of screen forms, report forms, etc. The clarification and formulation of requirements, as well as the development of Terms of Reference should be carried out business analyst. And certainly not a programmer (unless he combines these roles, this happens). Those. this person must speak to the Customer in the language of his business.

Technical project- this is a document that is intended for the technical implementation of the requirements formulated in the Terms of Reference. This document describes data structures, triggers and stored procedures, algorithms and other things that will be required technical specialists. The customer does not have to delve into this at all (even such terms may not be clear to him). Technical project does System Architect(combining this role with a programmer is quite normal). Or rather, a group of JSC specialists led by an architect. The larger the project, the more people work on the Terms of Reference.

What do we have in practice? It’s funny to watch when the director is presented with a technical specification for approval, which is replete with technical terminology, descriptions of data types and their values, database structure, etc. He, of course, tries to understand, since he needs to approve, trying to find familiar words between the lines and not lose the chain business requirements. Is this a familiar situation? And how does it end? As a rule, such technical specifications are approved, then implemented, and in 80% of cases, then they do not at all correspond to the fact of the work performed, because they decided to change, redo a lot of things, misunderstood, thought wrong, etc. etc. And then the series about submitting work begins. “But here it’s not what we need,” but “this won’t work for us,” “this is too complicated,” “this is inconvenient,” etc. Sound familiar?!! That’s familiar to me, I had to hit the bumps in due time.

So what do we have in practice? But in practice, we have a blurred boundary between the Terms of Reference and the Technical Project. She floats between TK and TP in a variety of manifestations. And that's bad. This happens because the development culture has become weak. This is partly due to the competencies of specialists, partly due to the desire to reduce budgets and deadlines (after all, documentation takes a lot of time - that’s a fact). There is another important factor influencing the use of the Technical Design as a separate document: the rapid development of rapid development tools, as well as development methodologies. But this is a separate story, I’ll say a few words about it below.

Another small but important point. Sometimes Terms of Reference are called a small piece of requirements, simple and understandable. For example, improve the search for an object according to some conditions, add a column to the report, etc. This approach is quite justified, why complicate life. But it is used not on large projects, but on minor improvements. I would say this is closer to software product maintenance. In this case, the Terms of Reference may also describe a specific technical solution for implementing the requirement. For example, “Make such and such a change to such and such an algorithm,” indicating a specific procedure and a specific change for the programmer. This is the case when the boundary between the Terms of Reference and Technical Projects is completely erased, because there is no economic feasibility to inflate paperwork where it is not needed, and a useful document is created. And that's right.

Is technical specification necessary at all? What about the Technical Project?

Am I overheating? Is this possible without any Technical specifications? Imagine it is possible (or rather, it is possible), and this approach has many followers, and their number is growing. As a rule, after young specialists have read books about Scrum, Agile and other rapid development technologies. In fact, these are wonderful technologies, and they work, but they don’t literally say “no need to do technical tasks.” They say “a minimum of paperwork,” especially unnecessary ones, closer to the Customer, more specifics and faster results. But no one canceled the recording of requirements, and this is clearly stated there. It is there that the requirements are fixed based on the three remarkable properties that I spoke about above. It’s just that some people’s minds are structured in such a way that if something can be simplified, then let’s simplify it to the point of complete absence. As Einstein said " Make it as simple as possible, but not simpler than that.” . These are golden words that go with everything. So Technical specifications necessary, otherwise you won’t see a successful project. Another question is how to compose it and what to include there. In the light of rapid development methodologies, you need to focus only on the requirements, and all the “camouflage” can be discarded. In principle, I agree with this.

What about the Technical Project? This document is very useful and has not lost its relevance. Moreover, often you simply cannot do without it. Especially when it comes to outsourcing development work, i.e. on the principle of outsourcing. If you don't do this, you run the risk of learning a lot about what the system you have in mind should look like. Should the Customer become familiar with it? If he wants, why not, but there is no need to insist and approve this document, it will only hold back and interfere with work. It is almost impossible to design a system down to the smallest detail. In this case, you will have to continuously make changes to the Technical Design, which takes a lot of time. And if the organization is heavily bureaucratic, then you’ll leave all your nerves there. Reducing this kind of design is exactly what modern rapid development methodologies that I mentioned above are all about. By the way, they are all based on the classic XP (extreme programming) - an approach that is already about 20 years old. So make a high-quality Technical Specification that is understandable to the Customer, and use the Technical Design as an internal document for the relationship between the system architect and programmers.

An interesting detail about technical design: some development tools designed on the principle of subject-oriented design (such as 1C and similar) assume that design (meaning the documentation process) is required only in truly complex areas where interaction between entire subsystems is required. In the simplest case, for example, creating a directory or document, only correctly formulated business requirements are enough. This is also evidenced by the business strategy of this platform in terms of training specialists. If you look at the exam card of a specialist (that’s what it’s called, not a “programmer”), you will see that there are only business requirements, and how to implement them in a program language is the specialist’s task. Those. that part of the problem that the Technical Project is intended to solve, the specialist must solve “in his head” (we are talking about tasks of medium complexity), here and now, following certain development and design standards, which again are formed by the 1C company for its platform. Thus, of two specialists whose work results look identical, one can pass the exam, but the other cannot, because flagrantly violated development standards. That is, it is obviously assumed that specialists must have such qualifications that they can design typical tasks independently, without the involvement of system architects. And this approach works.

Let's continue to study the question: “What requirements should be included in the Terms of Reference?”

Formulation of requirements for the information system. Structure of the Terms of Reference

Let’s be clear right away: we will talk specifically about formulating requirements for an information system, i.e. assuming that the work on developing business requirements, formalizing business processes and all previous consulting work has already been completed. Of course, some clarifications can be made at this stage, but just clarifications. The automation project itself does not solve business problems - remember this. This is an axiom. For some reason, some managers are trying to refute it, believing that if they buy the program, order will come to a chaotic business. But an axiom is just an axiom; it does not require proof.

Like any activity, formulating requirements can (and should) be divided into stages. Everything has its time. This is hard intellectual work. And, if you treat it with insufficient attention, then the result will be appropriate. According to expert estimates, the cost of developing technical specifications can be 30-50%. I am of the same opinion. Although 50 is perhaps too much. After all, the Technical Specification is not the last document that must be developed. After all, there must also be technical design. This variation is due to different automation platforms, approaches and technologies used by project teams during development. For example, if we are talking about development in a classical language like C++, then detailed technical design is indispensable. If we are talking about implementing a system on the 1C platform, then the situation with design is somewhat different, as we saw above (although, when developing a system from scratch, it is designed according to the classical scheme).

Although the requirements statement is the main part Technical specifications, and in some cases it becomes the only section of the technical specifications, you should pay attention to the fact that this is an important document, and it should be drawn up accordingly. Where to start? First of all, you need to start with the content. Write the content and then start expanding it. Personally, I do this: first I sketch out the content, describe the goals, all the introductory information, and then get down to the main part - the formulation of the requirements. Why not the other way around? I don't know, it's more convenient for me. Firstly, this is a much smaller part of the time (compared to the requirements), and secondly, while you are describing all the introductory information, you tune in to the main thing. Well, whoever likes it. Over time, you will develop your own Technical Specification template. To begin with, I recommend taking as content exactly the one described in GOST. It's perfect for content! Then we take and begin to describe each section, not forgetting about the recommendations of following three properties: understandability, specificity and testability. Why do I insist on this so much? More on this in the next section. And now I propose to go through those points of the technical specifications that are recommended in GOST.

1. general information;
2. purpose and goals of creation (development) of the system;
3. characteristics of automation objects;
4. system requirements;
5. composition and content of work to create the system;
6. procedure for control and acceptance of the system;
7. requirements for the composition and content of work to prepare the automation object for putting the system into operation;
8. documentation requirements;
9. development sources.

In total, 9 sections, each of which is also divided into subsections. Let's look at them in order. For convenience, I will present everything in the form of a table for each item.

Section 1. general information.

Section 2. purpose and goals of creation (development) of the system.

In general, the ability to identify goals, formulate them, and build a tree of goals is a completely separate topic. Remember the main thing: if you know how, write, if you are not sure, don’t write at all. What happens if you don’t formulate goals? You will work according to the requirements, this is often practiced.

Section 3. Characteristics of automation objects.

Section 4. System Requirements

GOST deciphers the list of such requirements:

• requirements for the structure and functioning of the system;
• requirements for the number and qualifications of system personnel and their mode of operation;
• destination indicators;
• reliability requirements;
• safety requirements;
• requirements for ergonomics and technical aesthetics;
• transportability requirements for mobile speakers;
• requirements for operation, maintenance, repair and storage of system components;
• requirements for protecting information from unauthorized access;
• requirements for the safety of information in case of accidents;
• requirements for protection from external influences;
• requirements for patent purity;
• requirements for standardization and unification;

Despite the fact that the main one will certainly be the section with specific requirements (functional), this section can also be of great importance (and in most cases it is). What may be important and useful:

• Qualification Requirements. It is possible that the system being developed will require retraining of specialists. These can be both users of the future system and IT specialists who will be needed to support it. Insufficient attention to this issue often develops into problems. If the qualifications of the existing personnel are clearly insufficient, it is better to specify requirements for the organization of training, training program, timing, etc.
• Requirements for protecting information from unauthorized access. No comments here. These are precisely the requirements for delimiting access to data. If such requirements are planned, then they need to be written separately, in as much detail as possible, according to the same rules as functional requirements (understandability, specificity, testability). Therefore, these requirements can be included in the section with functional requirements
• Requirements for standardization. If there are any design standards that are applicable to the project, they can be included in the requirements. As a rule, such requirements are initiated by the Customer’s IT service. For example, the 1C company has requirements for the design of program code, interface design, etc.;
• Requirements for the structure and functioning of the system. Here the requirements for integrating systems with each other can be described, and a description of the general architecture is presented. More often, integration requirements are generally separated into a separate section or even a separate Technical Specification, because these requirements can be quite complex.

All other requirements are less important and need not be described. In my opinion, they only make the documentation heavier and have little practical benefit. And it is very difficult to describe ergonomic requirements in the form of general requirements; it is better to transfer them to functional ones. For example, the requirement may be formulated “Get information about the price of a product by pressing only one button.” In my opinion, this is still closer to specific functional requirements, although it relates to ergonomics. Requirements for functions (tasks) performed by the system This is the main and key point that will determine success. Even if everything else is done perfectly, and this section is “3”, then the result of the project will be at best “3”, or even the project will fail altogether. It is these that we will deal with in more detail in the second article, which will be included in the 5th issue of the newsletter. It is to this point that the “rule of three properties of requirements” that I spoke about applies. Requirements for types of collateral

GOST identifies the following types:

• Mathematical
• Informational
• Linguistic
• Software
• Technical
• Metrological
• Organizational
• Methodical
• and others...

At first glance, these requirements may seem unimportant. In most projects this is true. But not always. When to describe these requirements:

• No decisions have been made on which language (or platform) development will be carried out;
• The system requires a multilingual interface (for example, Russian/English)
• For the system to function, a separate unit must be created or new employees must be hired;
• For the system to function, the Customer must undergo changes in work methods and these changes must be specified and planned;
• Integration with any equipment is expected and requirements are imposed on it (for example, certification, compatibility, etc.)
• Other situations are possible, it all depends on the specific goals of the project.

Section 5. Composition and content of work to create the system

Section 6. Procedure for control and acceptance of the system

General requirements for acceptance of work by stages (list of participating enterprises and organizations, place and timing), procedure for coordination and approval of acceptance documentation; I strongly recommend that you take responsibility for the procedure for submitting work and checking the system. This is exactly why testable requirements are needed. But even the presence of testable requirements may not be enough when the system is delivered if the procedure for acceptance and transfer of work is not clearly stated. For example, a common trap: the system is built and is fully operational, but the Customer for some reason is not ready to work in it. These reasons can be any: no time, goals have changed, someone quit, etc. And he says: “Since we are not yet working in the new system, it means we cannot be sure that it works.” So learn to correctly identify stages of work, and ways to check the results of these stages. Moreover, such methods must be clear to the Customer from the very beginning. If they are fixed at the level of the Technical Specifications, then you can always turn to them if necessary and complete the work with the transfer.

Section 7. Requirements for the composition and content of work to prepare the automation object for putting the system into operation

There may be any other rules for entering information adopted by the company (or planned). For example, information about a contract used to be entered as a text string in any form, but now a separate number, a separate date, etc. are required. There can be a lot of such conditions. Some of them may be perceived with resistance from staff, so it is better to register all such cases at the level of requirements for the order of data entry. Changes that need to be made in the automation object

Creation of conditions for the functioning of the automation object, under which the compliance of the created system with the requirements contained in the technical specifications is guaranteed. Any changes that may be required. For example, the company does not have a local network and has an outdated fleet of computers on which the system will not work.

Perhaps some necessary information was processed on paper, and now it needs to be entered into the system. If you do not do this, then some module will not work, etc.

Perhaps something was simplified, but now needs to be taken into account in more detail, so someone must collect information according to certain rules.

This list can be long, look at the specific case of your project. Creation of departments and services necessary for the functioning of the system;

Timing and procedure for staffing and training We have already talked about this earlier. Perhaps the system is being developed for a new structure or type of activity that did not exist before. If there are no appropriate personnel, and even trained ones, the system will not work, no matter how competently it is built.

Section 8. Documentation Requirements

Consider how user manuals will be presented.

Perhaps the Customer has accepted corporate standards, which means we need to refer to them.

Ignoring documentation requirements very often leads to the most unexpected consequences on projects. For example, everything is done and everything works. Users also know how to work. There was no agreement or conversation about documentation at all. And suddenly, when handing over the work, one of the Customer’s top managers, who did not even participate in the project, but is involved in accepting the work, asks you: “Where are the user manuals?” And it begins to convince you that there was no need to agree on the availability of user manuals, this is supposedly implied “of course.” And that’s it, he doesn’t want to take your job. At whose expense will you develop the guidelines? Many teams have already fallen for this hook.

Section 9. Development Sources

Therefore, it is better to simply refer to the survey report and the requirements of key persons.

And so, we have considered all the sections that can be included in the Terms of Reference. “Can” and not “Must” precisely because any document must be developed to achieve a result. Therefore, if it is obvious to you that a particular section will not bring you any closer to the result, then you don’t need it and you don’t need to waste time on it.

But no competent technical specification can do without the main thing: functional requirements. I would like to note that in practice such Technical Specifications occur, and how! There are people who will be able to separate the waters in all sections, describe the general requirements in general terms, and the document turns out to be very weighty, and there are a lot of clever words in it, and even the Customer may like it (that is, he will approve it). But it may not work according to it, i.e. It has little practical use. In most cases, such documents are born when you need to get a lot of money specifically for the Terms of Reference, but it needs to be done quickly and without diving into details. And especially if it is known that the matter will not go further, or completely different people will do it. In general, just to manage the budget, especially the state budget.

In the second article we will talk only about section 4 “System requirements”, and specifically we will formulate requirements for reasons of clarity, specificity and testability.

Why requirements must be clear, specific and testable.

Because practice shows: at first, most of the technical requirements that are developed by specialists either turn out to be not in demand (do not correspond to reality), or become a problem for those who must implement them, because The customer begins to manipulate vague terms and requirements. I will give a few examples of what phrases were encountered, what this led to, and then I will try to give recommendations on how to avoid such problems.

From the author: How to write terms of reference (TOR) for website development? The topic is quite extensive, and it is difficult to analyze it 100% within the framework of one note (if at all possible). But I will try to outline the general provisions about what needs to be taken into account and what you should pay attention to when drawing up the terms of reference for a website in sufficient detail.

So, technical specifications for website development

The technical specifications are prepared for the developer. The terms of reference must be referred to when drawing up an agreement between the customer and the contractor. Responsibility for non-fulfillment or incorrect fulfillment of points and deadlines on both sides must be stipulated. But the most important thing (in my opinion) for which technical specifications are created is for speeding up the project development process.

Let's analyze this example:

Let's assume that you need a calendar somewhere on the side of your website. It seemed like a small thing. But the more detailed you describe its functionality, the faster you will get the result.

Let me explain a little here. There is a calendar that simply shows the numbers by day of the week of the current month. And there is the ability to flip through the months. There is a calendar with the ability to flip through months and years.

JavaScript. Quick start

Let's say you want the latter option (with the ability to scroll through months and years) with the current date highlighted. In the terms of reference you indicated: “a calendar is needed in the sidebar.” They give you the first option (it simply shows the numbers by day of the week of the current month).

What do we have? The contractor fulfilled the specification, but you wanted something completely different. Everything seems to be in accordance, no one is to blame, there is no conflict, but the most important thing is lost time and money.

This is an example of just a banal calendar.

What if you have to redo something more serious, the processing of which requires more than half a day, as is the case with the calendar? The contractor is busy with you when he could finish your project and start a new one.

Therefore, than more details You describe the functionality of each module, the faster you will get the result. Both sides should be interested in this.

What points does a technical specification usually consist of?

Let's imagine that you are the owner of a company or firm. Your company is engaged in the production of any product and its sale. You have buyers. You cooperate with sellers (shops and online stores), service centers, and product consumers. Or you are making a resource for such a company and you need to write a technical specification.

Regardless of what role you play, the first thing you need to do before drawing up technical specifications for creating a website design is to study the structure of the organization, what it does, nomenclature, characteristics and in general everything that is connected with the product and the company. What will happen on the resource depends on how deeply the customer understands the essence of what is happening at the enterprise. Therefore, the task here is mutual: the customer must tell about the enterprise in as much detail as possible, and the contractor must thoroughly understand the essence of what is happening.

Even if you yourself are writing technical specifications for the company that will do your project, it’s a good idea to figure it all out on a piece of paper.

Let's go point by point.

Description

Here you can write in a couple of sentences about the company and what it does. Do something like an introduction.

for whom - target audience:

potential buyers

product sellers (shops, online stores)

service centers

partners (firms)

consumers of products (those who have already purchased)

Why do you need a website:

To improve the company's image

To increase sales

For customer convenience

Corporate

Website – business card

Online store

Language versions:

English

The site must solve some problems. Accordingly, we further move on goals and objectives.

Goals and objectives

In this section of the technical specifications, we go through the entire target audience and describe the range of tasks that the site should solve for them.

Potential product buyers.

Target: attract more buyers and convince them to make their first purchase, help them make a choice.

Problems need to be solved:

Provide high-quality, comprehensive information about products, additional services, guarantees, service, and selection methods.

Provide information about showrooms

Provide information about the retail network

Provide an opportunity to ask a question by organizing online consultation of potential buyers by company specialists on issues of choosing and purchasing products.

Thus, we go through the entire target audience. We also describe the goals and objectives for product sellers (stores, online stores), service centers, partners (firms), and product consumers. That is, what the site should do specifically for each of them.

Now we list the modules.

Site functionality

In order to list the functionality, you need to decide what it needs:

Is registration required?

Do I need a closed section (only for registered users)

Is a feedback form necessary?

Etc. etc.

JavaScript. Quick start

Learn the basics of JavaScript with a hands-on example of how to create a web application.

After we have described all this, we get to the most important and interesting thing. Of course, all the work done above is very important, but now it gets even hotter.

Description of functionality

At the moment, we know who the site is for, what goals and objectives it should fulfill, and its additional functionality.

The time has come when you need to bring all the collected information into the system and arrange it beautifully. To make the task easier and not reinvent the wheel, you can look at resources on similar topics. Take something from them, look at and try out their functionality and what seemed inconvenient, try to improve it on your project. In principle, you can look at sites on similar topics (and if you don’t have experience, then you even need to) at the very beginning of drawing up technical specifications.

I suggest starting with menu items. It needs to display the main pages and make sure that each visitor quickly finds information for themselves. And visitors are our target audience. The menu will include many items, so it will be in the form of a drop-down list.

First, you need to tell us about the company. There may be pages about the company, company history, contacts, reviews.

Naturally, there should be a menu item “products”, with sub-items “product catalogue”, “releases”, “product reviews”.

In general, I hope it’s clear how to describe it. Let me present the final version of the possible menu:

about the company

company history

contacts

products

product catalog

product reviews

service department

warranty service

post-warranty service

to the consumer

purchase and delivery

use

about the service

shops and online stores

product photos

Frequently Asked Questions

service centers

How to become a service center

Frequently Asked Questions

partners

invitation to cooperation

Frequently Asked Questions

We seem to have sorted out the menu. Now you need to describe what will be on each page and how it all works. Plus provide an approximate layout. It can be drawn on a piece of paper with a pencil, scanned and attached to the technical specifications. The only thing I will say is that don’t limit the designer’s imagination, sketch it in the most general form.

This part changes depending on how you want your page to look. Maybe you don’t need so many banners at the top, perhaps you need to indicate contacts (address, phone, fax) at the top, maybe in the form of “site map”, “home”, “contacts” icons. Maybe you don’t need news on the left, but show “promotions and releases” on the left.

The main thing now is to describe the logic of the work.

Operation logic

I will describe based on the picture above.

The header remains the same on every page. The news feed is visible only on the main page. On the secondary pages on the left we show the menu sub-items of the item we are currently in (for example, if we are on the “customer service” page, we show links to “warranty service”, “post-warranty service”). Accordingly, clicking on these links leads to the corresponding pages. Here, under the sub-items on the left, we display data for contacting online consultants (Skype, ICQ). The promotions and releases block remains on each page. The footer is displayed the same on every page.

This is roughly how the general logic of work is described.

Now, in our terms of reference for website development, we describe in detail each designated block of the site. For example, “News Feed”.

“News feed” of the 10 latest news. Each news should consist of a news title, publication date, a brief beginning of the news (4-5 lines) and a “read in full” link. When you click on the “read in full” link, you will be taken to the news page. The news you came across is displayed in place of the main content. It also includes the news title and date of publication. The news feed is also displayed on the left. News from past months and years is archived. That is, under the news for the current month we display “archive for (such and such month or year)”. When you click on the “archive for (such and such month or year)” link, a list of news for the corresponding month/year drops down.

This is how we describe the operation of each block. Let's not forget about the calendar incident. And most importantly, you need to describe the work of the product catalog. Here I give you a task: try to think through and describe how the catalog will work. Send your options by e-mail. We will publish the best one.

What else should there be? It would be nice to indicate compatibility.

Compatibility

In this paragraph of our terms of reference for creating a website, we indicate on which operating systems and in which browsers the website should look equally good. In what version, what language should it be written. What CMS is used. It's worth pointing out if you actually know what you're talking about.

If you do not know these questions, then simply indicate the browsers in which the site should be displayed correctly. For the rest, rely on the conscience of the performer.

Conclusion

In this article, I did not try to show that this is how the technical specifications are compiled and no other way. Do this and there will be no problems. Compose a qualitative terms of reference for website development- this is more of a question experience. Not everyone will be able to create a competent technical specification in the first couple of years.

In this article, I wanted to show an example and principles on which a sample technical specification for developing the design and logic of a website is built, as well as the main points that are worth paying attention to. How far I succeeded, I hope to find out from your comments.

And don't forget about the task!