The short answer is that you don't. Big, upfront planning is orthogonal to agile development. Instead, you should focus on iterative and incremental development with tight feedback loops to ensure that you're building the right things and embracing change throughout the project's life cycle.
Big, Upfront Requirements an Anti-Pattern
Doing detailed or large-scale requirements at the inception of a project is an agile anti-pattern. In particular, the Manifesto for Agile Software Development values:
Working software over comprehensive documentation[.]
Likewise, Scrum Theory explicitly avoids the use of fixed, upfront planning:
Scrum employs an iterative, incremental approach to optimize predictability and control risk.
While there is nothing stopping you from linking user stories or other types of Product Backlog Items to functional requirements, doing so is often a "project smell" that you're fixing scope, which is ideally the movable part of the Iron Triangle in Scrum. Furthermore, it's often an indication that you're making implementation decisions too early in the process. Lean practices require that you make architectural and design decisions at the last responsible moment, which is almost never at the very beginning of a project when functional requirement specifications are usually gathered.
What to do Instead
Within the Scrum framework, you should be leveraging the framework to perform just-in-time planning at the proper level of granularity. In particular:
- Leverage Backlog Refinement to identify work that will likely be in scope for the next iteration, maximizing the amount of work not done.
- Use Sprint Planning to decompose work into tasks and deliverables only for the current increment, optimizing for just-in-time planning.
- Leave implementation details out of Product Backlog and (most) Sprint Backlog items, allowing for greater flexibility.
- Gather feedback from stakeholders during the Sprint Review to identify changes and refinements to be treated as new work, allowing the project to continually evolve to meet changing market demands and to take advantage of lessons learned.
While not required by Scrum, agile practices generally require integrating test-driven design or behavior-driven development (often in collaboration with stakeholders or customers) to ensure that any functional requirements in scope for the current iteration are well-defined and testable. This type of "living documentation" is often more useful, more accurate, more maintainable, and more effective than typical functional requirements documents.