Development of technical specifications (TZ) for a software product from the point of view of the customer
During my work I was able to look at the process of developing technical specifications for software products from several points of view. From the point of view of the analyst - the direct executor of work, from the point of view of the project manager on the part of the performer organizing the process of creating the TK, from the point of view of the head of the group of developers implementing these very TK, and also from the point of view of the customer of the system who subsequently decides .
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. 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. 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 with large strokes in order to try to include new requirements within the agreed budget. Of course, with a different “mentality” of the customer and the performer, everything can be exactly the opposite. Now I would like to dwell on the development of TK from the point of view of its customer, having considered possible situations, goals and tactics of behavior.
To begin with, we will determine the factors that influence the development of TK. First of all, it is the degree of understanding of customer requirements. As mentioned above, at the time you start working on the TOR, you can have little idea what kind of system you want to create. As a source of data, you may have disparate, often conflicting requests from units interested in creating a new system. It is good if your IT service managed to structure them, resolve inconsistencies and, thus, prepare for communication with the contractor. If not, then the best option is to first develop a very common TZ, with large strokes describing the vision of the system, list the necessary modules (subsystems), without going into details of their functioning, and then work with the executor on detailing the requirements for them. Subsequent versions of the TK can be made up as additions to the original TZ or as a so-called. “Private technical assignments” (CTZ) for solution modules. 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.
An important point is the probability of requirements drift. Companies are changing, adapting to external challenges, and, often, this happens quite quickly. What is developed today can serve its own and become completely unnecessary tomorrow in its original form. In order to avoid unnecessary problems in the future, it is necessary to immediately speak with the performer and tune in to 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. In this case, it is possible to refuse to write a bulky initial TZ by limiting the TZ to the first version (iteration).
')
The expected duration of the project, in fact, is one of the factors driving requirements. Over the long term, even in a fairly slow-moving company, a lot can change, for example, a new leadership with a new vision will appear. If, on the contrary, the project is small and fast, then the best option is to develop, coordinate and implement one small and sufficiently detailed TK.
A significant number of project participants who create separate components of the solution require more detailed technical tasks developed by them, as well as taking into account the specifications and implementation features of neighboring modules at the TOR stage. This will help to further minimize the risks of module mismatch and, accordingly, avoid unnecessary psychological and material costs for rework.
The complexity of the task also influences the approach to writing TK. Alas, the task may be too difficult, not only for the customer, but also for the performer, who would seem to have experience in creating solutions of this class. The difficulty usually lies in the fact that the solution being created is not typical and none of the project participants can predict in advance the result of its implementation and use in business. In this case, it is very important to competently break 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.
Companies work in a real environment and often they have to deal with new partners with whom they have not previously worked. The same applies to IT solution developers. Of course, it’s good to have an artist who knows all the details of your business, understands you perfectly and in which you are 100% sure (in this case, you can refuse to develop TK, in general, but in reality it may turn out to be completely unknown to you company. In this case, of course, it is advisable to start cooperation with small, if possible, projects and with clear and detailed wording of the requirements specified in the ToR.
The degree of detail of the TK and the separation in the time of its development, of course, are not the only points 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 the 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.
As you know, there are many software development methodologies that differ among other things by the different degree of formality of project documentation. However, TK is explicitly or implicitly present in any of them. In this case, the templates of this document may vary significantly for different companies and software development processes. The future developer of your system can impose on you 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. And, secondly, common sense and the main purpose of the TK, consisting in the formation of a common vision of the software product by the customer and performer, are not canceled by any of the development methodologies.
Currently, the Russian Federation has a GOST 34.602-89 “Terms of Reference for the creation of an automated system”, which, in spite of 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.
From my own experience I can recommend to draw the attention of the contractor to the need to consider in the TK, among other questions:
Categories (roles) of users working with the system - list the roles and briefly describe which posts from which departments they correspond to.
The functional of the system is to create a hierarchical structure in which large modules (subsystems) are listed on the top level, further detailed to smaller functional blocks and even individual functions.
The system usage model is to compare the categories of users of the system and the functional blocks used by them, indicated above.
Scenarios for using the system when performing core business processes is to impose a vision of a solution on actual processes, describe at what stages and how it will be used. Take the time to work together with the contractor to visually schematically paint scenarios at least for the main business processes and coordinate them with interested parties.
User interface prototypes - schematically depict, for example, with the help of Microsoft Visio what the main forms of your future software will look like.
Logical data model - to depict the main entities of the subject area and the relationship between them. This will allow you and the performer to speak the same language using common terminology.
Data sources and interaction with other systems - describe where the initial data will be loaded from when the system is introduced and from which external sources they will come later.
Consideration of these issues in the TK should be approached “without fanaticism”, given the possible uncertainty of the requirements described above. Their detailed elaboration can be left to the later stages of creating the system, but if you at least dwell on them when developing the TOR, then make the executor and yourself better think about a solution that still exists only on paper and which has not yet been altered. is associated with global financial and time costs.
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, for 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 proposals from them.
Another advantage of an in-house TK is that it will reflect only your needs, and not the limitations of the technological platforms used by the contractor and the techniques he has for reuse. Of course, the contractor may need to conduct additional surveys and develop his own project documentation, but all these documents will have to meet the requirements in the ToR developed by you. If any of your requirements prove to be unrealizable for a specific artist, then you will certainly know about it and be able to make the appropriate decisions.
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. 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. 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 with large strokes in order to try to include new requirements within the agreed budget. Of course, with a different “mentality” of the customer and the performer, everything can be exactly the opposite. Now I would like to dwell on the development of TK from the point of view of its customer, having considered possible situations, goals and tactics of behavior.
To begin with, we will determine the factors that influence the development of TK. First of all, it is the degree of understanding of customer requirements. As mentioned above, at the time you start working on the TOR, you can have little idea what kind of system you want to create. As a source of data, you may have disparate, often conflicting requests from units interested in creating a new system. It is good if your IT service managed to structure them, resolve inconsistencies and, thus, prepare for communication with the contractor. If not, then the best option is to first develop a very common TZ, with large strokes describing the vision of the system, list the necessary modules (subsystems), without going into details of their functioning, and then work with the executor on detailing the requirements for them. Subsequent versions of the TK can be made up as additions to the original TZ or as a so-called. “Private technical assignments” (CTZ) for solution modules. 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.
An important point is the probability of requirements drift. Companies are changing, adapting to external challenges, and, often, this happens quite quickly. What is developed today can serve its own and become completely unnecessary tomorrow in its original form. In order to avoid unnecessary problems in the future, it is necessary to immediately speak with the performer and tune in to 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. In this case, it is possible to refuse to write a bulky initial TZ by limiting the TZ to the first version (iteration).
')
The expected duration of the project, in fact, is one of the factors driving requirements. Over the long term, even in a fairly slow-moving company, a lot can change, for example, a new leadership with a new vision will appear. If, on the contrary, the project is small and fast, then the best option is to develop, coordinate and implement one small and sufficiently detailed TK.
A significant number of project participants who create separate components of the solution require more detailed technical tasks developed by them, as well as taking into account the specifications and implementation features of neighboring modules at the TOR stage. This will help to further minimize the risks of module mismatch and, accordingly, avoid unnecessary psychological and material costs for rework.
The complexity of the task also influences the approach to writing TK. Alas, the task may be too difficult, not only for the customer, but also for the performer, who would seem to have experience in creating solutions of this class. The difficulty usually lies in the fact that the solution being created is not typical and none of the project participants can predict in advance the result of its implementation and use in business. In this case, it is very important to competently break 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.
Companies work in a real environment and often they have to deal with new partners with whom they have not previously worked. The same applies to IT solution developers. Of course, it’s good to have an artist who knows all the details of your business, understands you perfectly and in which you are 100% sure (in this case, you can refuse to develop TK, in general, but in reality it may turn out to be completely unknown to you company. In this case, of course, it is advisable to start cooperation with small, if possible, projects and with clear and detailed wording of the requirements specified in the ToR.
The degree of detail of the TK and the separation in the time of its development, of course, are not the only points 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 the 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.
As you know, there are many software development methodologies that differ among other things by the different degree of formality of project documentation. However, TK is explicitly or implicitly present in any of them. In this case, the templates of this document may vary significantly for different companies and software development processes. The future developer of your system can impose on you 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. And, secondly, common sense and the main purpose of the TK, consisting in the formation of a common vision of the software product by the customer and performer, are not canceled by any of the development methodologies.
Currently, the Russian Federation has a GOST 34.602-89 “Terms of Reference for the creation of an automated system”, which, in spite of 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.
From my own experience I can recommend to draw the attention of the contractor to the need to consider in the TK, among other questions:
Categories (roles) of users working with the system - list the roles and briefly describe which posts from which departments they correspond to.
The functional of the system is to create a hierarchical structure in which large modules (subsystems) are listed on the top level, further detailed to smaller functional blocks and even individual functions.
The system usage model is to compare the categories of users of the system and the functional blocks used by them, indicated above.
Scenarios for using the system when performing core business processes is to impose a vision of a solution on actual processes, describe at what stages and how it will be used. Take the time to work together with the contractor to visually schematically paint scenarios at least for the main business processes and coordinate them with interested parties.
User interface prototypes - schematically depict, for example, with the help of Microsoft Visio what the main forms of your future software will look like.
Logical data model - to depict the main entities of the subject area and the relationship between them. This will allow you and the performer to speak the same language using common terminology.
Data sources and interaction with other systems - describe where the initial data will be loaded from when the system is introduced and from which external sources they will come later.
Consideration of these issues in the TK should be approached “without fanaticism”, given the possible uncertainty of the requirements described above. Their detailed elaboration can be left to the later stages of creating the system, but if you at least dwell on them when developing the TOR, then make the executor and yourself better think about a solution that still exists only on paper and which has not yet been altered. is associated with global financial and time costs.
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, for 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 proposals from them.
Another advantage of an in-house TK is that it will reflect only your needs, and not the limitations of the technological platforms used by the contractor and the techniques he has for reuse. Of course, the contractor may need to conduct additional surveys and develop his own project documentation, but all these documents will have to meet the requirements in the ToR developed by you. If any of your requirements prove to be unrealizable for a specific artist, then you will certainly know about it and be able to make the appropriate decisions.
Source: https://habr.com/ru/post/149810/
All Articles