Main problems when working with requirements
Problem #3. Wrong method
The problem of shortage of time and personnel with the proper qualifications and experience leads to the fact that the development of requirements becomes easy and inexpensive. All you need to do is take the TK from a previous similar project, rewrite it to fit the parameters of the current one, and then send it to everyone who is, in one way or another, affected by certain sections of the TK.
Among those to whom the technical specifications are sent, there will definitely be at least one meticulous and picky person, from whom there will be many comments, clarifications and corrections. This means that the rest of the mailing list can relax and not read too much, or assign the “reading” of the TK to someone who is not very busy at the moment.
Then the developer of the technical specifications will correct all the comments made, receive all the signatures – approvals, approve the technical specifications from the authorities, who will not even read it, and transfer it to someone: to the procurement department; or to the Customer, if the technical specifications were developed for him.
Is this a method? – yes, this is a method. But this is not the method that leads to good requirements and good results. In my requirements management course, one of the students described the following situation. The technical specifications were developed exactly as written above. The customer approved the technical specifications. The system was developed in close contact with the Customer, and the Customer was completely satisfied with the developed system. But when they began to develop a test program and methodology in accordance with the requirements of the technical specifications, it turned out that the system that suited the Customer and the technical specifications did not correspond to each other. At the same time, it was impossible (or undesirable) to change the technical specifications for formal reasons. Therefore, the test program and methodology were developed instead of requirements (and not in accordance with them), and the finished system was accepted according to it.
This approach is similar to the Texas marksman's method of first shooting at the barn and then drawing a circle around the area where the most hits were made.
We don't know how many missed features, black swans, and trivial glitches there were in this system as a result. We cannot predict at what moment and in what situation this cyber-physical system will behave unpredictably. But we can confidently say that the method described above is bad.
In our Requirements Management classes we offer a different method:
first identify all stakeholders;
with stakeholders, by modeling the behavior, life cycle, mission, modes and states of the future system, explore the problem area as thoroughly as possible;
define methods for structuring, formulating, identifying and tracking requirements, and recording these definitions in a formally accepted document (requirements development standard);
develop requirements;
simultaneously develop methods for confirming requirements;
verify the developed requirements for compliance with the standard;
validate the developed requirements and methods for their confirmation, again using modeling methods and validation methods associated with group participation of stakeholders.
We teach all this at requirements management courses. And, if there is a desire, we help implement this approach by provision of consulting services.
Part 4.
