In this article, I tried to consider in detail the problem of developing Terms of Reference. The topic is as old as the problem. But it is still often solved "how it goes."
As Henry Shaw said, "It's the little things that worry us the most: it's easier to dodge an elephant than a fly."

Development terms of reference. What is it, why is it needed, where to start and how should it look like?

What is this article about?

I am often asked: “How to develop a technical task for automated system? A similar topic 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 work to put everything in one article, because. it will turn out under 50 pages and 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 how it should look? 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.
• The second part " Development of technical specifications. How to formulate requirements? will be entirely devoted to identifying and formulating requirements for the information system.

First you need to figure out what question really interests those who ask "How to develop a technical task?" The fact is that the approach to the development of technical specifications will greatly depend on the purposes for which this is done, and also 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 person must develop the Terms of Reference and give it to a third-party organization for development;
• A commercial organization decided to implement an automated system. It has its own IT service. We decided to do this: develop a Terms of Reference, then coordinate it between the IT service and interested parties, and implement it on our own;
• The state structure decided to start an IT project. Everything is so muddy here, a lot of formalities, kickbacks, cuts, etc. I will not consider this option in this article.
• An IT company is engaged in 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 its own specialists with their own views, and they have specific requirements for the Terms of Reference;
  • The terms of reference are developed for our own developers (the client does not care);
  • The terms of reference are developed for transfer to the contractor (i.e. a group of programmers who are outside the company's staff, or an individual specialist);
  • There is a misunderstanding between the companies 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 latter case may seem like a paradox, but it is true.
  • Other, less common options are also possible;

I think now the reader should have questions:

• Why can't the Terms of Reference be always developed in the same way?
• Are there any standards, methods, recommendations? Where to get them?
• Who should develop the Terms of Reference? Does this person need to have any special knowledge?
• How to understand if the terms of reference are well written or not?
• At whose expense should it be developed, and is it needed at all?

This list could be endless. I speak so confidently from the fact that I have been in professional software development for 15 years, and the question of Terms of Reference pops up in any development team with whom I have to work. The reasons for this are different. Raising the topic of the development of the Terms of Reference, I am well aware that I will not be able to present it 100% for all those interested in the topic. But, I'll try, as they say, "put everything on the shelves." 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 brilliant thoughts. It is enough to type in the search engine "How to develop Terms of Reference" and you will be able to read a lot of interesting, but, unfortunately, repeated many times. As a rule, those who like to be clever on the forums (try to search after all!), Never made a sensible Terms of Reference themselves, and continuously quote GOST recommendations on this issue. And those who really seriously deal with the issue usually have no time to sit on the forums. By the way, we will also talk about GOSTs. AT different years In my work, I have seen many variants 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 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 abide by the confidentiality policy, despite the fact that these documents come to me from public sources or the irresponsibility of consultants (they scatter information over the Internet). Therefore, I immediately say: I do not share confidential information that belongs to other companies, regardless of the sources of occurrence (professional ethics).

What is a technical task?

The first thing we will do now is to figure out what kind of animal this is, the “Terms of Reference”.

Yes, there really are GOSTs and standards in which attempts are made 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 is somewhere in the middle. I would answer with the words of Goethe: “They say that between two opposing opinions lies the truth. In no case! Between them lies a problem." 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 the GOST clearly does not even give a definition, it only says: “The TOR for the NPP is the main document that defines the requirements and procedure for creating (development or modernization - further creation) of an automated system, in accordance with which the development of the NPP is carried out and its acceptance upon commissioning into action."

If someone is wondering what GOSTs I'm talking about, then here they are:

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

A much better definition is presented on Wikipedia (the truth about TK in general, and not just for software): “ Technical task is the original design document technical object. Technical task establishes the main purpose of the object being developed, its technical and tactical and 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 a source 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 mission, homework, a contract for a literary work, etc.)”

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

It is the main one, but the only one. It's time to take on the main thing: to put everything "on the shelves", as promised.

What do you need to know about the requirements? It must be clearly understood that all requirements must be divided by type and by properties. Now we will learn how to do it. To separate the requirements by type, GOST will just 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;
• Requirements for security and access rights;
• Requirements for personnel qualification;
• …. 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's obvious to you that well-formulated requirements for functionality are the key to a successful Terms of Reference. It is these requirements that are devoted to most of the works and methods that I spoke about. Functionality requirements are 90% of the complexity of the development of the Terms of Reference. Everything else is often "camouflage" that is put on these requirements. If the requirements are formulated poorly, then no matter what beautiful camouflage you put on them, a successful project will not work. Yes, formally all the requirements will be met (according to GOST J), the TOR has been developed, approved and signed, and money has been received for it. So what? And then the fun begins: what to do? If this is a project on the State Order, then there are no problems - there is such a budget that it won’t fit into any pocket, everything will be clarified in the process of implementation (if it exists). This is exactly how most of the budgets of projects on State Orders are sawn (they fired up "TK", merged ten million, but did not begin to do the project. All formalities were met, there were no guilty, a new car near the house. Beauty!). But we are talking about commercial organizations where money is counted, and the result is different. Therefore, let's deal with the main thing, how to develop useful and working Terms of reference.

I said about the types of requirements, but what about the properties? If the types of requirements can be different (depending on the goals of the project), then with the 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 tested;

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, then it is either not clear or not specific. Think about it. It is in the possession of these three properties of requirements that skill and professionalism lie. In fact, everything is very simple. When you figure it out.

On this story about what a Terms of Reference is, one could complete and move on to the main thing: how to formulate requirements. But it's not all that fast. There is another extremely important point:

• in what language (in terms of the complexity of understanding) should the terms of reference be written?
• Should the specification of various functions, algorithms, data types and other technical things be described in it?
• And what is technical design, which, by the way, is also mentioned in GOSTs, and how is it related to the Terms of Reference?

