A view that a UseCase (UC) is a "dialog" between the System under Consideration (SuC) and an Actor (for a specific UC) brings focus to what "messages need to be exchanged between the SuC and Actor to reach UC Goal".
 Agreeing on and specifying UC Goal is related to business or application. UC Goal would be the right first step of UC description.
 There are many "means" of generating "messages from SuC", through various internal activities within the SuC. They need not be (I would even say should not be) specified in UC Description.
 The concept of UseCase is profound and useful because it is a "dialog" but NOT a process. This distinction is not defined and clarified which is why, I think, the full benefits of UC modeling are not widely realized.
 This view of UC (as per 1, 2 & 3) clearly separates the "internal processes" of the SuC from UC. The "internal processes" can be hypothesized and evolved separately using UML Sequence Diagrams. All the business / user needs can be specified with sufficient precision and rigor through the “messages” of UC dialog. There are no external dependencies, though constraints may exist and have to be taken care of.
I have REVISED & uploaded the PPT with TWO Sections, Section 2 First.
 I would like to study applications and demonstrate how the "dialog" view of UseCase would simplify & clarify UseCase description for the business user as well as system developer without sacrificing precision and usefulness.
02 FEB 14
Clipping is a handy way to collect important slides you want to go back to later.