Workflow Definition Document (WTD) Template.pdf

Technical Specification

Workflow Definition Document (WTD) Template.DOC 2/25/2013

Technical Design Specification - Workflow

Version :

Document Status : Review[Draft/Review/Signed Off]

Author :

Last Revision Date :

Date Created :



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



Table of Contents

1. General Information ________________________________________________________ 4

2 Description and Purpose ____________________________________________________ 5

3 Assumptions: _____________________________________________________________ 5

4 Issues ___________________________________________________________________ 5

5 SAP Workflow Diagram _____________________________________________________ 6

TEXT TO BE REMOVED. GUIDANCE ONLY: _________________________________________ 6

6 Business Object Information ________________________________________________ 7

7 Workflow Definition ________________________________________________________ 8

Responsibility Agents: __________________________________________________________ 9

8 Steps in Workflow ________________________________________________________ 10

9 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



1. General Information

Functional Design Spec ID:

Implement. Phase

Message Class:

Develop. Class:

Module:

Workflow User/User Group:

Region / Country

Contact Details:

Prepared By Prep Date:

Phone Number:

Email Address:

Business/Functional Analyst:

Phone Number:

Email Address:

Run Frequency Languages

Priority: Complexity:

Transport Information

Change

Request #

Task #

Object Identifier

(Program ID, Layout Set

ID, etc)

Object Type

(Program, Transaction, Layout

Set)



2 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

3 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

4 Issues




>


Issu

e #

Date

Raised

Issue Description Issue Resolution

5 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.



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.

6 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

Dictionary Field Pseudo

logic

Ref

Virtual

Database

Multiline

Mandatory

Instance- independent

A1

Virtual

Database

Obj Status

Multiline

Mandatory

Instance- independent

A2

Pseudo logic : Mention Logic for custom attributes only.

A1:

A2:



Method (only mention those used in the workflow template)

Name Description Source Result Type ABAP Pseudo logic Ref

Dialog

Synchronous

Result parameter

Instance independent

Function Module

API

Transaction

Dialog Module

Reports

Others

M1

Dialog

Synchronous

Result parameter

Instance independent

Function Module

API

Transaction

Dialog Module

Reports

Others

M2

Pseudo logic: Mention Logic for custom methods only.

M1 Pseudo logic:

Parameter List

IMP EXP Parameter List Mutiline

Exception

M2 Pseudo logic:

Parameter List

IMP EXP Parameter List Mutiline

Exception

Event (only mention those used in the workflow template)

Name Description Parameter List Import Export

7 Workflow Definition

Abbreviation: Number:

Name:

Triggering Events:



Object Type:

Event:

Workflow Container:

Eleme

nt

Description Impor

t

(Y/N)

Expor

t

(Y/N)

Multiple

Values

(Y/N)

Mandator

y

(Y/N)

Dictionary

Field

Object

Type

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 Notification



8 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 Type-

Method

Property Agent Agent

Assignment

Secondary

Methods (if

any)

Terminating

Event

Triggering

Event

Work Item

subject/Text

Others

Background

Confirm end Of process

Background

Confirm end Of process



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

Expression Operator Expression



9 Deadline Monitoring Requirements:

Task Name Deadline Time Agent Type

10 Security/SAP Authorization Requirements:

Task Name Role SAP Authorization

11 Reporting/Form Requirements:

Description SAP Tool Report Name Custom

Requirements

12 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 Name

Data Element Domain Type Length Check Table-Field

Key Field

Foreign Key

Description



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 Screen shot Delegation SW01

Type Linkage SWETYPV

Instance Linkage SWEINST

Workflow Start Condition SWB_COND

Change Document SWEC

Status Management BSVW

Message Control NACE

Organization Structure Display

PPOSW

Rules PFAC

Responsibility for Rules OOCU_RESP

Setting Substitution SBWP/UWL of Portal

Auto forwarding SO12

Defined Distribution List S023



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.




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".



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




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


By/Date

Remarks

Error Handling - functionality in case of errors (e.g. Customer not found, Record already exists)

Test

Condition


By/Date

Remarks

Documents

Workflow Definition Document (WTD) Template.pdf