About the Project Specification

This spec is a description of what the final product should look like. It's basically the list of what the customer (NCSSAR) needs.

As with any contract product development process, the spec is an evolving, living document. Requirements may change as software is field-tested. Advice from software developers is welcome.

The spec can be intentionally vague, leaving a lot of freedom for the developer, or, it can be highly specific. In general, the developer has to meet the wording of the spec, so any part of the spec that is vague can be developed in whatever manner the developer chooses.

PLEASE NOTE: There is an extremely high bar for the decision to start using any computerized T-card system, as spelled out in the README.md file. Software used for search and rescue purposes must be robust, reliable, fault-tolerant, forward-maintainable, and extremely user friendly. A software fault during a search and rescue operation could endanger the lives of volunteers or search subjects, so every contribution to the software will be reviewed according to those goals. Developers should stay in close contact with the project lead(s) regarding implementation plans, thoughts about what platform(s) to use, etc, before investing much time in any direction.

Separately, the project lead is not the one to ultimately decide whether this system will work for the entire SAR team. The actual 'customer' in this scenario is the SAR leadership and the incident command team as a whole, which will bring many more considerations in to play. The project lead is on the incident command team and can try to predict many of the team's requirements, but does not have the final say.