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
Test Scenarios
Status
colour
Red
title
required
Expand
title
ℹ️ More info
Performed by IQX Business Analystor Test Specialist
High-level scenarios that answers “What do we need to test?”
Test Cases
Status
colour
Red
title
required
Expand
title
ℹ️ More info
Performed by IQX Business Analystor 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
colour
Red
title
required
Expand
title
ℹ️ More info
Performed by Business User
Test Data that covers all positive and negative Test Cases.
Workflow Functionality (if applicable)
Status
colour
Red
title
required
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
colour
Green
title
OPTIONAL
Expand
title
ℹ️ More info
Is it required to make Approvals available in OneList?
Post-mortem and team feedback
Status
colour
Red
title
required
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
colour
Red
title
required
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.
Identify validations that can be done on the front-end
Status
colour
Red
title
required
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
colour
Red
title
required
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
colour
Red
title
required
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
colour
Red
title
required
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
colour
Red
title
required
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
colour
Red
title
required
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
colour
Red
title
required
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.
Handling of Sensitive Data where possible
Status
colour
Green
title
Optional
Expand
title
ℹ️ More info
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.