Activity

[Work on own experiences/completions]

Requirement Analysis

A-229 Detail system use case

Develop a complete activity model for each identified system use case. It should contain all relevant exceptions and variants. Use this model to identify and describe dialogs.

Activity has to be run in Elaboration Phase (Iterative Activity)
Activity has to be run in Construction Phase (Iterative Activity)


Develop an activity model for each system use case
After the use case essences have been described, they should be analysed in detail. Detail them in such a way, that each activity step with its pre- and pastconditions, actors, incoming and outcoming data and events are comletely described. Do it in separate steps:

Textual descriptions often make no statement about the step sequence or if they have to flow side by side, and under which conditions this is possible. An activity model offers this advantage and describes this point in a formal way. And do this without producing long text.

Describe the standard process
Use the separate steps of the description of the use case essence and model the process flow of each system use case with an activity diagram. Describe only the standard process, as elementary single activities. If a use case essence conclude more that one elementary single activity, break down the essence and activity to sensible units. Each acitivity diagram has an initial state and one or more final states.

Describe the complete process
Now model for each activity all relevant exceptions and variants and clarify them. For example: The activity "Identify customer" (system use case: Reserve a car by telephone) has only on outcoming/going transition [ok] as a standard process. The question is now: What other events are conceivable and possible for the activity on a technical level? One possibility [Costumer number/ID invalid] or [Caller not authorized].

Proceed in the same manner with all activities. Add only the exceptions which are on a technical level and which might be relevant for the flow into the activity model. The degree of detail in the use case essence will not be changed by this.

Additionally collect all possible candidates for secondary system use case on a list. Note the name of each system use case with all relevant names for candidates for each secondary system use case (e.g. Identify customer). At a later stage collect all lists of candidates and put them together. This is necessary for modeling the system use case model.

As an artifact you are able to define all relevant test cases out of the activity specification. Each transition has one test case at least.

Identify dialogs
In complex application systems you find dialogs in large numbers of different contexts. Because it is not useful that the system user has to handle different dialogs for each data entry and also in view of the development and maintenance cost, you should try to define dialogs in a way that they are usable in different contexts.

To identify dialogs analyse the activity modell systematically. In which situation is a dialog needed? Identify and name elements of dialogs which are at the same technical level (e.g. all single data fields for one address). Describe them by adding a note to the relevant system use case or describe them on a separate list. All needed dialog elements (widgets) have a name. Try to divide elements into necessary sets (each set has a name), if applicable. All single elements of a set should be detailed.

Describe each dialog essentially like that:
At a following stage Specify a dialog all lists are added and all dialog elements are described in detail. All dialogs which are identified and essential described have to be consolidated by the responsible persons of the task among each other or by the special architect.


Reasons:

Trigger:

Precondition:

Documents:

E-20 Requirement specification
E-7 Glossary
E-6 Essence of Use Cases
E-2 Use case overview
E-115 UML-Business-Class-Model

Countercondition:

Results:

E-38 Activity Diagram
E-152 List of open points/Todo list
E-45 Dialog Component Specification
E-59 Testcase
E-154 List of candidates of secondary system use cases
E-139 Dialog sequence diagram

Special tools:







Responsible person:

.System Analyst

Involved persons:

.System Analyst
.Domain Expert

Postcondition:

A-233 Develop a use case model with associations between system use cases
A-230 UML-business-class-model
A-231 Identify and describe output (artifact)
A-26 Specify a dialog

OEP - Object Engineering Process, v3.0, 06.11.2006 11:07:50, Copyright © 2006 by oose Innovative Informatik eG