What Comes Before Use Cases ?
Use cases are rarely the starting point for any project when it is first being conceived. Initially, the business sponsor is thinking about business benefits, costs savings or creating competitive advantage. They will be starting to formulate a business case whether formally or informally.
This should always be the case whether it is done on a very informal basis in a smaller organisation or as part of a formal process which will be the case in larger organisations.
The need for a business case is required by all businesses even those in the not for profit sector although their desire to generate increased profit, for example, is not the same central, overriding goal as it is the private sector.
Anyhow, there could be a whole heap of preliminary work that goes on before the word use case is mentioned. It should involve defining strategy and achieving business goals in support of that which will be internally driven.
Alternatively, it may be driven externally by, for example, regulatory requirements where there is usually a timetable for compliance dictated by a body outside the business.
I do not intend to cover any of this in detail but just give a flavour of where use cases may sit and how they are just part of an ongoing process that starts some time before and may or may not involve the business analyst.
The more experienced business analyst, who is hooked into the corporate strategy, may well be participating or even driving this preliminary work.
Often, however, the business analyst (in the IT department) is only called in when the project has a name and some objectives.
At this stage there are some useful models that can bear fruit downstream before diving into the level of detail required by use cases.
Context Diagram
The first is called a context diagram 
and positions the system within the larger business context. It will identify the interfaces with other parts of the business – typically, this is a point of contact or handoff between two parties that shows the scope of the project.
Ultimately, it will be a box that defines the boundary or the project scope. Business activities within the box are in scope and activities outside the box are out of scope.
Below is an example of a context diagram.
