<F2M/PLM/…>_<P/W/R/I/C/E/F>_<SeqNo>

_<Short_Description>

Dev ID: <Dev ID>

Conversion Technical Specification

Author
[Pick the date]
 Technical Specification Document

Functional Specification Document

Table of Contents
1 EXECUTIVE SUMMARY...................................................................................................3
1.1 OBJECT INFORMATION AND ATTRIBUTES........................................................................3
1.2 BUSINESS DRIVER............................................................................................................4
1.3 DESIRED FUNCTIONALITY OVERVIEW.............................................................................4
1.4 ASSUMPTIONS...................................................................................................................4
1.5 PROJECT / DEVELOPMENT CONSTRAINTS........................................................................4
1.6 PERFORMANCE CRITERIA.................................................................................................4
1.7 APPLICATIONS AFFECTED................................................................................................4
1.8 DATA VOLUME.................................................................................................................5
1.9 DATA QUALITY METRICS................................................................................................5
1.10 OTHER OBJECTS AFFECTED.............................................................................................5
2 DETAILED REQUIREMENTS...........................................................................................6
2.1 PWRICEF TYPE SPECIFIC INFORMATION – CONVERSION...............................................6
3 ADDITIONAL INFORMATION.......................................................................................13
3.1 BACKUP / RECOVERY.....................................................................................................13
3.2 INFORMATION SECURITY................................................................................................13
3.3 AUDIT.............................................................................................................................15

Technical Specification – Conversion – Object ID and Dev ID Page 2 of 15

 Technical Specification Document

Functional Specification Document

1 EXECUTIVE SUMMARY
1.1 Object Information and Attributes
The following is current information about this object and document:
Object ID Assigned Object ID from Functional Specification
Title Object ID and Short Description from Functional Specification
Dev ID Dev ID from SAP Development Log
Gap Number Gap Number from SAP Development Log
Version Document version
Creation Date Date document created
Author(s) Name of the Technical specification author(s)
System Version SAP system version
Development Type Conversion
Disposition Draft, Approved, Rejected, or Deferred
Estimated S(imple), M(edium), C(omplex) or VC (very complex) – Initial Complexity from
Complexity SAP Development Log

Revision History:

Version Date Author(s) Revision Notes

1.0 Name of the initial Initial version
version author
1.1 Name of the author of Reason for/short description of change:
the revision Reference section number:
Changes made under a section

Technical Specification – Conversion – Object ID and Dev ID Page 3 of 15

 Technical Specification Document

Functional Specification Document

1.2 Business Driver

Description:
Give a description of the object that provides an overall explanation, purpose, and business
rationale. Please refer to the same section in Functional Specification for more details. Update
this section based on Functional Specification.

1.3 Desired Functionality Overview

Description:
List the desired functionality that the development object should provide Please refer to the same
section in Functional Specification for more details. Update this section based on Functional
Specification.

1.4 Assumptions
Description:
Assumptions include those that will impact development, testing, roll-out, implementation and
on-going maintenance, as well as any potential impacts on other processes. Please refer to the
same section in Functional Specification for more details.

1.5 Project / Development Constraints

Description:
Document any business or system constraints that will hinder or pose a challenge to the
development of the object in question. For example, capture any potential dependencies that may
constrain this development Please refer to the same section in Functional Specification for more
details. Update this section based on Functional Specification.

1.6 Performance Criteria

Description:
Capture any system performance criteria and requirements that must be met. Note: add any
additional performance considerations that aren’t captured in the following tables. Please refer
to the same section in Functional Specification for more details. Update this section based on
Functional Specification.

Performance Requirements for Conversions

Average Transactions / Records and Type per Conversion <Number> <Type>
Run:
Peak Transactions / Records and Type per Conversion Run: <Number> <Type>
Required Throughput For Conversion: <’X’ Transactions Per Second, Minute, Hour>

1.7 Applications Affected

Description:
Outline a list of application areas being changed or affected by this design including both SAP
and non-SAP (legacy) systems. Please refer to the same section in Functional Specification for
more details. Update this section based on Functional Specification.

Technical Specification – Conversion – Object ID and Dev ID Page 4 of 15

 Technical Specification Document

Functional Specification Document

SAP Modules Affected

SAP Module Impact/Change Description

Legacy Applications Affected

NON-SAP Impact Description
System

1.8 Data Volume

Description:
Provide the estimated volume of data (e.g. the number of vendors to be converted). Please refer
to the same section in Functional Specification for more details. Update this section based on
Functional Specification.

1.9 Data Quality Metrics

Description:
Provide the target values for required data quality metrics (e.g. 90% data completeness).
Please refer to the same section in Functional Specification for more details. Update this section
based on Functional Specification.

1.10 Other Objects Affected

