Use Cases and Goals:

Actors have goals or needs, use applications to help satisfy them. Consequently,
an EBP-level use case is called a user goal-level user case, to emphasize
that it serves (or should serve) to fulfill a goal of a user of the system, or the
primary or main actor.
This is slight shift in emphasis for the use-case modeler. Rather than asking
"What are the use cases?", one starts by asking: "What are your goals?" In fact,
the name of a use case for a user goal should reflect its name, to emphasize this
viewpoint.Goal: capture or process a sale; use case: Process Sale.
Note that because of this symmetry, the EBP guideline can be equally applied to
decide if a goal or a use case is at a suitable level.



Imagine we are together in a requirements workshop. We could ask either:
. "What do you do?" (roughly a use case-oriented question) or,
. "What are your goals?"
Answers to the first question are more likely to reflect current solutions and
procedures, and the complications associated with them.
Answers to the second question, especially combined with an investigation to
move higher up the goal hierarchy ("what is the goal of that goal?") open up
the vision for new and improved solutions, focus on adding business value,
and get to the heart of what the stakeholders want from the system under
discussion.
Applying the EBP Guideline
you are investigating user goals. The conversation goes like this: During a
requirements workshop:
Requirements for use case of a system:

System analyst: "What are some of your goals in the context of using a POS
system?"
Cashier: "One, to quickly log in. Also, to capture sales."
System analyst: "What do you think is the higher level goal motivating logging
in?"
Cashier: "I’m trying to identify myself to the system, so it can validate that
I’m allowed to use the system for sales capture and other tasks."
System analyst: "Higher than that?"
Cashier: "To prevent theft, data corruption, and display of private company
information."
Note the analyst’s strategy of searching up the goal hierarchy to find higher
level user goals that still satisfy the EBP guideline, to get at the real intent
behind the action, and also to understand the context of the goals.
"Prevent theft, ..." is higher than a user goal; it may be called an enterprise goal,
and is not an EBP. Therefore, although it can inspire new ways of thinking
about the problem and solutions (such as eliminating POS systems and cashiers
completely), we will set it aside for now.
Lowering the goal level to "identify myself and be validated" appears closer to
the user goal level. But is it at the EBP level? It does not add observable or measurable
business value. If the CEO asked, "What did you do today?" and you
said "I logged in 20 times!", she would not be impressed. Consequently, this is a
secondary goal, always in the service of doing something useful, and is not an
EBP or user goal. By contrast, "capture a sale" does fit the criteria of being an
EBP or user goal.

As another example, in some stores there is a process called "cashing in", in
which a cashier inserts their own cash drawer tray into the terminal, logs in,
and tells the system how much cash is in drawer. Cashing In is an EBP-level (or
user goal level) use case; the log in step, rather than being a EBP-level use case,
is a subfunction goal in support of the goal of cashing in.

Goals and Use Cases Can Be Composite:
Goals are usually composite, from the level of an enterprise to
many supporting intermediate goals while using applications
to supporting subfunction goals within applications .
Similarly, use cases can be written at different levels to satisfy these goals, and
can be composed of lower level use cases