systemrequirementsspecification-customer master interface ver 1.1
DESCRIPTION
SAPTRANSCRIPT
BETA
System Requirements SpecificationCustomer Master Integration
Customer Maser IntegrationSystem Requirements Specification
Project Revision History
Version Name Date Reason For Changes1.0
System Requirements Specification Template Doc. Version 1.0Template Version 1.0 Page 1 of 18
BETA
System Requirements SpecificationCustomer Master Integration
Table of Contents
1 SYSTEM OVERVIEW............................................................................................................31.1 SYSTEM PERSPECTIVE.....................................................................................................51.2 OPERATING ENVIRONMENT..............................................................................................6
2 USE CASES.......................................................................................................................... 72.1 USE CASE DIAGRAM.......................................................................................................82.2 USE CASES................................................................................................................... 10
3 FUNCTIONAL REQUIREMENTS........................................................................................123.1 BEHAVIORAL REQUIREMENTS.........................................................................................123.2 DATA REQUIREMENTS....................................................................................................133.3 INTERFACE REQUIREMENTS...........................................................................................13
4 NON-FUNCTIONAL REQUIREMENTS...............................................................................154.1 LANGUAGE FOR IT SYSTEMS..........................................................................................154.2 DOCUMENTATION REQUIREMENTS..................................................................................154.3 LEGAL REQUIREMENTS..................................................................................................164.4 HARDWARE REQUIREMENTS..........................................................................................164.5 SOFTWARE REQUIREMENTS...........................................................................................164.6 DISASTER RECOVERY REQUIREMENTS...........................................................................164.7 SECURITY MANAGEMENT REQUIREMENTS.......................................................................17
5 ASSUMPTIONS, CONSTRAINTS AND DEPENDENCIES.................................................196 CONCLUSION.....................................................................................................................19Appendix A – System Requirements Information Gathering Template.........................................20
System Requirements Specification Template Doc. Version 1.0Template Version 1.0 Page 2 of 18
BETA
System Requirements SpecificationCustomer 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 locationsb) Warranty repair stationsc) Fleet companiesd) Auto Industry sub organizationse) Plantsf) Governmentg) Financial organizationsh) 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 customersb) Pending - they are creating the sitec) Active - Currently actived) 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.0Template Version 1.0 Page 3 of 18
BETA
System Requirements SpecificationCustomer 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.
System Requirements Specification Template Doc. Version 1.0Template Version 1.0 Page 4 of 18
Database Server
Application Server Application Server
PC PC PC PC
3 Tier System Landscape
BETA
System Requirements SpecificationCustomer Master Integration
1.1 System Perspective
Given the volume of the Change Point 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 interface is to transfer data between Change Point and SAP customer masters.
Here is a comprehensive architectural overview of the system. It is intended to capture and convey the significant architectural decisions that have been made on the system.
System Requirements Specification Template Doc. Version 1.0Template Version 1.0 Page 5 of 18
BETA
System Requirements SpecificationCustomer Master Integration
System Requirements Specification Template Doc. Version 1.0Template Version 1.0 Page 6 of 18
- July 2007
18
Logical Architecture of DID to SAP
DID
Customer Master Data
Add, Change, Delete
SAP Applications Landscape
UPLOAD FILE SAP
BETA
System Requirements SpecificationCustomer Master Integration
1.1.2 Major system features
Benefits of implementing SAP Solutions:
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
System Requirements Specification Template Doc. Version 1.0Template Version 1.0 Page 7 of 18
BETA
System Requirements SpecificationCustomer Master Integration
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
Use Case Name: Create/Change Customer Master Record In The Legacy Gold Source Systems Version No: 1.0
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 systemBelow are the features specific to SAP –
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: Mona Kaushal On (date): 06/15/2010User/Actor: InterfaceBusiness Owner Name: Key business users Contact
Details:Trigger: Request for creation/change of customer from upstream systemReferences: N/AFrequency of Use: Frequent – daily
Preconditions: Customer created/changed in the legacy systemPost Conditions: Customer masters are created/changed in SAP Non-functional Requirements None
Steps:
- Create request in legacy system to create/change customers in SAP- Trigger Customer Master Interface - Create/change customer master record in the SAP
System: SAP ECC , DID
Step User Actions System Actions
1Create request in legacy system to create/change customers in SAP N/A – Legacy
System Requirements Specification Template Doc. Version 1.0Template Version 1.0 Page 8 of 18
BETA
System Requirements SpecificationCustomer Master Integration
2 Trigger Customer Master Interface Legacy system feeds data file to the GIF (Global
Integration Factory) The GIF passes on the data file to SAP through an
IDoc.
3
New customers are created in SAP from the data received from the interface by internal number 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.0Template Version 1.0 Page 9 of 18
BETA
System Requirements SpecificationCustomer Master Integration
Use Case 2.1.2 CMI_INT_001-2: Change Customer Master Record in SAP
System Requirements Specification Template Doc. Version 1.0Template Version 1.0 Page 10 of 18
BETA
System Requirements SpecificationCustomer Master Integration
System Requirements Specification Template Doc. Version 1.0Template Version 1.0 Page 11 of 18
BETA
System Requirements SpecificationCustomer 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.0Purpose:
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: Mona Kaushal On (date): 06/15/2010User/Actor: InterfaceBusiness Owner
Name:Key Business user Contact
Details:Trigger: Request for creation of DID into SAP
References: N/AFrequency of
Use:Frequent – daily
Preconditions: Request for new customer is approved. Post Conditions: Customer masters are created in SAP
Non-functional Requirements
None
Assumptions, Issues:
The request is approved The customer does not already exist.
Steps:- Create customer master record in the SAP system
System: SAPTransaction – XD01
Step User Actions System Actions1 Create customer master record in the
SAP New customers are created in SAP
System Requirements Specification Template Doc. Version 1.0Template Version 1.0 Page 12 of 18
BETA
System Requirements SpecificationCustomer 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.0Purpose:
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: Mona Kaushal On (date): 06/15/2010User/Actor:
Business Owner Name:
Key business user Contact Details:
Trigger: Request to change a customers in SAPReferences: N/A
Frequency of Use:
Frequent – daily
Preconditions: Customer exists in SAPPost Conditions: SAP customer masters are changed as requested.
Non-functional Requirements
None
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 Actions1 Change customer master record in
the SAP Existing customer is changed
System Requirements Specification Template Doc. Version 1.0Template Version 1.0 Page 13 of 18
BETA
System Requirements SpecificationCustomer 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.0Template Version 1.0 Page 14 of 18
BETA
System Requirements SpecificationCustomer Master Integration
3.2 Data Requirements
Here is the list of the Source system data elements: - DIDError! Not a valid link.
Here is the list of the Destination system data elements: - SAPError! Not a valid link.
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 Manualo Manual if someone has to kickoff the process, review the file beforehand,
or manually upload/download a file like a spreadsheeto Answer: both manual and automated
Responsible Business Ownero 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 Volumeso How many records are coming per transmission?o Answer: Approximately 10 customer
3.3.1 Reporting Requirements
System Requirements Specification Template Doc. Version 1.0Template Version 1.0 Page 15 of 18
BETA
System Requirements SpecificationCustomer Master Integration
Report Name
Description/Use Frequency
S_ALR_87012179 - Customer List
The customer list is used for displaying and for printing customer master data which is needed in the area of financial accounting. The list can be used for information and documentation.
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.
Adhoc
S_ALR_87012180 Address List
The address list report displays customer address from the General view of the customer master record.
Adhoc
S_ALR_87012182 Display Changes to Customers
You can use this report to display changes to the customer master record.
Select options exist concerning the customer, the change date, the name of the person changing and the field group. Additionally, you can choose whether you want to see the changes for the general data, the company code data or the sales area data. Within each data range, you can set limits according to the organizational form
Adhoc
S_ALR_87012183 Display/Confirm Critical Customer Changes
A program is used for displaying and changing the customer's confirmation status.
The confirmation status provides information as to whether sensitive fields have been changed in the customer master record.
Adhoc
System Requirements Specification Template Doc. Version 1.0Template Version 1.0 Page 16 of 18
BETA
System Requirements SpecificationCustomer Master Integration
4 Non-Functional Requirements
4.1 Language for IT systems
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 Hardware Requirements
Laptops, Desktop, HP UNIX Network, and other infrastructure needs to be installed before moving into the “Realization” mode of the project.
4.3 Software Requirements
The project system will be run on UNIX platformThe user community will use Windows, MS Office, SAP and other required tools to work on the project.
4.4 Disaster Recovery Requirements
Backup of the data, system will be maintained as scheduled.
4.5 Security Management Requirements
4.5.1 User Security Requirements
User privacy, security, access will be controlled by the System administrator and per the security norms.
4.5.2 Data Security Requirements
System Requirements Specification Template Doc. Version 1.0Template Version 1.0 Page 17 of 18
BETA
System Requirements SpecificationCustomer Master Integration
Data security will be maintained as per standard security norms baselined below:
Define Access RequirementsThe 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.0Template Version 1.0 Page 18 of 18