Best of Luck!
The simple truth is that the "securable objects" in AX are not documented. It is trial and error to properly define security until such time as we users or MSFT decides to document the "securable objects". I can tell you that it took us over a month, with the benefit of a third-party tool, to properly secure just 12 actions in AX.
If this were that ERP named after the stuff that oozes out of trees, the securable objects would be full documented both internally and on a web accessible database that turn up in a Google search of the T-code.
There are ways to see which tables (but not securable objects) are used in a form, but I assume you already know that trick.
With regard to the supplied roles, be aware that they are not built on the principle of Least Priviledged Access and should undergo SOD analysis before, during, and after deployment. Since a user can be placed in more than one role and roles can be nested in other roles, SOD must be continuously monitored and tested.