RICEFW Functional Design Review Checklist

RICEFW Functional Design Review Checklist

Use this checklist to validate the consistency and completeness of the RICEFW functional design Deliverables at the end of the Design
See the Revision History table at the end of the Document for revision status.

Naming convention: This PR has to be saved as "PR - Functional Design RICEFW ID (Project Code + SAP Module + RICEFW type + gap ID).xls"

Design Checklist

Modified: 11/18/2016 01:41:56

2006 Accenture. All Rights Reserved.

Date

Status

Time

Last modified by: User

RICEFW Functional Design Review Checklist

Revision History
Date

Revision Type

Time Version

Modified: 11/18/2016 01:41:56

2006 Accenture. All Rights Reserved.

Author

Comments

Last modified by: User

General Checks:

#
1

Criteria
1 - Documentation Criteria:
Check the FD uses the latest version of the corresponding design template. The latest updated
Design templated can be found in SolMan --> Project COTY_DOCU --> 0.0 Project Templates -->
Business Processes --> 0.0.2. Design

Functional Design name should follow contain the RICEF ID:

4 first digits: Coty project (for example GRNA -> Green NA)
2 next digits for the SAP module: SD, MM, FI, PP, etc
1 next digit for the RICEFW type:
o I: Interface
o R: Report
o C: Conversion
o E: Enhancement
o F: Form
o W: Workflow
3 last digits are a sequential number
Additionaly, a description that defines the workunit

3
4
5

Functional Design approvers are identified

The Functional Specification is available in SolMan in Project COTY_DOCU
All sections in the FD are populated (If any point does not apply fill with 'Not Applicable' and include
a justification).
Document assumptions are clearly specified.
The development complexity (i.e., Easy, Medium, Difficult, Very Difficult) is defined
Ensure blue comments from the FD template about how to fulfill the document are removed
Ensure FD is using font type Arial and size 11 across all document
English Review is performed

6
7
8
9
10
11
12
13
14
15
16
17
18
19

2 - Functional Criteria:
Explore and incorporate reuse of existing assets into the design where appropriate.
Provide processing details, and clearly define the activities that need to occur during each step in
the end-to-end process.
Document performance considerations/constraints as appropriate.
Impacted SAP Transactions / Tables are detailed
Provide any processing flow diagrams needed
Provide any data flow diagrams needed.
Use of custom tables and append structures are justified and have the approval by CoE (functional
and technical)
Values of parameters/ranges to be include in ZCY001 table in order to avoid ABAP hardcoding has
been clearly documented in the FD
The Functional Design ensure performance optimization of table accesses
3 - Test Criteria:

20
21
22
23
24

Test cases are mandatory and must be documented in the design

Test data is optional in case there is available master data in development environment
Test scenarios include multiple scenarios including unexpected results and error handling
The Test's required or expected results are documented, a guide to create test data and expected
results has been documented.
Specify error handling requirements

25

4 - Authorisation check
Checks related to authorisations that need to be done for the RICEFWs are mentioned in the
corresponding section of the FD.

26

If there are specific values that should be placed in User parameters (su01: Parameter ID and parameter
value), the information has been clearly mentioned in the FD.

27

Check that the authorization objects are mentioned in the FD for the next cases:
- For the custom programs associated to custom transactions, define authorization group in the
attributes of program and specific authorization objects into the code of program using the
organizational units of the selection screen .
- For the all custom transactions, define authorization group to be assigned

28

29
30
31
32

5 - General checks
Check that all references to external documents are clear and any included hyperlinks are correct
Ensure that the document version number is promoted at each stage and the signed off version is
promoted to the next integer
Check that performance criteria include measurable targets and volume estimates
Check that the terminology used in the documented avoids ambiguity by not using words
like'presume'
Verify control sheet updates to include sections changed and details of why the change has
occurred. This should inlcude an increment on the version number of the document.

Status

Status

Status

Peer Review:
Comments/Actions

Quality Revie
Status

Quality Review:
Comments/Actions

Report Specific Checks:

#
1
2
3
4
5
6

