U.S.

Department of Education Federal Student Aid

Detailed Design Document Template

[Version Number (x.xx)]

[Final/Draft]
[Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Document Version Control

Document Version Control

Version Date [TBD] [TBD] Description

[Version Number (x.xx)]

[Version Number (x.xx)]

[Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Document Version Control

Table of Contents
Detailed Design Document Template..............................................................................................v Executive Summary......................................................................................................................viii Section 1. Introduction.....................................................................................................................1
1.1 PURPOSE..................................................................................................................................................................1 1.2 SCOPE.....................................................................................................................................................................1 1.3 INTENDED AUDIENCE.................................................................................................................................................1 1.4DOCUMENT ORGANIZATION.........................................................................................................................................2 1.5REFERENCES AND RELATED DOCUMENTS......................................................................................................................2

Section 2. <Project Name> Solution Overview...............................................................................3

2.1FUNCTIONAL REQUIREMENTS OVERVIEW.......................................................................................................................3 2.2HIGH LEVEL COMPONENT MODEL...............................................................................................................................3 2.2.1Component Diagram.....................................................................................................................................3 2.2.2Component Descriptions...............................................................................................................................4

Section 3. Key Design Decisions....................................................................................................5 Section 4. Application Framework..................................................................................................6 Section 5. Package Extension and Modification Designs................................................................7 Section 6. User Interface Design.....................................................................................................8
6.1INFORMATION ARCHITECTURE......................................................................................................................................8 6.2USER INTERFACE APPLICATION ARCHITECTURE..............................................................................................................8 6.3USER INTERFACE SCREENS..........................................................................................................................................8 6.4USER INTERFACE TECHNICAL COMPONENTS...................................................................................................................9 6.5DEVELOPMENT ARTIFACTS LIST...................................................................................................................................9 6.6OTHER DESIGN CONSIDERATIONS...............................................................................................................................10

Section 7. Data Movement Interfaces and Conversions................................................................11

7.1<INTERFACE OR CONVERSION NAME>........................................................................................................................11 7.1.1Overview.....................................................................................................................................................11 7.1.2Design Approach.........................................................................................................................................12 7.1.3Logical Design............................................................................................................................................12 7.1.4Data Flow Diagram and Narrative.............................................................................................................12 7.1.5Data Sources and Targets...........................................................................................................................12 7.1.6Lookups and References..............................................................................................................................12 7.1.7Data Mapping, Transformations and Formatting......................................................................................13 7.1.8Component Detailed Design and Framework Extensions..........................................................................13 7.1.9Supporting Scripts.......................................................................................................................................13 7.1.10Error Handling, Logging, Monitoring and Recovery...............................................................................13 7.1.11Interface Design Considerations...............................................................................................................14 7.1.12Interface Configurations...........................................................................................................................15 7.1.13Interface Deployment Considerations.......................................................................................................16 7.1.14Unit Test Verification for <interface name>............................................................................................16 7.2<INTERFACE OR CONVERSION NAME>........................................................................................................................16 7.2.1Overview.....................................................................................................................................................16 7.2.2Design Approach.........................................................................................................................................16 7.2.3Logical Design............................................................................................................................................16 7.2.4Data Flow Diagram and Narrative.............................................................................................................16 7.2.5Data Sources and Targets...........................................................................................................................16 ii

[Version Number (x.xx)]

[Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Table of Contents

7.2.6Lookups and References..............................................................................................................................16 7.2.7Data Mapping, Transformations and Formatting......................................................................................17 7.2.8Component Detailed Design and Framework Extensions..........................................................................17 7.2.9Supporting Scripts.......................................................................................................................................17 7.2.10Error Handling, Logging, Monitoring and Recovery...............................................................................17 7.2.11Interface Design Considerations...............................................................................................................17 7.2.12Interface Configurations...........................................................................................................................17 7.2.13Interface Deployment Considerations.......................................................................................................17 7.2.14Unit Test Verification for <interface name>............................................................................................17

Section 8. Common Application Services.....................................................................................18 Section 9. Persistence Layer..........................................................................................................19

9.1PERSISTENCE LAYER COMPONENT DESIGNS.................................................................................................................19 9.2TRANSACTION DESCRIPTIONS.....................................................................................................................................19 9.3UNIT TEST VERIFICATION FOR PERSISTENCE LAYER COMPONENTS..................................................................................20

Section 10. Data Model..................................................................................................................21

10.1LOGICAL DATA MODEL..........................................................................................................................................21 10.2PROCESS DATA USAGE (CRUD)............................................................................................................................21 10.3PHYSICAL DATA DESIGN........................................................................................................................................21 10.4TECHNICAL TRANSACTION MAP...............................................................................................................................21

Section 11. Enterprise Services......................................................................................................23 Section 12. Use Case Walk Through.............................................................................................24
12.1<USE CASE NAME> USE CASE REALIZATION...........................................................................................................24 12.1.1Component Interaction..............................................................................................................................24 12.1.2Walkthrough Narrative.............................................................................................................................24 12.2<USE CASE NAME> USE CASE REALIZATION...........................................................................................................24 12.2.1Component Interaction..............................................................................................................................24 12.2.2Walkthrough Narrative.............................................................................................................................24

Section 13. Design Considerations................................................................................................25

13.1PROTOTYPE(S).......................................................................................................................................................25 13.2PERFORMANCE.......................................................................................................................................................25 13.3RELIABILITY AND AVAILABILITY..............................................................................................................................25 13.4MAINTAINABILITY..................................................................................................................................................26 13.5SERVICEABILITY.....................................................................................................................................................26 13.6PRIVACY...............................................................................................................................................................26 13.7SECURITY.............................................................................................................................................................27 13.8ACCESSIBILITY......................................................................................................................................................27 13.9GLOBALIZATION.....................................................................................................................................................27

Section 14. Configuration.............................................................................................................28 Section 15. Physical Packaging....................................................................................................29 Appendix A: Acronyms and Abbreviations.....................................................................................2 Appendix B: Glossary......................................................................................................................2

List of Figures

[Version Number (x.xx)]

iii

[Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Table of Contents

There are no figures in the document.

List of Tables
Table 0-1: Intended Audience and Document Uses......................................................................vii Table 1-2: Intended Audience and Document Uses........................................................................1 Table 2-3: High Level Component Diagram Description................................................................4 Table 3-4: Key Design Decision Format.........................................................................................5 Table 7-5: Error handling, Logging and Monitoring Information.................................................14 Table 7-6: Key Interface Non-Functional Requirements...............................................................14 Table 9-7: Transactions Table.......................................................................................................20

[Version Number (x.xx)]

iv

[Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Project Name

Detailed Design Document Template

[Note: Text enclosed in square brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author and should be deleted before publishing the document. A paragraph entered following this style will automatically be set to normal (style=Body Text).]

[TEMPLATE GUIDANCE Light-blue text is explanatory and should be deleted from the final document. Before you start filling out the content of the new document, go to File/Properties/Custom. Enter the Document Name, Version Date (in DD/MM/YYYY format), and Version Number (in x.x format) in the custom properties that bear these respective names. In the document, press CTRL+A, then F9, and click OK. Go into every footer for each section, press CTRL+A, then F9, and click OK. If a section marked Optional is deemed unnecessary or inapplicable to the document, the section should be retained and the content for the section should be Not applicable. Body Text The text in the document is the body text style, TNR (Times New Roman) 12, color-black; leftjustified. Numbered Lists (for Sections): Numbering for lists should follow the [lower-case letter].[number].[number] pattern. All levels in the list will be flush-left with the main text in the section. Example: 1. List item a. List item i. List sub-item

Bulleted Lists (Do not change the font once it is set) Bulleted Lists: Level 1 bullets should be Symbol 9 (Format, Bullets & Numbering, Customize, Font-Symbol, Size-9) for level 1 of indentation black bullet symbol (Two spaces in between bullet and first letter of sentencesee ruler at top of document.) Indent first bullet three spaces from left margin.)

Detailed Design Document Template

Project Name

Level 2 bullets should be dash symbol for level 2 of indentation. (FontSymbol, Size-9.) (Two spaces in between bullet and first letter of sentencesee ruler at top of document.) Indent second bullet three spaces from start of Level 1 bullet.

Level 3 should be open bullet symbol for level 3 of indentation. (Font-Symbol, Size-9) (Two spaces in between bullet and first letter of sentencesee ruler at top of document.) Indent level 3 bullets three spaces from start of Level 2 bullets.

Page setup: Margins: 1 inch Top, Bottom, Left, and Right; From Edge= .5 header, .5 footer. Section Style Data: Sections should start on their own page. Heading 1

Font: Arial 16 pt., bold, black Paragraph spacing: 12 pt spaces Before, 18 pt After Keep with next, Level 1, Outline numbered, tabs 0.5

Heading 2

Font: Arial 14 pt., bold, black Paragraph spacing: 12 pt spaces Before, 12 pt After Keep with next, Level 2, Outline numbered, tabs 0.5

Heading 3

Font Arial 13 pt, unbold Paragraph spacing: 6 pt spaces Before, 6 spaces After Keep with next, Level 3, outline numbered, tabs 0.5, Indent: 0.5

Numbered Lists (for Sections):

All major section headings (Heading 1) should be in numerical order (e.g., Section 1, Section ...................................................................2, Section 3, etc.) Secondary headings (Heading 2) should be in numerical order (e.g., 1.1, 1.2, 2.1, 2.2, 3.1, ................................................................................................3.2, etc.) Sub-secondary headings (Heading 3) should be in numerical order (e.g., 1.1.1, 1.1.2, 2.1.2, ...................................................................2.1.3, 3.1.1, 3.1.2, etc.)

Tables You may utilize a few styles for table text and table headings.

Detailed Design Document Template

Project Name

Caption: Table Caption Heading style: Arial Bold, TNR 12, paragraph spacing 18 pt Before, 3 pt After Table Heading: Arial 11, Bold, paragraph spacing 18 pt Before, 3 pt After Table Text: Can vary from TNR 9-11 (because documents can vary in size and length, the author may choose which is suitable for his/her document) (The author may choose from Table Text 9, Table Text 10, and Table Text 11 styles.) Bullets within tables: Font of bullet is 6 pt; bullet position: indent at .1, text position: indent at .15 Table 0-1: Intended Audience and Document Uses
Users Relevant Sections
table text TNR 10 table text is TNR 10

Uses
table text is TNR 9 table text is TNR 9

table text TNR 11 table text TNR 11

Headers The header contains the title of the document on the left, and the section on the right. How to add section titles in the header: 1. Create a section break in the page ahead of the page of the header you want to change. 2. Click View, Headers and Footers. 3. Put your cursor in the header. Ensure that Same as Previous is turned off. 4. Click Insert, Cross-Reference. a. In the drop-down box, ensure it states Heading and that the Insert Reference To states Heading Text; then, select the heading in the dialog box that reflects the heading you want to insert. b. Click Insert. Footers The footers contain the version number of the document on the left, page numbers in the middle, and the version date on the right. (Regarding version numbers, keep the numbering system to a 1.1, 1.2, etc., and 2.1, 2.1, etc. (For in-house, you may use alternate numbering systems like 1.1.1 and so forth.)

Detailed Design Document Template

Executive Summary

Executive Summary
[Optional A one-page high-level introduction describing, in brief: Document purpose Document users Document uses (what, when, how) Document owners Document main point of contact for questions or feedback]

[Version Number (x.xx)]

viii

[Version Date (MM/DD/YYYY)]

Detailed Design Document

Section 1. Introduction

Section 1. Introduction
[This section, including all sub-sections except intended audience, is mandatory. This information is provided in every Federal Student Aid deliverable in the Work Products Guide. This part of section one should capture background information on the project and this detailed design to provide background and context to the reader. The remaining sub-sections of the introduction should provide the purpose, scope, and the intended audience for this design document, as well as the document organization and a list of document references for any documents supporting this design or referred to in this design document.] [GENERAL DETAILED DESIGN TEMPLATE GUIDANCE: Detailed Design document contents are typically specific to the system being designed and the technologies being utilized. This detailed design template provides foundation for detailed design documents working with the core Federal Student Aid technologies. However, any given project may need to significantly alter this template based on the specific solution being designed, package being implemented or tools being utilized. Therefore, this detailed design template may be customized on a design by design or project by project basis. Any changes should be reviewed and agreed upon by the project team and the Federal Student Aid Technical Architecture Support Services (TASS) team. Obtaining buy-in on the details of a customized template ensures all parties agree the necessary information will be captured at an appropriate level of detail, thereby enabling Federal Student Aid to effectively evaluate the detailed design. Additionally, the technical quality control review criteria must be adjusted to account for agreed upon changes to the template.]

1.1 Purpose
[This section defines the intended goals of this design document.]

1.2 Scope
[This section provides a brief description of the boundaries of this design document, what this design document applies to, and what is affected or influenced by this design document.]

1.3 Intended Audience

[Optional. The table below lists the intended users for the Detailed Design Document, the document sections most relevant for each type of user, and the purpose for which the users may utilize the information in this document.] Table 1-2: Intended Audience and Document Uses
Users Relevant Sections Uses

table text is TNR 10 table text is TNR 10

[Version Number (x.xx)]

table text is TNR 10 table text is TNR 10

1

table text is TNR 10 table text is TNR 10

[Version Date (MM/DD/YYYY)]

Detailed Design Document

Section 1. Introduction

1.4 Document Organization

[This document comprises the following sections. Section 1 - Introduction: [Description] Section 2 - [Section Name]: [Description] [] Appendix A Acronyms and Abbreviations Appendix B Glossary Appendix C - Placeholder for document-related appendix]

1.5 References and Related Documents

[This subsection should provide a complete list of all documents referenced elsewhere in the Detailed Design Document. Each document should be identified by title, report number (if applicable), date, and publishing organization. Specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document.] [References for the Detailed Design Document template are: Federal Student Aid, Work Products Guide, the most recent version may be obtained from the Enterprise Integration Services team. Federal Student Aid, Enterprise Service Model, the most recent version may be obtained from the Technical Architecture Support Services team. Federal Student Aid, Exemplar Preliminary Design, Version 1.8, August 26 2008. Federal Student Aid, Exemplar Detailed Design, Version 1.4, October 2, 2008. Federal Student Aid, Exemplar Interface Control Document Person Updates from CPS to PRMS, Version 1.1, October 1, 2008.]

[Version Number (x.xx)]

[Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Section 2. Overview

Section 2. <Project Name> Solution Overview

[This section is mandatory. This section is intended to provide a summary of the solution and its components based on the information preliminary design. If the solution is being broken up into multiple detailed design documents, this section should illustrate the components in scope for this detailed design document in the context of the entire solution. One way to achieve this is to provide some narrative identifying the solution area(s) in scope for this particular detailed design document, followed by a requirements overview identifying the requirements relevant to the functionality in scope for this detailed design document, followed by the component model in scope for this detailed design document. Please refer to the exemplar detailed design document for an example of this section. Note that in the case of the exemplar detailed design document, components were not broken out into separate detailed design documents. However, only select functionality was covered as part of the example detailed design. The exemplar overview section identifies the functionality in scope for the exemplar detailed design document. The requirements overview then identifies the use cases that pertain to the in scope functionality.]

2.1 Functional Requirements Overview

[This section should summarize the functional requirements in scope for this detailed design document. If the detailed design is broken up into multiple documents, this summary should consist of the subset of the requirements over provided in the preliminary design document which is in scope for this detailed design document.]

2.2 High Level Component Model

[This section should provide a component model to demonstrate the components in scope for this detailed design document. This component model may be largely based on the component model provided in the preliminary design document. If the detailed design is broken up into multiple detailed design documents, the component model information provided her should provide information on the components in scope for this particular detailed design document.]

2.2.1

Component Diagram

[This section should contain the component diagram identifying the components in scope for this detailed design document. If this document is one of multiple detailed design documents for this solution, it may be helpful to the reader to provide a high level component diagram depicting the entire solution, and identifying which component(s) from the high level diagram are in scope for this document. This could then be followed by a lower level component diagram illustrating further detail on the component within the scope of this detailed design document.]

[Version Number (x.xx)]

[Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Section 2. Overview

2.2.2

Component Descriptions

[This section should communicate the description information supporting the component diagram. An example of a table that may be used to capture the description information is below.] Table 2-3: High Level Component Diagram Description Component Description Services Provided

[Version Number (x.xx)]

[Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Section 3. Key Design Decisions

Section 3. Key Design Decisions

[The intent of section is to document the key decisions and the rationale for those decisions governing the detailed design of the solution. The format may be largely the same as the Architectural Decisions documented in the preliminary design. However the decisions documented here are often at a lower or more detailed level, and reflect issues that came up during the detailed design activities. A sample table to capture the information is provided below. Please refer to the exemplar detailed design document for an example of this section. ] Table 3-4: Key Design Decision Format Subject Area Design Decision Issue or Problem Assumptions Motivation Alternatives Decision Justification Implications Derived requirements Related Decisions Topic AD ID

[Version Number (x.xx)]

[Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Section 4. Application Framework

Section 4. Application Framework

[This section is mandatory, unless the project can successfully make the case that it doesnt apply to this design. In the case where multiple detailed design documents exist for a single system, this section is mandatory for at least one of the detailed design documents, preferable the primary, or core detailed design document. The intent of this section is to capture detailed design information describing the overall framework of the application. This applies to custom applications as well as packaged implementations. In the case of a packaged implementation, this section may be providing information which the vendor has already documented, in which case the appropriate vendor documents may be referenced here. The overall framework of the application may be communicated using a combination of sequence diagrams and narratives, class diagrams, class descriptions or other detailed dynamic and static views of the system. A unit test verification section is required to detail the following: Unit testing involves testing each feature in a given component to ensure that each component is coded to meet the design and requirements. The intent of this section is to describe what will be unit tested and how. This section should list: The components to be tested What will be verified for each component How will each component be tested Please refer to the Exemplar Detailed Design Document for an example of this section.]

[Version Number (x.xx)]

[Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Section 5. Package Extension and Modification Designs

Section 5. Package Extension and Modification Designs

[This section is mandatory for in cases where a package is being extended or modified. In this context a package extension is defined as adding or customizing package functionality in a manner supported by the vendor. This is usually achieved through some sort of scripting or programming that does not change the base application code provided by the vendor. This does not include configuring the package, which should be captured in the configurations section of this document. Package modifications are generally defined as making changes to the package base code, which is typically not supported be the vendor. These types of changes often create issues and incur extra work during the application of vendor supplied patches or during a package upgrade. The manner in which the extensions and/or modifications are documented is somewhat dependent on the package and technologies being used. If there are standard methods of documenting such changes for the package being implemented, in most cases those methods should be utilized here. Finally, a unit testing verification section detailing the following is required: The components to be tested What will be verified for each component How will each component be tested Please refer to the exemplar detailed design document for an example of package extension detailed designs using Java and UML techniques.]

[Version Number (x.xx)]

[Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Section 6. User Interface Design

Section 6. User Interface Design

[This section is mandatory for any projects developing a user interface. The main intent of this section is to communicate the user interface related detailed design information necessary to allow the user interface detailed design consumers, such as development and testing staff, to perform their jobs in the subsequent phases of the project.]

6.1 Information Architecture

[This section should provide a high level overview of the information architecture. In the future, a User Interface Specification document template will be available to capture detailed Information Architecture and wire frame type information. This section may reference that document for more detail. However, if the user interface has relatively few screens, it may make sense to capture all of the information architecture information in this document. This section should generally contain: The high level overview of the information architecture may reference the future User Interface Specification document for more detailed information. A graphical depiction of any screens and how they flow High level components of each page, such as Portlets, JSF or style sheets, where applicable. This information may be largely driven by the technologies selected to implement this user interface. Please refer to section 6.1 of the Exemplar Detailed Design Document for a WebSphere Portal based example of this section.]

6.2 User Interface Application Architecture

[This intent of this section is to provide the overall user interface technical design information which is common across the user interface portion of the application.]This should include: A description of the overall technical approach to the user interface technical design, and a matching graphical representation of the technical architecture The various technologies as well as design and development standards being utilized in the design and development of the user interface, including how each will be used. Please refer to section 6.2 of the Exemplar Detailed Design Document for a WebSphere Portal based example of this section.]

6.3 User Interface Screens

[This section is intended to provide the technical design of each user interface screen. This section is not intended to provide the mockup for each screen. That information should be captured in the future User Interface Specification document. However, if the user interface has relatively few screens, it may make sense to capture all of the screen design information in this document for simplicity. For each screen, the following should be included where applicable. Any relevant information not identified below should be included where appropriate in communicating the detailed design to the design consumers (developers, testing team, etc.).

[Version Number (x.xx)]

[Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Section 6. User Interface Design

A description and graphical depiction of each screen This section may reference the User Interface Specification document for the graphical representations of each screen. Key attributes of each screen Wiring information for each screen Mapping of applicable data attributes (attributes not captured in components detailed in the following section) Please refer to sections 6.3 and 6.4 of the Exemplar Detailed Design Document for a WebSphere Portal based example of this section.]

6.4 User Interface Technical Components

[This section is intended to provide the detailed design of each user technical component (i.e. portlets) to be developed for the user interface. For each component, the following should be included where applicable. Any relevant information not identified below should be included where appropriate in communicating the detailed design to the design consumers (developers, testing team, etc.). A summary of the technical approach to the detailed design of each component Key attributes of each component A graphical depiction and related information pertaining to any displays created by the component (i.e. Portlet or JSF views) Logical view(s) of the component design, including graphical representation(s) and descriptions of each element (for Portal, this might include items such as Classes, JSFs, CSSs, WSDL files, XML files, Properties files, etc.) Mapping of data attributes Security related information Custom Error information Information for any Helper files (different per technology i.e. Portlet Resource Bundle information, component specific Style Sheet information) Other applicable graphical representations and related information necessary to adequately communicate the detailed design to detailed design consumes (developers, testing team, etc.). This may be largely driven by the technology used in the user interface implementation. Please refer to sections 6.5 - 6.7 of the Exemplar Detailed Design Document for a WebSphere Portal based example of this section.]

6.5 Development Artifacts List

[The intent of this section is to organize and list all artifacts that will be developed during the implementation of this user interface design. These artifacts were mostly likely all detailed in the preceding sections. The intent of this section is to organize to present that list in a manner that allows people to more easily review, estimate and ensure all of the necessary development artifacts have been identified and detailed. The types of artifacts to be listed may be largely driven by the technologies selected to implement the user interface. Please refer to section 6.8 of the Exemplar Detailed Design Document for a WebSphere Portal based example of this section.]

[Version Number (x.xx)]

[Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Section 6. User Interface Design

6.6 Other Design Considerations

[The intent of this section is capture or reference relevant information that did not belong or fit well into Section 6 of this template. Please refer to section 6.9 of the Exemplar Detailed Design Document for an example of this section.]

[Version Number (x.xx)]

10

[Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Section 7. Data Movement Interfaces and Conversions

Section 7. Data Movement Interfaces and Conversions

[This section is mandatory for any project with data movement interfaces or conversions within the scope of the project. This section should provide a detailed design for each data movement interface or conversion necessary to support the external system interfaces and conversions identified in the preliminary design context model. In this context an interface is generally defined as an on-going data movement from a source system to a target system. A conversion is generally defined as a data movement from a source system to a target system which is typically a one-time data migration, also sometimes referred to as an initial data load. In most cases, each Interface Control Document will result in an associated interface or conversion detailed design. Depending on the project and the number of interface detailed design required, this section may be broken out into a separate detailed design document, or even a detailed design document for each interface or conversion. In the case where all interface detailed designs were captured in this single section, ideally there would be a level 2 sub-section for each interface detailed design, repeating the subsections below for each interface detailed design (i.e. 6.1 Person Updates from PRMS to COD, 6.2 Person Updates from PRMS to NSLDS, 6.3 Persons Updates from CPS to PRMS, etc.). The subsections of this document may need to be customized based on the integration tools being utilized for given interfaces. Please refer to the exemplar detailed design for an example of a single batch interface detailed design.]

7.1 <Interface or Conversion Name>

[The heading above identifies the interface or conversion that the detailed design in sub-section 7.1 pertains to. Section 7.2 would then contain the detailed design for another interface, and so on. Ideally, the interface or conversion should allow readers to easily understand which element of the preliminary design context model, and which interface control document this detailed design represents. Alternately, it may be valuable to provide a table above this sub-section illustrating the mapping of each interface and conversion detailed design to its associated system context element and interface control document.]

7.1.1

Overview

[This intent of this section is to provide the reader a description of the interface that this detailed design pertains to, highlighting key information from the context model and interface control document, and providing some context with regard to how this interface fits into the application as a whole.]

[Version Number (x.xx)]

11

[Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Section 7. Data Movement Interfaces and Conversions

7.1.2

Design Approach

[This intent of this section is to detail the summary approach to the overall design of this interface or conversion. For instance, sub-section may outline how the data will be provided by the source system, what type of technologies will be used in the interface design (ETL, ftp, MQ, etc.), how the source system will consume the data, key timing or scheduling elements, and any outputs the source system might produce after consuming the data. Please refer to the exemplar detailed design for an example. Note that in the exemplar detailed design there is no approach section. However, the approach is laid out in the single paragraph under section 6.1.]

7.1.3

Logical Design

[This section should contain a logical diagram and associated narrative illustrating the logical interface components and flow from source to target. The diagram should show the source and target system(s), middleware, and other key components to provide readers a general understanding of the interface. This may be as simple as a context diagram depicting the interface program in scope for this document as a black box. Generally, it is effective if the major components in the end-to-end data movement are all depicted here, with the component(s) in the scope of this document highlighted for clarity. For instance, if the source system is a legacy system responsible for producing the input file and moving it to a given location, the diagram may show that for completeness, but also indicate it is not in the scope of this detailed design. Please refer to the exemplar detailed design for and example.]

7.1.4

Data Flow Diagram and Narrative

[This section is optional. Depending on the amount of processing taking place within the interface program, it may be helpful to provide a data flow diagram and narrative for the reader. Where as the Logical Diagram may depict the interface program as a black box, the data flow diagram can provide detail depicting the process flow and decision points taking place within the interface program itself.]

7.1.5

Data Sources and Targets

[While this should have been captured in the interface control document, it is reiterated here for convenience when passing this detailed design to the interface developer. Alternately, this section may reference the interface control document containing this information.]

7.1.6

Lookups and References

[While this should have been captured in the interface control document, it is reiterated here for convenience when passing this detailed design to the interface developer. Alternately, this section may reference the interface control document containing this information. If the required lookups and references were not defined as a part of the interface control document, they must be defined here. Please refer to the interface control document for template instructions.]

[Version Number (x.xx)]

12

[Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Section 7. Data Movement Interfaces and Conversions

7.1.7

Data Mapping, Transformations and Formatting

[While this should have been captured in the interface control document, it is reiterated here for convenience when passing this detailed design to the interface developer. Alternately, this section may reference the interface control document containing this information. If the Data Mapping was not defined as a part of the interface control document, it must be defined here Please refer to the interface control document for template instructions.]

7.1.8 Component Detailed Design and Framework Extensions

[The intent of this section is to capture the detailed design of the interface program internals. This may take very different forms depending on the tools and technologies used to build the interface program(s). It is safe to use the standard method of documentation for the tools and technologies being utilized. In the case of the interface detailed in the exemplar detailed design, the program was written in Java, and this section consisted of sequence diagrams, class diagram, and associated narratives and description information. Please refer to the exemplar detailed design for that example.]

7.1.9

Supporting Scripts

[Often an end-to-end interface or conversion requires various shell scripts, jcl scripts or other types of scripts to support the interface. Any necessary scripts which must be written in order for the interface to function correctly should be identified and described here.]

7.1.10 Error Handling, Logging, Monitoring and Recovery

[The intent of this section is to outline: The list of errors that have been accounted for in the design of this interface Restate the error number and error message information that must be coded into the interface error handling mechanisms Document the recovery methods for each type of error. For instance if the interface is an ETL conversion which experience a fatal error, may the batch job simply by restarted once any identified issues are fixed, or does this batch job required a checkpoint/restart method to start processing where the batch left off, etc. How are the errors logged? Is there a logging framework that applies across interfaces, or must a specific log file be created for this interface? Is there any monitoring necessary to pass failures or other information to the support team? For example, does a log file need to be monitored for specific errors being written to the file? What are the details? Do any queue depths need to be monitored and exactly how? Does a process need to be monitored in case it goes down? Information related to the following tables may have been captured in the Interface Control Document, but may need to be further detailed and finalized in this design:]

[Version Number (x.xx)]

13

[Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Section 7. Data Movement Interfaces and Conversions

Table 7-5: Error handling, Logging and Monitoring Information

Error# ERR1024 Error Message Text Mandatory information not furnished Triggering Condition Required fields not supplied Recovery Options Please indicate what the recovery options are and any special conditions. Remarks

Category Exception handling Exception logging Compensation

Value Please indicate the requirements in case that the interface fails Indicate the log file, error message Indicate conditions how to compensate the interface (retry, re-execute, cancel)

Remarks

Should the process simply be restarted after any issues are resolved? Can the message(s) be re-sent? Is there checkpoint, restart processing that needs to be implemented? Is there parallel processing of data (batch) taking place? What exactly should be monitored and how? What should happen in the event of failure?

Exception Monitoring

List any other exception here Required or Not

7.1.11

Interface Design Considerations

[The intent of this section is to restate key non-functional requirements (i.e. security, availability, capacity, etc.) and demonstrate how the design of the interface supports those requirements. The non-functional requirement related to the table below should have been captured in the associated interface control document or other requirements documentation. However, it may help to restate them here for convenience. Please refer to the to the design considerations section 14 of the exemplar detailed design for a general example of how to document this information.] Table 7-6: Key Interface Non-Functional Requirements
Category Availability Average Volume Exchanged Value Normal the same as infrastructure availability HA Highly Available Estimated volume in normal conditions. For ETL this is typically expressed by number of records per run and an estimate of total size of data per run. For Messaging this is typically
14

Remarks Other pertinent constraints, conditions or observations regarding this requirement. Other pertinent constraints, conditions or observations regarding this requirement.

[Version Number (x.xx)]

[Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Section 7. Data Movement Interfaces and Conversions

Category

Value expressed in number or messages per hour or minute (depending on frequency) and average and maximum message sizes. Estimated peak volume 1. On-Demand, 2. NRT, 3. Daily/Nightly 4. One-Time Load Job Name or Process Name Provide information for required start time (for scheduled interfaces) or state On-request Estimated duration for the execution in normal conditions (Minutes) Estimate the allowable delay for this interface before it has a major impact on business operations or dependent interfaces or process flows. Describe any other procedures, processes or jobs to be executed prior to running this interface, or any other interfaces or jobs are to be initiated after successful or unsuccessful run of the current job. Describe any processes, jobs or interfaces that need to be started after this interface completes (normally or abnormally). Specify Authentication Specify authorization

Remarks

Peak Volume Exchange Frequency

Other pertinent constraints, conditions or observations regarding this requirement. On-demand, Near Real-time, Daily/Nightly, Weekly, Periodically, Data Migration For batch interfaces that will be executed as part of an Job Stream (running in Job Scheduling infrastructure)

Scheduling Start time Estimated duration Allowable delay

Pre-Run-time dependencies

Post-run dependencies Authentication Authorization Other security

7.1.12

Interface Configurations

[Any necessary configurations that must be made in order for the interface to run correctly should be detailed here. This includes items such as configuration files, environment variables, or configurations stored in a database. Each configuration file, variable, constant and value or set of values should be identified here. Ultimately this information will greatly aid those responsible for configuration management and deployments.]
[Version Number (x.xx)] 15 [Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Section 7. Data Movement Interfaces and Conversions

7.1.13 Interface Deployment Considerations

[The intent of this section is to capture any information beyond that captured in the configuration section that may assist those responsible for setting up various environments and deploying the software to those environments (i.e. testing environments, training environment, production environment). Examples of items to consider include: Any database information that must be loaded in advance of running the interface (initial loads) Any dependencies on setup of related jobs (i.e. a SOFT file transfer job) Directories that must be created Users that must be create, including operating system level, database level, etc. User groups or permissions that must be granted to users or directories]

7.1.14

Unit Test Verification for <interface name>

[The intent of this section is to capture: Whom is responsible for unit test How it will be performed, including what any tool that will be used A list of transaction types or scenarios that must be tested in order to verify the interface program is working as designed]

7.2 <Interface or Conversion Name>

[This structure is repeated for each interface or conversion.]

7.2.1 7.2.2 7.2.3 7.2.4 7.2.5 7.2.6

Overview Design Approach Logical Design Data Flow Diagram and Narrative Data Sources and Targets Lookups and References

[Version Number (x.xx)]

16

[Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Section 7. Data Movement Interfaces and Conversions

7.2.7

Data Mapping, Transformations and Formatting

7.2.8 Component Detailed Design and Framework Extensions 7.2.9 Supporting Scripts

7.2.10 Error Handling, Logging, Monitoring and Recovery 7.2.11 7.2.12 7.2.13 7.2.14 Interface Design Considerations Interface Configurations Interface Deployment Considerations Unit Test Verification for <interface name>

[Version Number (x.xx)]

17

[Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Section 8. Common Application Services

Section 8. Common Application Services

[This section is mandatory for solution building common application services. The purpose of this section is to provide the detailed design for the common components that will be built and/or utilized in this solution. Enough detail must be provided in this section to provide developers with an understanding of how to build and utilize these components. This may be achieved through the use of sequence diagrams, class diagram and related narratives and description information, depending on the technologies and tools used for this design. Typical common application services that may be detailed in this section include: Caching Service - a generic component that may be leveraged to temporarily store data in memory in order to speed up the operations of the system Performance Tracking Service a component that my be leverage to monitor given application services to ensure the service is performing at an acceptable level of service Error Handling Services may be leveraged across application component to capture exceptions and generate error messages in a consistent and centrally maintained manner. Logging Framework may be leveraged across application components to handle logging in a consistent, centrally maintained manner. Audit Logging Service a component that may be leveraged to track transactions for audit logging purposes Data Validation Service a service that may be leveraged to validate data inputs into the system. Business Rules Service a service that may be leveraged to store customized business rules, as well as utilize use them to drive internal processes Data Visibility Service a component that may be leveraged to define and apply data attribute level permissions to given users Configuration Management Service a component that may be used to central manage system configuration and control run-time application behavior Additionally, a unit test verification section detailing the following is required: The components to be tested What will be verified for each component How will each component be tested Please refer to the exemplar detailed design for an example of this section.]

[Version Number (x.xx)]

18

[Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Section 9. Persistence Layer

Section 9. Persistence Layer

[This section is mandatory for solutions accessing a data store. The intent of this section is to capture the detailed design of the persistence layer of the application. Typically, the persistence layer consists of the application data store(s) and the components responsible for interactions with the application data store(s). Encapsulation of this functionality enables components such as the user interface or business and domain components to avoid directly accessing the application data store(s), and channels all data stores access through a centrally maintained set of components.]

9.1 Persistence Layer Component Designs

[The contents of this section will vary based on the type of persistence layer being built. A Java based persistence layer detailed design should typically be expressed through sequence diagrams, class diagram, and associated narratives and descriptions. Please see the exemplar detailed design for an example of a documents Java based persistence layer.]

9.2 Transaction Descriptions

[This section is optional. It may be helpful to document the transactions that the persistence layer will manage. The purpose of Transaction Descriptions is to ensure the system adequately enforces data integrity. Specifically, the work product ensures that the developers and database designers understand which database, directory and interface accesses must be grouped together into atomic units. This information is used: To arrange logic into Service classes that implement atomic units of work to which commit and rollback logic can be applied by the framework. To assist with database optimization and performance tuning. To prioritize relative performance of the transactions Note the following architectural requirements of Service designs that apply to transactions: 1. Each service will have only one transaction. 2. If a service requires updates to both database and either a directory or an interface, the database updates must occur first. This is because the directory and interfaces do not support rollback. If the directory / interface invocation fails then the database modification can be rolled back. The following table shows an example of transactions initiated by a service component. There is one transaction per service class. In the table, rows are grouped into a set of operations performed as part of one transaction. The rows are shown in the order that they will be executed.

[Version Number (x.xx)]

19

[Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Section 9. Persistence Layer

Table 9-7: Transactions Table

Transaction Id Service Name Domain Object Operation Comments(Optional)

SV-0XX.1

BasketCheckoutS ervice

BasketItems Basket Basket Order Order

Delete Delete Update Create Submit If all items are deleted If all items are not deleted Multiple orders created SPICS transaction DPO-XXX

9.3 Unit Test Verification for Persistence Layer Components

[Unit testing involves testing each feature in a given component to ensure that each component is coded to meet the design and requirements. The intent of this section is to describe what will be unit tested and how. This section should list: The components to be tested What will be verified for each component How will each component be tested]

[Version Number (x.xx)]

20

[Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Section 10. Data Model

Section 10. Data Model

[This section is mandatory for all systems utilizing a data store. This section largely points to data model deliverables that should have been produced outside of this detailed design specification, but are being utilized by this design. If the required data model deliverables from the list below are not complete, the detailed design of the system cannot be considered complete.]

10.1 Logical Data Model

[This section is mandatory. The logical data model will be captured in a separate deliverable or tool (or both). The intent of this section is to link to or provide simple instructions to access the logical data model(s) relevant to this design. This serves to provide completeness to the detailed design document as well as a convenience to those using or reviewing this detailed design document. The intended work product guide template for the logical data model is currently the Logical Data Model Design and Development v1.0 template.]

10.2 Process Data Usage (CRUD)

[This section is optional. If CRUD (Create, Read, Update, and Delete) matrix wok is performed for the Detailed Design, will be captured in another work product from the Work Product Guide owned by the Enterprise Data Management Team. Currently this information is captured in the Enterprise Data Management Plan template.]

10.3 Physical Data Design

[The physical data model will be captured in a separate deliverable or tool (or both). The intent of this section is to link to or provide simple instructions to access the physical data model(s) relevant to this design. This serves to provide completeness to the detailed design document as well as a convenience to those using or reviewing this detailed design document. The intended work product guide template for the physical data model is currently the Physical Data Model Design and Development v1.0 template.]

10.4 Technical Transaction Map

[This section is optional. The intent of the technical transaction map is to identify the technical profile of the individual business processes that make up the application. Examples of the types of information comprising a technical transaction map for a specific business process are:

[Version Number (x.xx)]

21

[Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Section 10. Data Model

An assessment of the activity by system component (e.g. workstation, application server, database server, etc.) associated with the execution of the business process. This assessment could include: - The number of data retrieval requests by type generated by the process. This could be the number of SQL calls by type (e.g. SELECT, FETCH, UPDATE, etc) issued to the database server, the number of HTML page requests issued to the WEB server, the number of file I/Os by type (e.g. Sequential READ, Random READ, etc.) issued to the file server, etc. - Number of data store requests by type generated by the process. This could be the number of SQL INSERT calls issued to the database server, the number of file Write I/Os issued to the file server, etc. - The processing cost involved in composing, and subsequently post processing the result set data from, the data retrieval requests. This will be estimated from an assessment of the application, middleware, and OS elements of that overall cost. - The processing cost involved in composing the source data associated with the data store requests. This will be estimated from an assessment of the application, middleware, and OS elements of that overall cost. An assessment of the number of message pairs exchanged between the individual system components during execution of the process, along with an estimate of the typical message sizes involved. An assessment of the working set size required by component to support execution of the business process. The technical volumetrics for a given business process are then derived from a combination of the business volumetric information captured within the Non Functional Requirements, along with the technical profile information captured within the Technical Transaction Map for each of those business processes. When producing this information, as in all of the performance estimation activities, it is recommended the 80:20 principle be employed. That is, focus in detail on the key business processes only - those that are high volume, business significant, or complex. These by definition contribute most to the overall system requirements. Each of the non-key processes can then be mapped to a representative candidate from the selected key process list. Without well-understood technical transaction maps, the performance model is unlikely to provide an accurate estimate of the system resource requirements for a bespoke application. In such cases, there is therefore an increased risk that a system based on those requirements will fail to deliver the required level of performance once deployed.]

[Version Number (x.xx)]

22

[Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Section 11. Enterprise Services

Section 11. Enterprise Services

[The intent of the enterprise services section is to: Identify and describe the list of enterprise services this system will utilize. Note that many of the enterprise service may be existing services. Detail how each enterprise service will be called, and how the data will be utilized by the system. For existing enterprise services, a service design does not exist within this document. If possible, documentation for the existing service should be referenced here. This information may generally be documented through static and dynamic UML diagrams and associated narrative and description information. ]

[Version Number (x.xx)]

23

[Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Section 12. Use Case Walk Through

Section 12. Use Case Walk Through

[This section is mandatory. The intent of the Use Case Walkthrough is to demonstrate how the solution fulfills key use cases. Sub-section 12.1 and its sub-sections should be repeated for each use case realization. Please refer to the exemplar detailed design for an example of this section.]

12.1 <Use Case Name> Use Case Realization

[This section should contain a very short description of the use case.]

12.1.1

Component Interaction

[This section should contain a sequence diagram which demonstrates the interaction of the key components involved in realizing the basic flow of the use case from the previous section.]

12.1.2

Walkthrough Narrative

[This section should narrative walking through the diagram in the previous sub-section. The walkthrough should clearly demonstrate how the use case is realized through component interaction.]

12.2 <Use Case Name> Use Case Realization

[This structure should be repeated for each use case realization.]

12.2.1

Component Interaction

[This section should contain a sequence diagram which demonstrates the interaction of the key components involved in realizing the basic flow of the use case from the previous section.]

12.2.2

Walkthrough Narrative

[This section should narrative walking through the diagram in the previous sub-section. The walkthrough should clearly demonstrate how the use case is realized through component interaction.]

[Version Number (x.xx)]

24

[Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Section 13. Design Considerations

Section 13. Design Considerations

[The intent of this section is to illustrate how the system was designed to meet key non-functional requirements, and to describe any compromises/choices, if any, made in the course of the design. For example, choosing between using more memory space vs. using more disk space; performance vs. complexity of code, and so on. What rationale was used for the current design? Were other design alternatives considered? If so, identify them and explain why this design approach was chosen. Suggested areas to address are prototypes (or proof of concept), performance, availability, reliability, maintainability, serviceability, privacy, security, accessibility and globalization. Please refer to the exemplar detailed design for an example of this section.]

13.1 Prototype(s)
[Describe what prototypes or proof of concepts, if any, were used in developing this design, and how was it used in making design decisions.]

13.2 Performance
[Describe the major characteristics of the software that impact the design, as well as the target performance constraints. Example items to discuss are: Discuss the performance significance for this function (critical, unimportant, etc.) Describe the high-level performance characteristics of this system (change to existing function, new function) List and discuss the specific performance goals including metrics by which it could be measured What is being done to optimize the performance of this design/implementation? List and discuss any performance considerations or open questions that need to be addressed Describe how the Number of users, Number of elements, etc. may affect performance What profiling should be done? What statistics need to be collected? Describe network performance, system performance, throughput, utilization (memory, CPU), etc.]

13.3 Reliability and Availability

[Describe the design points that are associated with the reliability and availability of the design elements.
[Version Number (x.xx)] 25 [Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Section 13. Design Considerations

Example items to discuss are: Under what (external as well as internal) conditions are design elements likely to experience failure? How will the failure manifest itself to the user? How does the design recover from or work around failure conditions? What instrumentation is needed to isolate failing areas or to diagnose failure conditions? Redundancy Events, Notifications and Exceptions: Specify what events or notifications are consumed or produced by the design elements. Exception handling can also be unusual conditions, but not necessarily error conditions.]

13.4 Maintainability
[Describe the concepts that will enable the design elements to be easily maintained. Example items to discuss are: Modularity and Reuse: Describe the modularity of the resulting implementation, componentization of this design, design considerations for reuse of this design, reuse of other components for this design, etc. Conversion/Reversion (Backward Compatibility): Conversion/Reversion refers to any meta-data whose structure may need to change in support of the version or release defined by this design document. For instance, consider a database that represents an inventory of files. If the record layout in that database needs to be converted to a new format, how is that conversion accomplished? Will it be automatically done upon first use of the new version? If the customer needs to revert to an earlier version of the product or component, how is that record layout converted back (reversion)? ]

13.5 Serviceability
[Describe the design points needed in order to enable design elements to be easily serviced once its available for external use. Example items to discuss: How will the user know or determine design element failures and report it to service organizations?]

13.6 Privacy
[Privacy is about purpose-based access control to Personal Information. Whereas security provides general access control to data, Privacy relates to particular pieces of data. In this section, describe who has access to see certain parts of your data and what methods are used to ensure that they are the only ones who can access it.]

[Version Number (x.xx)]

26

[Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Section 13. Design Considerations

13.7 Security
[Use this section to illustrate how the overall design accommodated security requirements such as authentication and authorization requirements.]

13.8 Accessibility
[Use this section to identify if accessibility requirements were met. Section 508 of the US Rehabilitation Act requires that all federal government agencies purchase accessible solutions unless none exist. ]

13.9 Globalization
[Indicate whether design elements will be enabled for National Language Support. Consider all externals, such as messages, commands, panels, and documentation. Describe how design element will be enabled to support its use in other languages and customs. Identify what languages or groups of languages are supported.]

[Version Number (x.xx)]

27

[Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Section 14. Configuration

Section 14. Configuration

[Specify all configuration parameters used within this detailed design. This may consist of a combination of items such as:

A list of all configuration files, the configurations available within each file, and a description of the options available Any configuration or metadata stored in database tables that must be setup in order for the application to run as desired Any environment variables or constants that need to be created and/or set to specific values Any product configurations such as Oracle performance tuning settings or WebSphere ESB configurations that must be made. Any users (application users, database users, operating system level users, etc.) or directories that must be created, including user groups and permission settings that must be configured in order for the application to function correctly.

In some cases, some configuration information may be captured in separate documents. Those documents should be referenced here. Additionally, and other deployment related setup information which may be helpful to those charge with creating and deployment new environments (i.e. testing, training, production) may be captured here. Example of items to capture here are:

What things will aid the testing effort? Dependencies Test Data requirements Other environment related setup requirements

Please refer to the exemplar detailed design document for an example of this section.]

[Version Number (x.xx)]

28

[Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Section 15. Physical Packaging

Section 15. Physical Packaging

[Specify packaging requirements for the module. Examples of the types of items documented as part of the physical packaging:

Build instructions List of installation files (i.e. WAR, EAR files, stubs, etc.) Database create (DDL) scripts]

[Version Number (x.xx)]

29

[Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Appendix A Acronyms and Abbreviations

Appendix A Acronyms and Abbreviations

Guidance: Insert a cover page before each Appendix. (Heading 7, TNR 12, centered, paragraph spacing 156 pt before.)

[Version Number (x.xx)]

A-1

[Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Appendix A Acronyms and Abbreviations

Appendix A: Acronyms and Abbreviations

[List all the acronyms used in the document. Example:
Acronym COD CPS DDL ETL FTP HA HTML I/O JSP NRT NSLDS SOFT SQL OS PRMS UML Definition Common Originations and Disbursements Central Processing System Data Definition Language Extract, Transform and Load File Transfer Protocol High Availability Hyper Text Markup Language Input/Output Java Server Page Near-Real Time National Student Loan Data System Service Oriented File Transfer Structured Query Language Operating System Person record Management System Unified Modeling Language

Guidance on additional appendices:

Additional Appendices should be in sequence to the previous (e.g., Appendix A, B, C, D, etc.) A and B are reserved for Acronyms and a Glossary, and any appendices after that are document-specific. Footers: restart page numbering (e.g., if you create an Appendix D, the page numbers in the footers should read D-1, D-2, etc.) Describe all associated terms for this project / document / methodology, etc.]

[Version Number (x.xx)]

A-2

[Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Appendix B - Glossary

Appendix B - Glossary

Guidance: Insert a cover page before each Appendix. (Heading 7, TNR 12, centered, paragraph spacing 156 pt before.)

[Version Number (x.xx)]

B-1

[Version Date (MM/DD/YYYY)]

Detailed Design Document Template

Appendix B: Glossary
[List all the glossary terms used in the document. Example:
Term Common Origination and Disbursement (COD) Definition Initiative designed to put in place more common processes across financial aid programs. FSAs participating schools use a common process, platform, and record to originate and disburse Title IV federal aid funds. Funding request document describing the business case for an investment, financials, performance measures, SRM and TRM mappings. Short for File Transfer Protocol, the protocol used on the Internet for exchanging files. FTP works in the same way as HTTP for transferring Web pages from a server to a users browser and SMTP for transferring electronic mail across the Internet in that, like these technologies, FTP uses the Internets TCP/IP protocols to enable data transfer. FTP is most commonly used to download a file from a server using the Internet or to upload a file to a server (e.g., uploading a Web page file to a server). Integrated Technical Architecture (ITA) Infrastructure that will reduce the number of stove piped applications within FSA that are costly to update. FSA applications use this infrastructure to reduce performance bottlenecks and resolve issues. The Work Products Guide seeks to provide project managers with access to a knowledge base of guidelines, procedures, and templates for all critical project activities.

Exhibit 300

FTP

Work Products Guide

[Version Number (x.xx)]

B-2

[Version Date (MM/DD/YYYY)]