Why should we (the business analyst) document user requirements when we already know what we want the system (functional requirements) to do?
What this is really saying is that you as the business analyst "assume" that you know what the system should do based on what you "assume" the user wants. The Standish Group International has identified "user involvement" every year for the past decade as the most critical factor for project success. Without formally eliciting (seeking input directly from the user), analyzing (documenting assumptions and prioritizing the requirements), representing and validating the user requirements, the project team risks implementing the wrong system functionality. This, of course, equates to rework later on. Furthermore, without first looking at what the user role does to perform their business tasks, the "manual" aspects of what they do are completely overlooked and are not accounted for in the solution.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.