Activity: Analyze Behavior








var defaultQueryStr = '?proc=_hdw4QSCcEdq3qtLcbHn6PQ&path=_hdw4QSCcEdq3qtLcbHn6PQ,_Cgn1MCCdEdq3qtLcbHn6PQ';
var backPath = './../../';
var imgPath = './../../images/';
var nodeInfo=null;
contentPage.preload(imgPath, backPath, nodeInfo, defaultQueryStr, false, true, false);










Activity: Analyze Behavior















This activity transforms the behavioral descriptions provided by the requirements into a set of elements upon which the design can be based.


Extends: Analyze Behavior








DescriptionWork Breakdown StructureTeam AllocationWork Product Usage








Relationships



Parent Activities


Develop Components [within Scope]






Description



This activity occurs in each iteration in which there are behavioral requirements to be analyzed and designed. The analysis of behavioral requirements includes the following: identifying analysis classes that satisfy the required behavior 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 activity may also include modeling and prototyping of the user interface.



Properties



Event Driven


Multiple Occurrences


Ongoing


Optional


Planned


Repeatable



Staffing



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 Task: Use-Case Analysis is best conducted by a small group with a blend of skills; staffing guidelines are presented in Guideline: 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.



Usage



Usage Guidance Task: Design the User-Interface and Task: 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 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; eight 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, 2006.  All Rights Reserved.







contentPage.onload();