There is a very insidious thing in the answers to these questions. That is why disputes often arise about the sufficiency or absence of the necessary detailing of requirements, about the comprehensibility of the document by the Customer and the Contractors, about redundancy, presentation format, etc. And where is the border between the Terms of Reference and the Technical Design?

Technical task is a document based on requirements formulated in a language that is understandable (usual, familiar) for the Customer. In this case, industry terminology understandable to the Customer can and should be used. There should not be any bindings to the features of the technical implementation. Those. at the TK stage, in principle, it does not matter on which platform these requirements will be implemented. Although there are exceptions. If a we are talking on the implementation of a system based on an existing software product, then such a binding can take place, but only at the level of screen forms, report forms, etc. Clarification and formulation of requirements, as well as the development of the Terms of Reference should be business analyst. And certainly not a programmer (unless he combines these roles, this happens). Those. this person should speak with 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. Just this document describes data structures, triggers and stored procedures, algorithms and other things that will be required technical specialists. It is not at all necessary for the customer to delve into this (he may not understand such terms). The technical project does System architect(Here, the combination of this role with the programmer is quite normal). Or rather, a group of 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 brought for approval by the Terms of Reference, which is replete with technical terminology, descriptions of data types and their values, database structure, etc. He, of course, tries to understand, since it is necessary to assert, trying to find familiar words between the lines and not lose the chain business requirements. What, familiar situation? And how does it end? As a rule, such TOR is approved, then implemented, and in 80% of cases then it does not at all correspond to the fact of the work performed, because a lot of things they decided to change, redo, misunderstood, thought wrong, etc. etc. And then the handover series begins. “But here it’s not the way we need it,” but “it won’t work for us,” “it’s too complicated,” “it’s inconvenient,” etc. Familiar?! So I know, I had to fill the bumps in due time.

So what do we have in practice? But in practice, we have a blurred border between the Terms of Reference and the Technical Design. It floats between TK and TP in a variety of ways. And that's bad. And it turns out so because the development culture has become weak. This is partly due to the competence of specialists, partly due to the desire to reduce budgets and deadlines (after all, documentation takes a lot of time - this is 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 will say a few words about it below.

Another small but important point. Sometimes the Terms of Reference are called a small piece of requirements, simple and understandable. For example, to refine 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 the maintenance of the software product. In this case, the Terms of Reference may also describe a specific technical solution for the implementation of the requirement. For example, “To make such and such a change in the algorithm”, indicating a specific procedure and specific change for the programmer. This is the case when the boundary between the Terms of Reference and the 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 it is right.

Do you really need a technical specification? What about the engineering project?

Am I overheated? Is this even possible without terms of reference? Imagine perhaps (more precisely, it occurs), and this approach has many followers, and their number is increasing. As a rule, after young specialists read books about Scrum, Agile and other rapid development technologies. In fact, these are wonderful technologies, and they work, only they do not 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 fixing of requirements, and it is clearly stated there. It is there that the requirements are fixed based on the three wonderful properties that I spoke about above. It's just that some people's consciousness is arranged in such a way that if something can be simplified, let's simplify it to complete absence. As Einstein said " Make it as simple as possible, but not simpler than that." . Words of gold go with everything. So that Technical task necessary, otherwise you will not see a successful project. Another question is how to compose 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. Basically, I agree with this.

What about the technical project? This document is very useful and has not lost its relevance. Moreover, often it is simply impossible to do without it. Especially when it comes to outsourcing development work, i.e. on the principle of outsourcing. If this is not done, there is a risk of learning a lot about how the system you have in mind should look like. Should the customer get to know him? If he wants to, why not, but there is no need to insist and approve this document, it will only restrain 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 bureaucratized, then generally leave all the nerves there. It is precisely this kind of design reduction that is being discussed in modern rapid development methodologies, which I mentioned above. By the way, they are all based on the classic XP (extreme programming) approach, which is already about 20 years old. So make a high-quality Terms of Reference, 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 arranged according to the principle of subject orientation (such as 1C and similar) suggest that design (meaning the documentation process) is required only in really complex areas where interaction between entire subsystems is required. In the simplest case, for example, to create a reference book, a document, only correctly formulated business requirements are sufficient. This is evidenced by the business strategy of this platform in terms of training specialists. If you look at the exam ticket of a specialist (that’s what it is called, and not a “programmer”), then you will see that there are only business requirements there, and how to implement them in a programming language is the task of a specialist. Those. that part of the task that the Technical project is designed to solve, the specialist must solve “in the head” (we are talking about tasks of medium complexity), and here and now, following certain standards of development and design, which are again formed by the 1C company for its platform. Thus, out of two specialists, the result of whose work looks the same, one can pass the exam, and the second cannot, because. grossly violated development standards. That is, it is obviously assumed that specialists must have such qualifications that they can design typical tasks on their own, without involving system architects. And this approach works.

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

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

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

As with any activity, the formulation of requirements can (and should) be divided into stages. Everything has its time. This is hard intellectual work. And, if it is treated with insufficient attention, then the result will be appropriate. By expert opinion, the cost of developing the Terms of Reference can be 30-50%. I am of the same opinion. Although 50 is perhaps too much. After all, the Terms of Reference is not the last document to 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 such as C++, then detailed technical design is indispensable. If we are talking about the implementation of a system on the 1C platform, then the situation with the design is somewhat different, as we saw above (although, when developing a system from scratch, it is designed according to the classical scheme).