Description:
In order to better understand the total impact of this Technical Specification, please describe
other known related/impacted PWRICEF objects. Please refer to the same section in Functional
Specification for more details. Update this section based on Functional Specification

Technical Specification – Conversion – Object ID and Dev ID Page 5 of 15

 Technical Specification Document

Functional Specification Document

2 DETAILED REQUIREMENTS
2.1 PWRICEF Type Specific Information – Conversion
Description:
Identify the data requirements of this conversion including the business object, date range to be
considered for extracting information from Source System(s) for conversion, data cleansing and
detailed data mapping requirements.

Conversion Business Object

Business Object <Name of Business Object>
Business Object <Description of Business Object, and its functionality>
Description
Date Range Considered <Include Time Zone when specifying the date range>
for Conversion
Conversion Method <Choices ETL, ABAP/LSMW, Manual/Winshuttle)

Business Object Retention & Archiving Requirements

<Describe the data retention requirements for this business object>

Program name and description

Define Conversion Program name and description

Execution Method
Describe in detail, the method of program invocation (JCL specifics, online, etc.)

Program Type
Define type of program (Custom transaction, Batch, LSMW etc.)

Inputs / Outputs
A list of required inputs and outputs

File Descriptions (if applicable)

Description:
Describe the overall input file sources (complete this section if file was selected above as source or
target) required to support the object.
Input File Requirements (if applicable)
Information Needed Description
Logical File Name < Name file is commonly known by>
File Description < Description of type and purpose of the file>

Technical Specification – Conversion – Object ID and Dev ID Page 6 of 15

 Technical Specification Document

Functional Specification Document

Input File Requirements (if applicable)

Information Needed Description
Message Type <Message Type like IDoc, XML, HTML etc>
Variants <Variants in Logical File Name if used>
System Name <System the file is associated with >
Physical File Location & <Name and directory path of file >
Name
Selection Requirements < Selection criteria if required>
Empty Files < Are empty files to be expected/permitted as part of normal processing?>
Sort Order For Incoming <list of columns for the default sort order and indication on ascending or
File / Message descending for each column>
Length of Time to Archive <X Days, Months, Years, etc.>
the Source File

Error Messages and Classes

A list of required error messages

Technical Specification – Conversion – Object ID and Dev ID Page 7 of 15

 Technical Specification Document

Functional Specification Document

Detailed Logic
Describe logic through the use of pseudo code, flow charts and supporting text. Include specific error handling.
Number all “If”s, “When’s and condition checks to drive test scenario. Describe the pre/post processing business
rules, data cleansing approach, data verification approach and additional requirements

Technical Specification – Conversion – Object ID and Dev ID Page 8 of 15

 Technical Specification Document

Functional Specification Document

Pre-Processing Business Rules

<Describe the pre-processing business rules>

Post-Processing Business Rules

< Describe the post-processing business rules >

Data Cleansing Logic/Approach

<Describe the logic/approach that will be used for data cleansing>

Data Verification Logic/Approach

< Describe the logic/approach that will be used for data verification. Define how will it be determined that the
Conversion has been run successfully? What validations will be made to determine that the number of records
extracted is correct? How will it be determined that the records imported into the target system are imported
correctly? Who will be responsible for the testing/validation? Will reports be run out of the source or target
system? Will special reports be required? Be specific as possible, since this information will be used as input to
in the Conversion and Acceptance test plans.>

Additional Processing Requirements for this Conversion

Information Needed
What are the predecessor
processes & dependencies
for this conversion?
Conversion Process Log
Details
Post Execution Notification
Details (if applicable)
Other processing
requirements?
Description
<List any processes that must be run before this to create the data necessary for
this conversion. Also, specify high level dependencies before running this
particular conversion.>
<Identify how process will be logged (detailed Error Reports are defined in
section 3.5) including details and format of logs.>
< If applicable, identify details of Execution Notification (Report, Email
Notification, Workflow, etc)>
<List any additional processing requirements not captured above>

Proposed Development Tool (done by Tech Arch. Team member/Dev. Architect)

Proposed Development Tool <From the Functional Specification>
Reasoning for Proposed <From the Functional Specification>
Development Tool

Technical Specification – Conversion – Object ID and Dev ID Page 9 of 15

 Technical Specification Document

Functional Specification Document

Proposed Development Tool (done by Tech Arch. Team member/Dev. Architect)

Proposed Development Tool <From the Functional Specification>
TS Proposed Development Tool <Put in the proposed development tool like Adobe print forms, etc. from the Development Tools
(if different from one above) Strategy>
Reasoning for TS Proposed <Reasoning behind the choice of the proposed development tool which is different than the one
Development Tool proposed from the Functional Specification>
Detailed Data Mapping
Description:
Identify all of the legacy systems that will be used for the conversion of this Business Object. For each additional
legacy application, you may use an additional data mapping spreadsheet. As a norm, Data conversion file format
will be provided by SAP. The mapping sheet will describe the detailed mapping including transformation and
business rules to be applied.

