The practice of forming requirements in IT projects from A to Z. Part 7. Transfer of requirements into production. Conclusion

XI Specify Requirements

The requirement is only a temporary intermediary for solving the problem of the real world.
"Factory development programs" [8]

When the main design artifacts are ready, you can proceed directly to specifying the Requirements in order to transfer them to the developers who implement the customer’s needs for the target product. The quality and the final cost of this product depends on how accurately the specifications created are suitable for a specific team to process them into a finished software product.

The purpose of this group of works: on the basis of the collected information about the target product, to prepare qualitative specifications of the requirements, allowing you to most effectively organize the process of their implementation.

For ease of use of such representations, divide the requirements into parts in the form of: subsystems, contours, domains, or other groups. Issue them as separate documents. I shall specify that the subsystem must have all the properties of the system, in particular, the property of integrity (by sub-goals) and emergence (irreducibility of the properties of the system to the properties of the elements). But the system component, unlike the subsystem, is only a set of elements for which a sub-goal is not formulated and there is no integrity.
')
Since most subsystems are not self-sufficient, it is necessary to establish cross-references between them, referring not only to the models, but also to their elements. Therefore, it is desirable to have a complete catalog of all artifacts used in the project. For these purposes, usually use the document - "Configuration Management Plan". Below is an example of the description of the documents used in the project:



In addition to the specified artifacts, the Configuration Management Plan also records: The persons responsible for the project and its parts (the project team), the tools used, the work regulations in the project, references to project workbenches and project repositories, etc. But this document is more related to the competence of the project manager, therefore in this paper we will not dwell on it in detail.

This section was almost completely published earlier, in my article “On the quality of requirements in IT projects, cleanly (from the perspective of the development team)” . Therefore, I will not reprint it, but send you to the original source. I hope that after reading the rest of the publication this section will be perceived by you in a new way.

XII Embody the requirements of the target product

As part of this publication, we analyze in detail only those software production processes that are related to the requirements management aspects. Therefore, the processes of converting requirements into a target product, we will consider as a “black box”, to the input of which our specifications are passed, and the output is a software product that satisfies them. But we will definitely talk in detail about the transfer process itself and all its aspects.

1. We transfer the requirements to the process of implementing them in the target product.

An important moment in the life of the demand, the apogee of its life cycle is the transfer of it for implementation to the project manager and the development team. Therefore, it is better not to let this process take its course, and not to be limited to a banal letter with a reference to requirements in the text. No, I do not urge to do this with pomp and special effects, but it is necessary to organize the procedure so that none of the team is left with a misunderstanding of what should be obtained at the output and how to do it.

To coordinate and effectively interact with team members who play various roles in the process of converting requirements into a target product, it is advisable to use one of the many systems that support the life cycle of problem solving (Jira, Mantis, XBTrack, etc.). Let me remind you that in this publication we focus not on tools, but on aspects that help the development team make the most effective use of the fruits of the analyst’s work.

Not often, but it happens that the process of transferring requirements to development in some teams turns out to be too formalized and bureaucratic, but more often than not, it is simply left to chance. And in that and in another case there are a lot of dangers and pitfalls. If the process is unnecessarily administered, then there are great difficulties with making changes and increasing the cost of supporting it. If there is no transfer procedure at all, the process is practically unmanageable, and this anarchy is especially sensitive when the product develops several teams.

For an optimal solution to this problem, I propose to use slightly modified managerial delegation rules, namely:

1. You can only transfer development requirements to a specific employee who has the appropriate authority and can be responsible for its implementation. Otherwise, let the management know that you have no opportunity to fulfill your functions with high quality. This rule will help save time for useless conversations "in a circle."
2. It is obvious to discuss with the contractor what final result should be obtained when implementing each requirement, as well as how to perform the task. It is advisable to make sure that you understand correctly and see the result of the work as you see it. This will avoid communication distortion of information.
3. Determine priorities for the implementation of requirements, taking into account the functions: mandatory and desirable for execution. This will increase the likelihood of obtaining workable modules by sacrificing some functionality.
4. Agree that in case of difficulties for the executors with the implementation of the requirements, it is necessary to immediately contact you to clarify, clarify or change the requirements.
5. Regularly analyze the progress of work and discuss the problems that arise in the process of implementing the requirements.
6. Improve and develop the process of transferring requirements to the development, in order to gradually reduce the intensity of control and simplify the explanation and the procedure itself.
7. Approve the schedule of delivery of ready-made solutions.

By and large, the responsibility for this process lies with the project manager. But if the process failed, then most often it is the analyst who is to blame, who wrote “any nonsense that no one can figure out.” Therefore, in order to pre-lay the straw in the right place, the analyst needs to take over this function.

2. We transfer the developed product to the customer

After acceptance from the developers of the finished product that meets the system requirements, the implementation team faces the task of transferring the target product to the customer. Since here it is possible to do without an analyst, but it is difficult, I want to briefly touch on some important points of this process.

