On the quality of requirements in IT projects, to be honest (from the standpoint of the development team). Part 3
Part 1 can be found by clicking on the link.
Part 2 can be found by clicking on the link.
In the introductory section, a group of project participants was mentioned, for which we also promised to make life easier and provide conditions for the effective use of requirements - these are project managers. What do these respected people get when choosing the approach proposed in the article?
By planning work on such detailed specifications, even at the early stages, it is possible to determine with high accuracy the resources and terms necessary for their implementation. The time it takes to create a table, form, function, report, etc. You can calculate on the example of one project and then use this data as a reference. And in our specifications, all the tables, forms, procedures, etc. are listed. and counting their number is not difficult.
')
But, of course, there are inaccuracies and the procedure - the procedure is different, therefore, for a more accurate calculation, you can use the complexity coefficients for the objects to be implemented. For example, "complex form" - 1.5; "Ordinary form" - 1; “Simple form” - 0.5. For each type of element we select our own line of coefficient values. The data obtained in this way can be entered into a spreadsheet and bring down the total costs in man / days or man / hours (as you prefer) by subsystems and the project as a whole.
In a simplified form, a table of preliminary calculation of labor intensity may look, for example, like this:
This is a very handy tool for pre-calculating the cost of coding in the project, as well as: testing, developing instructions and other processes for preparing for the transfer to the customer. Such a table can be started at the stage of the formation of specifications, in this case, when they are finalized and refined, you can observe the change in the required resources and decide on the choice of priority works or the feasibility of their implementation in general.
Think this and everything? And only because of this we fooling around with drawing up such detailed specifications. No, this is only the first step. Take a look at the Content example, where the specifications headings are visible.
Doesn't it look like a structured task list?
Since we have tried to make each lower-level specification as similar as possible to an atomic task for a developer, PM needs only to select from the requirements of the specification and transfer them to the tool for creating the project schedule. Moreover, the specification points follow in the order in which they are to be carried out (we have taken care of this). In addition, top-level sections fall into the project schedule as a group of tasks, and the bottom level directly as tasks. If the specification header is too large for the task header, they can be converted, but the specification identifier remains reinforced, this is the project axis.
Below is an example of constructing a plan-schedule according to specifications:
Well, then, the matter of technology: risk planning, resource allocation, etc.
Naturally, this approach does not cancel or replace requirements management. They will change, priorities will shift, and a lot of other things can happen and therefore it is desirable to use traceability of requirements: from the very needs of users, to high-level requirements, further to specifications and to the schedule schedule of a project. Therefore, at each step we used object identification and lined up chains of references to related artifacts in the requirements.
Such specifications, as noted above, are simply a haven for QA specialists, as they contain scenarios, in very detailed form, describing the user's actions with the target product. They can form the basis of test cases, acceptance cards, etc. Also, the requirements for visual forms, reports, user access rights to user interface elements, procedures and data storage structure are written out in great detail.
Based on the scenarios from our specifications, it is also convenient to prepare user instructions and this is another point that saves money in the project.
In the article I would like to focus on what the target product is - the culmination of the work of the project team as a whole. The quality of the project is estimated by its quality. And no matter how skillfully and beautifully the requirements look, if the team that implements them spends the lion's share of their time not on coding, but on trying to correctly perceive the information and search in the documentation for the necessary fragments of solutions that they should implement directly in the product.
In the article, I tried to show with examples from personal experience how to choose the optimal content of requirements in order to optimize their use in the process of developing a software product, making it more comfortable and expedient.
Such an approach can significantly reduce the cost of the project, due to more rational use of team time in the project. In my experience, one analyst is able to continuously provide 3-5 programmers with work, depending on the uniqueness and complexity of the project. At the same time, developer productivity rises several times and becomes more predictable in terms of implementation. On the other hand, the quality level of the result of teamwork becomes more uniform and the cost of supporting it can be optimized.
Another important point from the point of view of the effective use of requirements by the team is the proper organization of the process of the analyst transferring the fruits of his work to the development team at the implementation stage. But this topic is worthy of a separate discussion.
This article should not be taken as some kind of recommendations on the mandatory use of the proposed composition and form of requirements specifications. Each team must develop its own concept of the formation of specifications. Moreover, the team may have several templates for different subject areas and used technological platforms. Such templates can be designed in the form of technological maps of the software development process.
The article used materials from my book "System Analyst ... On Designing Software Products."
Part 2 can be found by clicking on the link.
Using requirements specifications in project management
In the introductory section, a group of project participants was mentioned, for which we also promised to make life easier and provide conditions for the effective use of requirements - these are project managers. What do these respected people get when choosing the approach proposed in the article?
By planning work on such detailed specifications, even at the early stages, it is possible to determine with high accuracy the resources and terms necessary for their implementation. The time it takes to create a table, form, function, report, etc. You can calculate on the example of one project and then use this data as a reference. And in our specifications, all the tables, forms, procedures, etc. are listed. and counting their number is not difficult.
')
But, of course, there are inaccuracies and the procedure - the procedure is different, therefore, for a more accurate calculation, you can use the complexity coefficients for the objects to be implemented. For example, "complex form" - 1.5; "Ordinary form" - 1; “Simple form” - 0.5. For each type of element we select our own line of coefficient values. The data obtained in this way can be entered into a spreadsheet and bring down the total costs in man / days or man / hours (as you prefer) by subsystems and the project as a whole.
In a simplified form, a table of preliminary calculation of labor intensity may look, for example, like this:
This is a very handy tool for pre-calculating the cost of coding in the project, as well as: testing, developing instructions and other processes for preparing for the transfer to the customer. Such a table can be started at the stage of the formation of specifications, in this case, when they are finalized and refined, you can observe the change in the required resources and decide on the choice of priority works or the feasibility of their implementation in general.
Think this and everything? And only because of this we fooling around with drawing up such detailed specifications. No, this is only the first step. Take a look at the Content example, where the specifications headings are visible.
Doesn't it look like a structured task list?
Since we have tried to make each lower-level specification as similar as possible to an atomic task for a developer, PM needs only to select from the requirements of the specification and transfer them to the tool for creating the project schedule. Moreover, the specification points follow in the order in which they are to be carried out (we have taken care of this). In addition, top-level sections fall into the project schedule as a group of tasks, and the bottom level directly as tasks. If the specification header is too large for the task header, they can be converted, but the specification identifier remains reinforced, this is the project axis.
Below is an example of constructing a plan-schedule according to specifications:
Well, then, the matter of technology: risk planning, resource allocation, etc.
Naturally, this approach does not cancel or replace requirements management. They will change, priorities will shift, and a lot of other things can happen and therefore it is desirable to use traceability of requirements: from the very needs of users, to high-level requirements, further to specifications and to the schedule schedule of a project. Therefore, at each step we used object identification and lined up chains of references to related artifacts in the requirements.
Using requirements specifications in product quality management
Such specifications, as noted above, are simply a haven for QA specialists, as they contain scenarios, in very detailed form, describing the user's actions with the target product. They can form the basis of test cases, acceptance cards, etc. Also, the requirements for visual forms, reports, user access rights to user interface elements, procedures and data storage structure are written out in great detail.
Based on the scenarios from our specifications, it is also convenient to prepare user instructions and this is another point that saves money in the project.
Conclusion
In the article I would like to focus on what the target product is - the culmination of the work of the project team as a whole. The quality of the project is estimated by its quality. And no matter how skillfully and beautifully the requirements look, if the team that implements them spends the lion's share of their time not on coding, but on trying to correctly perceive the information and search in the documentation for the necessary fragments of solutions that they should implement directly in the product.
In the article, I tried to show with examples from personal experience how to choose the optimal content of requirements in order to optimize their use in the process of developing a software product, making it more comfortable and expedient.
Such an approach can significantly reduce the cost of the project, due to more rational use of team time in the project. In my experience, one analyst is able to continuously provide 3-5 programmers with work, depending on the uniqueness and complexity of the project. At the same time, developer productivity rises several times and becomes more predictable in terms of implementation. On the other hand, the quality level of the result of teamwork becomes more uniform and the cost of supporting it can be optimized.
Another important point from the point of view of the effective use of requirements by the team is the proper organization of the process of the analyst transferring the fruits of his work to the development team at the implementation stage. But this topic is worthy of a separate discussion.
This article should not be taken as some kind of recommendations on the mandatory use of the proposed composition and form of requirements specifications. Each team must develop its own concept of the formation of specifications. Moreover, the team may have several templates for different subject areas and used technological platforms. Such templates can be designed in the form of technological maps of the software development process.
The article used materials from my book "System Analyst ... On Designing Software Products."
Source: https://habr.com/ru/post/336026/
All Articles