Confusion
The confusion starts with the customer. Most customers are unsure of what they require to and how to express any requirement precisely and accurately to any third party.
In theory the customer writes the functional requirements; what a system is required to do. There will be a general high-level requirement that may be functionally decomposed to lower-level requirements and so-on until a level of detail is arrived at which is considered appropriate for an analyst to work on.
A use case may be used to model a certain functional requirement at an appropriate level of detail. This can be useful to the designer and the manager of the software solution. The designer will have a start in perceiving some structure to the software solution and the manager will have a start in visualising a block of work and hence to begin formulating resource needs, creating milestones, perceiving traceability dependencies etcetera.
A use case is also a set of use-case scenarios. A use-case scenario that is actually written is a particular instance from the set of use-case scenarios that is the use case. The particular, written use-case scenario has been written to describe the interaction between a system and an entity using that system with an explicit or implicit reference to a functional requirement and at the same level of detail as that functional requirement.
This implies that unambiguous use cases follow from unambiguous functional requirements.
I take with a pinch of salt and large dose of scepticism any assertion that anything is key to understanding a complex problem.
Except may be, critical thought.
Biting the hand that feeds IT
