Maybe I have been stuck in space engineering for too long, but what else would you do as opposed to requirements driven?
There is no other way...!
The problem with the design is that all the knowledge is fragmented, so I do not precisely know what goes where with regards to the planning.
Off course the different varieties can be different URIs, it makes NO SENSE not to do that.
Lets add use cases instead, do we have more?
Eric PA2EON identified the with to also upload and store data, but I do not agree that this should be part of the system. It is the satellite teams responsibility to gather the data, for example, FUNcube warehouse or Delfi-C3 RASCAL database.
let me add the customers to the lines as I see it. In this case with community I mean for public viewing on a website or list. Viewing with an app would be applications, and digesting the list with a tracking program would also be applications.
- Dcarr alike satellite status reporting - customer: IARU, community, applications
- Overview of active satellites including frequencies and modulation types - customer: IARU, community, applications
- IARU coordination data - customer: IARU, community
- Machine readable output for software - customer: applications
- Tracking app on website - customer: community
- list of decoders / modems etc - customer: community
- list of central warehouses - customer: community, applications?
So the three main "output models" are
- machine readable (for this there is the XML thread)
- Human readable, various websites
- IARU coordination website - only accessible for officials
Human readable is just another form of machine readable with presentation added to it.
The meat is really in defining the database scheme, the JSON and XML schemes. After that, the actual coding is not so much of a problem.
When I think about it....maybe designing a database is not blindingly obvious to everyone, but it is to this group, as this forum is specifically
set up for discussing the software models.
Keep in mind that gluing things together is not