Workflow Definition Document (WTD) Template PDF

<Project>
<XXXXXX> Technical Specification
Technical Design Specification - Workflow

<Name of the specification>
Version
Document Status
Author
Last Revision Date

Date Created
:
:
<Version Number>
Review[Draft/Review/Signed Off]
<Author Name>
:
:
Workflow Definition Document (WTD) Template.DOC
<DD-MON-YYYY>
<DD-MON-YYYY>
2/25/2013
<Page 1 of 17>
<Project>
Approval
Approved by
Name
Role
Signature
Date
Process
Team Lead
Development
Team Lead
Document History
Version
Reason for change
Date
1.0
1.1
1.2
1.3
2/25/2013
<Page 2 of 17>
<Project>
Table of Contents
1.
General Information ________________________________________________________ 4
Description and Purpose ____________________________________________________ 5
Assumptions: _____________________________________________________________ 5
Issues ___________________________________________________________________ 5
SAP Workflow Diagram _____________________________________________________ 6
TEXT TO BE REMOVED. GUIDANCE ONLY:_________________________________________ 6

6
Business Object Information ________________________________________________ 7
Workflow Definition ________________________________________________________ 8
Responsibility Agents: __________________________________________________________ 9

8
Steps in Workflow ________________________________________________________ 10
Deadline Monitoring Requirements: _________________________________________ 12
10
Security/SAP Authorization Requirements: ___________________________________ 12
11
Reporting/Form Requirements: _____________________________________________ 12
12
Custom screen design (if any) ______________________________________________ 12
13
Custom Tables/Structure in SAP (if any) ______________________________________ 12
14
User Exit / Enhancement Detailed Description _________________________________ 13
15
Configuration Information __________________________________________________ 13
16
Additional Information/Attachments _________________________________________ 14
TEXT TO BE REMOVED. GUIDANCE ONLY: < ______________________________________ 14

17
Unit Test Plan ____________________________________________________________ 15
TEXT TO BE REMOVED. GUIDANCE ONLY: < ______________________________________ 15
2/25/2013
<Page 3 of 17>
<Project>
1. General Information
Functional Design Spec ID:
Implement. Phase
Message Class:
Develop. Class:
Module:
Workflow User/User Group:
<Name of Region / country going to use this Workflow>
Region / Country
Contact Details:
Prepared By
Prep Date:
Phone Number:
Email Address:
Business/Functional Analyst:
Phone Number:
Email Address:
Run Frequency
Priority:
Languages
Complexity:
Transport Information
Change
Request #
Task #
Object Identifier
(Program ID, Layout Set
ID, etc)
2/25/2013
Object Type
(Program, Transaction, Layout
Set)
<Page 4 of 17 >
<Project>
Description and Purpose

TEXT TO BE REMOVED. GUIDANCE ONLY
< Description of the program such as its purpose, how, when, why, where, who, as
appropriate. Provide additional information about the design of the program not covered in
the other descriptions.
>
END OF GUIDANCE TEXT
Assumptions:
TEXT TO BE REMOVED. GUIDANCE ONLY:
< The Technical designer should detail here all the procedures or configuration affecting the
enhancement that the developer can take for granted. Other assumptions that the designer
foresees will better focus the scope of the enhancement should also be included here.
These are a very important part of the specification as they ensure that no unnecessary
development work is undertaken.
It is normal for assumptions to be thought up at the technical development stage as well as
the functional specification stage as development and testing may throw up more obscure
scenarios than thought out at a business level. These should be discussed during the
development stage and added to the spec when agreed.
Example assumptions:
All weights in the SAP system will be in kilograms
The user-exit will only be available to the Spanish users
Deliveries will have a maximum of 5 line items
The login language will be Spanish
Only Billing documents with Delivery documents (SD Preceding document category J) as
their preceding referenced document will be extracted
The lessees price will never be more than 7 characters long
Etc.
> END OF GUIDANCE TEXT
Issues
<This section should be used like a log during the creation of this document to outline any
outstanding issues that need to be resolved prior to continuing with the development work.
Prior to sign-off there should be no issues remaining.
2/25/2013
<Page 5 of 17 >
<Project>
>
Issu
e#
Date
Raised
Issue Description
Issue Resolution
SAP Workflow Diagram

