Goal Directed Analysis with Use Cases
-
Upload
edan-odonnell -
Category
Documents
-
view
37 -
download
1
description
Transcript of Goal Directed Analysis with Use Cases
![Page 1: Goal Directed Analysis with Use Cases](https://reader030.fdocuments.us/reader030/viewer/2022032313/56812bd7550346895d904319/html5/thumbnails/1.jpg)
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
![Page 2: Goal Directed Analysis with Use Cases](https://reader030.fdocuments.us/reader030/viewer/2022032313/56812bd7550346895d904319/html5/thumbnails/2.jpg)
2
Outline• Modeling with Goals
• A Goal-Oriented Method
• Defining System Goals and Requirements
• Deriving Use-Cases
• Elevator Requirements
• Discussion
![Page 3: Goal Directed Analysis with Use Cases](https://reader030.fdocuments.us/reader030/viewer/2022032313/56812bd7550346895d904319/html5/thumbnails/3.jpg)
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.
![Page 4: Goal Directed Analysis with Use Cases](https://reader030.fdocuments.us/reader030/viewer/2022032313/56812bd7550346895d904319/html5/thumbnails/4.jpg)
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.
![Page 5: Goal Directed Analysis with Use Cases](https://reader030.fdocuments.us/reader030/viewer/2022032313/56812bd7550346895d904319/html5/thumbnails/5.jpg)
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
![Page 6: Goal Directed Analysis with Use Cases](https://reader030.fdocuments.us/reader030/viewer/2022032313/56812bd7550346895d904319/html5/thumbnails/6.jpg)
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
![Page 7: Goal Directed Analysis with Use Cases](https://reader030.fdocuments.us/reader030/viewer/2022032313/56812bd7550346895d904319/html5/thumbnails/7.jpg)
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
![Page 8: Goal Directed Analysis with Use Cases](https://reader030.fdocuments.us/reader030/viewer/2022032313/56812bd7550346895d904319/html5/thumbnails/8.jpg)
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.
![Page 9: Goal Directed Analysis with Use Cases](https://reader030.fdocuments.us/reader030/viewer/2022032313/56812bd7550346895d904319/html5/thumbnails/9.jpg)
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
![Page 10: Goal Directed Analysis with Use Cases](https://reader030.fdocuments.us/reader030/viewer/2022032313/56812bd7550346895d904319/html5/thumbnails/10.jpg)
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
![Page 11: Goal Directed Analysis with Use Cases](https://reader030.fdocuments.us/reader030/viewer/2022032313/56812bd7550346895d904319/html5/thumbnails/11.jpg)
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?
![Page 12: Goal Directed Analysis with Use Cases](https://reader030.fdocuments.us/reader030/viewer/2022032313/56812bd7550346895d904319/html5/thumbnails/12.jpg)
12
Refinement Patterns
• BasicDisjunction (or)Conjunction (and)
• Milestone
• Case-based
![Page 13: Goal Directed Analysis with Use Cases](https://reader030.fdocuments.us/reader030/viewer/2022032313/56812bd7550346895d904319/html5/thumbnails/13.jpg)
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
![Page 14: Goal Directed Analysis with Use Cases](https://reader030.fdocuments.us/reader030/viewer/2022032313/56812bd7550346895d904319/html5/thumbnails/14.jpg)
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
![Page 15: Goal Directed Analysis with Use Cases](https://reader030.fdocuments.us/reader030/viewer/2022032313/56812bd7550346895d904319/html5/thumbnails/15.jpg)
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
![Page 16: Goal Directed Analysis with Use Cases](https://reader030.fdocuments.us/reader030/viewer/2022032313/56812bd7550346895d904319/html5/thumbnails/16.jpg)
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
![Page 17: Goal Directed Analysis with Use Cases](https://reader030.fdocuments.us/reader030/viewer/2022032313/56812bd7550346895d904319/html5/thumbnails/17.jpg)
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