Despite the fact that the requirements statement is the main part of the Terms of Reference, and in some cases it becomes the only section of the TOR, you should pay attention to the fact that this is an important document, and it should be drawn up accordingly. Where to begin? First of all, you need to start with the content. Compose the content and then start unrolling it. Personally, I do this: first I outline the content, describe the goals, all the introductory information, and then I take on the main part - the formulation of the requirements. Why not vice versa? 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 describing all the introductory information, you tune in to the main thing. Well, whoever likes it. Over time, you will develop your own template of the Terms of Reference. To begin with, I recommend taking as content exactly the one that is described in GOST. It's great for content! Then we take and begin to describe each section, not forgetting the recommendations for 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 all-tact to go through those points of the TK 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 on the creation of 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.

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

Section 1. general information.

	What to do with it in practice
full name of the system and its symbol;	Everything is clear here: we write what the system will be called, its short name
topic cipher or cipher (number) of the contract;	This is not relevant, but you can specify if required.
the name of the enterprises (associations) of the developer and customer (user) of the system and their details;	indicate who (what organizations) will work on the project. You can also specify their roles. You can generally delete this section (rather formal).
a list of documents on the basis of which the system is created, by whom and when these documents were approved;	Useful information. Here you should indicate the regulatory and reference documentation that you were provided to familiarize yourself with a certain part of the requirements
planned dates for the beginning and completion of work on the creation of the system;	Timing wishes. Sometimes they write about this in the TOR, but more often such things are described in work contracts
information about the sources and procedure for financing the work;	Similarly, as in the previous paragraph about the timing. More relevant for government orders (for state employees)
the procedure for formalizing and presenting to the customer the results of work on the creation of the system (its parts), on the manufacture and adjustment of individual means (hardware, software, information) and software and hardware (software and methodological) complexes of the system.	I do not see the need for this paragraph, tk. the requirements for documentation are made separately, and besides this, there is a whole separate section "Procedure for control and acceptance" of the system.

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

	What to do with it in practice
Purpose of the system	On the one hand, the appointment is simple. But I would like to be specific. If you write something like “high-quality automation of inventory control in company X”, then you can then discuss the result for a long time when it is completed, even regardless of the good wording of the requirements. Because The customer can always say that he meant something else by quality. In general, nerves can spoil each other a lot, but why? It is better to immediately write something like this: "The system is designed to maintain warehouse records in company X in accordance with the requirements fixed in this Terms of Reference."
The goals of creating a system	Goals - this is certainly an important section. If we turn it on, then we must be able to formulate these goals. If you have difficulties with the formulation of goals, then it is better to exclude this section altogether. An example of an unsuccessful goal: "Ensure fast paperwork by the manager." What is fast? This can then be proven endlessly. If this is important, then it is better to reformulate this goal as follows: "The sales manager should be able to issue a document" Sales of goods "of 100 lines in 10 minutes." Such a goal may appear if, for example, the manager currently spends about an hour on this, which is too much for this company and it is important for them. In this formulation, the goal already intersects with the requirements, which is quite natural, because. when expanding the tree of goals (i.e. splitting them into smaller related goals), we will already approach the requirements. Therefore, you should not get carried away. In general, the ability to identify goals, formulate them, build a tree of goals is a completely separate topic. Remember the main thing: if you know how - write, if you are not sure - do not write at all. What happens if you don't set goals? You will work according to the requirements, this is often practiced.

Section 3. Characteristics of automation objects.

Section 4 System Requirements

	What to do with it in practice
General 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 the personnel of the system and the mode of its work; destination indicators; reliability requirements; safety requirements; requirements for ergonomics and technical aesthetics; transportability requirements for mobile AS; operating requirements, maintenance, repair and storage of system components; requirements for the protection of information from unauthorized access; requirements for the safety of information in case of accidents; requirements for protection from the influence of external influences; requirements for patent purity; requirements for standardization and unification;	Although 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 staff are clearly insufficient, it is better to prescribe the requirements for the organization of training, the training program, terms, etc. Requirements for protecting information from unauthorized access. There are no comments here. This is precisely the requirements for access control 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 the functional requirements (comprehensibility, specificity, testability). Therefore, these requirements can be included in the section with functional requirements. Requirements for standardization. If there are any development 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 the integration of systems with each other can be described, a description of the general architecture is presented. More often, integration requirements are singled out in general in a separate section or even a separate Terms of Reference, because these requirements can be quite complex. All other requirements are less important and can be left out. In my opinion, they only make the documentation heavier and are of little practical use. And it is very difficult to describe the requirements for ergonomics in the form of general requirements, it is better to transfer them to functional ones. For example, the requirement "Get information about the price of a product by pressing only one button" can be formulated. In my opinion, this is still closer to specific functional requirements, although it refers to ergonomics.
Requirements for the functions (tasks) performed by the system	Here it is, the very main and key point that will determine success. Even if everything else is done perfectly, and this section is at "3", then the result for the project will be at best "3", or even the project will fail. These are the ones we will deal with in more detail in the second article. It is to this point that the “rule of three properties of requirements” that I spoke of applies.
Requirements for types of collateral GOST distinguishes the following types: Mathematical informational Linguistic Software Technical Metrological Organizational methodical and others…	At first glance, it may seem that these requirements are not important. This is true for most projects. But not always. When to describe these requirements: No decision has been made as to which language (or platform) development will be in; The system is subject to the requirements of a multilingual interface (for example, Russian / English) For the functioning of the system, 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 supposed 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 on the creation of the system

Section 6. Procedure for control and acceptance of the system

What to do with it in practice

Types, composition, scope and methods of testing the system and its constituent parts(types of tests in accordance with the current standards applicable to the system being developed); General requirements for the acceptance of work by stages (list of participating enterprises and organizations, place and timing), the procedure for agreeing and approving acceptance documentation;

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 spelled out. For example, a common trap: the system is done, it is fully functional, but the Customer, for some reason, is not ready to work in it. These reasons can be any: once, goals have changed, someone quit, etc. And he says: “Since we are not yet working in new system, so we cannot be sure that it works. So learn to correctly identify the stages of work, ways to check the results of these stages. Moreover, such methods should be clear to the Customer from the very beginning. If they are fixed at the level of the Terms of Reference, then you can always contact 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

	What to do with it in practice
