System Requirements Specification

Customer Master Integration

Customer Maser Integration

System Requirements Specification

Project Revision History

Version Name Date Reason For Changes

1.0 SUMIT NAIR 6/05/2011 New document

System Requirements Specification Template Doc. Version 1.0

 System Requirements Specification
Customer Master Integration

Table of Contents
1 SYSTEM OVERVIEW..................................................................................................................3
1.1 SYSTEM PERSPECTIVE.................................................................................................................5
1.2 OPERATING ENVIRONMENT...........................................................................................................7
2 USE CASES................................................................................................................................7
2.1 USE CASE DIAGRAM..................................................................................................................8
2.2 USE CASES............................................................................................................................11
3 FUNCTIONAL REQUIREMENTS..............................................................................................13
3.1 BEHAVIORAL REQUIREMENTS......................................................................................................13
3.2 DATA REQUIREMENTS...............................................................................................................14
3.3 INTERFACE REQUIREMENTS.........................................................................................................14
4 NON-FUNCTIONAL REQUIREMENTS.....................................................................................15
4.1 LANGUAGE FOR IT SYSTEMS.......................................................................................................15
4.2 DOCUMENTATION REQUIREMENTS.................................................................................................16
4.3 LEGAL REQUIREMENTS..............................................................................................................17
4.4 HARDWARE REQUIREMENTS........................................................................................................17
4.5 SOFTWARE REQUIREMENTS........................................................................................................17
4.6 DISASTER RECOVERY REQUIREMENTS...........................................................................................17
4.7 SECURITY MANAGEMENT REQUIREMENTS.......................................................................................17
5 ASSUMPTIONS, CONSTRAINTS AND DEPENDENCIES.......................................................20
6 CONCLUSION...........................................................................................................................20
THE PROPOSED SOLUTION MEETS THE OBJECTIVE OF INTERFACING LEGACY
APPLICATION DEALER INFORMATION DATABASE WITH SAP SOLUTION. THIS
SOLUTION SHALL FACILITATE THE CENTRALIZED CUSTOMER MASTER DATABASE
SYSTEM.......................................................................................................................................20
IMPLEMENTATION OPTIONS FOR THIS SOLUTION HAVE BEEN DETAILED IN THE
RESPECTIVE DOCUMENTS IN THE “PROJECT DELIVERABLE DOCUMENT LIST VER
1.0.XLS” FILE..............................................................................................................................20
APPENDIX A – SYSTEM REQUIREMENTS INFORMATION GATHERING TEMPLATE..........21

System Requirements Specification Template Doc. Version 1.0

 System Requirements Specification
Customer Master Integration

1 System Overview
This project is scoped on creating a centralized customer master Database. Data from
Legacy system (Dealer Information Database) is going to be merged into SAP. SAP will
be the Core Master Maintenance system.

A brief overview of the Legacy system- Dealer Information Database (DID):

DID is an Auto industry Dealer Information Database system that stored

customers/Dealers information. It consists of customers who are primarily classified as
dealers and non-dealers. They are
a) Ship-to locations
b) Warranty repair stations
c) Fleet companies
d) Auto Industry sub organizations
e) Plants
f) Government
g) Financial organizations
h) Distribution Centers (RDC,CDC)

It is a Mainframe DB2 database that stores dealers’ customer master data.

Following are the status used to determine DID customers:

a) History - completely done customers
b) Pending - they are creating the site
c) Active - Currently active
d) Terminate - out of business, not an active dealer, but still financially active

Here is a brief on what SAP is:

SAP stands for Systems, Applications and Products in Data Processing.

SAP is an enterprise resource planning (ERP) software product capable of integrating

multiple business applications, with each application representing a specific business
area.
These applications update and process transactions in real time, thus allowing
seemingly, effortless integration and communication between areas of a business.
ABAP (Advanced Business Application Programming) is the programming language
used in SAP.

System Requirements Specification Template Doc. Version 1.0

 System Requirements Specification
Customer Master Integration

A figure below that depicts SAP’s integration across different processes, function
silos.

Here is a context diagram of SAP landscape that will be used for this project.

3 Tier System Landscape