Criteria
1 - Report Specific Checks:
Specify the transaction or process initiating the report (with passed information).
Specify the processing type (i.e., batch, synchronous, asynchronous).
Specify the report frequency (i.e., yearly, quarterly, monthly, weekly, daily, etc.).
Document the performance constraints clearly.
Specify the type of output (i.e., online, download to spreadsheet, printer).
Provide a layout of the selection screen. Define the selection criteria clearly. Provide data
elements for each select option and parameter. Depict radio buttons, check boxes, pushbuttons,
and titles. For each selection criteria, indicate whether it is a parameter or a select option,
whether it is obligatory and any required validations. Identify values to use if no data is available
for the field defined.

Specify the summary level (i.e., summary, detail, drill-down). Provide a layout for each report
level (i.e., pictorial representation of the form) specifying report headings, fonts, page-widths,
sorting, page-breaks, calculations, and drill-down requirements.

8
9
10
11

Specify any page break criteria and logic.

Provide control totals and control total calculations.
Specify sort order.
Describe any report interactive capabilities in detail. Specify all the required drill-down methods
(i.e., push-button, double-click, etc.).
Specify any default values required for the report.
Specify menu options.
Specify toolbar options.
Document any potential re-use of prior code.
Specify any field concatenation needed.
Define all of the data formatting (e.g., dates, currency, measurements etc.) required.
Provide report mapping (i.e., identification of tables where this data can be found in packaged
software).

12
13
14
15
16
17
18

Status

Status

Status

Peer Review:
Comments/Actions

Status

Quality Review:
Comments/Actions

Status

Interface Specific Checks:

(Applicable for iWay Interfaces)

P
#
1

Criteria
1 - General checks
The Middleware to be used in the interface (iWay) has been clearly
specified.

The direction of the Interface (Outbound / Inbound) has been clearly

specified.

Scheduling requirements are defined if applicable (frequency of Job

execution is clearly specified)

All input (file names/formats/delimiters, names of database tables

accessed, IDOCs, etc) and output requirements are specified in FD.

For non IDoc interfaces the file name pattern is identified and aligned with
the one expected by legacy

Error Handling requirements (types of notifications, messages/data

contained in notifications) are clearly specified in the Functional Design.

Source & target data structures have been defined.

All process logic fully detailed in FD.

9 If a filter criteria exists it has been clearly defined

10 The routing criteria is clearly defined
11 If any R/3 table access is included in the design, applicable checks
contained in Performance check tag are passed ok
2 - Architecture Team Specific checks
12 It is clearly mentioned in the FD document if the interface is Global or Local

13 Any custom IDOC or any custom message type in use has been explicitly
approved by CoE (segments, message types and way of processing) are
explicitly approved by CoE

Status

14 Any IDoc extension has been documented in FD: document contents

(segments, message types and way of processing) are explicitly approved
by CoE team
15 Where ABAP development is needed for the interface, the design of the
extension has been validated using the Extension check list included in this
document
16 iWay requirements are compliant with the Application Architecture
Specification Integration Services

17 If a filter is needed it will be implemented in iWay, not inside SAP, unless it

can be applied with a simple variant in ECC. Any filter in ECC need can be
approved only by the Project Manager / CoE in charge of the project
release.
3 - Interface Definition checks
18 All fields and logic necessary (including data validation rules, data
derivation/calculation and default values, if applicable) are clearly specified.
19 All values mentioned in theFD that are not Value/key mapping and should
be mantained in each envionment -(D*, Q*, P*), should be specified clearly
in order to Development team implement the information in some
parameters table in iWay.
20 It's clearly specified how the IDOC fields will be populated in master data
objects: Full IDOC (always populating all segments/fields) or Standard SAP
(only fields changed)
21 It's clearly specified type of extraction: Full (all records in database) or Delta
(only records updated/created since last execution)
22 All IDOCS used have been WE19 tested and satisfy functional needs (this
test will ensure interface will work before sending to Development team for
Development)
23 If the interface is delivery is file based, the structure and format is clearly
specified in FD (comma separator file, fixed length, XML file, etc).

24 Both inbound and outbound Sample Files / IDOCs has been received.

