Software Requirement Analysis Service
Requirements analysis is part of the software development process, which includes the collection of software requirements (software), their systematization, identification of relationships, and documentation. In all models of software development in one form or another, the identification and description of software requirements is performed. These requirements reflect the users’ needs for a system that is designed for a certain purpose.
-The process of identification, analysis, documentation is called the development of requirements.
-The requirements indicate what should be built, but do not say how to do it.
-There are 3 main parties interested in creating a new PS: 1. Customer 2. Developer 3.Users
Somehow, the requirements which will satisfy the needs of customers and the concerns of users should be transferred the developers. There is a communication gap between these participants in the development project (not understanding). SRS is a means (bridge) for overcoming such a gap, because they are a common representation of the software being developed.
The purpose of the activity to work with the requirement is the creations of Specifications for Software Requirements (SRS), which describe in detail what, should be able to do the software being developed.
With the help of STPO, the customer explicitly describes what he expects from the supplier, and the developer clearly understands what capabilities the developed software should have.
First: A 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 with the customer to design scenarios of the system’s operation with a high probability will result in a poor-quality result. The best way to understand the requirement, to do everything on the contrary – To manifest empathy, to plunge into the terminology, tasks and processes of the customer. After that, it will be possible to apply our experience and knowledge to this and offer the Customer a consistent and effective solution.
Secondly: Since requirements are desires of several people, the analysis of requirements begins with identifying individuals whose desires the system should consider.
Identifying all stakeholders and an independent survey of each is a job that is most often ignored, and the support is provided by the project’s customers and sponsors, due to a lack of understanding of the need for this work.
Of course, you need to maintain a balance between laboriousness and quality of results, but the reason for most of the failures of start-ups and the introduction of corporate systems is that the opinion of customers and creators about what users need does not coincide with reality.
Third: Requirements, this expectation, that is, something that does not yet exist. The inconstancy of the future is conditioned by nature itself, and man’s desires are constantly adjusted to change. And it’s not about weeks and months; the requirements will be different depending on what time of the day to ask questions.
Requirements are expectations. Expectations are not fixed, expectations are managed.
It’s not enough to collect and sign the requirements; you have to “sell” them to all interested parties, so 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 characterizes the process, but carries a negative connotation. In this context, this does not imply any deception or manipulation.
Since the requirements are given by many persons having influence on the system, there will necessarily be contradictions, and somebody’s interests will be infringed.
The process of requirements analysis cannot be considered successful if the compromise achieved makes some of them indifferent or negative attitudes towards the system. If you do not offer them solutions to their problems, they will come up with their own and force you to implement them.