It's important to recognize that the Guide to the SWEBOK does not define processes. SWEBOK is the Software Engineering Body of Knowledge - it's the collection of stuff that is relevant to practitioners of software engineering. The Guide to the SWEBOK is designed to organize the knowledge into logical categories so that specific topics and associated references and resources can be collected and collated for easy access.
Because neither the SWEBOK nor the Guide to the SWEBOK are processes, neither will provide any guidance for how to do things. Two sections are related to how work is done - Software Engineering Process and Software Engineering Models and Methods. Some of the references in the Software Requirements and Software Design sections will also give suggestions on how to perform requirements engineering or design activities in the context of software engineering projects.
From a broader perspective, there's also a lot of fuzziness in different aspects of the software development process. For example, one method of eliciting and validating requirements is prototyping and this is discussed in the Software Requirements section of the Guide to the SWEBOK. However, prototypes are also associated with the user interface design as well as analyzing and evaluating the quality of a design - both of these are discussed in the Software Design section of the Guide. Prototyping is related to both requirements and design, and I'm sure there are other techniques that cross two or more Knowledge Areas.
If you are trying to define your process, don't look to the Guide to the SWEBOK to help you do that. That's not the purpose of the document.
As far as your core question:
When it comes to requirements gathering and building a requirements specification, should it include low-level details such as fields and their validation? Or is that typically done in the design phase?
Like most things in software engineering - it depends.
We've learned that, in many cases, having silos around the different activities and throwing work over the wall doesn't work. In fact, even Winston Royce in the paper that defined a waterfall method called out the fact that the staged progression of a software project was inviting failure and, in order to be successful, one would need to have feedback loops between the different activities.
Your requirements will inform your design. But as you are designing, you may learn more about the requirements. And if you are following an iterative and incremental delivery model, each increment will allow for feedback on both the requirements as well as their realization in the design, which may identify changes to one or both as knowledge increases.