Something I encounter everywhere I've worked but never seen a good solution for: when writing software business requirements, we follow a template that contains some pretty standard sections (assumptions, constraints, etc.). Every now and then the team will make a business decision about how the software will be used, but not specific to any functionality of it. It's not something that the QA team will need to test, so we just don't include it in the requirements. Then of course months or years later someone will want to know why something is the way it is.

Just one recent example: at first the client said that the software would only be used by certain locations. Then during requirements gathering they decided not to restrict the location in the software, just that they'd only tell staff at those specific locations that they could use the feature. (Basically security by obscurity - ha!)

It seems like business decisions need to be documented somewhere. But... where? What do your teams do with them?