Workflow Detail: Analyze Behavior The purpose of this Workflow Detail is to transform the behavioral descriptions provided by the requirements into a set of elements upon which the design can be based. Topics Description Related Information Timing Optionality  How to Staff Work Guidelines                 User-Interface Designer     Design the User Interface   Prototype the User-Interface                   Navigation Map   User-Interface Prototype                   Technical Reviewer     Review the Design   Review the Design                   Review Record   Review Record               Software Architect     Identify Design Elements                 Design Subsystem Design Model         Design Package Signal         Event Design Class         Enterprise Java Bean (EJB) Interface               Designer     Use-Case Analysis                 Analysis Class Design Use-Case Realization         Analysis Model   Description This Workflow Detail occurs in each iteration in which there are behavioural requirements to be analyzed and designed. The analysis of behavioural requirements includes: identifying analysis classes that satisfy the required behaviour determining how these analysis classes fit into the logical architecture (the major subsystems and classes) of the system. The analysis classes may be determined to belong to existing subsystems, require the creation of new subsystems, or cause existing subsystems and their interfaces to be redefined. This Workflow Detail may also include modeling and prototyping of the user interface. Related Information This section provides links to additional information related to this workflow detail. Timing Starts in Elaboration phase, recurs through Construction and Transition phases. Optionality Required How to Staff Especially in larger projects, user-interface design and prototyping is performed by a separate group of people, focused only on usability of the system and the user interface. However, this group should work closely with other members of the development team, especially those responsible for the requirements and the business logic, to make sure that the user interface is what the user expects, and that the business logic provides what the user interface requires (in terms of content and user actions). The Activity: Use-Case Analysis is best conducted by a small group with a blend of skills; staffing guidelines are presented in Guidelines: Use-Case Analysis Workshop. The Activity: Identify Design Elements requires a broader perspective of the architecture and the results of other use-case analysis workshops, and requires some experience in the implementation technology and any frameworks being used on the project. Reviews should be staffed with people who have both in-depth knowledge of the implementation technologies as well as an understanding of the problem domain. Work Guidelines Activity: Design the User-Interface and Activity: Prototype the User-Interface are performed iteratively throughout the Elaboration iterations. Early iterations focus on the initial user interface design, which includes the identification and design of the key user interface elements and the navigation paths between them. Storyboarding is an effective technique that can be used during user-interface design to gain a better understanding of how the user interface should behave. Once consensus on the initial user-interface design has been reached, then the development of an executable user-interface prototype begins. Feedback on the prototype is fed back into the user-interface design (and possibly even the requirements). The initial prototype typically supports only a subset of the system's features. In subsequent iterations, the prototype is expanded, gradually adding broader coverage of the system's features. The main benefit of producing non-functional versions of the user-interface during user-interface design is to postpone the investment of more elaborate and costly functional user-interface prototypes until there is consensus on the overall user-interface design. It is important to work closely with users and potential users of the system when designing and prototyping the user-interface in order to confirm and validate the usability of the system. A number of use-case analysis workshops may be organized in parallel, limited only by the available resource pool and the skills of the participants. As soon as possible following each use-case analysis workshop, some members of the workshop and some members of the architecture team should work to merge the results of the workshop in the Activity: Identify Design Elements. Members of both teams are essential: the use-case analysis team members understand the context in which the analysis classes were identified, while the architecture team understands the greater context of the design as well as other use cases which have already been identified. As the design work matures and stabilizes, increasingly larger parts of it can and should be reviewed. Smaller, more focused reviews are better than large all-encompassing reviews; sixteen two-hour reviews focused on very specific aspects are significantly better than a single review spanning two days. In the focused reviews, define objectives to bound the focus of the review, and ensure that a small review team with the right skills for the review, given the objectives, is available for the review. Early reviews should focus primarily on the integrity of layering and packaging in the design, the stability and quality of the interfaces, and the completeness of coverage of the use case behavior. Later reviews should drill down into packages and subsystems to ensure that their contents completely and correctly realize their defined interfaces, and that the dependencies and associations between design elements are necessary, sufficient and correct. See the check-points on each design artifacts for specific review points. © Copyright IBM Corp. 1987, 2004. All Rights Reserved.

Rational Unified Process