The second part of your comment, I don’t really understand. If something is a requirement, it should be documented as a requirement; if something is a guideline, it should be documented as a guideline.
In my example, it is a requirement, so it should be documented as such.

Both functional and non-functional requirements are requirements. Perhaps your question is a more basic question about requirements management, but it is not the subject of this blog posting.

Your last statement “A requirements document should be readable to any project member interested in the functionality” is not valid, so maybe you misunderstand the purpose of a requirements specification. If that’s the case, let’s take it up by e-mail because it diverges too far from the topic of this post.

Is that so? Exactly how are you going to get there? This statement leaves open if it’s going to be a plane, train or automobile, etc.

>>“A requirement is an externally observable characteristic of a desired system”.

Yes, and there’s functional and non-functional requirements. Both can be equally important to a customer (group of different stakeholders). But documenting them serves different purposes.
A functional requirements document should be readable to any stakeholder interested in the functionality, be it a developer, tester, project manager, or end user.
Other stuff like design guidelines and code quality requirements is not primarily interesting for (for example) testers and should therefore be documented elsewhere. This is merely a way of creating readable and maintainable documentation.

So I think your final conclusion is valid, but the picture you draw is not entirely adequate.
Yes, and there’s functional and non-functional requirements. Both can be equally important to a customer. But documenting them serves different purposes. A requirements document should be readable to any project member interested in the functionality,