Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Page Properties

Please use format: Task Details REQUIRED / OPTIONAL @Assignee by //Completion Date

  •  Task Details
    Status
    colourRed
    titlerequired
    /
    Status
    colourGreen
    titleOPTIONAL
    /
    Status
    colourYellow
    titleRECOMMENDED

Functional Checklist

Design

Task

Reviewed By

Review Date

  •  Functional Specification
    Status
    colourRed
    titlerequired
    Rick Villa (Deactivated) by
  •  Functional Discussion complete
  •  Non-functional Requirements complete
  •  Cutover implications - has this been considered?
Expand
titleℹ️ More info

Performed by IQX Business Analyst and Business User or BA

Functional requirements define what the system does or must not do.

Target devices (laptop / desktop / 2-in-1s / Pad / phone)
Theming / Colours / Logos

Assumptions

Expected Volume
User experience (restrictions / guidelines / client needs)

Non-functional requirements specify how the system should do it. These includes the following:
Target UI5 version
Target browsers
Deployed to cloud / on-premise
Fiori LaunchPad or FAB LaunchPad
Scanners to be used?
OCR to be used?

Rick Villa (Deactivated)

@Reviewer

  •  Test Scenarios
    Status
    colourRed
    titlerequired
Expand
titleℹ️ More info

Performed by IQX Business Analyst or Test Specialist

High-level scenarios that answers “What do we need to test?”

  •  
  •  Test Cases
    Status
    colourRed
    titlerequired
Expand
titleℹ️ More info

Performed by IQX Business Analyst or Test Specialist

Test Cases are the set of positive, negative and exceptional executable steps of a test scenario which contains the following:

Pre-conditions, Test data, Expected result, Post-conditions and Actual results.

  •  
  •  Test Data
    Status
    colourRed
    titlerequired
Expand
titleℹ️ More info

Performed by Business User

Test Data that covers all positive and negative Test Cases.

  •  
  •  Workflow Design Functionality (if applicable)
    Status
    colourRed
    titlerequired
Expand
titleℹ️ More info

Performed by IQX Business Analyst or Business User

Complete flow, including all variations / paths.
Identify possible system tasks where the user that does the approval does not have the rights / auths to execute the next step.

  •  
  •  Integration with Onelist (if applicable)
    Status
    colourGreen
    titleOPTIONAL
Expand
titleℹ️ More info

Is it required to make Approvals available in OneList?

  •  Post-mortem and team feedback
    Status
    colourRed
    titlerequired
Expand
titleℹ️ More info

Performed by IQX Developer, IQX Business Analyst and IQX Project Manager

- Did we meet the customer brief?
- What did we do well during this project?
- What did we do poorly during this project?
- What did we not foresee when planning for this project?
- What cool technology / software components did we build (that can maybe be reused in other projects)?
- Did we meet the budget for this project? If not, why not?
… and so on

  •  

Security Design Considerations

Task

Reviewed by

  •  Plan OData Services
    Status
    colourRed
    titlerequired
Expand
titleℹ️ More info

Performed by IQX Developer and IQX Business Analyst
Do not use a generic OData service for multiple tasks.
Rather create specific services, each of which can be secured with its own role(s).
Separate functionality by role
For example: Create 2 services for ‘Create’ and ‘Approve’ if they are likely to be executed by 2 different roles
Consider redefining the IQX FAB service so that a separate role can be created specifically for the app.

See documentation Redefine FAB OData Services for Security Reasons.

  •  
  •  Identify validations that can be done on the front-end
    Status
    colourRed
    titlerequired
Expand
titleℹ️ More info

Performed by IQX Developer

This should be limited to ‘cosmetic’ checks, like:

Validity of e-mail address (includes an @ and <period>, etc.)
Regex or other checks for fields that need to satisfy a specific pattern
Type and content validation (integers, numbers, string length, and etc.
(Note that this will likely be validated again on the back-end)

  •  
  •  Identify validations that have to be done on the back-end (server-side)
    Status
    colourRed
    titlerequired
Expand
titleℹ️ More info

Performed by IQX Developer

All authorization checks
All business rules/validations
All checks for data correctness (before passing to a BAPI or persisting in a table)

  •  
  •  Consider all content that has been included in the FAB Data Model
    Status
    colourRed
    titlerequired
Expand
titleℹ️ More info

Performed by IQX Developer

Storing any sensitive data in the Data Model is not advisable.
If sensitive data has to be stored in the Data model, the developer has the option to use methods inherited from the FAB Base Class to:
1. Encrypt the data before sending to the front-end.
2. Decrypt the data before using it in the back-end.

The developer can tick the ‘Encrypt Data’ checkbox on the Project Properties page to prevent sensitive data from being persisted in the FAB tables.

  •  
  •  When passing data to BE / FE, consider sending only part of the Data Model
    Status
    colourRed
    titlerequired
Expand
titleℹ️ More info

Performed by IQX Developer

When calling a FAB Action, limit the amount of data being sent.

  •  
  •  Ensure ‘JavaScript mapping’ has been removed before sending App to QA or PRD
    Status
    colourRed
    titlerequired
Expand
titleℹ️ More info

Performed by IQX Developer

For example: //# sourceURL=journal_upload.js
This line of code has to be deleted before it is moved to production, as it gives a developer the ability to change the code during run-time.

  •  
  •  Avoid using ‘Local Storage’ in the browser for any application/user data
    Status
    colourRed
    titlerequired
Expand
titleℹ️ More info

Performed by IQX Developer

Local Storage in browser inherently insecure and possibly shared with other apps.

  •  
  •  For reporting and analytics, ensure that authorizations are applied to the data before displaying/using
    Status
    colourRed
    titlerequired
Expand
titleℹ️ More info

Performed by IQX Developer

Avoid doing SELECTS with no consideration of the data that might be retrieved.

Alternatively strategies might include:
1. Using BAPI’s or other standard SAP-provided mechanisms to retrieve data. Auths are checked in BAPI’s already.
2. Checking a user’s access or performing manual authorization checks and using the results to filter the data.
3. Do not extract all the data and apply a filter but rather build a Range (or set of Ranges) of acceptable values. Use the SELECT statement to retrieve only valid values.

  •  
  •  Avoid using standard Search Helps Handling of Sensitive Data where possible
    Status
    colourGreen
    titleOptional
Expand
titleℹ️ More info

Performed by IQX Developer

Avoid To avoid exposing sensitive data, avoid using Standard Search Helps and .

Instead, use OData service instead where you can control the data that is returned (auth checks, business rules, etc.) and secure the OData service with authorizations.

  •  
  •  Consider the SAP UI5 guidelines on security
    Status
    colourRed
    titlerequired
Expand
titleℹ️ More info

Performed by IQX Developer

Read and follow the SAPUI5 Securing Apps Guidelines.

  •  

...