Development of technical specifications (TZ) for a software product from the point of view of the customer. We work on bugs

In the recent past, an article “ Development of a technical assignment (TK) for a software product from the point of view of a customer was published on this remarkable resource. The article - not a bad one in itself - unfortunately contains a number of inaccuracies that should be mentioned. Let's do it in “one pass” in paragraphs. In the second paragraph:

It must be said that each of these stakeholders has their own requirements and their own vision of what a “well-written TK” should be. For example, the customer and the contractor may have completely opposite opinions on this matter.

Clarifications:

1. Technical tasks are not written (they make up, prepare, draw up, etc.), but develop , see at least clause 1.2 of GOST 34.602-89;
2. If the customer and the performer are guided by the requirements of GOST, then in principle they can not and should not have completely opposite opinions. If the interaction is carried out “by notions” - as is customary now - then, of course, one cannot do without “pluralism of opinions”.

The contractor may be interested in the most detailed TOR in order to maximally formalize its obligations regarding the functionality of the solution being created.

Three-point stick:

1. An overly detailed technical project becomes a technical project, which, in general, is not bad, but who will give the performer so much time and money to develop an unnecessarily detailed TK?
2. A sane executive always seeks to reduce the scope of the technical task, since “fewer words - fewer questions”. And less work. Moreover, at the stage of technical assignment it is very difficult to predict the technical appearance of the product, program or automated system as a whole, therefore there is a typical excuse "this and that should be clarified at the technical design stage";
3. The contractor should not forget that he has obligations not only in terms of the implementation of functional requirements, but also of general requirements - requirements for reliability, security, etc. It makes no sense to list, since there are quite a lot of them and all of them are described in detail in the same GOST 34.602-89.

At the same time, a customer who has not precisely decided on the parameters of the future system or whose “wind is in his head” may require more general formulations, a description of the system in large strokes in order to try to include new requirements within the agreed budget.

And here it all depends on the experience of the performer. An intelligent contractor must prescribe a condition in the contract or terms of reference, under which all additional customer desires of the customer must be financed separately with a corresponding increase in the development period (additions to the terms of reference, additional agreements, etc.). At the same time it is very important - it is extremely important! - do not completely trust the preparation of the contract to lawyers, be sure to verify everything down to every comma, ruthlessly destroy any legal casuistry in the documents, bring the documents into a harmonious, strict and transparent form. In the third paragraph:

As mentioned above, at the time you start working on the TOR, you may have little idea ... You may have scattered, often conflicting requests as source data ... Well, if your IT service succeeded ... If not, then the best option is it is first to develop a very general TZ, in large strokes describing the vision of the system, to list the necessary modules (subsystems), without going into details of their functioning, and then work together with the contractor on detailing the requirements for them.

In fact, this is correct, only it will not be TK, but something like an operational technical note, TTZ, applications, letters with Wishlist - common functional requirements. Now let's talk about inaccuracies: you cannot mix the concepts of modules and subsystems, because a subsystem is the same system, only a small one. The subsystem, like the system, includes all types of software, all the same general requirements, and the module is just “A program or a functionally complete program fragment, designed to be stored, translated, merged with other software modules and loaded into RAM [from Clause 15 of Table 1 of GOST 19781-90]

This will give you a better time to understand what you want to get in the end, mobilize the company's divisions to work on the project, gather the necessary information, learn the basic concepts, if the subject matter of the solution being created is new for you. Also, the performer will be able to better get acquainted with the activities of your company.

As for the "basic concepts", then there is a huge number of GOSTs, containing in their names the line "... Terms and definitions". They should be used in the work in order to quickly master a new subject area, but in no case do not refer to all sorts of "... pedias," since this is not only undignified, but also fraught with side effects. In the fourth paragraph:

An important point is the likelihood of requirements drift ... In order to avoid unnecessary problems in the future, this should be immediately discussed with the contractor and adjusted for long-term cooperation. A competent performer in these conditions can choose a so-called. spiral model of software development, in which TK, in fact, is developed on each new turn of the spiral and describes the changes that should occur in the next version of the software product.

The executor will cling to all limbs for long-term cooperation, if, of course, the customer is imputed ... We replace the spiral model with clause 1.7 of GOST 34.602-89 and specify clause 11 of Appendix 1 of the same standard. In the seventh paragraph:

The complexity of the task also has an impact on the approach to writing TK ... The complexity usually lies in the fact that ... In this case, it is very important to correctly divide the project into stages (steps), implying that each next step will be adjusted according to the results achieved at the previous ones. Accordingly, the technical task will be developed at the beginning of each stage, based on the experience of the previous one.

