Demonstrating coverage is a tricky thing. I’m not familiar with “functional coverage” but to me the two main approaches seems to be to do some kind of requirements coverage by saying something like: “This requirement have at least one test on it” or code coverage which is typically saying: “This like of code have been executed during at least one test.”.
Let’s start with what I think you want to say in most cases and why these two don’t say that. Normally you would like to say “Everything that is important enough have been covered sufficiently with tests.”. Code coverage both fails on what is important enough since you typically do not have any means to express the importance of a line of code, and on sufficiently since you do not say what kind of data variations that are meaningful. Requirement coverage at least have the importance, but the sufficient is normally missing. If you have both then you have a chance to express the statement. (I’ve never worked at a place that had both).
After that you have an aggregation problem when reporting / demonstrating. For instance if you report 50%, you have aggregated all that juicy information into a number that prevents you from making the statement.
Regarding when you do not have to demonstrate it for me the main reason typically lies in the applicability of the information provided. For instance, if you provide the number and no one looks at it or looks at it but does not take any actions the information is typically useless. Another reason is that you typically will get the information after testing anyway, as in bugs reported in production. That will at least tell you that there are some things the testing does not cover. If those are severe enough your coverage is to low. The last note is that I have been at places which value these thing very highly, but all I’ve seen them used for is to cover your ass not to help increase quality. As in, it’s not my fault because my coverage is 80% and that was the specified rule.
So what can you do about it. The most useful information provided in my experience is when you and your stakeholder can come up with some kind of actions that you may want to take. Like we need to test more variants of the deposit money function. Then you can say today we have 2 variants on that let’s increase that to 5. Thus increasing the coverage from 2 to 5.