Database Server

Application Server Application Server

PC PC PC PC

System Requirements Specification Template Doc. Version 1.0

 System Requirements Specification
Customer Master Integration

1.1 System Perspective

Given the volume of the DID data and the need for a stable, repeatable process of
creating, changing and deleting customer master records, manual creation or change to
the customer master data is not an option. The interface will bring in all the changes to
the customer master on a daily basis to keep the systems in sync.

Manually modifying the customers would be tedious and error prone and may result in
data inconsistency between the two systems. However, controlled manual intervention
would be required to an extent (for SAP specific fields) once the interface is up and
running.

1.1.1 High-level architecture diagram

The objective here is to have a global customer master repository in SAP for the
purpose of billing and accounts receivables. DID, being the Gold System for dealer
information, is one of the main source systems for customer master.

The purpose of the on-going interface is to maintain data consistency between DID and
SAP customer masters.

Here is a comprehensive architectural overview of the system. It is intended to capture

Logical
and convey the significant Architecture
architectural of DID
decisions that have to on the system.
been made
SAP

SAP
Add, UPLOAD FILE
DID Change,
Delete

Customer Master Data

SAP Applications Landscape

- July 2007

18

System Requirements Specification Template Doc. Version 1.0

 System Requirements Specification
Customer Master Integration

1.1.2 Major system features

Benefits of implementing SAP Solutions:

System Requirements Specification Template Doc. Version 1.0
 System Requirements Specification
Customer Master Integration

Increase revenue: Access real-time data fast with SAP

Reduce costs: Gone are the days of costly and recurring customization
Adaptable: React quickly whenever your business needs to change and adjust to new
market conditions
Complete solution: Run your entire business effectively with just the one solution
Personalized: Improve your employees’ productivity with a role-based user experience,
built-in learning, analytics and collaboration
Improve customer relationships: Integral CRM arms your team with relevant
information
Maintain IT solution as you grow: SAP will not hold your business back from growth
Clear, instantaneous insights: Create up-to-the minute dashboards
Business Critical alerts: Powerful alerts system
Improve efficiency: One centralized data repository
Support Multi-currency transactions: Multi-currency transaction and report
capabilities
Multi-lingual capabilities: Available in 27 languages and 40 countries
Integrate with Microsoft Office: Word, Excel and Outlook

1.2 Operating Environment

Dealer Information Database is a Mainframe DB2 database that stores dealers’
customer master data.
UNIX is going to be the operating system on which SAP is installed and functions.

2 Use Cases
Create/Change Customer in SAP by Trigger from Legacy Systems

Use Case Identification and History

Use Case ID: CMI_INT_001
Create/Change Customer Master Record In
Use Case Name: Version No: 1.0
The Legacy Gold Source Systems
Purpose: The purpose is to create/change a customer master record in the SAP system
whenever a request for creation/change of a customer is sent from a legacy
system
Below are the features specific to SAP –

System Requirements Specification Template Doc. Version 1.0

 System Requirements Specification
Customer Master Integration

• DID – source system for dealerships. Approximately, 90% of the customers will
come from DID.

• The number assignment will be internal to local SAP instance. The account
groups and the actual number ranges will not be affected by this decision.

Last Update by: SUMIT NAIR On (date): 06/05/2011

User/Actor: Interface
Business Owner Contact
Key business users
Name: Details:
Trigger: Request for creation/change of customer from upstream system
References: N/A
Frequency of
Frequent – daily
Use:
Preconditions: Customer created/changed in the legacy system
Post Conditions: Customer masters are created/changed in SAP
Non-functional
None
Requirements
- Create request in legacy system to create/change customers in SAP
- Trigger Customer Master Interface
- Create/change customer master record in the SAP
Steps:
System: SAP ECC , DID

Step User Actions System Actions

Create request in legacy system to
1 create/change customers in SAP N/A – Legacy

• Legacy system feeds data file to the GIF (Global

Trigger Customer Master Interface Integration Factory)
2
• The GIF passes on the data file to SAP through an
IDoc.
• New customers are created in SAP from the data
received from the interface by internal number
3 assignment.
• Existing customer master records are changed as
requested.