The concepts of stages and queues are mixed. With regard to automated systems: Stage - Part of the stage of creation of the AU, allocated for reasons of unity of the nature of the work and (or) the final result or specialization of performers [from clause 4.4 of GOST 34.003-90] Queue - Part of the AU for which In general, there were established separate terms of entry and a set of implemented functions [from clause 4.5 of GOST 34.003-90] In the ninth paragraph:

The degree of detail of the TK and the separation in the time of its development, of course, are not the only moments important for the customer. Before starting the development of TK, I highly recommend to determine its structure, in fact, to compile pages with its content, a list of items and sub-items before starting work on the TK, and not during or after. In this case, you and the contractor agree on what issues should be considered at this stage. You will understand well what you will receive in the end, and the performer will understand what you expect from him. Despite its apparent simplicity, this is not always done, even for large and complex projects. As a result, the TK may turn out completely indecent for further work.

Why all this amateur with drawing up pages with the contents of the TK? There is GOST 19.201, there is GOST 34.602 and other standards in which the structure and content of technical specifications are clearly and strictly defined by the state, contains almost nothing superfluous, and it is allowed to introduce additional sections, subsections, paragraphs and sub-items at the discretion of the customer and the performer? In the tenth paragraph:

... TK, explicitly or implicitly, is present in any of them. In this case, the templates of this document can vary significantly for different companies and software development processes. The future developer of your system can impose the TK templates adopted by him, but in this case it is important to understand that, firstly, TK is an essential tool not only for the contractor, but also for the customer, who also has the full right to determine its structure .. .

Here it is completely incomprehensible: after all, the one who pays and orders the customer orders the music. How can a performer impose anything on him? Only mutual “consent as a product with complete non-resistance of the parties” is possible here ... In the eleventh paragraph:

Currently, the Russian Federation has a GOST 34.602-89 “Terms of Reference for the creation of an automated system”, which, despite the 89th year of its creation, reflects well the general structure of the TK. Nevertheless, for many cases, it is not sufficiently detailed and well describes the specifics of the development of modern software products.

Tears flowed:

1. It’s not good or bad to judge us, since all existing foreign standards, including MIL, are not even close to the GOST of the 34th system in terms of detail and coverage;
2. GOST 34.602 has nothing to do with software products, since “This standard applies to automated systems (AS) for the automation of various types of activities (management, design, research, etc.), including their combinations, and establishes the composition, content, rules of execution of the document “Technical task for the creation (development or modernization) of the system” (hereinafter - TK at the NPP) ”.

True, the individual requirements of GOST 34.602 should be added to the TZ developed according to GOST 19.201 to compensate for some of its flaws, which is not forbidden by GOST 19.201 itself - “Depending on the features of the program or software product, it is allowed to clarify the content of sections, introduce new sections them [from clause 1.4 of GOST 19.201-78] ”. In the fourteenth big paragraph:

Categories (roles) of users working with the system - list the roles and briefly describe which posts from which departments they correspond to.

All this is not provided for by both GOST 19.201 and GOST 34.602, but there is a subsection “Requirements for the number and qualifications of the system personnel and the mode of its operation”, which is reasonable to add to the TOR for the software and to describe in detail the personnel categories in it. And even the roles ... And in GOST 34.602 there are requirements for organizational support - they can be perfectly turned around and give free rein to the imagination. Everything that is listed below is detailed in RD 50-34.698-90. If you are interested in the details - ask questions in the comments. According to the conclusion:

In conclusion, I would like to note that in my experience the best TK is TK written by the customer himself or with the most active participation of the customer, since no one knows your needs, the details of the work better than the employees of your company, and it is far from always possible to figure this out at an interview. Of course, to do this you need to have enough qualified IT specialists in your staff or use the services of an IT consultant. The received TK can be used as part of the tender documentation in order to give a large number of potential contractors a clear understanding of the required result and to receive offers from them.

And finally:

1. “Legislatively” the TK is developed by the customer only if he represents the Ministry of Defense or another security agency;
2. Tender documentation is developed by the contractor who knowingly must win the tender. Sorry, but these are realities ...

Something like this. In conclusion, we can recommend an old article. The terrible truth about the terms of reference , which describes in some detail the processes of interaction between the customer and the performer during the development of the technical specifications, as well as all sorts of "secret tricks" of this wonderful document. To the author of the original article: as mentioned at the beginning, this post was created in “one pass”, i.e. Some of our clarifications turned out to be "ahead" - something was taken into account by the author of the source below in the text. Nothing personal...