FUNCTIONAL SPECIFICATION

INSPECTION PLAN CREATE AND CHANGE TRANSACTIONS ENHANCEMENT

(QP01 AND QP02)

Produced by: November 21, 2017

Jabil IT Revision D

Page 1 of 10
 Table of Contents

1. SPEC GUIDELINES / INSTRUCTIONS ............................................................................................................ 3

2. DOCUMENT HISTORY – (MANDATORY) ...................................................................................................... 4
3. REFERENCE DOCUMENTS – (IF ANY EXIST) ................................................................................................. 4
4. KEYWORDS............................................................................................................................................... 4
5. INTRODUCTION / OVERVIEW..................................................................................................................... 5
5.1 CURRENT STATE .................................................................................................................................................. 5
5.2 FUTURE STATE .................................................................................................................................................... 5
6. ASSUMPTIONS.......................................................................................................................................... 6
7. FUNCTIONAL REQUIREMENTS ................................................................................................................... 6
8. NON-FUNCTIONAL REQUIREMENTS ........................................................................................................... 6
9. IMPACTS ................................................................................................................................................... 7
10. USER INTERFACES / SELECTION SCREEN LAYOUT (MANDATORY FOR SAP FIORI AND PERSONAS) ............... 7
11. NAVIGATION ......................................................................................................................................... 7
12. ON-SCREEN DISPLAY .............................................................................................................................. 7
13. OUTPUTS .............................................................................................................................................. 7
13.1 TO SCREEN ........................................................................................................................................................ 7
13.2 TO PAPER .......................................................................................................................................................... 7
14. DATA ELEMENTS / MAPPING .................................................................................................................. 7
15. PROCESS FLOW ..................................................................................................................................... 7
15.1 USER FLOW ........................................................................................................................................................ 7
15.2 SYSTEM FLOW .................................................................................................................................................... 8
16. TECHNICAL ARCHITECTURE / DESIGN AND SIGNOFF (OPTIONAL, BUT RECOMMENDED) ........................... 8
16.1 TECHNICAL DOCUMENTS ...................................................................................................................................... 8
16.2 NOTES TO DEVELOPER .......................................................................................................................................... 8
16.3 ZRANGE ENTRIES APPLICABLE (YES / NO) .............................................................................................................. 8
17. SECURITY DETAILS (SAP T-CODE / ROLE ASSIGNMENT) ............................................................................ 8
17.1 SEGREGATION OF DUTY CONSIDERATIONS ................................................................................................................ 8
17.2 AUTHORIZATION OBJECTS (MANDATORY FOR SAP FIORI) ........................................................................................... 8
17.3 WEB APPLICATION (YES / NO) ............................................................................................................................... 9
18. TESTING SCOPE AND REQUIREMENTS (MANDATORY) ............................................................................. 9
18.1 SCENARIO DESCRIPTIONS AND EXPECTED RESULTS ...................................................................................................... 9
18.2 SCOPE OF TESTS (LIST ALL ASPECTS AS TO WHAT THE TEST SCRIPTS SHOULD CONTAIN) ....................................................... 9
18.3 ASSUMPTIONS .................................................................................................................................................... 9
18.4 PREREQUISITES (LIST ALL MASTER DATA ELEMENTS THAT ARE TO BE USED/CREATED, AND ORGANIZATIONAL OBJECTS THAT NEED
TO BE CONSIDERED) ......................................................................................................................................................... 9

19. APPROVALS (MANDATORY).................................................................................................................... 9

19.1 REQUESTOR APPROVAL (SCREENSHOT REQUIRED): .................................................................................................... 9
Page 2 of 10
 1. Spec Guidelines / Instructions
1.1 New Folder Structure:
A. All Functional specs should be placed into a Business Process folder in Solution Documentation.
Example:

1.2 New Naming Convention

A. For any documents that will be stored in SolDoc, the naming convention should be as follows:
• First 4 characters - Document Type
• Underscore (_)
• Next few characters - Module or Business Scenario (use your discretion)
• Underscore (_)
• Remaining characters - Short Description of Object or Test
Examples:
1. ZFSE_SD_ZSD_Billing_Extract_Change.docx (Functional Spec Document for ENHANCEMENT)
2. ZTSE_SD_001_ZSD_Billing_Extract_Change.doc (Technical Spec Document for ENHANCEMENTS)
3. ZCON_SD_Delivery Item Text Element (Configuration Document)
4. ZTST_SD_Netapp_Label (Test Script Document)
B. These document names should not contain any IM/SR/PR numbers. The reason for this is that we
are following the best business practice of having one functional spec document per object/app. Thus the
name needs to be generic to the object level. This will give us one historical document per object, making
it easier to research and troubleshoot. There will no longer be multiple versions of the same document.
1.3 New Document Content Rules:
A. Additions and changes to a document should be identified with 5 asterisks, “Start Version
<version #>” , a space, and 5 asterisks. An example is as follows:
*****Start Version X *****
Description of changes
*****End Version X*****
B. No highlighted text is to be used unless highlights are actually needed in the function.
C. Title should contain function and/or program name if possible.

Page 3 of 10
 2. Document Histor y – (Mandator y)
