I usually state that requirements are situated in the sense that they depend upon the details of the particular situation or context in which they arise. You will most likely need to reference those details to interpret the requirements directly. Requirements are negotiated in that they result (ostensibly) from discussions among interested parties, the outcome of which depends on the parties’ interest, organizational position, technical background, and other factors. Also, the relations of requirements to one another and to other objects also arise through negotiation and thus also depend upon context. For example, to say that a requirement is derived from some document will have different meanings in different contexts. A traceability procedure will be more useful if it can account for this situatedness, letting customers and users do what is most appropriate in each situation.

Also figure that this even applies in a more limited context when you consider that requirements evolve throughout the life of the system. They change in nature, from general to specific; they change in scope, by incorporating new features and deleting old ones; and they change in content and in form, to become more consistent, precise, and clear as the result (hopefully) of QA activities upon them. The requirements are also related to each other and to other artifacts involved in the development of the product and/or system. Moreover, even these connections also evolve over time. So you have a great deal of situational aspects to consider and all of that should be considered in a traceability procedure.