How Software Requirements are gathered?

Sales people or any one else like director of engineering and more interact with customers, they learn about the possibility or opportunities for solving problem for their customers.

All of them, along with Business Analyst and sometimes tech managers, they all sit together and have a discussion around it. The requirements here shared by the sales team or director or the customers directly are mostly vague or thoughts or ideas. Business Analyst get this vague requirements documented (shared by customers or others directly in some cases), and start writing the stories for it. Because the requirements were vague and it’s not easily understandable by the developers or testors, that’s why business analyst break these vague requirements into stories after some research, discussions, or understanding the documents or technical aspects. After this, the BA discuss the stories within the team and everyone share their thoughts and perceptions how it can be achieved. Accordingly, the story is either broken down into more smaller parts or just used it as it is after adding more information. After that, the requirements are documented in form of stories, smaller unit of work that can be achieved in smaller amount of time or it can deliver value to the customer. Once the story is finalized, developer starts working on it and start development, while QAs start writing test cases as per the requirements to make sure that whatever will be developed is properly developed and there are no bugs (atleast critical). QAs maintain their test cases in their test management suite, developer maintain document of their implementation, update the architecture or models if required. Once development is complete, QAs performed the testing, and everything is fine, the feature is released to the customer for use. Each story represent a valuable feature that is valuable to the customer.

In the end, whole vague requirements is delivered piece by piece using the stories of same requirements.

Connect with designer, discuss the key flows in your application, add these designs as reference or overview in your BRD, this will help developers & QAs to plan their work accordingly.