Author Name Requestor Date Reference** Description/Section(s) Affected Version Revision Transport(s)
Purna Chitta Mike Yoos 04/18/2018 QM – The enhancement helps to limit the
Consolidated number of dynamic modification
Hector
Deltas and rules applicable/ available for
Marin-Diaz
Gaps list inspection plan for a material/ plant
combination. Without this
enhancement user will see several
dynamic modification rules on the
screen for inspection plans.

**PR number, IM number, etc…

3. Reference Documents – (If any exist)

Title Link

4. Keywords
Inspection Plan Dynamic Modification Rule

Page 4 of 10
5. Introduction / Overview

5.1 Cur rent State in standard S/4 system:

Transaction QP01/ QP02 is used to create/ change the inspection plans. Dynamic modification rule
which adjusts the scope of inspection is attached to Inspection Plans at header level. To meet
requirements of all plants Dynamic Modification rule created and this list appears in QP01/ QP02
transactions while creating or changing inspection plans. In order to restrict the number of dynamic
modification rules available to users while working with QP01 or QP02 transactions, an
enhancement is currently used for these transactions.
Following screen shows the standard SAP QP02 screen layout. Note that Dyn Modification Rule is
selected from a drop-down list.

5.2 Future State

The same enhancement which is in ECC is proposed to be used in S/4 environment to limit the
available Dynamic modification rules per material/ plant.

Following screen shows to be scenario, where the Dynamic Modification rule is selected based two
Radio buttons: LV5 and LV6. This setup is needed for the EMS S/4 Pilot Project implementation.

5 of 10
 As seen on the right side of the screen capture above, this enhancement should provide two
Dynamic modification rules with Radio button for QP01 and QP02 screens for EMS Creston Pilot
Project.
Additional details could not be collected on the current enhancement as no access for ECC system
is granted at the time these specs are prepared.

6. Assumptions
Assumptions are things that are believed to be true but have not b een confirmed. Generally
speaking, any assumptions that are not met become a risk. Enter N/A if there are no assumptions.

The test system will have data available to support the development of this enhancement.

7. Functional Requirements

Each requirement should be able to be traced to a test scenario.

8. Non-Functional Requirements

The quality attributes, design and implementation constraints, and external interfaces that the
product must have. Non-functional Requirements are also known as the following terms:
Constraints, Quality Attributes, Quality Goals. Enter N/A if there are no constraints.
Requirement 1

6 of 10
9. Impacts

10. User Interfaces / Selection Screen Layout (Mandatory for

SAP Fiori and Personas)

Provide an example and/or mock up of desired screen fu nctionality. After each mockup, please provide
detailed information about the requirements. These requirements should be cross referenced in the
Systems Requirements section.

11. Navigation

12. On-Screen Display

13. Outputs

13.1 To Screen

13.2 To Paper

14. Data Elements / Mapping

Provide data elements/mapping in the table below. Titles can be changed to meet the needs of the
application.

15. Process Flow

15.1 User Flow

Where applicable, provide a flow chart depicting the process the user will follow.

7 of 10
 15.2 System Flow

Where applicable, provide a flow chart depicting the process the system will follow.

16. Technical Architecture / Design and Signoff (Optional, but

recommended)

16.1 Technical Documents

Add screen shot under the table below from the Development Architect or Tech Lead, which contains the
approval, date (not “today”) & FS Version being approved. This will help speed up a spec approval.

Date FS Approver Notes/Links (if necessary)

Approved Version (Dev. Architect/Tech Lead) Tech Spec Names (if known)

16.2 Notes to Developer

16.3 ZRANGE Entries Applicable (Yes / No)

17. Security Details (SAP T-code / Role Assignment)

17.1 Segregation of Duty Considerations

17.1.1 What standard transaction is this custom T-code similar to or “like”?

17.1.2 What activity Group will be used to hold the T-code of this program?
17.1.3 In case of a custom program, what security objects should be considered for
access control?
17.1.4 Has this T-code been reviewed by Corporate Finance?
17.1.5 Will this T-code be required to be entered in SAP Risk Analysis and
Remediation application (Compliance Calibrator)?

17.2 Authorization Objects (Mandator y for SAP Fiori)

In case the request is for SAP Fiori, the application operation (Display, Change, Delete and Create) must
be controlled using authorization objects. Please provide the authorization object details.

8 of 10
 17.2.1 Every new Tcode created must have an authorization check added in the
program. If this is a new Tcode, provide the authorization object(s) to be used.

17.3 Web Application (Yes / No)

17.3.1 If Yes, then need to submit for IT Security testing.

17.4 Data Extraction

17.4.1 Does this spec contain the extraction of data that would be considered sensitive
in nature or may cause legal/license implications? For example, system data that legally
should not be replicated or exposed.

18. Testing Scope and Requirements (Mandatory)

18.1 Scenario descriptions and expected results (to be used to assist

TAAS, Testing As A Ser vice)

18.2 Scope of Tests (List all aspects as to what the test scripts should
contain)

18.3 Assumptions

18.4 Prerequisites (List all master data elements that are to be

used/created, and organizational objects that need to be considered)

19. Approvals (Mandatory)

19.1 Requestor Approval (Screenshot Required):

19.2 DRC Approval (Mandator y, to be completed by DRC Approver ):

Date FS DRC Approver Type of Approval Notes/Comments

Approved Version (e.g. Functional Reviewer) (Offline / Full) (if necessary)

--End of document--

9 of 10
10 of 10