< Please show the technical workflow diagram
(One can use Visio or can even paste the diagram from the downloaded file from the
workflow builder Menu options: Workflow Print Graphic
>
SAP Workflow Process Steps:

Business Process Trigger:
The process steps should describe the technical implementation done in the workflow template.
There should be a one to one match between the process step & the workflow diagram. Thus if
the workflow diagram had 12 boxes and each numbered from 1 to 12 then there should be 12
process steps describing each step in the diagram.
Please see below for sample pseudo-code:
1. Workflow is started via transaction XYZ.
2. Condition Step: Describe the condition.
3. Container Operation: Describe the operation taking place in the container.
3A.Background Step: Describe the step; for example: the date after eight business days is
calculated. This date will be used to send a notification to the supervisor of Approver#1 is
no action was taken by Approver#1 for three business days.
4. Background Step: Approver#1 is determined.
5. Activity (Dialog) Step: The work item is presented to the approver for necessary action
(Approve/ Reject).
Approve Path
6. Container Operation: The status container is set to A.
7. Container Operation: The name of approver is added to a multi line container.
Reject Path
8. Activity (Dialog) Step: A window is presented to approver to enter the rejection comments.
9. Background Step: The document is reverted back to the original status.
10. Background Step: A mail is sent to the initiator informing him/her about the rejection.
11. Process Control Step: The workflow instance is terminated.
12. The workflow ends.
2/25/2013
<Page 6 of 17 >
<Project>
Exception Handling
13. Background Step: A mail is sent to the workflow administrator.
14. Background Step: A mail is sent to the approver stating that the work item will be
presented again for approval.
Escalation Handling
14A. Background Step: Supervisor of Approver#1 is determined.
14B. Background Step: A mail is sent to the Supervisor of Approver#1 informing
that no action was taken by Approver#1.
15. Loop: If the status container is not equal to A (Approved); the work item is routed back
to the approver; else the workflow continues to the next approver.
Business Object Information

Object Type:
Description:
Short Description:
Program:
SuperType:
Application
Key Fields
Element
Description
Dictionary Field
Attributes (only mention those used in the workflow template)

Element
Description
Source
Attribute Property
Virtual
Multiline
Database
Mandatory
Dictionary Field
Pseudo
logic
Ref
A1
Instanceindependent
Virtual
Multiline
Database
Mandatory
Obj Status
Instanceindependent
A2
Pseudo logic : Mention Logic for custom attributes only.

A1:
A2:
2/25/2013
<Page 7 of 17 >
<Project>
Method (only mention those used in the workflow template)

Name
Description
Source
Result Type
ABAP
Pseudo logic Ref
M1
Function
Module
Dialog
Synchronous
API
Result
parameter
Transaction
Instance
independent
Dialog
Module
Reports
Others
M2
Function
Module
Dialog
Synchronous
API
Result
parameter
Transaction
Instance
independent
Dialog
Module
Reports
Others
Pseudo logic: Mention Logic for custom methods only.

M1 Pseudo logic:
IMP
EXP Parameter List
Mutiline
IMP
EXP Parameter List
Mutiline
Parameter List
Exception
M2 Pseudo logic:
Parameter List
Exception
Event (only mention those used in the workflow template)

Name
Description
Parameter List
Import
Workflow Definition
Abbreviation:
Name:
Triggering Events:
Number:
2/25/2013
<Page 8 of 17 >
Export
<Project>
Object Type:
Event:
Workflow Container:
Eleme
nt
Description
Impor
t
Expor
t
(Y/N)
(Y/N)
Multiple
Values
(Y/N)
Mandator
y
Dictionary
Field
Object
Type
(Y/N)
Binding Workflow Container/Event Container: (Please indicate in the middle column

below as to the direction of the parameters - or )
Workflow Container Element
Event Container Element
Responsibility Agents:
Task Name
Agent
Deadline
2/25/2013
Notification
<Page 9 of 17 >
<XXXXX> Technical Specification
<Project>
Steps in Workflow
List the technical details of the steps used in the workflow template. Step No should refer to step no as in section 8 above
Activity/Send Mail/User Decision/Subworkflow

Step
No
Task No
Step Description
Object TypeMethod
Property
Agent
Agent
Assignment
Secondary
Methods (if
any)
Background
Confirm end
Of process
Background
Confirm end
Of process
2/25/2013
<Page 10 of 17 >
Terminating
Event
Triggering
Event
Work Item
subject/Text
Others
<Project>
Condition
Step
No
Step Description
Relational
operator
Relational
Expression
Subsequent Events
True
False
Wait For Event/Create Events

Step
No
Step Description
Object Type-Event
Event
Container
Task
Container
No of
Events
Responsible
Loop (While)/(Until)
Step
No
Step Description
Condition
Outcomes
Loop end
Continue
Multiple Condition
Step
No
Step Description
Type
Comparison Basis
Comparison Value
Value
Outcome
Fork
Step
No
Step Description
Parallel
Branch
Necessary
Branch
Condition
Process Control
Step
No
Step Description
Outcome Name
Function
Workflow Step
Container Operation
Step
No
Step Description
Result
Assign
ment
2/25/2013
Expression
Operator
Expression
<Page 11 of 17 >
<Project>
Deadline Monitoring Requirements:

Task Name
10
Deadline Time
Role
SAP Authorization
Reporting/Form Requirements:
Description
12
Type
Security/SAP Authorization Requirements:

Task Name
11
Agent
SAP Tool
Report Name
Custom
Requirements
Custom screen design (if any)

<
Technical details of custom screen can be incorporated here . Number of screens

required and flow diagram can be included and provide the selection screen screen
shot along with the table name and field name and screen shot for the required
output.
>
13
Custom Tables/Structure in SAP (if any)

Table Name
Short text
Size category
Table maintenance
allowed
Data class
Buffering
Table maintenance
generator
Authorization Group
Field
Data Element
Name
Domain
Type
Length
2/25/2013
Check
TableField
Key
Field
Foreign
Key
Description
<Page 12 of 17 >
<Project>
Comments
14
User Exit / Enhancement Detailed Description

<
If workflow to be triggered from user exit or if any modification required using user
exit.
>
15
Configuration Information
<
List the configuration/custom objects that need to be maintained for this workflow to
function. Some commonly used examples are listed below
>
Server:
Client:
Activity
T-Code
Delegation
Type Linkage
Instance Linkage
Workflow Start Condition
Change Document
Status Management
Message Control
Organization Structure
Display
Rules
Responsibility for Rules
SW01
SWETYPV
SWEINST
SWB_COND
SWEC
BSVW
NACE
Setting Substitution
Auto forwarding
Defined Distribution List
Screen shot
PPOSW
PFAC
OOCU_RESP
SBWP/UWL of
Portal
SO12
S023
2/25/2013
<Page 13 of 17 >
<Project>
16
Additional Information/Attachments
TEXT TO BE REMOVED. GUIDANCE ONLY: <
Any information the designer believes to be of benefit to the developer should be attached here. Custom report, any other dictionary objects
necessary for the correct running of the enhancement should also appear here.
2/25/2013
<Page 14 of 17 >
<Project>
17
Unit Test Plan

TEXT TO BE REMOVED. GUIDANCE ONLY: <
Test Condition A phrase that briefly describes the condition/functionality to be tested. Test Conditions should be numbered sequentially.
The number should be indicated with the description. (i.e.: 1. Validate Material Number Screen Field). A Test Condition should comprise one
unique test, not multiple tests that are similar. For example, a correct test condition would include validating one selection screen field, not
validating all the selection screen fields and then listing them as steps of the condition. Each Test condition should appear in its own table row.
Step # The step number within the condition. Each condition will probably have several steps. Steps are the individual actions the unit test
controller must perform in order to test the condition. You can reference previous condition(s) steps as required (for instance, you've already
opened the transaction in the first test condition and now you need to validate the Plant so you'd indicate something like: 2.1 After step 1.5,
enter a valid Plant in the Plant field and press return. Steps within each condition should also be numbered sequentially and include the
condition number first. (i.e., 1.1, 1.2, 1.3, 1.4, 2.1, 2.2, 2.3, 3.1, 4.1, 4.2, etc)
Step Description The description of the action to be performed for each step number.
Test Data The actual data to be used for the test step or, if data is not available, give a business description of the data needed to test the
step (i.e., customer number = 40389). Actual data used during final test run should be recorded here if only a business description was
provided initially (this can also be done by referencing a screen shot of the selection screen showing the inputs).
Expected Result The output or action that should occur according to the specification. Expected Results should describe the screen or
output appearance, indicating the fields, lists, etc. with expected values, error messages with message text, etc. Also indicate where to verify
the data. This verification should be made via SAP transactions (not just table) whenever possible. For example, for an output that displays
purchase order information could refer the UTP controller to transaction ME13 (Display Purchase Order).
Actual Result What actually happens. By the time you're done testing and fixing this should match your expected result. If actual result
matches expected result, enter 'As Expected' in this column. If you're really spiffy, you'll indicate the page number your screen shot(s) for the
test occur on in the UTP Results Document. Other possible entries include "Failed", "Not Tested", "Partial Failure", and "Not as expected but
acceptable".
2/25/2013
<Page 15 of 17 >
<Project>
Remarks Comments on the test (indicates specific work around to be performed, if the test couldn't be performed adequately because of
data, etc.) Difference from expected results should be indicated. The implications of a not "as expected" test should also be noted. (What
problems might result because the condition couldn't be tested or failed.)
Executed By/Date Date executed and test controller's initials.
Additional UTP Guidelines
Unit test results should be screen-printed and included in the UTP Results Document. Results should be cross-referenced to the appropriate
unit test plan step by indicating 'Step 1.1', etc. plus a description. This step number and description should be placed just above the screen
print in the UTP Results Document (see the instructions in the UTP Results Document for more details). All selection screen entries and
corresponding results appearing during execution of the UTP should be screen-printed and cross-referenced.
The following should be tested in the UTP:
Defaults
All calculations
Check that database selects are returning the correct data
Check return codes
Screen flows are correct
Screen information is correctly displayed
Database updates/modifications are correct
Standard header is used (if applicable)
Sorts are correct
Subtitles are correct
Negative signs on numbers are in the right place
Any rounding is occurring correctly
Any truncation is occurring correctly
If there is no data to be displayed, an appropriate message occurs
Any error checks and/or validations performed by the program etc
2/25/2013
<Page 16 of 17 >
<Project>
Normal Functionality - test cases that ensure the workflow functions as it should. (e.g. updates fields correctly, processes all records)
Test
Condition
Step
Step Description
Test Data
Expected Result
Actual Result
Executed
By/Date
Remarks
Exception - special logic or exceptions (e.g. do not process Government Markets customers, only process pre-packs)
Test
Condition
Step
Step Description
Test Data
Expected Result
Actual Result
Executed
By/Date
Remarks
Actual Result
Executed
By/Date
Remarks
Error Handling - functionality in case of errors (e.g. Customer not found, Record already exists)
Test
Condition
Step
Step Description
Test Data
Expected Result
2/25/2013
<Page 17 of 17 >

Workflow Definition Document (WTD) Template PDF

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Workflow Definition Document (WTD) Template PDF

Загружено:

Авторское право:

Доступные форматы

<Project>

<XXXXXX> Technical Specification

Technical Design Specification - Workflow

Last Revision Date

Workflow Definition Document (WTD) Template.DOC

<XXXXXX> Technical Specification

Reason for change

Workflow Definition Document (WTD) Template.DOC

<XXXXXX> Technical Specification

General Information ________________________________________________________ 4

Description and Purpose ____________________________________________________ 5

SAP Workflow Diagram _____________________________________________________ 6

TEXT TO BE REMOVED. GUIDANCE ONLY:_________________________________________ 6

Business Object Information ________________________________________________ 7

Workflow Definition ________________________________________________________ 8

Responsibility Agents: __________________________________________________________ 9

Steps in Workflow ________________________________________________________ 10

Deadline Monitoring Requirements: _________________________________________ 12

Security/SAP Authorization Requirements: ___________________________________ 12

Reporting/Form Requirements: _____________________________________________ 12

Custom screen design (if any) ______________________________________________ 12

Custom Tables/Structure in SAP (if any) ______________________________________ 12

User Exit / Enhancement Detailed Description _________________________________ 13

Configuration Information __________________________________________________ 13

Additional Information/Attachments _________________________________________ 14

TEXT TO BE REMOVED. GUIDANCE ONLY: < ______________________________________ 14

Unit Test Plan ____________________________________________________________ 15

TEXT TO BE REMOVED. GUIDANCE ONLY: < ______________________________________ 15

Workflow Definition Document (WTD) Template.DOC

<XXXXXX> Technical Specification

Workflow Definition Document (WTD) Template.DOC

<XXXXXX> Technical Specification

Description and Purpose

<XXXXXX> Technical Specification

SAP Workflow Diagram

SAP Workflow Process Steps:

<XXXXXX> Technical Specification

Business Object Information

Attributes (only mention those used in the workflow template)

Pseudo logic : Mention Logic for custom attributes only.

<XXXXXX> Technical Specification

Method (only mention those used in the workflow template)

Pseudo logic Ref

Pseudo logic: Mention Logic for custom methods only.

EXP Parameter List

EXP Parameter List

Event (only mention those used in the workflow template)

<XXXXXX> Technical Specification

Binding Workflow Container/Event Container: (Please indicate in the middle column

Event Container Element

Workflow Definition Document (WTD) Template.DOC

<XXXXX> Technical Specification

Activity/Send Mail/User Decision/Subworkflow

Workflow Definition Document (WTD) Template.DOC

<XXXXXX> Technical Specification

Wait For Event/Create Events

Workflow Definition Document (WTD) Template.DOC

<XXXXXX> Technical Specification

Deadline Monitoring Requirements:

Security/SAP Authorization Requirements:

Custom screen design (if any)

Technical details of custom screen can be incorporated here . Number of screens