Requirements analysis

requirements Analysis — part of the process of software development, including gathering of software requirements (SOFTWARE), their systematization, identification of linkages and documentation.
https://ru.wikipedia.org/wiki/анализ_требований

Most of us intuitively understand what is talking about, but I have not met people who have guided intuition in the analysis of the requirements and got something usable.

Often it ends unfinished table, made for show, living in isolation from the real functional system.

In my opinion, in order to avoid this situation, all we gotta do is look at the process from a different angle...

The main problem of requirements gathering, in my opinion, the wording used in Wikipedia articles and the professional literature.

a Requirement is a singular documented physical and functional need that a particular design, product or process must be able to perform.
https://en.wikipedia.org/wiki/Requirement

Of software requirements — a set of statements concerning the attributes, properties or qualities of the software system to be implemented.
https://ru.wikipedia.org/wiki/Требования_к_программному_обеспечению

Reading this definition, most professionals come to the conclusion that as a result of the requirements analysis will be a high-level description of functions (scenarios) of the system.

Then they communicate with users and customers, make up the mass of confusing, contradictory and inconsistently information, filled with sarcasm the Internet and designing a system, starting from their subjective understanding of the task.

The results of this approach are evident only at the receiving stage or product launch, in the form of a phrase, which is at least once each of us had heard — “We wanted, you have badly done your job.”

In the case of waterfall processes risks partly closed because the Client approves the design documentation and we can say “blame Yourself!”, but what does it change, actually?

In my opinion in the definitions of requirements missed a key detail:

the Requirement is not “a need that a particular product must be able to perform”, the requirement is “an expectation of particular person that a particular product should be able to perform”.

In the new context there are many ideas to change the process of requirements analysis, personally I think the most important the following three:

First: the Requirement is not a function of the system, a description of the problem or problems that need to be solved.

Attempt together with the customer to design scenarios of system operation are likely to cause poor result. The best way to understand the requirement, do the opposite — to Show empathy, to take in the terminology, objectives and processes of the customer. It will then be able to apply to that my experience and knowledge to offer customers a consistent and effective solution.

Second, because the demands are desires of several people, analysis of requirements starts with the identification of individuals whose desires system should be considered.

Identification of all stakeholders and an independent survey every is the work most often ignored, and the resistance have just customers and project sponsors, because of a misunderstanding of the need of this work.

Of course, you need to maintain a balance between complexity and quality of results, but the cause of most failures of startups and deployments of enterprise systems, is exactly what the opinion of the customers and the creators that need the users do not match with reality.
Third: the Requirements of this waiting, that is something yet. The volatility of the future by the very nature and desires of man are constantly adapt to the changes. And we are not talking about weeks and months, requirements will be different depending on what time of the day to ask questions.

Requirements are expectations. Expectations are not fixed, expectations run.

It is not enough to collect and sign requirements, they must “sell” to all stakeholders, so that they remember what they want, or in the process of the whole project will have to deal with chaotic functionality changes and sudden turns.

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

As the requirements give many persons with influence on the system, will appear the contradiction, and whose interests will be infringed.

The process of requirements analysis cannot be considered successful if the compromise makes some of them indifferent or negatively disposed toward the system. If you do not offer them solutions to their problems, they come up with their own and force you to implement 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 the PMBoK and I hope my interpretation will also be useful.

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

Article based on information from habrahabr.ru