I know it sounded trite, but let me give you a metaphore of why it is not a great deal of use.
Suppose we take the design of a car, that includes an internal bonnet release catch, and the use case "Release Bonnet". Now the type of testing you are talking about would get two ticks.
1) the car has an internal bonnet release catch
2) it opens the bonnet.
A tester worth his salt will add the test case, "Use internal bonnet release catch while car is traveling at 80km/h".
These test cases are (in my experience) not in the (software) design. But mark my words, they are the things that those terrors of all software developers, the "users", do.
For example, typically one of the first things I do, to the utter dismay of the usual set of developers, is to start running the system with an entirely empty database. They keep saying "but the system will fail", and I keep saying, "yes, I expect so, but will it do it <i>nicely</i>?" Guess what... designers and developers still tend to neglect the use case scenario "there ain't no data"!
Second typical example, "do it twice". For example, cancel the same booking twice, record the same employee twice, pay the same employee twice, record the same employee timesheet twice, book the same time to the same job for the same employee on the same contract twice. In over twenty years of testing I have not yet found a system in shakedown mode where we haven't found about half a dozen of these.
(and I've also never tested a system where the developers haven't said " but a normal user wouldn't do that "!

)
b
p.s. I'm thinking of changing my sig to "There is only one consistency - users aren't"