Bringing the information entering the system (in accordance with the requirements for information and linguistic support) to a form suitable for processing using a computer;	A very important point. For example, for the system to function as intended, it may be necessary to use any industry or all-Russian directories and classifiers. These directories must somehow appear in the system, be updated and used correctly. There may be any other rules for entering information adopted by the company (or planned). For example, information about the contract used to be entered as a text line in an arbitrary form, but now the number is required separately, the date separately, etc. There can be many such conditions. Some of them can be perceived with the resistance of the staff, so it is better to register all such cases at the level of requirements for the order of data entry
Changes 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 TOR is guaranteed	Any changes that may be required. For example, the company does not have a local network, an outdated fleet of computers on which the system will not work. Perhaps some necessary information processed on paper, and now it must be entered into the system. If this is not done, then some module will not work, etc. Perhaps something has been simplified, but now it 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 subdivisions and services necessary for the functioning of the system; Timing and procedure for staffing and staff training	We have already talked about this before. Perhaps the system is being developed for a new structure or type of activity that did not exist before. If there is no appropriate personnel, and even trained, the system will not work, no matter how competently it is not built.

Section 8 Documentation Requirements

What to do with it in practice

A list of sets and types of documents to be developed agreed by the system developer and customer

Having full documentation is an important part of the result. We all know that documenting something is hard work. Therefore, it is necessary to discuss in advance with the Customer what types of documentation will be developed, how they will look (content and preferably examples). Consider how user guides will be presented. Perhaps the Customer has accepted corporate standards, so you need to contact 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. We did not agree on the documentation at all and did not talk. And suddenly, when the work is handed over, one of the top managers of the Customer, who did not even participate in the project, but participates in the acceptance of work, asks you: “Where are the user manuals?” And he begins to convince you that it was not necessary to agree on the availability of user manuals, this “by itself” is allegedly implied. And that's it, he doesn't want to take your job. At whose expense will you develop guidelines? Many teams have already fallen for this hook.

Section 9 Development Sources

	What to do with it in practice
Documents and information materials (feasibility study, reports on completed research works, information materials on domestic, foreign analogue systems, etc.) should be listed, on the basis of which the TOR was developed and which should be used when creating the system.	To be honest, it's closer to the lyrics. Especially when they talk about the economic effect and other things that are almost impossible to calculate objectively. Those. If it is possible, then it will be more likely on paper, purely theoretically. Therefore, it is better to refer simply to the survey report, the requirements of the key persons.

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

But without the main thing: functional requirements, not a single competently Terms of Reference is complete. I want to note that in practice such Terms of Reference are encountered, and how! There are figures who will be able to dilute the waters in all sections, describe 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 (i.e., he will approve it). But it may not be possible to work on it, i.e. there is little practical use for it. In most cases, such documents are born when you need to get a lot of money specifically for the Terms of Reference, and you need to do it quickly and without diving into details. And especially if it is known that things will not go further, or completely different people will do it. In general, just for the development of the budget, especially the state.

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

Why requirements should be clear, specific and testable.

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

Type of requirement

Wrong wording

Preparation for laboratory work

Read the lecture material on the topic “Software Lifecycle Models. Stages of the life cycle in accordance with GOST 19.102-77. Statement of the problem" of the discipline "Development and standardization of PS and IT".

1. Study the relevant sections in the publications.

Theoretical part. Development of technical specifications

Technical task is a document that formulates the main goals of development, requirements for a software product, determines the terms and stages of development, and regulates the process of acceptance tests. Both representatives of the customer and representatives of the contractor are involved in the development of the terms of reference. This document is based on the initial requirements of the customer, analysis of advanced technology, the results of scientific research, pre-project research, scientific forecasting, etc.

The order of development of technical specifications

The development of technical specifications is carried out in the following sequence. First of all, they establish a set of functions to be performed, as well as a list and characteristics of the initial data. Then a list of results, their characteristics and presentation methods are determined.

Next, the software operation environment is specified: the specific configuration and parameters of the hardware, the version of the operating system used, and, possibly, the versions and parameters of other installed software with which the future software product will interact.

In cases where the developed software collects and stores some information or is included in the management of any technical process, it is also necessary to clearly regulate the actions of the program in case of equipment and power failures.

1. General provisions

1.1. The terms of reference are drawn up in accordance with GOST 19.106-78 on sheets of A4 and A3 format in accordance with GOST 2.301-68, as a rule, without filling in the fields of the sheet. Numbers of sheets (pages) are affixed at the top of the sheet above the text.

1.2. The approval sheet and the title page are drawn up in accordance with GOST 19.104-78. The informational part (abstract and content), the change registration sheet may not be included in the document.

1.3. To make changes and additions to the technical background at the subsequent stages of developing a program or software product, an addendum to it is released. Coordination and approval of the addition to the terms of reference is carried out in the same manner as established for the terms of reference.

1.4. The terms of reference should contain the following sections:

Introduction;

Name and scope;

Basis for development;

Purpose of development;

Technical requirements for the program or software product;

Technical and economic indicators;

Stages and stages of development;

Procedure for control and acceptance;

Applications.

Depending on the features of the program or software product, it is allowed to clarify the content of the sections, introduce new sections or combine some of them. If necessary, it is allowed to include applications in the terms of reference.

2.1. The introduction should include a brief description of the scope of the program or software product, as well as the object (for example, the system) in which they are supposed to be used. The main purpose of the introduction is to demonstrate the relevance of this development and show what place this development occupies among similar ones.

