About AeroLeap

Most source files should be available in GitHub

Substantial database and training data will generally be stored on (database service not identified)

This does not need to be fully flushed out requirement documentation, as long as there are some notes helping to give context to the expected changes in behavior from a top / user level, or improvements in technical application that drove changes to implementation.

"Capabilities" which are oriented around the end-users expected behavior, and give context as to why the user wants that behavior. This could also link to videos, and example "test" scenarios that would verify expectations are met. Ideally this would be maintained in an excel document, where capabilities could be assigned stakeholder scores to help assert what capabilities need to take priority for development. These correlate to "Customer Needs" and "Customer Wants" in a single list where all information can be contained and prioritized, but it is important here to focus on end behavior, not an specific solution the customer may think need be employed. It is easy for all of us (end user or designer) to be trapped into a perspective oriented around predestined solution, but in order to make sure we all share the same real objective, it is important to write out the outcome that is expected, not what we imagine a solution could be.

"Design Decomposition Documentation" (referred to occasionally here as DDDs) which can be documented at various "levels" of the engineering design process (mechanical / electrical power / sensors / computer / network / software ) and along different interfaces. But all the individual design decomposition documentation should be able to be collected for a single project to describe in detail how the project proceeded from capabilities to low level implementation. (hardware selection, signal interface definition, material selection, ect). These effectively replace what would typically be called "Requirement" documentation in an organization, as the focus should always be ultimately on meeting the capability, without getting stuck on "requirements", which are often just describing implementation level decisions that were made at another level of the design process. That is - often a decision at one level, is a "requirement" at another. Design decisions and the respective restrictions that they may impose are still valid, but they should not be attributed as "requirements".

How IDs will be designated is yet to be determined, related: I am not a big fan of UUIDs.

Note here modelling language is useful to embed diagrams directly into requirement documentation (such as plantuml)

Requirements should always be decomposed into design decisions with well-defined interfaces and the full dimension of the interface should be described.