Aside from its security layer, systemaccounting code is public for the principal reason that transparency begets trust. Also, encouraging public involvement raises the demand for technical people in government & commerce—an intended consequence since internally developing all features for all users isn't practical for an operation primarily concerned with educating the public on the principles, tools, and benefits of pursuing physics through data science.

You are therefore invited to independently produce whatever feature you wish, then submit a pull request that contains a comprehensive list of the feature's test cases. Features affecting a systemaccounting-hosted interface must be proposed with links to publicly-shared visual elements, style-guide-annotated mock screens, and wire-frames (use Google Drive, Dropbox, etc.). Additional formatting guides will be published for the public's assistance.

Systemaccounting does not accept software requirements in document format since 'Product Requirements' = 'Expected Results'. The preference to skip over high-level requirement documentation is justified by recognizing that code is only marked 'Deployment-Ready' when testing proves 'Observed Results' = 'Expected Results'. Therefore, designers must produce a rigorously-researched and comprehensive list of positive & negative expected results before observed results are produced*. Test cases will be submitted by including a single file formatted according to TestRail's XML bulk import tool in the pull request (JSON-formatted files will be accepted after an 'add_cases' POST method becomes available in the TestRail API). All cases will be located in the '/test/requirements' directory of the project and will be updated regularly with expected & unexpected (identified by bugs) cases. With few exceptions, cases must be automated.

Test case fields using the createAccountDebitSequence as an example:

<title>Selecting createButton on landingScreen displays selectFundingSourceScreen</title>
<references> Pull request ID</references>
<preconditions></preconditions>
<steps>
     1. Navigate mobile web client to http://URL.
     2. Select the createButton after the landingScreen is displayed.
</steps>
<expected>The selectFundingSourceScreen is displayed.</expected>
<buttons>createButton</buttons>
<screens>
      landingScreen
      selectFundingSourceScreen
</screens>
<supplementary_requirements>
     [Link to visual elements](http://URL)
     [Link to style-guide-annotated mock screens](http://URL)
     [Link to wire-frames](http://URL)
</supplementary_requirements>
<cf-dependency-cud></cf-dependency-cud>
<cf-dependency-read></cf-dependency-read>
<api></api>

All screens, buttons, and other design elements will receive a camelCase name and be entered into a publicly-accessible product dictionary to maintain product definition stability, e.g. createButton, landingScreen, selectFundingSourceScreen. Links to publicly-shared visual elements, style-guide-annotated mock screens, and wire-frames will be listed in the supplementary_requirements field according to TestRail's editor guide. Specify names of column families where there is a create, update, and delete dependency. Separately, specify names of column families where there is a read dependency. API dependencies must also be specified.

Once a proposed feature passes a review of its i) test cases, ii) code (unit tests included), and iii) design assets, the feature will undergo testing. Code will be prioritized for deployment after it passes its automated and/or manual tests.

*Note: Systemaccounting advises the public to always offer software engineers what some may wish to deny students, i.e. enable them to code to the test. Supplying engineers the answers to the test before coding begins wards off ambiguity and wasted time since their primary duty is to convert human language into machine language; not predict the yet-to-be formed ideas in other people's minds. Just as incomplete code may reveal a careless and/or unskilled engineer, incomplete requirements tend to reveal a lazy and/or indecisive product designer (often found advocating that passion may be substituted for well-thought-out ideas, thus shifting away the liability of an undiscovered fatal flaw to others, and leaving much of the intellectual work to be completed by individuals who acquired the discipline of completing their homework assignments & studying for exams in school). Stated plainly, product designers who fail to task engineers with test cases pose as much risk to a project as engineers who fail to test their own code.