2.2. In the section "Name and scope" indicate the name, a brief description of the scope of the program or software product and the object in which the program or software product is used.

2.3. In the "Basic for development" section, the following must be indicated:

The document (documents) on the basis of which the development is carried out. Such a document can be a plan, order, contract, etc.;

The organization that approved this document and the date of its approval;

Name and (or) symbol of the development topic.

2.4. The Purpose of Development section should indicate the functional and operational purpose of the program or software product.

2.5. The section "Technical requirements for the program or software product" should contain the following subsections:

performance requirements;

Reliability requirements;

Operating conditions;

Requirements for the composition and parameters of technical means;

Requirements for information and software compatibility;

Requirements for labeling and packaging;

Requirements for transportation and storage;

Special requirements.

2.5.1. The subsection "Requirements for functional characteristics" should indicate the requirements for the composition of the functions performed, the organization of input and output data, temporal characteristics, etc.

2.5.2. In the subsection "Requirements for reliability", the requirements for ensuring reliable operation (ensuring stable operation, control of input and output information, recovery time after a failure, etc.) must be indicated.

2.5.3. The subsection "Operating conditions" should indicate the operating conditions (ambient air temperature, relative humidity, etc. for the selected types of data carriers), under which the specified characteristics should be provided, as well as the type of service, the required number and qualifications personnel.

2.5.4. In the subsection "Requirements for the composition and parameters of technical means" indicate the required composition of technical means, indicating their specifications.

2.5.5. In the subsection “Requirements for information and program compatibility”, the requirements for information structures at the input and output and solution methods, source codes, programming languages ​​should be indicated. Where necessary, information and programs should be protected.

2.5.6. In the subsection "Labeling and packaging requirements", in the general case, the requirements for software product labeling, packaging options and methods are indicated.

2.5.7. In the subsection "Requirements for transportation and storage" for the software product, the conditions for transportation, storage locations, storage conditions, warehousing conditions, storage periods under various conditions must be indicated.

2.5.8. In the "Technical and economic indicators" section, the following should be indicated: estimated economic efficiency, estimated annual need, economic advantages of the development in comparison with the best domestic and foreign samples or analogues.

2.6. In the "Stages and stages of development" section, the necessary stages of development, stages and content of work (a list of program documents that must be developed, agreed and approved), as well as, as a rule, the development timeframe and determine the executors are established.

2.7. In the section "Procedure for control and acceptance", the types of tests and general requirements for the acceptance of work must be indicated.

2.8. In the annexes to the terms of reference, if necessary, provide:

List of research and other works substantiating the development;

Algorithm schemes, tables, descriptions, justifications, calculations and other documents that can be used in the development;

Other sources of development.

In cases where the customer does not make any requirements stipulated by the terms of reference, “No requirements are presented” should be indicated in the appropriate place.

Examples of the development of terms of reference are given in appendices B and C.

test questions

1. Give the concept of a software life cycle model.

2. Give the stages of software development.

3. What does the problem statement and pre-project research include?

4. List the functional and operational requirements for the software product.

5. List the rules for developing terms of reference.

6. Name the main sections of the terms of reference.

Annex A

Task options

Laboratory works No. 1-5 are performed for the same option.

1. Develop a software module "Accounting for students' progress." The software module is designed to promptly record the progress of students in a session by the dean, deputy deans and dean's staff. Information about the progress of students should be stored during the entire period of their studies and used in the preparation of certificates of courses taken and diploma supplements.

2. Develop a program module "Personal files of students". The software module is designed to obtain information about students by employees of the dean's office, trade union committee and personnel department. The information must be kept during the entire period of students' education and used in the preparation of certificates and reports.

3. Develop a software module "Solution of combinatorial optimization problems". The module should contain algorithms for finding a cycle of minimum length (traveling salesman problem), finding the shortest path, and finding the minimum spanning tree.

4. Develop a software module "Matrix processing". The module should contain algorithms for finding sums and products of matrix elements by rows and columns, as well as calculating the average, minimum and maximum values ​​in the matrix.

5. Develop a Windows application "Organizer". The application is designed to record, store and search for addresses and phone numbers individuals and organizations, as well as schedules, meetings, etc. The application is designed for any computer user.

6. Develop a Windows application "Calculator". The application is intended for any user and should contain all arithmetic operations (with respect to priorities) and preferably (but not required) a few mathematical functions.

7. Develop a software module "Department", containing information about the staff of the department (name, position, academic degree, disciplines, workload, social work, part-time jobs, etc.). The module is intended for use by employees of the personnel department and the dean's office.

8. Develop a software module "Laboratory", containing information about the laboratory staff (name, gender, age, marital status, presence of children, position, academic degree). The module is intended for use by employees of the trade union committee and the personnel department.

9. Develop a program module "Dry cleaning". When registering for service, an application is filled in, which indicates the name of the owner, product description, type of service, date of receipt of the order and cost of the service. After the work is completed, a receipt is printed.

10.Develop a software module "Accounting for violations of the rules traffic". For each car (and its owner) a list of violations is stored in the database. For each violation, the date, time, type of violation and the amount of the fine are recorded. When all fines are paid, the car is removed from the database.

11. Develop a software module "Card file of a car shop", intended for use by agency employees. The database contains information about cars (make, engine size, release date, etc.). When a purchase request is received, a suitable option is searched. If this is not the case, the client is entered into the client base and notified when an option appears.

12. Develop a software module "Card file of ATS subscribers". The card file contains information about phones and their owners. Fixes payment arrears (subscriber and time-based). It is believed that the hourly payment of local telephone calls has already been introduced.

13. Develop a software module "Avtokassa", containing information on the availability of seats on bus routes. The database should contain information about the flight number, route, driver, type of bus, date and time of departure, as well as ticket prices. When an application for tickets is received, the program searches for a suitable flight.

