Well, having it on a work item is a "no go" for me, it is an approach that solves one job by sacrificing many others. As a scaler CTO, I always think about how this information can be discovered and used after the work is done, maybe in 2-3 years, in bigger and more structured team, by different people. Recording it with the work means that you can never be sure, that there's no overlap with some other unit of work elsewhere, which could have made some parts of spec obsolete or replaced. Finding connections to other cases recorded in other units of work is also difficult.
For those reasons I always define requirements in a wiki or documentation management system, where you can look at all current requirements at glance and, if system supports versioning (it must), at all requirements at any given moment of time too (audit, incident investigation). From the requirements we can go into tasks and related code, if needed, but for product development it is more important to be able to see the full picture than when it was done. Implementation tickets just link the relevant parts of the spec, but never quote it or substitute it.
Good referencing model of course helps to navigate in reverse direction too, enabling engineers to understand the context of certain parts of the code.