Title -:The_What_What_Who_When_and_How_of_Software_RequirementsArticle SummaryThis article discusses a requirements elicitation process in the context of why, what, who, when and how . First, explain why there should be a requirements elicitation process, secondly what types and types of requirements should be defined at different levels, who are the stakeholders and how to involve them in this process, when the elicitation process requirements must take place during the process. Software development life cycle and finally how to analyze, specify and validate requirements during the requirements validation process using various techniques. Requirements are what customers, users, and suppliers expect from a system. This must be identified and determined based on available information and agreed by the client and project stakeholders. Based on this, what functional requirements should be implemented to meet the customer's business needs, what these requirements can do to effectively execute the customer's business functions should be determined. Additionally, what these non-functional requirements can do to add value to customers needs to be determined, as non-functional requirements improve the overall user experience. Additionally, what are the limitations in implementing the requirements should be identified by the technical team based on technical limitations, less Return on Investment (ROI) due to changing trends, etc. Business requirements are usually stated in terms of the objectives of the customer or organization requesting the development of the software. User requirements examine the functionality of the software product from the perspective of different users of that product. They define what the software should do in the middle of a sheet of paper. as input again and finalizing non-functional requirements is a somewhat impractical situation. According to "Software Requirements Memory Jogger" (Gottesdiener, 2005), these are parallel activities and it would be more effective if feedback from each of these areas was taken into account to determine and reference the requirements rather than considering each of them. between them as a dependency to complete the process. other process. Additionally, no requirements validation techniques were mentioned in the article. Since verification of requirements is absolutely required, this aspect should have been covered in more detail in this article. Article Citation 3000 Custer Road, Suite 270, PMB 101Plano, TX [email protected]