14. Develop a software module "Bookshop", containing information about books (author, title, publisher, year of publication, price). The buyer fills out an application for the books he needs, if there are none, he is entered into the database and notified when the necessary books arrive at the store.

15. Develop a software module "Parking". The program contains information about the brand of the car, its owner, the date and time of entry, the cost of parking, discounts, payment arrears, etc.

16. Develop a program module "Recruitment Agency", containing information about vacancies and resumes. The software module is designed both to find an employee who meets the requirements of the company's managers, and to find a suitable job.

LAB #1

Stages of software development in a structural approach to programming. Stage "Terms of Reference"

Objective: Familiarize yourself with the rules for writing technical specifications.

Preparation for laboratory work

Read the lecture material on the topic “Software Lifecycle Models. Stages of the life cycle in accordance with GOST 19.102-77. Statement of the problem" of the discipline "Development and standardization of PS and IT".

Study the relevant sections in the publications.

Theoretical part. Development of technical specifications

Technical task is a document that formulates the main goals of development, requirements for a software product, determines the terms and stages of development, and regulates the process of acceptance tests. Both representatives of the customer and representatives of the contractor are involved in the development of the terms of reference. This document is based on the initial requirements of the customer, analysis of advanced technology, the results of scientific research, pre-project research, scientific forecasting, etc.

The order of development of technical specifications

The development of technical specifications is carried out in the following sequence. First of all, they establish a set of functions to be performed, as well as a list and characteristics of the initial data. Then a list of results, their characteristics and presentation methods are determined. Next, the software operation environment is specified: the specific configuration and parameters of the hardware, the version of the operating system used, and, possibly, the versions and parameters of other installed software with which the future software product will interact. In cases where the developed software collects and stores some information or is included in the management of any technical process, it is also necessary to clearly regulate the actions of the program in case of equipment and power failures. 1. General Provisions

The terms of reference are drawn up in accordance with GOST 19.106-78 on sheets of A4 and A3 format in accordance with GOST 2.301-68, as a rule, without filling in the fields of the sheet. Numbers of sheets (pages) are affixed at the top of the sheet above the text. The approval sheet and the title page are drawn up in accordance with GOST 19.104-78. The information part (abstract and content), the change registration sheet may not be included in the document. To make changes and additions to the technical background at the subsequent stages of developing a program or software product, an addendum to it is released. Coordination and approval of the addition to the terms of reference is carried out in the same manner as established for the terms of reference. The terms of reference should contain the following sections:

introduction; name and scope;

basis for development; purpose of development; technical requirements for the program or software product; technical and economic indicators; stages and stages of development; procedure for control and acceptance; applications.

Depending on the features of the program or software product, it is allowed to clarify the content of the sections, introduce new sections or combine some of them. If necessary, it is allowed to include applications in the terms of reference. 2. Content of sections

The introduction should include a brief description of the scope of the program or software product, as well as the object (for example, the system) in which it is supposed to be used. The main purpose of the introduction is to demonstrate the relevance of this development and show what place this development occupies among similar ones. In the section "Name and scope" indicate the name, a brief description of the scope of the program or software product and the object in which the program or software product is used. In the Basis for Development section, the following should be indicated:

document (documents) on the basis of which the development is carried out. Such a document can be a plan, order, contract, etc.; the organization that approved this document and the date of its approval; name and (or) symbol of the development topic. 2.4. The Purpose of Development section should indicate the functional and operational purpose of the program or software product. 2.5. The section "Technical requirements for the program or software product" should contain the following subsections:

performance requirements; reliability requirements; terms of Use; requirements for the composition and parameters of technical means;

requirements for information and software compatibility;

requirements for labeling and packaging; requirements for transportation and storage; special requirements.

The subsection "Requirements for functional characteristics" should indicate the requirements for the composition of the functions performed, the organization of input and output data, temporal characteristics, etc. The subsection "Requirements for reliability" should indicate the requirements for ensuring reliable operation (ensuring stable operation, control of input and output information, recovery time after failure, etc.). The “Operating conditions” subsection should indicate the operating conditions (ambient air temperature, relative humidity, etc. for the selected types of data carriers) under which the specified characteristics should be provided, as well as the type of service, the required number and qualifications of personnel. In the subsection "Requirements for the composition and parameters of technical means" indicate the required composition of technical means with an indication of their technical characteristics. In the subsection “Requirements for information and program compatibility”, the requirements for information structures at the input and output and solution methods, source codes, and programming languages ​​should be indicated. Where necessary, information and programs should be protected. In the subsection “Labeling and packaging requirements”, in the general case, the requirements for software product labeling, packaging options and methods are indicated. In the subsection “Requirements for transportation and storage”, the conditions for transportation, storage locations, storage conditions, warehousing conditions, storage periods under various conditions for the software product must be indicated.

2.5.8. In the "Technical and economic indicators" section, the following should be indicated: estimated economic efficiency, estimated annual need, economic advantages of the development in comparison with the best domestic and foreign samples or analogues.

In the "Stages and stages of development" section, the necessary stages of development, stages and content of work (a list of program documents that must be developed, agreed and approved), as well as, as a rule, the development timeframe and determine the executors are established. In the section "Procedure for control and acceptance" the types of tests and general requirements for the acceptance of work should be indicated. In the annexes to the terms of reference, if necessary, provide:

a list of research and other works substantiating the development; algorithm schemes, tables, descriptions, justifications, calculations and other documents that can be used in the development; other sources of development.

In cases where the customer does not make any requirements stipulated by the terms of reference, “No requirements are presented” should be indicated in the appropriate place. Examples of the development of terms of reference are given in appendices B and C.

Work order

