This discussion is based on use of the Fusion methodology for object-oriented software development.
Two texts may be used as references for the Fusion methodology:
Book: Object-Oriented Development, The Fusion Method by Derek Coleman, et al.
Courseware: Object-Oriented Analysis and Design - Fusion by the Object Space training organization.
Where the Fusion methodology falls short, notations and techniques may be borrowed from other widely recognized object oriented methodologies such as Object Oriented Software Engineering (Jacobson), Booch, Object Modeling Technique (OMT) (Rumbaugh, et al.), and others.
Stated simply, the goal of analysis is to produce analysis documentation. This documentation plus the Business Specifcation serve as the primary input for user documentation, user test cases, validation test cases, training materials, and marketing materials. The analysis documentation completely defines what needs to be implemented, but not how.
| Business specification |
| Functional specification |
| Development plan |
| Detailed Analysis Plan template |
| Analysis Document template |
| Detailed analysis plans |
| Analysis document |
A formal review must be performed to ensure that the results of the analysis phase are consistent with the goals specified in the business and functional specifications.
In addition to the formal review, each team involved in analysis should perform their own incremental reviews to ensure that they are staying on track and to determine whether earlier specifications may need revision.
| Development teams and directors of development. |
| Subject matter experts |
| The parallel activities of each development team will be specified in the development plan. Each team is then responsible for planning their time within those parameters. Specifically, each team should set up finer grained milestones for completing portions of their assignments. Iteration should be considered and planned for as well. The team leader in each team will be responsible for ensuring that each team member is on schedule and progressing as planned. |
| The detailed analysis plans will be approved by the directors of development. |
To a great extent the analysis methodology will drive the contents of analysis documentation. The following contents would apply to most methodologies:
| use cases and prose |
| scenarios (similar to object interaction diagrams in OOSE) |
| analysis object model (domain or business object model) |
| class dictionary, includes detailed information on each class defined in the analysis object model. Also provides helpful documentation defining the meaning of the relationships and interdependencies of clusters of classes and frameworks. |
| life cycle model (can additionally use OMT state transition diagrams, may be used for any granularity of object) |
| operation model (shows details of system operations that were shown in the scenarios, similar to finer grained object interaction diagrams in object-oriented software engineering) |
| Additional notation that may be useful include the data flow diagrams in OMT. These diagrams allow for showing how data flows through an object-oriented system. For example, how data flows to create a new object or how data flows to complete a transaction. |
| user boundaries - prototypes of user interfaces, report layouts, external data formats such as for import and export or for ActiveX document or clipboard compatibility. This set of documentation is not meant to determine how to implement any of these items; instead, it is a means for further refining the user requirements. |
Risk analysis should be performed at every stage.
| In the analysis stage, unknowns in detailed user requirements will be one of the most glaring areas of risks. All unknowns should be resolved as soon as possible to avoid the impact of adding new functionality in the later stages of the development life cycle. |
Prototyping is a tool for narrowing down requirements and is imperative when requirements are incomplete and/or vague.
| Prototypes of user interfaces and reports/outputs, mentioned as part of the analysis document, can be helpful to further refine user requirements. When appropriate, development teams will rapidly compile a set of screens for end users to review to elicit some immediate feedback. These prototypes should be passed on to usability testing or human factors study. |
| Prototypes at the system architecture level can be helpful to resolve unknowns determined by the definition of the functional specification. For example, database or network capacity and throughput could be determined by building small prototypes of the system. |
Business Specification Analysis Detailed Design Testing Post Study Functional Specification Architecture Design Implementation Deployment and Maintenance HOME
