Getting requirements seems like the easiest task in the world. Ask questions to users or business and get requirements. In the real world, this process is one of the most difficult parts of the project. If the requirements are not fully understood, it will create problems in your analysis and decrease your chances of effectiveness and success. If you can properly elect, verify, and validate requirements, you will lay the foundation for an effective project. The phrase “gather requirements” does not express the true mission of the IT project requirements. You're not a caveman, you don't gather requirements, they don't just lie on the ground for you to collect. “Get” is the word that best fits the position. Elicit refers to an active role in consolidating, verifying and validating IT requirements. Merriam-Webster defines elicitation as: “To bring out or bring out (something latent or potential), To invoke or bring out (as information or response).” “It is the responsibility of project stakeholders to provide, clarify, specify and prioritize requirements. Additionally, project stakeholders have the right to have developers invest time in identifying and understanding these requirements. This concept is critical to your success as an agile modeler, it is the role of the project stakeholders to provide the requirements, it is the role of the developers to understand and implement them. (Ambler, 2011)When I was a young soldier, I was given a mission. Before we left, we had to re-read everything we had heard to make sure we understood the plan in its original intent. This may sound crude, but it ensured that every team member had the same image of success in mind. If IT managers and stakeholders could have... middle of paper ...... what elements are so important in each method and why one method is not better than another. Depending on the situation, you may choose to use more than one method but the preparation is the same. Works Cited Gottesdiener, E. (2008). YAGNI Documentation of your needs. EBG Consulting, Inc. Retrieved December 23, 2013 from http://www.requirementsnetwork.com/system/files/YAGNI.pdfSauter, V. (2007) Feasibility. Retrieved December 23, 2013 from http://www.umsl.edu/~sauterv/analysis/feasibility.htmAmbler, SW (2011). Agile requirements modeling. Agile modeling. Retrieved December 23, 2013, from http://www.agilemodeling.com/essays/agileRequirements.htmUsability.gov (ND) Evaluate Your Current Site: Usability Methods. U.S. Department of Health and Human Services. Retrieved December 23, 2013 from http://www.usability.gov/methods/analyze_current/index.html.