Develop terms of reference for a software product according to your version (see options in Appendix A) Prepare the work in accordance with GOST 19.106-78. Use MS Office for registration. Submit and protect your work.

Lab report protection

The laboratory work report should be drawn up on the basis of the STP and consist of the following structural elements:

title page; text part; application: developed by the terms of reference for the software product.

The text part of the report should include the following items:

the task; execution order.

The hardened report on laboratory work consists in presenting the results to the teacher in the form of a file and demonstrating the acquired skills in response to the teacher's questions.

test questions

Give the concept of a software life cycle model. Give the stages of software development. What does the problem statement and pre-project research include? List the functional and operational requirements for the software product. List the rules for developing technical specifications. Name the main sections of the terms of reference.

Bibliography

Bedrina S.L., Development and standardization of software. - Vladivostok: VSUES Publishing House, 2006. Blagodatskikh V.A., Volnin V.A., Poskakalov K.F. Standardization of software development. - M: Finance and statistics, 2003. GOST 19.102-77 ESPD. Development stages

Annex A

Task options

Laboratory works No. 1-5 are performed for the same option.

Develop a software module "Accounting for students' progress." The software module is designed to promptly record the progress of students in a session by the dean, deputy deans and dean's staff. Information about the progress of students should be stored during the entire period of their studies and used in the preparation of certificates of courses taken and diploma supplements. Develop a program module "Personal files of students". The software module is designed to obtain information about students by employees of the dean's office, trade union committee and personnel department. The information must be kept during the entire period of students' education and used in the preparation of certificates and reports. Develop a software module "Solution of combinatorial optimization problems". The module should contain algorithms for finding a cycle of minimum length (traveling salesman problem), finding the shortest path, and finding the minimum spanning tree. Develop a software module "Matrix processing". The module should contain algorithms for finding sums and products of matrix elements by rows and columns, as well as calculating the average, minimum and maximum values ​​in the matrix. Develop a Windows application "Organizer". The application is designed to record, store and search for addresses and phone numbers of individuals and organizations, as well as schedules, meetings, etc. The application is designed for any computer user. Develop a Windows Calculator application. The application is intended for any user and should contain all arithmetic operations (with respect to priorities) and preferably (but not required) a few mathematical functions. Develop a software module "Department", containing information about the staff of the department (name, position, academic degree, disciplines, workload, social work, part-time work, etc.). The module is intended for use by employees of the personnel department and the dean's office. Develop a software module "Laboratory", containing information about the laboratory staff (name, gender, age, marital status, presence of children, position, academic degree). The module is intended for use by employees of the trade union committee and the personnel department. Develop a program module "Dry cleaning". When registering for service, an application is filled in, which indicates the name of the owner, product description, type of service, date of receipt of the order and cost of the service. After the work is completed, a receipt is printed. Develop a software module "Accounting for violations of traffic rules." For each car (and its owner) a list of violations is stored in the database. For each violation, the date, time, type of violation and the amount of the fine are recorded. When all fines are paid, the car is removed from the database. Develop a software module "Card file of an autoshop", intended for use by agency employees. The database contains information about cars (make, engine size, release date, etc.). When a purchase request is received, a suitable option is searched. If this is not the case, the client is entered into the client base and notified when an option appears. Develop a software module "Card file of ATS subscribers". The card file contains information about phones and their owners. Fixes payment arrears (subscriber and time-based). It is believed that the hourly payment of local telephone calls has already been introduced. Develop a software module "Avtokassa", containing information about the availability of seats on bus routes. The database should contain information about the flight number, route, driver, type of bus, date and time of departure, as well as ticket prices. When an application for tickets is received, the program searches for a suitable flight. Develop a software module "Bookstore", containing information about books (author, title, publisher, year of publication, price). The buyer fills out an application for the books he needs, if there are none, he is entered into the database and notified when the necessary books arrive at the store. Develop a software module "Parking". The program contains information about the brand of the car, its owner, date and time of entry, parking costs, discounts, payment arrears, etc. Develop a Recruitment Agency software module containing information about vacancies and resumes. The software module is designed both to find an employee who meets the requirements of the company's managers, and to find a suitable job.

Note. When developing a program, do not limit yourself to the functions given in the variant, add a few of your own functions. It is obligatory to use structural and modular approaches to programming.

Annex B

Example 1 Develop terms of reference for a software product designed to visually demonstrate to schoolchildren graphs of functions of one argument y= f(x). The developed program should calculate the table of values ​​and build a graph of functions on a given segment according to a given formula and change the argument step and the boundaries of the segment. In addition, the program must remember the entered formulas.

1. Introduction

This terms of reference applies to the development of a program for sorting a one-dimensional array using bubble methods, direct choice, Shell and quicksort, designed for use by high school students when studying a school computer science course. 2. Foundation for development

The program is developed on the basis of the curriculum of the Department of Informatics and Software for Computing Systems. Job Title:

"One-Dimensional Array Sorting Program".

Executor: BcstSoft company. Contributors: ist.

3. Appointment The program is intended for use by schoolchildren when studying the topic "Processing one-dimensional arrays" in the course "Informatics". 4. Requirements for the program or software product 4.1. performance requirements 4.1.1. The program should provide the ability to perform the following functions:

entering the size of the array and the array itself; array and memory storage; choice of sorting method; displaying a text description of the sorting method; output of the sort result.

4.1.2. Initial data:

array size, given as an integer; array.

Organization of input and output data.

The input comes from the keyboard. The output is displayed on the screen and, if necessary, printed.

Reliability Requirements

Provide control of the input information. Provide for blocking incorrect user actions when working with the system.

Requirements for the composition and parameters of technical means.

The system must run on IBM-compatible personal computers. Minimum configuration:

processor type Pentium or higher; the amount of random access memory 32 MB or more; the amount of free space on the hard disk is 40 MB.