When transferring the developed system to the customer, it is desirable to provide him with the fullest possible understanding of the philosophy of the created product, convey to users the vision from the point of view of the development team. Often, users do not perceive the new software, for the reason that it did not meet their expectations, formed by previous experience, not always advanced. This can be a barrier to the introduction of a new product.

Therefore, it is not necessary to wait until the user himself finds the “chips” of your software and, through agonizing trials, will find options for navigating the “unusual” interface for it. Tell him about the advantages of your system over analogues, make the user worry about it. And if the user is “advanced” - show him how the technologies you use are used by industry leaders.

XIII Solve the problem of changing requirements during the operation of the target product

A very important characteristic of the requirements management process is its adaptability to change. The cost of making changes to the system requirements varies greatly depending on the stage of their implementation. The better developed the requirements, the easier it is to make changes to them, even at the stages when prototypes of the target product are created. It also helps to reduce the cost of the evolution of an already operated product.

In my practice, there was the experience of participating in a project, whose team at the beginning of development fully utilized the approach of creating quality requirements and, based on them, created a program code. Qualitatively developed requirements allowed us to create a complex, functionally correct data structure and system for their processing. But after the introduction of the product into operation, the requirements management process was abandoned, and the product continued to evolve through small but frequent modifications. As a result, a year and a half later, the system reached a state when its complexity was not fully owned by anyone: neither programmers nor analysts. Each change in it was reminiscent of walking on a minefield: you never know where and when trouble will come out the next moment after making changes.

The dilemma of changes: from the moment of making changes to requirements and their approval, a software product developed on their previous version ceases to be relevant, becomes “invalid” and enters into conflict with the requirements.

1. We make changes to the product, only through changes in the requirements

Any modifications to the target product should be made only by making changes to the requirements and further passing the entire chain of their implementation in the product. This is not a slogan, but a very desirable necessity. Such an approach makes it possible to repeatedly and painlessly make changes in the functionality of a product. This is due to the fact that modification of software that already operates may entail a whole chain of changes in the behavior of other parts of the system. Having the actual requirements, most of these additional modifications can be predicted and designed, or simply refuse to innovate in favor of product stability.

Therefore, the requirements should be kept versionally, with the ability to view all modifications and tasks for their implementation. Before submitting tasks to developers, appropriate changes should be made to all models and specifications.

But this is in theory and with significant reserves of resources, laid in advance, at the design stage. But in practice, it often happens that a project begins a period of rapid and frequent changes in requirements, for example, as a result of testing or preliminary demonstrations to the customer. While the project is being developed and the basic requirements are still fresh in the team’s memory, it is possible to make changes to the target product, simply based on the tasks set for the developers. But after the fact, all modifications must be “refreshed” in the requirements. It is at this moment that the difference between well-developed requirements and unsystematic notes is especially vividly felt. The systematized specifications are a basis for strength, allowing to deviate from the rules of work in the project, and later stabilize the requirements without significant loss of their controllability. The scale of these deviations and the duration depends on the scale and stage of the project. This is something that is often lacking in flexible methodologies that advocate: "We accept changes to requirements, even in the later stages of project implementation." The slogan is good, it’s only a pity that it is often not supported by any mention of a mechanism capable of supporting such loud statements.

2. We make changes to the requirements only through requests for changes

Another very important aspect of the requirements changes is that they should not be made without their full coordination with all the project participants. If the requirement has already been implemented, analysts and product architects must first analyze in detail the impact of changes on the rest of the product's functionality and assume the amount of possible changes in related components and processes. The resulting pool of changes must be approved by all interested parties, and only after that it is possible to proceed to the process of designing and documenting innovations. After the design process, it is desirable to approve the obtained models with customers and only after that proceed to the implementation.

In real projects, due to the constant lack of time, it is difficult to adhere to this approach. Therefore, at a minimum, enter the practice of using “Requirement Change Requests” from a person interested in a change. In this case, the system should provide for a separate status of the requirement, or rather its version, requiring approval not only by customers, but also by architects and product developers. The practice of filing change requests helps very well in negotiating the deadlines for delivering a product. As the customer, most often, very quickly forgets that he has repeatedly changed his wishes to the product and is surprised when the deadlines for its commissioning are not met. In this case, you can submit him his applications with the dates of creation, approval and deadlines. To make this data more convincing, include in the document a description of the reason that caused the need to change something, the initiator of the changes and the environment - the objects on which the change should have a significant impact.

XIV Conclusion

So, we with you, in this publication, have gone the way of forming system requirements from deciding on the development of the Software product to the transfer of the generated requirements specifications to the developers and the product they developed to the customer.

For a better presentation of the entire publication as a whole, let's now put all the steps in this process into one presentation.



With this publication, I didn’t so much want to teach readers to develop requirements, but rather to give an opportunity to feel and feel the whole process and push you to develop your best technical process, which is the starting point in software production. If I succeed, waiting for your feedback.