The procedure for developing technical specifications. Development of technical specifications

The technical specifications for the process control system are developed in accordance with GOST 34.602-89 and contain the following sections:

1. General information
1.1. Full name of the System
1.2. Topic code
1.3. Name of Organizations - developers, designers, customers, and their details
1.4. List of documents on the basis of which the System is created
1.5. Deadlines for completion of work
1.6. Sources and procedure of financing
1.7. The procedure for processing and presenting the results of work to the customer
2. Purpose and goals of creating the System
2.1. Purpose of the System
2.2. Goals of creating the System
3. Characteristics of the automation object
4. System requirements
4.1. Requirements for the System as a whole
4.1.1. Requirements for the structure and functioning of the System
4.1.2. Requirements for the number and qualifications of personnel
4.1.3. Requirements for destination indicators
4.1.4. Reliability requirements
4.1.5. Security requirements
4.1.6. Requirements for ergonomics and technical aesthetics
4.1.7. Operating requirements maintenance, repair and storage
4.1.8. Requirements for protecting information from unauthorized access
4.1.9. Requirements for the safety of information in case of accidents
4.1.10. Requirements for means of protection against external influences
4.1.11. Requirements for patent purity
4.1.12. Requirements for standardization and unification
4.1.13. Additional Requirements
4.2. Requirements for functions implemented by the System
4.2.1. List of DCS tasks and requirements for the quality of their implementation
4.2.2. List and failure criteria for each DCS function
4.2.3. List of tasks of the ESD system
4.2.4. List and failure criteria for each function of the safety and security system
4.3. Requirements for types of Collateral
4.3.1. Application Software Requirements
4.3.2. Requirements for Information Support
4.3.3. Requirements for linguistic support
4.3.4. Standard Software Requirements
4.3.5. Requirements for technical support
4.3.6. Requirements for Metrological Support
4.3.7. Requirements for Organizational Support
5. Composition and content of work on the creation of automated process control systems
5.1. First organizational meeting
5.2. Processing of source data
5.3. Development of the Technical Project
5.4. Review of the Technical Design
5.5. Configuration of monitoring and control functions
5.6. Configuration of information presentation functions
5.7. Acceptance of the Detailed Design
5.8. Supervised installation and commissioning
5.9. Putting the process control system into operation
5.10. Warranty period
6. Procedure for control and acceptance
7. Requirements for the composition and content of work to prepare the facility for the commissioning of automated process control systems
8. Documentation requirements
9. Development sources
10.APPLICATIONS
11. COMPLETED
12. AGREED

Terms of reference (hereinafter referred to as TK) - this document serves as the foundation, the starting point for the creation of any project or product. TK indicates the main criteria, principles and purposes of the object. Technical and software requirements, quantitative and qualitative indicators, design requirements and compliance with GOSTs and much more can be indicated in the technical specifications.

TOR is a legal document included in the contract (usually as an appendix) between the customer and the contractor for the performance of certain works, production or provision of services. The technical specifications most fully describe the tasks, goals, principles, timing, order and expected results of all work. As a result, it is the technical specification that serves as the document against which the conformity of the work performed is assessed for each item.

Changes to any of the items terms of reference They must undergo a process of coordination with the customer and are approved by him. This is dictated by the fact that if inaccuracies, deviations or errors in the initial data occur during the execution of work, one party or another may suffer losses, and it is the technical specification that will regulate the degree of guilt of one or another party.

Initially, the technical specifications are prepared and provided by the customer, but often the customer shifts this task to the contractor, providing only a number of technical specifications and wishes in consumer language, far from professional language and subject terminology. It is necessary to avoid uncertainties and ambivalent interpretations of the terms of reference; this may lead to uncertainty for all participants and will not allow an objective assessment of the quality of the work done. Also, the contractor must be aware that the customer may not have a complete understanding and knowledge of the special requirements, which in no case relieves the contractor of responsibility and obligation to comply with all norms and requirements supervisory authorities, regardless of whether they were in the technical specifications or not. Thus, both the customer and the contractor are responsible for setting tasks in the technical specifications and the quality of the result.

In any case, the more painstakingly and accurately the technical specifications are drawn up and agreed upon, the fewer degrees of freedom and loopholes the contractor will have to do his job dishonestly. Depending on how competently the technical specifications are drawn up, the quality and speed of the work will depend; this statement also works in the opposite direction.

