Not “what the software can do” — “what this one person is trying to get done, right now.”
Ivar Jacobson’s 1992 book Object-Oriented Software Engineering: A Use Case Driven Approach introduced the use case as a formal software-design unit: instead of specifying a system feature-by-feature, describe the concrete interactions an actual user has with it to accomplish a goal, and build the system to satisfy those interactions. The shift mattered because a feature list describes what software can do in the abstract; a use case describes what it actually gets used for, which is a much better test of whether it’s worth building at all.
This essay draws the same line for selling AI: “Showing a demo of an ecosystem, now that’s a working use case” — as opposed to just describing an automation abstractly, a working use case is proof, in front of the client, that the thing does what a real person in their business actually needs done.
Source: Jacobson, I., Christerson, M., Jonsson, P. & Övergaard, G. (1992), Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley. Foundational primary source — predates the DOI era, cited directly by title/publisher rather than a database record.