SoDA for Word includes the following Rose and Rose RealTime templates:
File Name |
Template Name |
Description |
Conditions |
498idd.doc |
498 IDD |
Interface Design Description: scope, referenced documents, interface design, and requirements traceability. |
Assumes there is a Rose model that represents the 498 System. Internal interface diagrams are class diagrams attached to the Logical View with the word "Internal" somewhere in the name. The CSCIs are packages in the Logical View, and the key interfaces for each CSCI are classes. The details of each CSCI (described in SDDs) are in separate models |
498irs.doc |
498 IRS |
Interface Requirements Specification: scope, referenced documents, requirements, qualification provisions, and requirements traceability. |
Assumes there is a Rose model that represents the 498 System. In the Use Case View is a package called "Interfaces." The use cases in that package become the interface requirements. |
498ocd.doc |
498 OCD |
Operational Concept Description: scope, referenced documents, requirements, qualification provisions, and requirements traceability. |
Assumes there is a Rose model that represents the 498 System. In the Use Case View is a package called "Interfaces." The use cases in that package become the interface requirements. There is another package in the Use Case View called "Operational Scenarios." The use cases and their interaction diagrams become the operational scenarios. |
498sdd.doc |
498 SDD |
Software Design Description: scope, referenced documents, CSCI-wide decisions, detailed design, and requirements traceability. |
Assumes there is a Rose model that represents each CSCI in the system. The Logical View should contain two diagrams: "System", for the system architecture, and "Main", for the CSCI architecture. Packages in the Logical View, representing CSCs, should each have a "Main" diagram as well. CSCs must be stereotyped as <<imported>> or <<exported>> to be documented as imported or exported CSCs. |
498sdp.doc |
498 SDP |
Software Development Plan: scope, referenced documents, overview of required work, plans for general and detailed software development activities, schedules and activity network, project organization and resources. |
This template contains no SoDA commands. It is included in the template set for consistency and completeness. |
498srs.doc |
498 SRS |
Software Requirements Specification: scope, referenced documents, requirements, qualification provisions, and requirements traceability. |
Assumes there is a Rose model that represents the CSCI. In the Use Case View is a use case called "CSCI." The state diagram for this use case becomes the required states for the CSCI. The Use Case View should also have two packages: "Capabilities" and "Interfaces." Use cases defined within these packages will become the capability and interface requirements. |
498sss.doc |
498 SSS |
System/Subsystem Specification: scope, referenced documents, requirements, qualification provisions, and requirements traceability. |
Assumes there is a Rose model that represents the System. In the Use Case View is a use case called "System." The state diagram for this use case becomes the required states for the System. The Use Case View should also have two packages: "Capabilities" and "Interfaces." Use cases defined within these packages will become the capability and interface requirements. |
Classes.doc |
Data Dictionary of Classes |
Rose model report: class names and descriptions. |
Classes must be defined in the model. |
ClassesAttrsOps.doc |
Data Dictionary of Classes with Attributes and Operations |
Rose model report: class names, descriptions, attributes, and operations. |
Classes must be defined in the model. |
ClassesAttrsOpsTable.doc |
Data Dictionary of Classes with Attributes / Operations in tables |
Rose model report: class names, descriptions, attributes, and operations formatted in a table. |
Classes must be defined in the model. |
Design.doc |
Software Design Document |
Design document for the system: scope, referenced documents, architectural goals and constraints, logical architecture, and interaction diagrams. |
Must have packages in the Logical View. |
LogicalViewFull.doc |
Detail of all Attributes and Operations by Class by Package |
Rose model report: logical view, including package names, class names, public and private properties (attributes) and methods (operations), and package structure. |
Must have packages and classes within those packages in the Logical View. |
LogicalViewPublic.doc |
Summary of Packages, Classes, and Public Attributes / Operations |
Rose model report: logical view, including package names. class names, public properties and methods, and package structure. |
Must have packages and classes within those packages in the Logical View. |
LogicalViewSimple.doc |
Components in the Model and their associated Classes |
Rose model report: logical view, including Package names, class names, and package structure. |
Must have packages and classes within those packages in the Logical View. |
PackagesClasses.doc |
Summary of Packages with Diagrams and Class Descriptions |
Package report with description, class diagram, and classes. |
Must have packages in the Logical View and classes within those packages. |
PhysicalViewFull.doc |
Physical View summary |
Rose model report: component view (also known as Physical View), including Package Name, component name, attached class names with public and private properties (attributes) and methods (operations) and package structure. |
Must have packages and components in the Component View, classes must be attached to the component. |
PhysicalViewPublic.doc |
Physical View with Public Operations and Attributes |
Rose model report: component view. |
Must have packages and components in the Component View, classes must be attached to the component. |
PhysicalViewSimple.doc |
Components in the Model and their associated Classes |
Rose model report: physical view (with packages, components, and classes) and package structure with component views. |
Must have packages and components in the Component View, classes must be attached to the component. |
RUP Actor Report.doc |
Rational Unified Process Actor Report |
Actor report: brief description, characteristics, relationships, and state diagram. |
External generation: Requires the Model (name and path), Parent Package, and Class (Actor) name. Rose Tight Integration: Select the Actor, either in the Class Diagram or in the Browser, then run the SoDA Report. |
RUP Business Entity Report.doc |
Rational Unified Process Business Entity Report |
Business entity report for a class: brief description, responsibilities, relationships, operations, attributes, state and class diagrams. |
External generation: Requires the Model (name and path), Parent Package, and Class name. Rose Tight Integration: Select the Class, either in the Class Diagram or in the Browser, then run the SoDA Report. **Only Operations stereotyped as <<responsibility>> are documented in the Responsibility Section. |
RUP Business Object Model Survey.doc |
Rational Unified Process Business Object Model Survey |
Business object model survey. |
Must have a package called "Business Object Model" in the Logical View. **Only classes stereotyped as <<business worker>> or <<business entity>> are documented in the Member Business Worker or Entities sections. |
RUP Business Use Case Model Survey.doc |
Rational Unified Process Business Use Case Model Survey |
Business use-case model survey of actors, business use cases (including use-case diagrams), and views. |
Must have a package in the Use Case View called Business Use-Case Model. External generation: Requires the Model (name and path), package name, and use case name. Tight Integration: Select the Business Use-Case, either in the Class Diagram or in the Browser, then run the SoDA Report. **Only classes under this package, stereotyped as <<business actor>>, are documented in the Business Actor section. **Only use-cases under this package, stereotyped as <<business use-case>>, are documented in the Business Use-Case section. |
RUP Business Use Case Realization Report.doc |
Rational Unified Process Business Use Case Realization Report |
Use case realization report: brief description, flow of events, interaction diagrams, participating business objects, class diagrams, and derived requirements. |
External generation: Requires the Model (name and path), Parent Package, and Use Case name. Tight Integration: Select the Use Case, either in the Use Case Diagram or in the Browser, then run the SoDA Report. |
RUP Business Worker Report.doc |
Rational Unified Process Business Worker Report |
Business worker report for a class: brief description of class, responsibilities, relationships, operations, attributes, competence requirements, state and class diagrams. |
External generation: Requires the Model (name and path), Parent Package, and Class name. Tight Integration: Select the Class, either in the Class Diagram or in the Browser, then run the SoDA Report. Retrieves External Word Docs into the Responsibilities and Competence Requirements sections. You must begin the file name with "Responsibilities" or "Competence". Note: External document file names are case sensitive. |
RUP Class Report.doc |
Rational Unified Process Class Report |
Class report: brief description, responsibilities, operations, attributes, relationships, and state diagram. |
External generation: Requires the Model (name and path), Parent Package, and Class name. Tight Integration: Select the Class, either in the Class Diagram or in the Browser, then run the SoDA Report. Only Operations, stereotyped as <<responsibility>>, are documented in the Responsibility Section. |
RUP Design Model Survey.doc |
Rational Unified Process Design Model Survey |
Design model hierarchy with classes, packages, and class diagrams at each level. |
A package called "Design Model" must exist in the Logical View. |
RUP Package Report.doc |
Rational Unified Process Package Report |
A package report that includes: public interface classes, with operations; class diagrams; subpackages; and public classes |
Requires a Rose model that contains one or more packages. |
RUP Software Architecture Document.doc |
Rational Unified Process Software Architecture Document |
Software architectural representation, goals, and constraints. Includes architecturally significant aspects of the views: use case, logical, process, deployment, and implementation. Logical view includes model elements, package and subsystem layering. Sections on size, performance, and quality are manually maintained. |
This template works best when the model is structured as described in the Rational Unified Process, Rose Model Template. Section 5 requires a package named "Use Cases" under the Use Case View and a diagram with "Significant" in the name. Section 6.2 requires a Class Diagram with "Layering" in the name. Section 7 requires a package under Logical View named "Process View." Section 9 requires a subsystem named "Implementation Model." |
RUP Use Case Model Survey.doc |
Rational Unified Process Use Case Model Survey |
Use-case model survey of actors, use cases (including use-case diagrams), and views. |
Requires a package under Use Case View named "Use-Case Model." Only classes, stereotyped as <<actor>>, are documented in section 2, Actors. |
RUP Use Case Realization Report.doc |
Rational Unified Process Use Case Realization Report |
Use case realization report: brief description, flow of events, interaction diagrams, participating objects, class diagrams, and derived requirements. |
External generation: Requires the Model (name and path), Parent Package, and Use Case name. Tight Integration: Select the Use Case, either in the Use Case Diagram or in the Browser, then run the SoDA Report. |
RUP Use Case Report.doc |
Rational Unified Process Use Case Report |
Use case report: relationships, with diagrams: use-case, interaction, state, class. |
External generation: Requires the Model (name and path), Parent Package, and Use Case name. Tight Integration: Select the Use Case, either in the Use Case Diagram or in the Browser, then run the SoDA Report. A Word document must exist for the Use Case Specification (this has the Title page, TOC, etc.) Only inherited relationships, stereotyped as <<uses>> or <<extends>>, are documented in either Uses or Extends Relationship sections.
|
RUP User-Experience Storyboard Report.doc |
Rational Unified Process User-Experience Storyboard Report |
User-experience storyboard report: brief description, storyboard flow of events, usability requirements, references to user interface prototype, interaction diagrams, participating objects, class diagrams. |
Requires a Rose model and a related use case. |
Use Case Model Survey.doc |
Use Case Model Survey |
Use-case model survey of actors, use cases (including use-case diagrams), and views. |
Only classes, stereotyped as <<actor>>, are documented in section 2, Actors. |