Detailed Data Mapping to Legacy System(s)

Legacy Legacy Legacy Detailed Data
Application Application Application Mapping Sample Data
Name Description Conversion Type
<Name of <Describe the <Identify the <Provide multiple sets of
Legacy legacy source that was sample data so that a full
Application> application> used to complete TA.DEV.007_Functio picture of the requirements can
the detailed data nal Specification Template -be realized. Data
Conversion ThisMapping
can be v1.1.xlsx
an
mapping to the embedded file or link to sample
SAP fields – <Reusable data.>
Screen, Report, Template>
File, Database
Table, Application
Protocol Interface
(API)>

Error Handling:
Description
Describe the error handling approach and error reporting in detail:

Technical Specification – Conversion – Object ID and Dev ID Page 10 of 15

 Technical Specification Document

Functional Specification Document

Conversion Report Layout (if applicable)

[Insert the layout of the Conversion report]

Technical Specification – Conversion – Object ID and Dev ID Page 11 of 15

 Technical Specification Document

Functional Specification Document

Error Report Layout (if applicable)

[Insert the layout of the error report]

Technical Specification – Conversion – Object ID and Dev ID Page 12 of 15

 Technical Specification Document

3 ADDITIONAL INFORMATION

3.1 Backup / Recovery

Description:
Describe the Backup/recovery plan according to Functional Specification.

3.2 Information Security

Description:
Provide details according to Functional Specification.

3.3.1 Information Classification

General Information

Businesses Impacted:
Information Classified by whom: Date
Contact Information
Company Name Phone E-mail Address
List Potential
Information Owners:
Architecture
Environments: (impacted by this Fspec): Development Test Training Production
Public (Internet) Facing Internal Only
Architecture: (system exposure): 3rd Party Hosted Company * Hosted

Identity & Access Management

During Project Yes Offshore? Yes List the 3rd
3rd party system access required? No No Parties:

Post Implementation Yes Offshore? Yes List the 3rd

3rd party system access required? No No Parties:
Business Impact Analysis
What may be impacted if the system or information/data is compromised? Check all that may apply.

Company Reputation/Trust Regulatory

Associate Relations Compliance
Competitive Advantage Securities & Exchange Commission (SEC)
Financial Impact Payment Card Industry (PCI)
Productivity Sarbanes-Oxley (SOX)
Supply Chain Privacy Laws
Contractual (i.e. NDA’s, MSA’s)*

Input any additional details related to business impact in the event of compromise:
*NDA – Non-Disclosure Agreement, MSA-Master Service Agreement

Technical Specification – Conversion – Object ID and Dev ID Page 13 of 15

 Technical Specification Document

Information Classification
Action #1: Check the box below that represents the most restrictive classification.
Action #2: If Level 1 or 2 is selected, check the box below indicating data storage or data transmission.

Level 1 – Confidential – Secure Handling Required “SHR”

Confidential – Secure Handling Required represents the most sensitive data classification related to individual personal
identifiable information and personal financial account information. This information considered critical to AG such that, if
disclosed, may disrupt or impede business operations, and due to legal, reputational, or operational concerns, requires
additional security controls. Information in this category includes, but is not limited to:
1. Social Security Number
2. Driver’s License Number or Government-issued Identification Number
3. Financial Account Number (card number or personal bank number)
4. Protected Health Information & Electronic Protected Health Information

SHR data stored? SHR data transmitted? SHR data stored and transmitted?

Level 2 – Confidential

Confidential represents the second most sensitive data classification related to operationally significant business information.
This information considered critical to AG such that, if disclosed, may disrupt or impede business operations. Examples of
Restricted Confidential include but are not limited to regulatory governed data, trade secrets, mergers and acquisition
discussions, product formulas and designs, corporate earnings data prior to public announcements, reorganization details prior
to announcements, current/closed company investigations and litigation, detailed network diagrams that could jeopardize
network security, strategic development/marketing plans and information integral to the success and operations of the
company.

Confidential data stored? Confidential data transmitted? Confidential data stored and transmitted?

Level 3 – Internal AG Use Only

Internal AG Use Only represents the third most data. It represents information that is less critical to privacy and business
operations but still must not be publicly disclosed. This information is not approved for general circulation outside AG.

Level 4 - Public

Public represents information that has been declared public knowledge by the information owner and can freely be given to
anyone without any possible impact to AG. As a result, no special data handling protections are required.

Technical Specification – Conversion – Object ID and Dev ID Page 14 of 15

 Technical Specification Document

3.3.2 Security Roles (Profiles and Authorizations)

Define the general security administration for this design as per Functional Specification.

3.3 Audit
Define the audit solution (if applicable) for this design based on Functional Specification

Technical Specification – Conversion – Object ID and Dev ID Page 15 of 15