25 The method of communication with the legacy system (FTP, AS2, etc.), is
identified.
(This information should be clearly specified in the FD and should be
validated by the Technical Team)
26 ALE configuration set up (Partners, Ports, RFC destication, IDoc type,
message type, etc) is clear and documented in the design.

27 The way an IDOC will be triggered should be defined explicitly in FD:

-->Std way should be the preference avoiding custom programs
-->If std way not applicable, custom way should be clearly identified

28 Output determination (when needed) is aligned with ALE configuration and

specified
29 For an Outbound Master Data interface, change pointers to apply are
clearly specified as well as the way IDOC is triggered
30 It is clearly specified if ABAP job is needed
--> Frequency is defined
--> IDOC process mode is specified (immediately or collect)

31
32
33
34
35
36
37
38
39

4 - Detailed mapping Excel sheet checks

Has the source application data structure been included?
Has the target application data structure been included?
Review that the file structures are in accordance with the ones described in
document.
Transformation logic has been clearly explained to avoid ambiguity and not
pasted from other sources
Has the data mapping been properly defined?
Confirm that all the requirements defined in FD document are included in
Mapping Excel document
Confirm that the Mapping Rules excel document is attached and well
formatted
If mandatory fields are to be mapped, double check if default values are
needed or not
Check that XSD is available inside the FD document in the corresponding
section.
If it is an inbound interface this should be provided by Legacy.
If it is an outbound interface this should be provided by the Integration
Team.

40 All value mapping required is clearly defined in the corresponding sheet

41 All key mapping required is clearly defined in the corresponding sheet
42 Currency format to use in each Currency field it is clearly specified: (format,
number of decimals, different currencies field can deal with).
How negative amounts are going to be formated it is also clearly specified.
43 Quantity format to use in each Quantity field it is clearly specified: (format,
number of decimals, different units of measure field can deal with).
How negative quantities are going to be formated it is also clearly specified.

44 Clearly specify any requirement for leading zeros (ex. Customer id, vendor
id, material id, GL account, etc) for a value

Status

Peer Review:
Comments/Actions

Quali
Status

Quality Review:
Comments/Actions

Status

Conversion Specific Checks:

Peer Re
#
1

2
3
4
5
6
7
8
9

10
11
12
13
14
15
16

Criteria
1 - Conversion Specific Checks:
Identify source and target systems. Specify location of translation (i.e.,
packaged software or partner system) for each required translation.
Provide a process flow diagram, and effectively communicate the end-toend conversion process from a business perspective.
Specify the logical or physical path for the file.
Give accurate data mapping from source and target system (e.g., field
lengths, table name, fields, screen number etc.).
Define default values.
Define data validation rules.
Define data derivation/calculation.
Define all transaction requirements clearly.
Specify reporting requirements (e.g., success, warning, error messages,
totals needed), and create a separate reporting specification for each
confirmation or audit report.

Specify Input or Output File layout/file type for the conversion

Specify transaction volume.
Specify execution frequency.
Define contingency procedures clearly.
Define restart/recovery requirements.
User defined routines to be used are specified
Transformation logic has been clearly explained to avoid ambiguity and
not pasted from other sources
17 Complexity of source data identified preparation requirements identified

Status

Status

Peer Review:
Comments/Actions

Quality R
Status

Quality Review:
Comments/Actions

Status

Extension Specific Checks:

Pee
#
1
2
3

Criteria
1 - General checks
The triggering event of the extension it is clearly specified in the
Functional Design
Technical attributes of the extension are clearly specified in the
Functional Design (Technology used, type of enhancement, etc)
If a custom transaction needs to be created for the Extension; the name
is clearly defined in the Functional Design and it aligned with Coty
naming convention.

It is clearly identified in the Functional Design if the Extension is business

critical.
5 It is clearly identified in the Functional Design if the Extension is executed
in Background or if it is a Front-End Transaction.
6 It is clearly identified in the Functional Design if the Extension has impact
in SAP performance.
7 It is clearly identified in the Functional Design if the Extension can be reprocessed in case of error.
8 In case of Critical and Front End Transactions the Extension has been
reviewed by a Manager of the SAP area involved.
9 The Extension is aligned with SAP Functional Best practices
10 The new custom indexes has been properly approved by CoE and
Architechture teams

