Designing a TDD – Technical Design Document
I would like to share my views on Technical Design Document helpful developing a Project.
TDD – Technical Design Document :
In the process of initiating a Project, one the important document is TDD. Here I would like to share the basic steps followed by most of the clients to prepare a TDD.
The TDD would help the consultants to start technically working on the SAP System to build required Objects.
Most of the times, this TDD can be in MS WORD or MS EXCEL explaining all the important guidelines to start the Project.
Majorly titled Tabs in Excel sheet are listed below:
- · Version Control
- · Document Title
- · Document Overview
- · Issue Log
- · Source a Target Design
- · DSource -> Testing
- · DSource -> Target Build
- · DSource -> Target Routines
- · Logical Design Model
In this tab, we would maintain the change request Log. The task of keeping a software system consisting of many versions and configurations are well organized in this Version Control Tab.
This tab will carry the company logo, name of the report, DSO Name, Date when this document of prepared and also the person who is owning this document.
This is the tab, that holds, the Serial Numbers, Name of the person making changes to the document, summary of changes with respect to the version number.
The issues are recorded in this tab, to track overall issues and ensure those are corrected. The Issue, Description, remedy number, status, entered by, owner, date entered, Planned resolution date, actual resolution date and special comments that help in understanding the issue. All these details collectively help the user to understand the overall issues happened for an interval.
Source à Target Design:
This tab consists most of the important details required for developing the objects. This tab should have the title of the project, DataSource details and Target Details. The name of the Data Source and target object is mentioned on the top. It is better if we divide the tab into two divisions, with left side having Source object details and the right with Target object details.
In the Source side, it is advised to add all the fields, DataType, Length, Decimal details, Field Description, View-Table-Func- Mod-Query, Source Name, Extraction User-Exit, Source Selection Conditions, Routine Master Data Initial / No Update, Ref. Int., Aggregation, InfoSource Structure, Constant Direct Assignment Formula, Target: Ref. Int., Aggregation, Field Description, Keys, Fields, Type, Length, Compounded, Nav Attr, Release Used, Query Used, Used in Subsequent Target.
Below the above division, we can maintain the following: Field Name, Index Number, Data Classes and Storage Classes: Table Type, Size Category(Active Table, Activation Queue). START Routine: <PsuedoCode> or Flow Chart
InfoSource Transformation(s): Name
Target Transformation(s): Name
END Routine: <PsuedoCode> or Flow Chart. Data Load Details, Extraction User Exit, Other Comments,
DSource -> Testing:
In this document, the Testing Requirements are consolidated. Test condition details, ID, Test description, Process/Step, Condition, Expected Results, Actual Result, Test Result. If there are any Test Condition Exceptions. Document the test conditions that are developed during the development of the Tech Design. The “Process/Step” column refers to the Processes that are documented Technical Description
DSource -> Target Build:
<INSERT Transformation PICTURE from RSA1>
DSource -> Target Routines:
<Insert Code from System>
GLOBAL DECLARATIONS, START ROUTINE, TRANSFORMATION ROUTINE, END ROUTINE
Logical Design Model:
This is the tab we need to paste the LDM created in Visio software.
With this Document, I feel the development stage would be a cake walk. Hope you agree with me.