Requirements analysis

Requirements analysis is a part of the software development process, which includes collecting software requirements (software), systematizing them, identifying relationships, and documenting.

https://ru.wikipedia.org/wiki/ requirements_analysis

Most of them are already intuitively aware of what is being said, however, I have not yet met people who would be guided by intuition in questions of the analysis of requirements and get something usable.



Often, everything ends with a unfinished table made up for a tick, living in isolation from the actual functionality of the system.



In my opinion, in order to avoid this situation, you just have to look at the process from a different angle ...

')

The main problem of the collection of requirements, in my opinion, in the formulations that are used in Wikipedia articles and professional literature.

You must be able to perform.

https://en.wikipedia.org/wiki/Requirement



Software requirements - a set of statements regarding the attributes, properties or qualities of the software system to be implemented.

https://ru.wikipedia.org/wiki/Requirements_for_programme

Reading these definitions, the majority of professionals come to the conclusion that as a result of the requirements analysis, a high-level description of the functions (operating scenarios) of the system should appear.



Then they communicate with users and customers, compose an array of confusing, inconsistent and inconsistent information, fill the Internet with sarcasm and design the system, starting from their own subjective understanding of the task.



The results of such an approach are fully manifested only at the stage of acceptance or launch of a product, in the form of a phrase that each of us heard at least once - “We didn’t want it at all, you didn’t do your job well”.



In the case of waterfall processes, risks are partially closed by the fact that the Customer agrees on the project documentation and we can say “blame themselves!”, But what does this change, in fact?



In my opinion, the key detail is missing in the definitions of requirements:

The requirement is “not a need to perform”, the requirement is “an expectation of a person”.

In the new context, there are many ideas for changing the requirements analysis process. I personally consider the following three as the most important:



First: The requirement is not a function of the system, but a description of the task or problem that a particular person wants to solve.



An attempt, together with the customer, to design scenarios for the operation of the system with a high probability will lead to a poor-quality result. The best way to understand the requirement, to do the opposite - to show empathy, immerse yourself in the terminology, tasks and processes of the customer. After this, it will be possible to apply your experience and knowledge to this, and to offer the Customer a consistent and effective solution.



Secondly: Since requirements are the desires of several people, the analysis of requirements begins with the identification of persons whose desires the system must take into account.



The identification of all interested parties and an independent survey of each is a job that is most often ignored, and the customers and sponsors of the project put up resistance, because of the lack of understanding of the need for this work.



Of course, you need to maintain a balance between labor-intensiveness and quality of results, but the reason for the majority of start-up failures and corporate system implementations is precisely the fact that customers and creators did not coincide with reality.



Third: Requirements, this is an expectation, that is, something that does not exist yet. The volatility of the future is due to nature itself, and man’s desires are constantly adapting to change. And this is not about weeks and months, the requirements will be different depending on what time of the day to ask questions.



Requirements are expectations. Expectations do not fix, expectations are managed.



It is not enough to collect and sign the requirements, it is necessary to “sell” them to all interested persons in such a way that they remember what they want, otherwise in the course of the whole project you will have to deal with chaotic changes in functionality and sudden turns.



The word “Sell” - accurately describes the process, but has a negative connotation. In this context, this does not imply any deception or manipulation.



Since the requirements give a lot of people who have an impact on the system, contradictions will necessarily appear, and someone's interests will be infringed.



The process of analyzing requirements cannot be considered successful if the compromise achieved makes some of them indifferent or negatively disposed towards the system. If you do not offer them solutions to their problems, they will come up with their own and make you realize them :)



Thank you very much for your attention, the above ideas and examples are not new, they are mentioned by many in one form or another, starting with such basic documents as the Agile Manifesto and PMBoK, I hope my interpretation will also be useful.



PS: Everything written is my personal opinion, which I am ready to discuss in the comments.