Status

Status

Peer Review:
Comments/Actions

Quali
Status

Quality Review:
Comments/Actions

Status

Form Specific Checks:

Peer Review
#
1
2
3

4
5
6

Criteria
1 - Form Specific Checks:
The Form layout is specified (e.g. Invoice is attached).
Special forms or stationery are defined in the Functional Design.
Print Specifications have been specified
- Print Logos
- Print Parameters
- Print Format
- Main Heading/ Sub Heading
The form calling program is specified.
Accurate data mapping is defined. The logic to fill all the fields in the form
are clearly specified in the FD.
Any page layout specifications are defined (and it is aligned with the
information provided in the Development standards regarding Form
layout):
- Page Break
- Page Numbering
- Page Layout

Formatting of data is given (e.g. font size, font type, languages etc.).

Dates format are defined.

Every amount has its currency defined.

10 Layout is harmonized with other similar forms.

11 Every quantity has its unit of measurment defined.
12 Standard texts to be used are defined.
13 Translation have been provided for all (additional) languages.
14 The choice of using Smartforms, SAPscript, Adobe Forms, or others is
clearly defined.
15 Legal requirements or company standards detailed

Status

Status

Peer Review:
Comments/Actions

Quality Review:
Status

Quality Review:
Comments/Actions

Status

Workflow Specific Checks:

Peer Re
#
1
2
3
4

Criteria
1 - Workflow Specific Checks:
Specify the initiation mechanism.
Describe design assumptions and constraints related to the workflow
clearly.
Identify user roles or profiles authorized to run the workflow.
Provide a workflow diagram and a detailed walkthrough describing the
new workflow process, error handling, notifications, and timeouts.

If an existing workflow is going to be modified, include the original

workflow diagram, and describe reasons for modifying the existing
workflow.

Provide a process flow diagram, and effectively communicate the end-toend flow of the extension.
If applicable, describe security considerations such as access levels.

8 Indicate the navigator menu path.

9 Specify and describe input parameters.
10 Identify all new database objects or existing database objects (i.e.,
tables, etc.) that will be created or affected.
11 Define default values.
12 Define data validation rules.
13 Define data derivation/calculation.
14 Specify calling program.
15 Give formatting of data (e.g., font size, font type etc.).
16 Identify and discuss design alternatives including advantages and
disadvantages.
17 Identify the recommended and selected option, and document reasons
for selecting the option.
18 Business Object to be based are defined
19 Triggering Defined (Automatic Standard Event/ Customizing needed)
20 Terminate Event Defined
21 Possible Agents Defined (based HR organizational structure)
22 Agent definition defined (Task (Reasons), Rule)
23 Escalation Needed/Defined
24 Deadline Monitoring Needed/Defined
25 Approve log needed/Defined
26 Rejection Reason management Defined

Status

27 Workflow UWL oriented - Web Screen needed/Defined

28 Workflow Error handling is defined

Status

Peer Review:
Comments/Actions

Quality R
Status

Quality Review:
Comments/Actions

Status

Description

OK
FAIL
N/A

The criterion is met

The criterion is not met
Not Applicable

Applicable
APPLY
N/A

Description
Applicable
Not Applicable

Reviewers
Peer Reviewer
Quality Reviewer

Description
Other functional person reviewing the doc
High level Reviewer

Revision Type

Description

Functional
Peer
Technical
English

Functional review
Peer review
Technical review
English review

Quality

Quality review

Time
0.5
1.0
1.5
2.0
2.5
3.0
3.5
4.0

4.5
5.0
5.5
6.0
6.5
7.0
7.5
8.0
8.5
9.0
9.5
10.0
10.5
11.0
11.5
12.0
12.5
13.0
13.5
14.0

Deliverable Type

Description

R - Report
I - Interface
C - Conversion
E - Extension
F - Form
W - Workflow

Report
Interface
Conversion
Extension
Form
Workflow