2.1 Use Case Diagram

Use Case 2.1.1 CMI_INT_001-1: Create Customer Master Record in SAP

System Requirements Specification Template Doc. Version 1.0

 System Requirements Specification
Customer Master Integration

Create Customer Master Record in SAP

Requestor

Request New
Start

Yes
Customer
No
SAP System
Decision

Request Does Customer

Yes
Approved? Already Exist?

No
SAP action

Create New
End
Customer

Decision Predefined
Terminator Process
Box Process
Dynamic Connector

Use Case 2.1.2 CMI_INT_001-2: Change Customer Master Record in SAP

System Requirements Specification Template Doc. Version 1.0

 System Requirements Specification
Customer Master Integration

Change Existing Customer Master Record in SAP

Requestor

Request to
Modify
Start

No
Existing
Customer No
SAP System
Decison

Request Does Customer

Yes
Approved? Exist?

Yes
SAP action

Apply Changes
to Existing E
Customer

Decision Predefined
Terminator Process
Box Process
Dynamic Connector

System Requirements Specification Template Doc. Version 1.0

 System Requirements Specification
Customer Master Integration

2.2 Use Cases

Use Case Identification and History

Use Case ID: 2.2.1: CMI_INT_001-1
Use Case Name: Create Customer Master in SAP Version No: 1.0
Purpose:
Creation of SAP customer master records directly in SAP -

Going forward, SAP will be the Gold Source for DID customers.
DID will send data file as mentioned in the mapping document. SAP will read the data,
validate and then create the customer master in SAP system.

Last Update by: SUMIT NAIR On (date): 06/05/2011

User/Actor: Interface
Business Owner Key Business user Contact
Name: Details:
Trigger: Request for creation of DID into SAP
References: N/A
Frequency of Frequent – daily
Use:
Preconditions: Request for new customer is approved.
Post Conditions: Customer masters are created in SAP
Non-functional None
Requirements
Assumptions, • The request is approved
Issues: • The customer does not already exist.
Steps:
- Create customer master record in the SAP system

System: SAP
Transaction – XD01

Step User Actions System Actions

1 Create customer master record in the • New customers are created in SAP
SAP

System Requirements Specification Template Doc. Version 1.0

 System Requirements Specification
Customer Master Integration

Use Case Identification and History

Use Case ID: 2.2.2. CMI_INT_001_2
Use Case Name: Change Existing Customer Master in SAP Version No: 1.0
Purpose:
Change an existing SAP customer master record in SAP -

The customer masters for which SAP is the gold source can be changed in SAP.
Going forward, SAP will be the Gold Source for DID customers.
DID will send data file as mentioned in the mapping document. SAP will read the data,
validate and then change the customer master in SAP system.

Last Update by: SUMIT NAIR On (date): 06/05/2011

User/Actor:
Business Owner Key business user Contact
Name: Details:
Trigger: Request to change a customers in SAP
References: N/A
Frequency of Frequent – daily
Use:
Preconditions: Customer exists in SAP
Post Conditions: SAP customer masters are changed as requested.
Non-functional None
Requirements
Assumptions: • The request is approved
• The customer already exists.
Steps:
- Change customer master record in the SAP

System: SAP
Transaction – XD02

Step User Actions System Actions

1 Change customer master record in • Existing customer is changed
the SAP

System Requirements Specification Template Doc. Version 1.0

 System Requirements Specification
Customer Master Integration

3 Functional Requirements
All the functional requirements are covered in the respective Deliverable objects list.
The requirements will be gathered through the WORKSHOPS conducted with the
business. Refer to the Workshop document for details.

3.1 Behavioral Requirements

3.1.1 Failed Transaction Handling/Error Handling for Interfaces

System/communication Errors:

The interface is run in scheduled background jobs. If a job does not run due to file
accessing errors or technical reasons, or terminates while running the job, the support
team monitors the jobs and takes follow up actions as per the established procedures.

If the interface was aborted in middle due to different technical reason, error is analyzed
and if required the job is rescheduled.

Data Errors:

While processing the Legacy source file in SAP, data records are validated at field level
for consistency with mapping rules and data related checks. The data records that pass
through these checks will be loaded to SAP, but those that fail in the validation checks
will not be loaded to SAP. The data records that fail in the validation will be stored in a
custom table in SAP for later error correction and reprocessing in a job run called
‘Suspense run’.

Before processing the Legacy source file in a Regular job run, the interface is executed
in a Suspense job run to load the corrected data records found in the previous Regular
job.

There are two stages where errors can occur; before loading to SAP during validation
and in the processing of the record in SAP.

There is no editing or correction done at the source file level in SAP. But, if there is a
need to correct the failed data records at the Legacy source and resend them in a file to
SAP, then these failed records in SAP will be archived first before reprocessing the file
containing the erred data records, which will be a Regular job run.

System Requirements Specification Template Doc. Version 1.0

 System Requirements Specification
Customer Master Integration

3.2 Data Requirements

Here is the list of the Source system data elements: - DID

Here is the list of the Destination system data elements: - SAP

Details of the how the data will be translated to be covered in the Mapping document of
the Functional Specification document.

3.3 Interface Requirements

Following are the Requirements that need to be gathered for the Interfaces

• Frequency (realtime, xMinutes, xDaily, xWeekly, xMonthly)

o How many files are we going to receive and when?
o Answer: Every hour

• Automated or Manual
o Manual if someone has to kickoff the process, review the file beforehand,
or manually upload/download a file like a spreadsheet
o Answer: both manual and automated

• Responsible Business Owner

o Who from the business owns the process and interface?
o Answer: Owned by the business Customer master team.

• Responsible person for Legacy system:

o Who owns from the deployment team and can answer mapping and
technical questions?
o Answer: Mona Kaushal

• Data Transaction Volumes

o How many records are coming per transmission?
o Answer: Approximately 10 customer

3.3.1 Reporting Requirements

System Requirements Specification Template Doc. Version 1.0

 System Requirements Specification
Customer Master Integration

Report Description/Use Freque

Name ncy
S_ALR_8 • The customer list is used for displaying and for printing customer Adhoc
7012179 - master data which is needed in the area of financial accounting.
Customer The list can be used for information and documentation.
List • You can narrow down the number of customers to be printed
using selection criteria. This includes, for example, the account
number of the customer, the company code, a search term, or an
interval for the selection criteria.
• Only customers for whom company-code-dependent master data
exists, are displayed for the following entries.

S_ALR_8 • The address list report displays customer address from the Adhoc
7012180 General view of the customer master record.
Address
List
S_ALR_8 • You can use this report to display changes to the customer Adhoc
7012182 master record.
Display • Select options exist concerning the customer, the change date,
Changes the name of the person changing and the field group. Additionally,
to you can choose whether you want to see the changes for the
Customer general data, the company code data or the sales area data.
s Within each data range, you can set limits according to the
organizational form

S_ALR_8 • A program is used for displaying and changing the customer's Adhoc
7012183 confirmation status.
Display/C • The confirmation status provides information as to whether
onfirm sensitive fields have been changed in the customer master
Critical record.
Customer
Changes

4 Non-Functional Requirements
4.1 Language for IT systems

System Requirements Specification Template Doc. Version 1.0

 System Requirements Specification
Customer Master Integration

English will be the only language of communication for documentation, meeting,

presentation, deliverable documents and workshops.

ABAP will be the programming language that will be used for SAP.

4.2 Documentation Requirements

Following are the list of documents that will be needed to be delivered at various stages
of the project. Link below to go into the details.
http://code.google.com/p/customer-master-integration/

S.No Description

1 Project Planning document

2 Project methodology document
3 Project milestones document
4 System Requirement document
5 Work-shop documents
Functional specification
6 document
7 Mapping document
8 Technical specification document
9 Test Cases/scripts
10 Training manual
11 Minutes of Meeting

4.2.1 Safety Requirements

The documents will be loaded in a safe and secure location for uniqueness, consistency,
avoiding data duplicity.
Access to the system will be restricted to the privileged group.
Backup of needed data will be maintained.

4.2.2 Training Requirements

