Goal Directed Analysis with Use Cases

Presented by Chin-Yi Tsaicyt@pmlab.iecs.fcu.edu.tw

http://140.134.26.25/~cyt

Journal of Object TechnologyWilliam N. Robinson and Greg Elofson

2

Outline• Modeling with Goals

• A Goal-Oriented Method

• Defining System Goals and Requirements

• Deriving Use-Cases

• Elevator Requirements

• Discussion

3

Concept

• Use cases are touted as means to manage the complexity of object-oriented software specification.The UML Use Case relationship

• It is difficult to determine the scope of a single use case, as well as define its elaborations.

HoweverHowever

Define a goal-directed modeling approach based upon functional definition for domain property, goal, requirement, and specification.Helps manage specification complexity.

4

Modeling with Goals• Software specification by use cases has grown with

the popularity of object-oriented software engineering.

• Four foundational definition to the description of software systemsA goal is a desired property of the environmentA domain property is a property that exists naturally in

the environmentA requirement is a special kind of goal that constrains the

software behaviorA specification is special kind of requirement that only

reference system properties.

5

Goal-Oriented Modeling

• Goals are used in a variety of ways to analyze software systems.

• Van LamsweerdeGoals derive the elaboration of requirements to supp

ort them.Requirement “implement” goals much the same way

as programs implement design specification

6

Goal-Oriented Modeling (cont’d)• Object-oriented analysis

Define use case to satisfy goals Goal has different abstraction level

• Five opportunities for goals Attach non-functional requirements to goal Track the project by goals Get subtle requirements from goal failure Use goal with responsibility-based design Match user goals to operational concept

• Goal can assist in choosing parameters from the object model

• Sometimes goals are called features A service the system provides to fulfill one or more stakeholder

needs

System goalSystem goal

User goalUser goal

subfunctionsubfunction

7

A Goal-Oriented Method

• Define a method for deriving UML specifications from goals.

• The method is synthesis of common UML methodsRUPGoal-oriented requirements analysis methodKAOS

8

Goal-Directed Analysis with Use CasesGoal-Directed Analysis with Use CasesMethod

• Elicit the system context• Define the system goals• Derive requirements• Derive use cases• Derive UML models

• Elicitation is common to all system analysis methods

• Defining goals and deriving requirement is common to goal-oriented method

• Defining use case at varied abstraction levels and deriving their associated models is common to object-oriented methods.

9

Benefit (adding goals to UML method of analysis)

• Abstraction Goals provide high-level, functional and non-functional, understanda

ble descriptions of what the system shall do, without the complexity of describing how the system works.

• Direction Goals provide analysis with a checklisk of activities to complete

• Traceability Bridge linking stakeholder request to system specification

• Analysis Provide a means to analyze the system prior to its construction

10

Defining System Goals and Requirements

• Analysts define desired properties of the environment, or goal, based on stakeholder need.

• Analysts refine goals by adding details, which typically constrain the software

requirements can be derived from goal by refinement

goalgoal

RefineAdd detail

RefineAdd detail

11

Defining System Goals and Requirements (cont’d)

• Analysts structure goals according to how they relate to each other. Provide a hierarchical structuring of goals

• To define a goal hierarchy One initial goal Two questions : how? and why?

12

Refinement Patterns

• BasicDisjunction (or)Conjunction (and)

• Milestone

• Case-based

13

When to stop asking How?

• Ideally, requirements are a minimal set of description that constrain the system behavior as a means to bring about desired properties of the environment.Only necessary

14

Deriving Use-Cases• In UML, a use case describes a sequence of action

a system performs that yield a result of value to a particular actor.Difference level of abstraction

• Three common use case typeOrganizational use casesTask use casesLow-level use case

• Consider use cases based on goal statement as abstract, and use cases based on requirements or specifications are concrete

15

Deriving Use-Cases (cont’d)

• Analysts derive use cases from the goal hierarchy. Consider each node: If it has sub-goals, then an abstract use case can be

defined with the sub-goals as use case steps

If is has sub-requirements, then a concrete use case can be defined with the sub-requirements as use case step

If it is a leaf requirement, then a low-level use case can be defined using specification statements

16

Elevator Requirements

• Three high-level goalsThe elevator shall minimize its cost of operationThe elevator shall minimize its movementThe elevator shall move passengers between floors

17

Discussion

• Analysts are quick to grasp the functional definitions

• Analysts find it natural to generate goal hierarchies using How and Why questions

• Analysts can quickly generate good use case from the goal hierarchy