A competently drawn up technical specification increases the chances of successful completion of a future project by 50%, and the time invested in the development of technical specifications is one of the best investment, which the customer can do during the project period. Therefore, the preparation of technical specifications is entrusted to the most experienced and qualified specialists, because correcting any mistake made at the design stage of technical specifications can be very expensive after the conclusion of the contract, and in some cases even put an end to the project as a whole.

The terms of reference serve as a strong bridge of mutual understanding between the customer and the contractor, helping to understand:

To the customer:

What exactly would he like to get as a result, based on his current resources and capabilities;
Carry out internal coordination of requests between structural divisions;
Monitor the compliance of the work performed by the contractor.

To the Contractor:

Understand the essence and details of the task;
Make plans for completing the work;
Exclude additional work, not described in the terms of reference, or require additional funding for this.

To all parties:

Understand the essence and appearance of the final product or service;
Check the work performed, conduct acceptance testing;
Minimize the number of errors and inaccuracies in the change process.

Development and approval of technical specifications for the creation of an NPP - stage 3.1 of the technical specifications stage. Revision dated June 20, 2018.

Development and approval of technical specifications for the creation of nuclear power plants

Created 05/18/2018 11:24:34

From the explanatory dictionary

Development is the construction, creation, approval - giving the document legal force. In the current one, this is filling out the structural terms of reference and receiving an approving signature on its title page. And the imprint of the approving seal.

Terms and definitions

Approval - An official certification by an authorized official or that something developed is being put into effect. The certificate can be recorded on the approved document directly or by reference to another document containing the decision on approval (act, protocol, letter, etc.) [from clause 1.4.74 R 50-605-80-93].

Standard requirements

The title page contains the customer, developer and approving organizations, which are sealed with an official seal. If necessary, the title page is drawn up on several pages. Signatures of the developers of technical specifications for the speakers and officials those involved in the coordination and consideration of the draft technical specifications for the plant are placed on the last sheet. Form title page The specification for the speaker is given in. The form of the last sheet of technical specifications for the AS is given in [from clause 3.4 of GOST 34.602-89].

At 3.1 “Development and approval of technical specifications for the creation of an NPP”, the development and, if necessary, technical specifications for parts of the NPP are carried out [from paragraph 7 of the appendix. 1 GOST 34.601-90].

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 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): “ Terms of reference- this is the original design document technical object. Terms of reference establishes the main purpose of the object being developed, its technical and performance characteristics, quality indicators and technical and economic requirements, instructions for performing 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, project assignment in construction, combat mission, homework, contract for literary work etc.)"

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 good example which 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're 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:

The requirement must be understandable;
The requirement must be specific;
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 another 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?

Terms of reference- 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 existing software product, then such a link 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 more people working on technical specifications.

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,” “it’s too complicated,” “it’s 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 separate document: 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, but 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 Terms of reference necessary, otherwise you won’t 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. 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 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 exam paper specialist (that’s what he’s called, not a “programmer”), then 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 medium difficulty), and 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 an axiom because 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. By expert assessments, 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 important document, and should be formatted 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.

general information;
purpose and goals of creation (development) of the system;
characteristics of automation objects;
system requirements;
composition and content of work to create the system;
procedure for control and acceptance of the system;
requirements for the composition and content of work to prepare the automation object for putting the system into operation;
documentation requirements;
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.

