Managing Changing Requirements Structure the Use Case Model

Managing Changing Requirements: Structure the Use Case Model Power. Point Presentation derived from IBM/Rational course Mastering Requirements Management Most slides copyright IBM/Rational. Slide 1

Objectives • Simplify the maintenance of the requirements without sacrificing clarity or comprehension for stakeholders. – Structure the use-case model. – Define and describe the relationships between use cases. • Include, Extend, Generalization – Describe concrete and abstract use cases. – Define actor generalizations. – Describe concrete and abstract actors.

Where Are We in the Requirements Discipline?

Manage Change: Activities and Artifacts

Workflow of use case modeling Analysis Phase Iterate Describe the Use Cases Seek Actors Seek Use Cases • Seek Actors: Name and describe • Seek Use Cases: – For each (active) actor ask “What would you like to use the system for? ” • Name and briefly describe each Use Case • Iterate based on previous findings

Structure the Use-Case Model • What is model structuring? – Factoring out parts of use cases to make new use cases. • Why structure the use-case model? – Simplify the original use cases. • Make easier to understand. • Make easier to maintain. – Reuse requirements. • Share among many use cases.

Relationships Between Use Cases • Include • Extend • Generalization «include» «extend»

What Is an Include Relationship? • A relationship from a base use case to an inclusion use case. • The behavior defined in the inclusion use case is explicitly included into the base use case. Inclusion «include» Base

Analysis Phase Dependency – Include • A relationship from a base use case to an inclusion use case • Implies that a use case “calls” another use case • Primarily for reuse behavior common to several use cases • The “calling” Use Case references the “called”. All conditions for the usage are stated in the “calling” Use Case, e. g: – ”… The system then prints. Order. Coffee the report according to <Print> …” – ”… The system collects the coins according to <Insert. Coins>, the system is now ready to …”

Include Relationship: RU e-st Example «include» Get Quote Execute Trading Customer «include» Other Use Case Get Quote Use Case 1. Include “Identify Customer” verify customer’s identity 2. Display options. Customer selects “Get Quote” 3. . to Identify Customer «include» Identify Customer Use Case 1. Log on 2. Validate logon 3. Enter password 4. Verify password A 1: Not valid logon A 2: Wrong password A 3: . . .

Execution of an Include Relationship • Fully executed when the inclusion point is Base reached. Use Case Use-Case Instance Included Use Case

Why Use an Include Relationship? Inclusion «include» Base – Factor out behavior common to two or more use cases. • Avoid describing same behavior multiple times. • Assure common behavior remains consistent. – Factor out and encapsulate behavior from a base use case. • Simplify complex flow of events. • Factor out behavior not part of primary purpose.

Analysis Phase Why not? • Do not overuse this concept – generates too many Use Cases – makes the Use Case Model more difficult to understand maintain Order. Coffee

What Is an Extend Relationship? • Connects from an extension use case to a base use case. – Insert extension use case’s behavior into base use case. – Insert only if the extending condition is true. – Insert into base use case at named extension point. Base «extend» Extension

Dependency - Extend Analysis Phase • From an extension use case to a base use case • Implies behavior in one use case is an extension of the behavior in an other use case. • Is used to model optional behavior. • Conditions for how and when the extension is done is stated in the extending Use Case: – ”… if the user pushes the “add sugar” button, sugar is added according to <Add. Sugar> …” Order. Coffee

Extend Relationship: RU e-st Example Trading Customer Get Quote «extend» Get News «extend» Get Expert Predictions Expert Quote System News System

Extend Relationship: (cont. ) Get Quote Use Case Basic Flow: 1. Include “Identify Customer” to verify customer’s identity. 2. Display options. 3. Customer selects “Get Quote. ” 4. Customer gets quote. 5. Customer gets other quotes. 6. Customer logs off. A 1. Quote System unavailable … Extension Points: The “Optional Services” extension point occurs at Step 3 in the Basic Flow and Step A 1. 7 in Quote System Unavailable alternative flow. Get News Use Case This use case extends the Get Quote Use Case, at extension point “Optional Services. ” Basic Flow: 1. If Customer selects “Get News, ” the system asks customer for time period and number of news items. 2. Customer enters time period and number of items. The system sends stock trading symbol to News System, receives reply, and displays the news to the customer. 3. The Get Quote Use Case continues. A 1: News System Unavailable A 2: No News About This Stock …

Execution of an Extend • Executed when the extension point is reached and the extending condition is true. Use-Case Instance Base Use Case Extension Point Extension Use Case

Why Use an Extend Relationship? Base «extend» Extension • Factor out optional or exceptional behavior. – Executed only under certain conditions. – Factoring out simplifies flow of events in base use case. – Example: Triggering an alarm. • Add extending behavior. – Behavior developed separately, possibly in later version.

Analysis Phase Why not? • Do not overuse this concept – generates to many Use Cases – makes the Use Case Model hard to understand maintain – should still add value to the Actor Order. Coffee

Concrete Versus Abstract Use Cases A use case is either concrete or abstract. Abstract use cases (A & D): • Do not have to be complete. • Exist only for other use cases. • Are never instantiated on their own. A «include» B C «extend» Concrete use cases (B & C): • Have to be complete and meaningful. • Can be instantiated on their own. D Hint: Cover up all abstract use cases and you should still be able to understand the main purpose of the system.

Why Wouldn’t You Structure The Model? Inclusion «include» Base «extend» Extension Child § The solution is harder to see when the use case gets fragmented. • Functionally decompose the requirements. • Decrease understandability. • Increase complexity. • Increases effort for reviewers, implementers and testers. • Not all stakeholders are comfortable with the format. § The use-case model looks like a design.

What Is Actor Generalization? • Actors may have common characteristics. • Multiple actors may have common roles or purposes interacting with a use case. Parent Child 1 Child 2

Actor Generalization: Hospital Example Schedule Operation • Parent: Medical Worker – Medical Worker can read charts • Children: Doctor, Nurse, Aide Doctor – Doctor, Nurse, and Aide can read charts Nurse Aide Medical Worker Read Chart

Why Use Actor Generalization? Parent Child 1 Child 2 • Simplify associations between many actors and a use case. • Show that an instance of a child can perform all behavior described for the parent. • Represent different security levels.

Abstract Versus Concrete Actors • An abstract actor contains the common part of the roles. Medical Worker – It cannot be instantiated itself. – Example: • No person is hired to be a Medical Worker. • A concrete actor can be instantiated. Doctor Nurse – Example: • Lauren is a Doctor. • Daniel is a nurse.

Use-Case-Modeling Guidelines • Notations to use and not use. – For example, whether to use generalization relationships. • Rules, recommendations, style issues, and how to describe each use case. • Recommendations for when to start structuring the use cases (not too early).

Discussion: Structuring the Use-Case Model • How should we structure the use-case model for our class project? – Include relationships? – Extend relationships? – Actor generalizations?

Model to from generalization communicates «include» «extend» generalization

Checkpoints for Use Cases • For an included use case: does it make assumptions about the use cases that include it? Such assumptions should be avoided so that the included use case is not affected by changes to the including use cases. • Are there some optional requirements that are not part of the standard product requirements? If so, you model this with an extend-relationship to the other use case.

Review: Structure the Use-Case Model 1. Why might you decide to structure your use-case model? 2. When is an extend-relationship used? 3. When is an include-relationship used? 4. What is an abstract actor? A concrete actor? An abstract use case? A concrete use case?