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 personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Dig Deeper on Penetration Testing
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.