Training documents will be detailed in the Training manual.

The training document will provide details on how to use the system in details with
snapshots and step by step instructions.

System Requirements Specification Template Doc. Version 1.0

 System Requirements Specification
Customer Master Integration

4.3 Legal Requirements

This project will be governed by HGU rules and regulations and in accordance with the
US legal rules/regulatory code.

4.3.1 Software Licensing Requirements

None

4.4 Hardware Requirements

Laptops, Desktop, HP UNIX Network, and other infrastructure needs to be installed

before moving into the “Realization” mode of the project.

4.5 Software Requirements

The project system will be run on UNIX platform

The user community will use Windows, MS Office, SAP and other required tools to work
on the project.

4.6 Disaster Recovery Requirements

Backup of the data, system will be maintained as scheduled.

4.7 Security Management Requirements

4.7.1 User Security Requirements

User privacy, security, access will be controlled by the System administrator and per the
security norms.

4.7.2 Data Security Requirements

System Requirements Specification Template Doc. Version 1.0

 System Requirements Specification
Customer Master Integration

Data security will be maintained as per standard security norms baselined below:

Define Access Requirements

The data can be classified by its sensitivity (e.g., restricted, confidential) or by user role.
Users can be classified by organizational unit, by user role, or by individual. Identify
restrictions by data and user classification.

Define time frames when secure data cannot be published to non-secure staff.

Define Audit Requirements

Define audit requirements. Consider gathering information on connections,

disconnections, data accesses, and data changes.

Define Network Requirements

Identify network requirements, such as data encryption/decryption and routing

restrictions.

Define Data Requirements

Identify any legal restrictions that apply to data kept on customers, employees, etc. To
meet legal restrictions it may be necessary to store summarized data so that individual
entities (e.g., employees, companies) cannot be identified.

Identify data privacy laws that must be adhered to (e.g., most countries require that
companies that hold data on customers must make this data available to the customer
on demand).

Define data movement security requirements. The following should be considered:

· Can data be transferred to a diskette?

· Can data be stored on a PC?

· Who might have access to data transferred to a diskette or a PC?
· Do back-ups have to be encrypted?
· Where should back-ups be kept?
· Who might have access to the back-ups?

Define High-Security Requirements

If high levels of security are required, define the requirements, such as "trusted" versions
of database management systems, "trusted" versions of operating systems, and secure
facilities.

System Requirements Specification Template Doc. Version 1.0

 System Requirements Specification
Customer Master Integration

System Requirements Specification Template Doc. Version 1.0

 System Requirements Specification
Customer Master Integration

5 Assumptions, Constraints and Dependencies

The assumptions and dependencies considered are:

• DID will continue to be the Gold Source System for dealers and will provide the
customer master for conversion.
• Dealers will not be created directly in SAP.
• All changes to customer master records (DID data) will be initiated from DID
system. However, changes to SAP specific data would be possible directly in
SAP.
• The Legacy system owners (DID) will ‘cleanse’ and ‘download’ the legacy data
as appropriate, and provide the customer data under the required structure.
• SAP will serve as a tool to facilitate the on-going interface processes and objects
like mapping source & destination system fields, file format, file structure etc.
• Only active customers will be extracted from the legacy systems.
• The SAP team is responsible for:
o Receiving valid Customer Master Data in SAP.
o Processing source flat files.
o Converting, mapping source fields as necessary.
o Extending additional SAP values as necessary.
• The Legacy System team is responsible for:
o Extracting, converting, translating Legacy data into SAP required format
as per the required guidelines

6 Conclusion

The Proposed solution meets the objective of interfacing legacy application Dealer
information Database with SAP solution. This solution shall facilitate the Centralized
Customer Master database system.

Implementation options for this solution have been detailed in the respective
documents in the “Project deliverable document list ver 1.0.XLS” file.

System Requirements Specification Template Doc. Version 1.0

 System Requirements Specification
Customer Master Integration

Appendix A – System Requirements Information

Gathering Template

Click the following link to get details of the documents pertaining to this project:
http://code.google.com/p/customer-master-integration/

System Requirements Specification Template Doc. Version 1.0