Recommended configuration:

processor type Pentium II 400; the amount of random access memory 128 MB; the amount of free space on the hard disk is 60 MB.

4.4. Software Compatibility Requirements.
The program must be managed by the family operating systems Win 32 (Windows 95/98/2000/ME/XP etc.).

The developed software modules must be self-documenting, i.e. the program texts must contain all the necessary comments. The program being developed should include background information on the operation of the program, descriptions of sorting methods, and tips for students. The accompanying documentation should include:

Explanatory note on five sheets, containing a description of the development. User's manual.

Annex B

Example 2 Develop terms of reference for the development of the “Module for the automated system for the operational dispatch control of heat supply to the buildings of the Moscow Institute”.

1. Introduction

The work is carried out within the framework of the project "Automated system of operational dispatch control of electric heat supply of buildings of the Moscow Institute". 2. Foundation for development

The basis for this work is the contract No. 1234 dated March 10, 2003.

Job Title:

"Module of the automated system for operational dispatch control of heat supply of buildings of the Moscow Institute".

Performers: OJSC "Software Creation Laboratory".

Companions: no.

3. Purpose of development Creation of a module for monitoring and prompt adjustment of the state of the main parameters of the provision of the buildings of the Moscow Institute. 4. Technical requirements 4.1. performance requirements. 4.1.1. The composition of the functions performed. The developed software should provide:

collection and analysis of information on the consumption of heat, hot and cold water according to SA-94 heat meters at all heat outlets; collection and analysis of information from control devices for air heating and air conditioning systems such as RT1 and RT2 (development of the Department of SMME and TC); preliminary analysis of information in order to find the parameters within acceptable limits and signaling when the parameters go beyond the tolerance limits;

issuing recommendations for further work;

display of the current state by a set of parameters - cyclically constantly (round-the-clock operation), while maintaining the frequency of monitoring other parameters; visualization of information on coolant consumption:

current, similar to meter readings; with accumulation for the past day, week, month - in the form of an hourly chart for information for the day and week; daily consumption - for information for the month.

For supply ventilation control devices, the current information must contain the number of the supply system and all parameters displayed on its own indicator. On request, internal adjustments are made. At the end of the reporting period, the system must archive the data. 4.1.2. Organization of input and output data. The initial data enters the system in the form of values ​​from sensors installed in the institute's premises. These the values ​​are displayed on the dispatcher's computer. After analyzing the information received, the operator of the control room sets the necessary parameters for devices that regulate heating and ventilation in the premises. It is also possible to automatically set some parameters for control devices. The main mode of using the system is daily work. 4.2. reliability requirements. To ensure reliability, it is necessary to check the correctness of the data received from the sensors. 4.3. Operating conditions and requirements for the composition and parameters of technical means. A responsible operator must be allocated for the operation of the system. The requirements for the composition and parameters of technical means are specified at the stage of the preliminary design of the system. 4.4. Requirements for information and software compatibility. The program must run on Windows 98/NT/2000 platforms.

4.5. Requirements for transportation and storage.

The program is delivered on a laser data carrier. Program documentation is supplied in electronic and printed form. 4.6. Special requirements:

the software must have a user-friendly interface designed for the user (in terms of computer literacy) qualifications; due to the volume of the project, the tasks are supposed to be solved in stages, while the software modules created at different times should provide for the possibility of expanding the system and be compatible with each other, so the documentation for the accepted operational software should contain complete information necessary for programmers to work with it; programming language - at the choice of the contractor, should provide the ability to integrate software with some types of peripheral equipment (for example, SA-94 counter, etc.).

5. Requirements for software documentation The main documents regulating the development of future programs should be the documents of the Unified System of Program Documentation (ESPD): user's manual, administrator's manual, application description. 6. Technical and economic indicators The effectiveness of the system is determined by the ease of use of the system for monitoring and managing the main parameters of heat supply to the premises of the Moscow Institute, as well as the economic benefits obtained from the implementation of the hardware and software complex. 7. Procedure for control and acceptance After the Contractor transfers a separate functional module of the program to the Customer, the latter has the right to test the module within 7 days. After testing, the Customer must accept the work for this stage or state in writing the reason for refusal of acceptance. In case of a justified refusal, the Contractor undertakes to modify the module.

1. Terms of reference for the supply of equipment for the development of information technology infrastructure of the fire department and the emergency response service. Subject of the state contract

   Technical task

   for the supply of equipment for the development of the information technology infrastructure of the fire department and the emergency response service.

2. Terms of reference for a complex of design and construction works

   Technical task

   2.1. Performance of work under this Terms of Reference implies the performance by the Contractor of the entire range of survey, design and construction works for the reconstruction (re-equipment, redevelopment) of the turnkey construction facility, incl.

3. Terms of reference for the implementation of work on the creation of a site of sheets

   Technical task

   requirements of RD 50-34.698-90 " Guidelines. Information technology. A set of standards and guidelines for automated systems.

4. Terms of reference for conducting a survey of the technical condition of apartment buildings for major repairs. Low-current system. Communication, alarm, security

   Technical task

   The automatic fire alarm system, as well as the warning and evacuation control system, is an integral part of the life support systems of buildings.

5. Terms of Reference Lot No. 1 Supply of foreign literature for the library of SevKavgtu

   Technical task

   Procedure for setting the price of the contract: the price of the contract must include all the Supplier's expenses related to the fulfillment of the contract, including the costs of delivery, unloading of literature to the library premises, payment of VAT and payment

6. Terms of reference for documentation on an open auction in electronic form No. 624-ea for the right to conclude

   Technical task

   2. Requirements for the term and (or) scope of providing product quality guarantees: the warranty period for the delivered product must be at least 24 months from the date of commissioning.