Functional Specification

Step by Step Guide Lines

Objectid_FS_Description

Object id naming conventionObject id is an identifier for identifying a functional specification.

Naming convention of a Object ID:- Process area_N2.0_YYYXXXXX

YYY – object type (INT – interface, RPT – Report, CON – Conversion, ENH – Enhancement, FRM – Forms, WF - Workflow

XXXXX - Object Number

Process area – Like OTC/HR/P2P

Eg:- OTC_N2.0_INT12345_FS_Interface with scanners

Functional Specification Document Details

Step 1: Here provide the details of author, version and Date

Step 2: This section is for more specific details about the Document.

Below steps (Step 1, 2 & 3) provide more detailed information about functional specification document, like Purpose and history of the Functional Specification and Approvals, etc,. These steps are common for all the Functional Specifications.

Step 3: i. Maintain the version of the document with document creation date,

description and name of the reviewer under the Versioning section.ii. Mention the Approval details in the Approvals section

Interface Functional Spec Section 1: Interface Tracking

In this section provide the details of the interface as highlighted

Section 2: Interface Functionality RequirementsIn this section provide very detail functional requirement of the Interface.

Description:- Provide in-detail business description and impact for the business with this interface requirement.

Data Filter Rules:- Provide any filter rules applicable to this interface.E.g., Only tolling relevant sales order line items which have been delivered completely.

Other Business Rules:- Here provide any other business rules which are applicable and informational to this interface.

Section 2.1:

Section 2.2: Assumption Write the assumptions which may /may not impact the goal/end result of the document/Object and also describe what are the assumptions to be taken into consideration while developing the object as well while deploying the object to production environment.

Examples:- i. The Login language is always Germanii. Tibco will pick the file from Application serveriii. Back ground job ‘XXXXXXXX’ will run daily at 6:00 am EST.

Section 2.3: Constraints

Provide the constraints which may affects the object directly / indirectly.

Example:i. Back ground job of interface ‘2’ should trigger after the execution of back

ground job of interface ‘1’.

Section 3: Interface Data Requirements

In this section provide all the data related to interface requirement.

i. Provide Source/Target Data Layout & Mapping.ii. Provide table name and field name, don’t key in structure names in place

of table names. Please refer the attached Excel for finding the table name for SAP screen field.

iii. If the interface is bi-directional provide both the mappings for both directions.

Worksheet in Functional Specification Ste

Section 3.2:- Sample Data SectionIn this section provide the sample test data with the expected results preferably in Development environment, It will help developers to analyze the better solution/approach which suits the requirement mentioned in the Functional Specification document.

Section 4:- SAP/Middleware/Legacy Requirements sectionUnder this section mention the requirements related to the individual systems SAP, Middleware and Legacy

Section 4 .1: - Interface Trigger in SAP, Middleware and/or Legacy In this section provide the information of process how the interface will trigger in live system

Section 4.2:- Transaction based

Here mention the SAP transaction details if the interfaces uses and SAP transaction, if it is not check the box None and mention how the interface triggers.

Section 4.3:- ALE and IDOC Specific Information (if any)

Here provide the details of the message type and IDOC type which full fill the requirement mentioned in the Functional Specification. If it requires the custom message type and/or custom IDOC type and/or any custom segments, mention those segment field names in detail and also provide the mappings for those custom segment fields in the mapping section.

Section 4.4:-Scheduling/ Performance Requirements/ Service Level Agreement

Here give the details about when the interface will trigger in Live environment. Is there any performance requirements like the volume of data it comes average and peak time. And also mention if there are any service level agreements which are related to requirement mentioned in the functional specification.

Section 4.5:- Special Requirements Section

Provide as much possible information here as it is most important in aspect of full fill the business requirement through custom coding. Write in detail data retrieval logic and detail functionality, if possible data retrieval logic diagram which suits the required functionality from the functional specification.

Section 4.6:- Custom Tables / Structures

In this section provide any custom table or custom structure information if required and also give the field details which are required in the table with the primary key information.

Section : 5 - Dependencies

In this section provide the dependencies if any to deploy and run the object in production environment.Example: i. Are there any interface(s) or enhancement(s) required to execute the object in

live system ?ii. Are there any third party/ Legacy system interfaces to be there in Live system

before this object executed ?

Section 6 : Controls

Provide what are the controls required to execute the object in liveMention in this section Error handling mechanism, how to reprocess the errors if occurred?, Where and how to capture the error log if it is an Interface/Conversion

Section 7: Compliance/Regulation Considerations

Section 8: Miscellaneous Data Capture Section

In this section please provide any reports required/exist for monitoring

Section 8.2: Other Pertinent Details

In this section please provide any applicable and important information regarding the Object which you may not find the place in the Document.

Section 8.1: Interface referring report Definition Documents(s)

Section 9: Security Requirements

This Section is most important in security wise. Here provide what are the security roles required for this object to restrict un authorized use.

Section 10: Issues Section

In this section provide any open issues/TBD process related to this object. This is very important to understand the developer what are the open issues and Developer understands is these are critical to start the development or not.

Enhancement Functional SpecificationSection 1: General information

In this section provide all the Enhancement details as described below for each sub section.

Section 2:- Business Needs & RequirementsIn this section describe the Business need and requirement of the enhancement as much as possible. Also provide the business logic , Processing calculations required for this enhancement development.

Section 3 :- Issues SectionIn this section write any outstanding issues which are needs to be resolved from the business and TBD process.Example:- TBD this enhancement should work for all the SO or only open SO

Section 4 :- Assumptions This section describes any assumption to be taken into consideration while developing the object.Example:- The UoM is always in Pounds. The currency is always in USD.

Section 5:- Functional Details

In this section provide in detail functional details and pseudo logic and any field details required for the development of the object. Attached is the excel sheet help how to find the SAP table name and field name. Don’t mention structure name instead of table name. Developer can’t retrieve the data from the structure as it doesn’t contain any data.

Example for Pseudo code:-1. Get VBRK-KUNAG2. Go to table KNA1 and fetch KATR4 where KUNNR equal to VBRK-KUNAG.3. When KATR1 equal to ‘NR’ or ‘Blank’ Skip the enhancement and continue the program.

Section 5.1:- Current Functionality

In this section provide the current functionality in the system as is before develop this enhancement.

Example:-In the Standard SAP reference can be defined by billing document type like customer purchase order#, Billing document number. Purchase order number is not copied into accounting document in standard SAP.

Section 5.2:- Required Functionality

In this section describe the required functionality needs to be placed as per the business.Example:- To meet Novelis requirement Bill of Lading and P.O. Number from the sales document to be copied into reference field of accounting document.

Section 6:- Error Handling

In this section provide Possible errors and/or business critical errors which needs to be handle.

Examples:-i. Job run notification ii. Error notificationsiii. E-mail messaging iv. Custom programv. Custom table

Report Functional SpecificationSection 1:- General information

Section 8/11: Testing Scenarios

-This is most important section to deliver the object and mark the status to development complete.

-In this Section provide the Test data and Test cases to the developers to perform the unit test after his development completed.

- This test data will help the developers to analyze the better solutions to fit the GAP described in the Document also.