In developing accurate requirements and derive accurate estimates from client engagements, user stories are increasingly becoming the de facto standard for documenting.
Simple in concept, but difficult to master, user stories have this basic format:
As a <actor/user>, I can/want <what> so that <why>
The “how” is kept out, since that is what the delivery team should figure out. You shouldn’t need as a client know how the car was built as much as how to properly run and maintain it.
However, the trouble can be with getting the right level of granularity to the user stories so no “big surprises” come out weeks or months after the initial requirements gathering process. There is an art to recognize this and doesn’t follow any template or “silver bullet”. There are many ways to help define user stories and going to the appropriate level of detail should include recognizing asking questions even in the details for say highlighting key facts of a product. It can be done in one form of highlighting but upon further research, there can be multiple ways with a “wish list” or favorite, commonly chosen favorites by others with similiar tastes or similiar products.
That’s when the devil is in the details and has to be handled through many questions and sufficient planning.