Goal Directed Analysis with Use Cases

1. Goal Directed Analysis with Use Cases Journal of Object Technology William N. Robinson and Greg Elofson Presented by Chin-Yi Tsai cyt@pmlab.iecs.fcu.edu.tw http://140.134.26.25/~cyt

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. However 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 systems • A goal is a desired property of the environment • A domain property is a property that exists naturally in the environment • A requirement is a special kind of goal that constrains the software behavior • A 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 Lamsweerde • Goals derive the elaboration of requirements to support 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 goal User goal subfunction

7. A Goal-Oriented Method • Define a method for deriving UML specifications from goals. • The method is synthesis of common UML methods • RUP • Goal-oriented requirements analysis method • KAOS

8. Method Goal-Directed Analysis with Use Cases • 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, understandable 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. goal Refine Add detail 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

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 • Basic • Disjunction (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 type • Organizational use cases • Task use cases • Low-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 goals • The elevator shall minimize its cost of operation • The elevator shall minimize its movement • The 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