In most cases, I think, it is best to organize an end-user manual by process because this is what the user cares about. When they use the software they will begin with the first step of their workflow and work according to their process. Complex processes can be divided into smaller sub-processes. The manual's outline will then follow their progress. Users ...
I will echo Matt in suggesting that the process orientation is the best approach.
However, let me propose a hybrid approach. The software might support multiple processes and those processes might share functional steps. Duplicating the documentation for those shared steps (especially if the steps are complicated) is not a good idea. It is better to document ...
Why not both?
In the Olden Days™, software would often come with two sorts of documentation:
A tutorial or user guide, explaining how to perform common tasks. This could be anything from a quick getting-started guide, up to a comprehensive list of tasks you might want to perform.
A reference manual, giving details of all the software's functions. It ...
I’ve never heard of issues caused by overciting, but underciting causes many problems.
When in doubt, cite it — if nothing else it lends credibility if you can cite reputable sources for any facts you include — it helps show you are aligned with standard practices in a field.
I’d recommend footnotes plus an appendix of works cited and further reading.