case study sap frd
TRANSCRIPT
System Requirements SpecificationCustomer Master Integration
Customer Maser IntegrationSystem 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 SpecificationCustomer Master Integration
Table of Contents
1 SYSTEM OVERVIEW............................................................................................................3
1.1 SYSTEM PERSPECTIVE.....................................................................................................51.2 OPERATING ENVIRONMENT..............................................................................................6
2 USE CASES.......................................................................................................................... 7
2.1 USE CASE DIAGRAM.......................................................................................................82.2 USE CASES................................................................................................................... 10
3 FUNCTIONAL REQUIREMENTS........................................................................................12
3.1 BEHAVIORAL REQUIREMENTS.........................................................................................123.2 DATA REQUIREMENTS....................................................................................................133.3 INTERFACE REQUIREMENTS...........................................................................................13
4 NON-FUNCTIONAL REQUIREMENTS...............................................................................15
4.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.................................................19
6 CONCLUSION.....................................................................................................................19
Appendix A – System Requirements Information Gathering Template.........................................20
System Requirements Specification Template Doc. Version 1.0
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.0
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.0
Database Server
Application Server Application Server
PC PC PC PC
3 Tier System Landscape
System Requirements SpecificationCustomer 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 and convey the significant architectural decisions that have been made on the system.
System Requirements Specification Template Doc. Version 1.0
- July 2007
18
Logical Architecture of DID to SAP
DID
Customer Master Data
Add, Change, Delete
SAP Applications Landscape
UPLOAD FILE SAP
System Requirements SpecificationCustomer Master Integration
1.1.2 Major system features
Benefits of implementing SAP Solutions:
System Requirements Specification Template Doc. Version 1.0
System Requirements SpecificationCustomer 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.
System Requirements Specification Template Doc. Version 1.0
System Requirements SpecificationCustomer Master Integration
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: SUMIT NAIR On (date): 06/05/2011User/Actor: InterfaceBusiness Owner Name:
Key business usersContact 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
2Trigger 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.
System Requirements Specification Template Doc. Version 1.0
System Requirements SpecificationCustomer Master Integration
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 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.0
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: SUMIT NAIR On (date): 06/05/2011User/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.0
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: SUMIT NAIR On (date): 06/05/2011User/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.0
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.0
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.0
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.0
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 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 document2 Project methodology document3 Project milestones document4 System Requirement document5 Work-shop documents
6Functional specification document
7 Mapping document8 Technical specification document9 Test Cases/scripts
10 Training manual11 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.System Requirements Specification Template Doc. Version 1.0
System Requirements SpecificationCustomer Master Integration
The training document will provide details on how to use the system in details with snapshots and step by step instructions.
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 platformThe 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
System Requirements Specification Template Doc. Version 1.0
System Requirements SpecificationCustomer Master Integration
User privacy, security, access will be controlled by the System administrator and per the security norms.
4.7.2 Data Security Requirements
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
System Requirements Specification Template Doc. Version 1.0
System Requirements SpecificationCustomer Master Integration
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 SpecificationCustomer 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 SpecificationCustomer 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