Recommendations according to GOST
full name of the system and its symbol;	Everything is clear here: we write what the system will be called, its short name
subject code or contract code (number);	This is not relevant, but you can specify it if required
the name of the enterprises (associations) of the developer and customer (user) of the system and their details;	indicate who (which organizations) will work on the project. You can also specify their roles. You can even remove this section (quite 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 was provided to you to familiarize yourself with a certain part of the requirements
planned start and finish dates for work on creating the system;	Requests for timing. Sometimes they write about this in the technical specifications, but more often such things are described in work contracts
information about the sources and procedure for financing the work;	Same as in the previous paragraph about deadlines. More relevant for government orders(for state employees)
the procedure for registration and presentation to the customer of the results of work on creating the system (its parts), on the production and adjustment of individual tools (hardware, software, information) and software and hardware (software and methodological) complexes of the system.	I don’t see the need for this point, because... Documentation requirements are set out separately, and in addition 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.

Recommendations according to GOST	What to do about it in practice
Purpose of the system	On the one hand, the purpose is simple. But it is advisable to formulate it specifically. If you write something like “high-quality automation of warehouse accounting in company X,” then you can discuss the result for a long time upon its completion, even regardless of the good formulation of the requirements. Because The customer can always say that by quality he meant something else. In general, you can spoil each other’s nerves a lot, but why? It’s better to immediately write something like this: “The system is designed to maintain warehouse records in company X in accordance with the requirements specified in this Technical Specification.”
Goals of creating the system	Goals are definitely an important section. If we are to include it, then we must be able to formulate these goals. If you have difficulty formulating goals, then it is better to exclude this section altogether. An example of an unsuccessful goal: “Ensure that the manager completes documents quickly.” What is fast? This can then be proven endlessly. If this is important, then it is better to reformulate this goal like this: “The sales manager should be able to draw up a document “Sales of goods” of 100 lines in 10 minutes.” A goal like this might come up if, for example, a manager is currently spending about an hour on this, which is too much for that company and it's important to 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 get closer to the requirements. Therefore, you shouldn’t get carried away.

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, of course, will be the section with specific requirements (functional), this section may also have great value(and in most cases it does). What may be important and useful:

Qualification Requirements. It is possible that the system being developed will require retraining of specialists. This could be like users future system, as well as the 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 “Get information about the price of a product by pressing only one button” may be formulated. 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. This is what 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 precisely 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 new system, which means we can’t be sure that it works.” So learn to correctly identify the stages of work, and how 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 commissioning of the system

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 local network, an outdated fleet of computers on which the system will not work.

Perhaps some necessary information was processed on paper and now 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 “of course” supposedly implied. 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

Recommendations according to GOST	What to do about it in practice
Documents must be listed and information materials(feasibility study, reports on completed research work, information materials on domestic and foreign analogue systems, etc.), on the basis of which the technical specifications were developed and which should be used when creating the system.	To be honest, this is closer to the lyrics. Especially when they talk about economic effect and other things that are almost impossible to objectively calculate. Those. Of course, it will be more likely on paper, purely theoretically.

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 closer to the result, then you do not need it and you do not 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 figures who will be able to separate the waters in all sections, describe general requirements in general terms, and the document turns out to be quite 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 it will be done by completely different people. 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.

Type of requirement

Incorrect wording

What to do if the development of technical specifications for a not very complex project takes a couple of months? What steps in developing technical specifications can protect against risks and errors? In this article we will consider the problem not of the content of the document, but of the methodology for its development.

What and how

The terms of reference are only part of the project. Be it a startup or a new service within an existing product.

In any case, the technical specification must present the fantasies of the Customers and Performers in an adequate and feasible form. When we talk about development methodology, we should not divide technical specifications into technical specifications for small or big projects. This is always a serious document, where the developer of the technical specifications (and the manager, of course) will be to blame if anything happens.

Stages of development of technical specifications

1. Preliminary study of the brief/task

As a rule, there is an ephemeral representation of what the customer wants - in the form of a brief, a letter with “wants”, technical specifications. Study the subject area, make a list of questions.

Collect information about the company, market, clients, competitors. The information you review will give you an understanding of the customer’s business, which, in turn, will raise you in his eyes.

2. Holding a meeting

Always make a specific list of questions and slowly find out everything from the customer.

Do not conduct the meeting as a survey; the customer may feel like he is being interrogated and become withdrawn. You should start with “tell us about the project and what you expect to get from it.” The customer will relax, will talk a lot, and in the meantime you will take notes on what coincided with your vision and understanding and what did not.

Write down the answers next to the questions and re-read them.

If the answer is still not received (it happens that the customer answers the question abstractly, and in the end there is no answer), ask the question again, changing the wording. For example, “I imagine this functionality like this... Do I understand you correctly? Does this match your vision?

Don't be afraid to ask questions, no matter how unexpected they may seem. Many things are so obvious within a particular business that you may forget to mention them.

3. Concept development

The concept usually contains brief abstracts of the future technical specifications, namely:

Goals and objectives;
Purpose;
Roles;
Structure;
Content;
List of features (in the form of services - briefly).
Sometimes the concept contains detailed description business ideas to understand why the project is beneficial.

Always develop a concept - a sketch of the future project. Often this allows you to reduce risks and also dot the i’s for both you and the customer.

4. Clarification of requirements

After the concept is approved, you clarify and formalize the missing requirements. Fix the requirements in the technical specifications, form them into ready-made blocks with descriptions (and preferably with interfaces). It is easier for the customer to perceive information about what he wants when there is graphic support of the described requirements.

Go through several iterations of developing the technical specifications, each time adding and changing the document based on the customer’s comments.

Even if everything seems clear and obvious, you need to ask whether you understand correctly. This will save a lot of time and nerves. Even when talking about simple news, we should not forget that there are concepts of “frequency of publication,” who updates, what materials may be in the news, etc. Answers to such questions can radically change the structure of the page and the priority of information.

5. Approval of technical specifications

Customers are divided into two types - those who do not take the technical specification seriously and think “they will do as I say anyway,” and those who try to fit the possible and the impossible into the technical specification. In a project, it is important to produce a good work product. No excess.

An example of an argument for dividing a project into stages: “Let's first implement a good working version, with basic functions, and then we will refine and come up with additional features. But we are planning on the opportunity you described from the very beginning.”

Try to always think about who will use the product. It is possible to provide all capabilities to the user, but either to the detriment of convenience or to the detriment of implementation time.

Difficulties and how to avoid

1. Missing deadlines

Sometimes it happens that there is no so-called muse to write a document. Sit down, read an interesting book, watch an interesting show or cartoon. No need to “surf the net.” New emotions from a book or something watched can greatly develop the imagination, give strength and inspiration. Don't put everything off until the very last day.

Do not give a false impression about the timing of the project and your capabilities; include deadlines for approval in the work plan. Plan the time allocated for the project: schedule the days according to tasks, and stick to the developed schedule.

2. Price-terms-scope of work

Always think about the fact that any task has a deadline and price. It is important to propose solutions without abstracting from these meanings.
3. Feedback

Always answer emails and calls. It is important for the customer to have feedback from you. He must be sure that if controversial issues, questions, or clarifications arise, he can call or write and get answers.

4. Try to record everything you agree on.

Confirm all the customer’s wishes conveyed to you in a conversation or in a personal meeting by letter, listing the items to be fulfilled; state the deadlines for completing the above.

If the customer sends 15 letters a day with wishes, ask the customer to collect the wishes in one letter. This way you will reduce the risk that some information will be lost in correspondence, and you will have to spend time making changes.

5. Present the result

Many ideas are rejected because they were not submitted with correct description. For example, if a customer wants to implement a function in one way, and you do not agree with this, develop your version, justify it, describe the idea of implementation, tell us about the advantages of your solution.

Try not to do only as the customer wishes. As a rule, the worst option in this case will be accepted.

When this is not the first time you are working on creating a technical specification, follow your rules. For example, the rules could be:

Mind maps

Mind Maps technique. Develop technical specifications using mental maps. The essence of the process is that you initially draw a future project in the form of a diagram. You divide the product into entities, concepts; Moreover, each point of the tree should not contain more than 3-4 words. Such a diagram is quickly read by all project participants, and it is easy to change and supplement the tree. There are many programs for developing such maps.

Versions and file names

Name files correctly. For example, this could be the name of the project - encoded or in its entirety. Write the version in the name of each file. This will make it easier for you to understand which file was the last one.

Based on experience, it is convenient to make names and versions of the following form:

NameProject.0.1.doc,

Where NameProject- name of the project,

0 - version sent to the client; If 0 - this means it was not sent while you are working within the company (department);

1 - the version that you create within the company (department).

For example, you sent version 0.1 to the client, while you are still working on the technical specifications. You create version 0.2 because it is a change, but it is already yours or within the company. You receive comments from the client and create an even newer version - 1.3.

If there are several documents (for example, concept, technical specifications), add the document type to the document name - NameProject.Concept.0.1.

Structure

Have a clear structure of the terms of reference. When collecting information, as well as developing a document, follow it. Depending on the customer's expectations, there are 4 alternatives for choosing a technical specification template. This could be GOST, IEEE, Corporate template, your own template (or the template of the company you work for).

Formatting

A good document is a competent and correctly executed document. Well-designed documents are easy to read because they don’t have dozens of styles or multiple blocks of text with different designs.

Conclusions
Try new templates and description formats. You are the one who can solve a business problem by offering competent and good decision; someone who can make product users happier (due to a convenient and logical interface). Value yourself and your time, because the finished product is the result of your efforts.

Popular

Chicken egg How to distinguish domestic eggs

« - This is a very common food product in the diet of modern people. In this article I would like to talk about the composition of a chicken egg... »

Cossacks - knights of Orthodoxy

« “Cossack” means “free”, “brave, freedom-loving person”, “daring warrior”. The Cossacks arose by the will of the government - by decree of Queen Elizabeth... »

Budget analysis, which will help to objectively assess the financial result of the company Plan factual analysis of budget execution

« Budgeting as a management technology is characterized by the fact that almost all departments of the enterprise are involved in it (and very actively).... »