-
Notifications
You must be signed in to change notification settings - Fork 1
T card 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.
This spec is broken into three parts: 'requirements', 'nice-to-haves', and 'ideas'. All items should begin in 'ideas'. If the items in the 'ideas' section get fleshed out and agreed upon to a sufficient level of detail, they can get promoted to 'requirements' or 'nice-to-haves' as appropriate.
- sign-in interface: fast electronic sign-in at the logistics table (by whatever means) is the entry point for this whole process
- networked: server/client configuration on a local wifi network, without internet access
- real-time updating: new sign-ins from any node should be visible to all other nodes 'instantly'
- cross-platform: Windows server; Windows, iOS, Android clients
- robust: double-redundant or better real-time automatic backups both digitally and on paper (to networked printer); also fault-tolerant enough to allow the system to keep working - on paper if needed - if any or all parts of the system fail for any duration
- xml-based T-card file format (.tml?): one file for each human - each county keeps updated .tml's ready to go for mutual aid - privacy factors in here somehow
- categorization: accommodate the various T-card data fields and figure out how to display and group them appropriately
- touch-screen interface: ops could build teams on a large touch-screen inside the trailer, with an interface that looks and behaves like a T-card sleeve (and updates are instantly visible on all other nodes)
- automatic printing of names, callsign, etc on assignment forms: does sarsoft already provide for this in any way? If not, can the sarsoft-generated assignment form PDF be a fillable form that this program can automatically fill out and print?