Guess what else?
It's not uncommon to forget the everything else.
If you have a functional requirements process (or story process, or backlog, or whatever you want to call it), generally features that come in will have requirements for parts or all of the everything else. A feature to add a new widget to the GUI will include a reference to needing to update the documentation, etc. There is other work, though, where this is more likely to be forgotten. When dev is working on a support tool, or on a diagnostic utility needed to track down a field issue, those often bypass or are rushed through the requirements process (or whatever you're calling it). In those cases, the everything else is often forgotten. In particular, these things are often intended for use by a different audience - support, or dev, or sales engineers - and not by your general user population. It's assumed that this group - support, or dev, or sales engineers - know what they're doing, so the documentation, training, and other needs are lower.
Even when your audience is the "people in the know", that's not an excuse for skipping the everything else.
Yes, support probably knows your product really well. Yes, dev is smart and can just read the code to figure it out. Don't make them do that. Just because they're users who have the same company name as you doesn't mean you get to treat them any less like users. You still have to provide the documentation, the utilities, the samples - everything else that goes with the software you deliver. They'll make fewer mistakes if you help them along with a quick howto. You'll make fewer mistakes if you write that howto (and have to figure out what this thing will actually do!). So stop cutting this corner, and be good to your internal users. They'll thank you, and you'll be glad you did.