The best time to model details usually isn't at the beginning of a project. Generally speaking, business requirements tend to change throughout the course of every IT project. Also, by waiting to do JIT requirements definition, project teams tend to have developed significantly more domain knowledge than if the requirements were defined at the beginning of a project. The benefit of delaying the final definition of requirements on a JIT basis until they are required for development is that it provides the business team with more time to work with the evolving system. Therefore, they can give the project team better answers, which in turn creates more usable and "correctly built" software and which also reduces rework and change orders. Additionally, the ability to change or refine a requirement late in the project’s lifecycle can represent a competitive advantage given ever changing market and business needs. That said, not knowing all of your requirements at the beginning of a project is probably a good idea, but your product owner should have a very clear idea of the requirements at the beginning of a sprint. How do you know if you have the requirements sorted out? Hint: it's not the devs that the product owner should be talking to - it's the QA staff. Especially the ones that really like breaking things through edge cases.