Explain a requirement change without losing context
The message that announces a change has one job beyond announcing it: telling everyone what it invalidates.
Requirements change. The message that announces the change usually says what the new value is, and stops there. What it needs to say as well is what the change breaks.
Six things the message needs
The version - Give the new requirement a revision letter or number and put it in the subject line and the filename, not only in the body.
What changed - One line, field by field. "Outlet changed from G5/8 to G3/4. Bore unchanged. Quantity unchanged."
Why, in one sentence - Optional but valuable. A supplier who knows the downstream equipment changed can spot a second consequence you have not.
What it supersedes - Name the documents: "This supersedes Rev A issued 12 March." Not "the previous version".
What has to be reissued - The quotations, drawings and enquiries built on the old revision, by reference. This is the line that stops old work continuing.
The date it takes effect - Especially if anything is already in production.
Who to send it to
Send it to everyone who received the previous version, not only to the people working on the new one. The people still working from the old revision are by definition not in the new conversation, which is exactly why they need the message.
If you kept a note of who received what, this is a two-minute job. If you did not, this is the moment that convinces you to start.
Do not edit in place
And one thing not to do: do not edit the old document and keep the filename. It looks tidy and it destroys your ability to answer "what did we quote against?" A new revision is a new file alongside the old one.
State the revision, what changed, and which of our quotations or drawings it supersedes.