IQX FAB Demo Apps Functional Checklist

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

Task Details required/ OPTIONAL / RECOMMENDED

Functional Checklist

Functional Checklist
Design
Task	Reviewed By	Review Date
Functional Specification required Functional Discussion complete Non-functional Requirements complete Cutover implications - has this been considered? 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?	@Reviewer	Aug 6, 2021
Test Scenarios required Performed by IQX Business Analyst or Test Specialist High-level scenarios that answers “What do we need to test?”
Test Cases required 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 required Performed by Business User Test Data that covers all positive and negative Test Cases.
Workflow Functionality (if applicable) required 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) OPTIONAL Is it required to make Approvals available in OneList?
Post-mortem and team feedback required 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 required 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 required 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) required 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 required 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 required 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 required 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 required 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 required 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.
Handling of Sensitive Data where possible Optional Performed by IQX Developer To avoid exposing sensitive data, avoid using Standard Search Helps. Instead, use OData service 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 required Performed by IQX Developer Read and follow the SAPUI5 Securing Apps Guidelines.