Developing and Deploying Siebel Business Applications > Introducing the Business Case >

Sample Project Design Documentation

The types of documents listed in this section capture the business requirements and detailed design of NREC's Siebel solution. These documents are outputs of the design stage of the Siebel eRoadmap implementation methodology. They define the scope of the solution and document the detailed specifications needed for configuration.

Design documentation is a critical part of an implementation. Customers can submit these documents to Oracle's Siebel Expert Services for a design review. If documents are not submitted or the templates are not used to guide them through the documentation process, the customer may omit important information and reduce the value of the review.

The types of documents used to capture the design are:

• Entity Relationship Diagram. This type of diagram (see Figure 3) shows the relationships between the major entities that are part of NREC's solution. Entities include object definitions such as business components and business objects.
• Business Component Design. The business component design template is used to define the properties of business components, including the user properties, joins, single-value fields, multi-value fields, and multi-value links.
• Business Object Design. The business object design template is used after business components are designed. The template groups business components and identifies links between business components. This indicates the parent and associated child records in the user interface.
• Applet Design. Applet designs are created after the implementation team decides what entities to track in their Siebel applications. Applet designs are reference documents created for each applet. They comprehensively document an applet's properties, the fields that are available on the applet, and the properties associated with each field. They must also include a mock-up or screen shot of the applet.
• View Design. View design documentation must show what applets are part of the view definition, identify any special visibility associated with a view, for example, a My Team's View or an All View. It must also document how the user navigates through the views using drilldowns, view tabs (third-level navigation), or the Site Map.
• Screen Flow. The screen design template lists the views available from each screen and indicates the default view for each screen.
• Report Design. Report templates track key information relating to reports. The report template includes the business component, Actuate file used, whether the report is dynamic or static, and any subreports available.
• Workflow Policies. Workflow Policy templates gather the key information needed to create workflow rules.
• Assignment Rules. Assignment Manager templates gather the key information needed to create assignment rules.
• Testing Strategy Document. The Testing Strategy Document identifies key project objectives and provides a structure for tracking progress. Without proper planning you may perform either too much or too little testing.
• Test Cases Document. Includes test cases based on approved technical designs. The written test cases can also serve as blueprints for developing automated test scripts. Test cases must be developed with strong participation from the business analyst to understand the details of usage and corner use cases.