Goal Directed Analysis with Use Cases
Presented by Chin-Yi [email protected]
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
Top Related