Technical
Specification
Object Id:
Description:
Author(s):
1 Administration
1.1 Sign-off: Technical Specification
Name (Levi/Atos/DC)
|
Phone
|
Date
|
Approved
|
|
Business Analyst
|
||||
Functional Analyst
|
||||
System Integration Specialist
|
||||
Development Sub Team Lead
|
||||
Technical Analyst
|
||||
Developer
|
1.2 Revision Log
Change
Log for Revisions and Updates
|
||||
Date
|
Name
|
Version#
|
Sections
Revised
|
Reason*
|
1.3 Technical Attributes
Object Name:
|
|
FRICE-ID
|
|
Development Type (F/R/I/C/E)
|
|
Processes / SAP Module
|
|
SAP System / Release
|
|
Priority (High/Medium/Low)
|
|
Complexity (Simple/Medium/Complex/Very
complex)
|
|
2 General Specifications
2.1 Functional Overview
Give
a general description of the business requirement for this development object.
2.2 Assumptions/Business Rules
List all assumptions or business rules
that impact this development.
2.3 References
List
all documents to be referred for this technical spec.
2.4 Systems Flow Diagram
In
case of an interface development, a system flow diagram can also be given here
to represent the data flow between the systems.
2.5 Impacted Processes, Systems, Packages/Applications
List
all impacted processes, systems and applications.
SAP Modules
Impacted
|
|
Other Systems
Impacted
|
|
Other Applications
Impacted
|
2.6 Overall function’s triggering
List how the function is triggered. E.g. by the user,
a event, an
external system or at a certain time.
For SAP user-exits state the transaction and the
activity (e.g. at save) when user-exit is invoked.
2.7 Overall function’s frequency
How many users (on average) will use this
function? How often is the function started during the month?
How often is the function started during
month-end work? Note: Use in your calculation (number of users) * (times per
day/month)
2.8 Overall function’s usability
List function’s overall usability.
3 Technical Requirements
In case of interface
development, both sending and receiving system should provide the details. Section
4.2 should be repeated for both the systems and should also include any
middleware object development.
3.1 Development Object Specifications
Development
objects are logical objects, which can be SAP programs, Functional Modules,
Business Subjects, Processes, Interfaces, etc (depending on the system for
which the spec is being written).
Object
Details
|
|||
New/
Change
|
Object Name
|
Object Type
|
Description of Object
|
3.2 Development Object Name
Name
of the development object like Program name, script name, table name etc. This
section can be repeated for different object name to be developed and listed
above.
3.2.1 Development Object Description
This section will have the detailed description of the object. If
there are multiple programs / include program to be developed for this
development, then the relationship can also be described in this section.
3.2.2 Development Object Design and components
Record
properties of data, fields, and look/feel elements as needed.
Inputs
List
all input requirements for this development. It could be selection-screen,
custom screen, variant, and file (A
detailed data-layout should be described in section 4). In case of selection-screen, list the field type,
length, default values, mandatory, range or single value etc.
Outputs
List all output requirements for this
development. It could be a report, file
(A detailed data-layout should be described in section 4). For report layout, use appendix A.
3.2.3 Development Object Program Logic Flow
This flow diagram of the logic in the program should be at a level
of detail that it describes the program and/or information flow that will be
implemented with this new development. The detail of the flow diagram(s) should
be determined by the complexity of the development. The diagram should be done
in Visio and pasted into this document.
3.2.4 Development Object Pseudo Code
This section will list the Pseudo code for the development
object. Describe any specific processing
logic required for this to conform to the business requirements. This will
include specific criteria and/or formulas to be used in the processing. This
includes the calculation and/or presentation of totals. The section should also
contain the description of the data sorting criteria if applicable.
3.2.5 Development Object Error Handling
This section will describe how the functional error handling
requirements will be met. List all the exception conditions raised within the
program including cause and action to be taken.
3.2.6 Development Object Unit Testing
A
development could have multiple objects. If
separate unit testing is required then lists those scenarios here. A complete
string testing should be done in section
6.
Test Scenario
|
Expected Result
|
Comments
|
4 Data Layout Requirements
This section will be used for
interface development both inbound and outbound. In case of IDOC development,
list segments, fields, high-level segment, occurrence etc. Repeat the layout section for header and
item specific layout.
Layout:
Field Name
|
Description
|
Data Type
|
Length
|
position
|
Comment
|
5 Operations Specifications
List
the operational requirements like specific security/authorization requirements (
Who (which user-roles) should execute it? Should this be executed in batch or
on-line? Any special authorization requirement within the development objects
like authority-check etc.?), Scheduling requirements (job name, frequency,
dependencies etc) and system recoverability requirements.
5.1
Security/ Authorization requirements
Object
name could be program name, transaction code, directory and file name etc.
Object Name
|
Auth.
Group
|
Remarks
|
5.2
Job Scheduling requirements
List the job frequency, timing, triggers,
job dependencies and conflicts.
Job Name
|
Frequency
|
Timing
|
Dependencies
|
Variant
|
Est. Volume
|
Remarks
|
5.3
System recoverability
requirements
During the execution a job could fail for
various reasons. Describe the various points of job failure and associated
recovery procedure like if the job fails then it can be retriggered or it
should not be triggered (will create duplicate records issue).
Object/Program/Job
|
Point of Failure
|
Recovery Procedure
|
Notes
|
5.4
Data retention requirements
The
technical team should discuss archiving, data and file retention with the
functional/ business teams and then fill out the following section (if
applicable).
1.
Estimated
size of interface file (maximum record length and number of records or size in
kilobytes)
2.
Maximum
number of versions to be kept on disk (UNIX level)
3.
Maximum
number of versions to be kept in the sending and receiving systems
4.
Expected
maximum retention period for each interface file or IDOC, spool, job log etc (in
days)
Describe
how clean-up or housekeeping will be performed.
Include name of script, batch job
and/or program
6 String Testing
6.1
String Test Description
Describe
the end-to-end testing approach; include scenarios, validation criteria, and
expected results.
Sequence
|
Test
Scenario
|
Expected
Result
|
Comments
|
7 Technical Specs Walk-Through
Complete
this section after review and walk-through of Technical Specs with appropriate
Technical and Functional team members.
Document Review
Technical specification document complete
Error Handling section is complete (if applicable)
Revision Log is complete. (in case of revisions)
Job Schedule section is complete.
Technical specification signed off and stored in Shared Point
Process Team Review
Walk-through with Process Team complete on
Technical Spec Document
Process Team sign-off obtained on Technical Spec
Document
Developer(s):
__________________________________
Reviewer(s):
__________________________________
Walkthrough Status pPASS
pFAIL
Comments
Appendix A : Reporting Layout
(Remove
this section if not required)
A.1 General
Report destination
|
|
Page Formats and Fonts
|
|
Execution Frequency
|
|
Special Cosmetic
|
Logical Database
|
|
Authorization groups
|
A.2 Report Columns description
Col Nr
|
Field name
|
Description
|
Calculations and Formats
|
A.3 Report headings structure
(Remove if not required)
Report
|
Z1CA_XX_REPORT_HEADER – standard header.
|
Page
|
|
Control break 1
|
|
Control break 2
|
A.4 Report footer structure
(Remove if not required)
Control Break 2
|
|
Control Break 1
|
|
Page
|
|
Report
|
A.5 Report Layout
1 2 3 4 5 6 7 8 9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
|
|
1
2
3
4
|
A.6 Hierarchy
VARIABLE
|
|||||
CHARACTERISTIC
|
NAME
|
DESCRIPTION
|
PROCESSING
TYPE
|
DEFAULT VALUE OR
PROGRAM NAME
|
|
A.7 Text
VARIABLE
|
|||||
CHARACTERISTIC
|
NAME
|
DESCRIPTION
|
PROCESSING
TYPE
|
DEFAULT VALUE OR
PROGRAM NAME
|
|
A.8 Formulas
VARIABLE
|
|||||
CHARACTERISTIC
|
NAME
|
DESCRIPTION
|
PROCESSING
TYPE
|
DEFAULT VALUE OR
PROGRAM NAME
|
|
A.9
Other Considerations
E.g.
Drill-down to other report
|
A.10 Workbook Level Controls/Functions:
Describe
any controls or processing that needs to occur at the workbook level
|
