Requirement Analysis

Requirement Analysis is one of the most important phases in the Software Development Life Cycle (SDLC). As a Business Analyst (BA), this phase helps in understanding what the customer actually needs and translating those needs into clear, detailed, and actionable requirements for the development team. In my project (health insurance mobile application), requirement analysis started after initial requirement gathering. During requirement gathering, stakeholders shared high-level expectations such as enabling customers to check nearby tie-up hospitals, track claim status, download policy documents, and consult doctors online. However, these needs were broad and required deeper analysis before development could begin. As a BA, my first step in requirement analysis was to review all gathered inputs and remove ambiguity. I analyzed user problems such as customers calling customer care to get policy documents, difficulty finding cashless hospitals, and lack of transparency in claim status. I worked closely with the Product Owner, customer support team, and technical team to validate these problems and confirm business priorities. Next, I broke down high-level requirements into detailed functional and non-functional requirements. For example, the requirement “Check nearby hospitals” was analyzed into sub-requirements such as GPS-based location detection, hospital list display, filtering by specialty, and response time performance. This helped developers clearly understand what needed to be built and avoided rework later. I also identified constraints and dependencies during analysis. Some features depended on third-party APIs like GPS services and hospital databases. Security requirements were analyzed for sensitive features like policy document download and claim details. Only authenticated users should be able to access these features, which was clearly documented. Another key activity during requirement analysis was defining acceptance criteria for each user story. Acceptance criteria helped set clear expectations on when a requirement would be considered complete. For example, for policy document download, the criteria included successful login, PDF availability, proper error messages, and secure access. This supported both development and testing teams. As part of Agile methodology, requirement analysis was not a one-time activity. It was continuous throughout the project. I participated in backlog refinement sessions where requirements were reviewed, clarified, and prioritized using MoSCoW technique (Must have, Should have, Could have, Won’t have). This ensured the team focused on delivering maximum business value in each sprint. Finally, I ensured all analyzed requirements were properly documented using user stories, process flows, and simple diagrams. These artifacts acted as a single source of truth for the team. Any changes in requirements were discussed with stakeholders and updated in Jira to maintain traceability. In conclusion, requirement analysis helped bridge the gap between business needs and technical implementation. As a BA, this phase allowed me to reduce risks, improve clarity, and ensure that the final product delivered real value to customers and met business goals.