Аннотация: On the net you can find many articles on the topic “UML is dead”, “Why system analysts do not need UML” and a lot of things like that. Working over the past 15 years in completely different companies, with completely different application and system life cycles, with different development structures and methodologies, I see the same thing - attempts to speed up time-to-market by abandoning the requirements management process, submitted under different excellent arguments lead 100% of companies to need to rewrite applications, not because it does not meet the requirements, but because "no one knows how or why it works the way it does."
The second problem of abandoning the normal requirements management process is that applications and systems developed without this process turn out to be absolutely inflexible, and even the most elementary, from the point of view of customers, changes lead to the launch of a full development cycle.
You can list a huge number of problems that development without a requirements model leads to, for example:
1. The inability to understand how the system works / worked in one version or another.
2. The impossibility of testing normally, based on specific numbering requirements.
3. The impossibility of linking defects to specific requirements.
4. The inability to understand clearly and transparently what requirements and processes within the system are affected by new changes.
5. The inability to see the timeline of requirements changes transparently and clearly.
And yet, time after time, they try to skip the stage of system analysis or run it in parallel, why not?
If all the streamlined and politicized arguments are cleaned from the husk, everything will come down to the fact that the customer wants to directly set tasks for development, and see how they immediately take them to work without delay and pauses to think.
The second problem of abandoning the normal requirements management process is that applications and systems developed without this process turn out to be absolutely inflexible, and even the most elementary, from the point of view of customers, changes lead to the launch of a full development cycle.
You can list a huge number of problems that development without a requirements model leads to, for example:
1. The inability to understand how the system works / worked in one version or another.
2. The impossibility of testing normally, based on specific numbering requirements.
3. The impossibility of linking defects to specific requirements.
4. The inability to understand clearly and transparently what requirements and processes within the system are affected by new changes.
5. The inability to see the timeline of requirements changes transparently and clearly.
And yet, time after time, they try to skip the stage of system analysis or run it in parallel, why not?
If all the streamlined and politicized arguments are cleaned from the husk, everything will come down to the fact that the customer wants to directly set tasks for development, and see how they immediately take them to work without delay and pauses to think.
Ключевые слова: systems analysis, system.
Статья в сборнике научных трудов по материалам конференции (форума) «International Conference on Art and Science: Fusing Creativity and Research»