[Xastir-dev] Xastir Requirements Capture

[Tom Russo]

Ok, I've been kicking around a strawman for "Xastir-NG" requirements
capture, and would like to get the ball rolling.

To start: Requirements are not Feature Requests.  If we let the discussion
start becoming feature requests, it will bog down and go nowhere -- which is
precisely what has happened every time "Xastir-2" has been brought up.

In proper software engineering terms, Requirements really are meant to be the
constraints that guide design choices.  Feature specification winds up being
done by "use cases" or "user stories" depending on what style of development
process one adopts.

What I desperately want to see out of this set of discussions is a commitment
to developing a coherent, extensible, flexible architecture for Xastir-NG,
to avoid it becoming what Xastir 1.x is now: a really neat collection of 
incoherently implemented features in an unmaintainable, band-aided code.

So, without further ado, my very, very first cut at requirements.


-------------------------------------------

- Support the full APRS spec.
  - Be flexible and extensible so that it can accommodate the arbitrary, 
    often poorly-specified "addenda" that are at this point more abundant than
    features listed in the "official" spec.
  - Non-spec "FUNDAMENTAL CONCEPTS(TM)" such as decaying algorithm for 
    transmission rates such as are routinely lamented as absent from 
    most APRS clients in rants by someone who shall remain nameless.
- Be extensible to allow support for existing and future non-APRS protocols 
  (e.g. OpenTrac, AIS, etc.).
- Cross-platform portability to at least:
   *nix/X11 variants
   Windows
   Non-X11 windowing platforms (e.g. Mac OS X's native windowing system)
   (list to be extended with discussion)
- Support multiple simultaneous sources of real-time data, some of which
  may be bi-directional:
  Examples of likely sources that will be required early: 
  - Packet radio inputs (TNC)
  - APRS-IS
  - Wx stations
  - automatic RDF units
  - GPS receivers
  * Generic, extensible interface to support future data sources and non-APRS
    data sources as needed
- Map display
  - Display all forms of APRS data (part of "support full APRS spec")
    - stations, objects, items, WX, tracks, etc.
    - allow display of other types of real-time, transient information through
      extensible architecture
    - Standard APRS symbology
    - Extensible symbology for non-APRS data
  - user-configurable map information
    - map layers, symbology, labels
  - Support common formats of map data (GIS and non-GIS (e.g. APRSDOS, UI-View, 
    WMS/WFS, etc.) with extensible architecture
  - Allow user interaction with map display
    - query features (real-time and base)
    - Ability to generate APRS data through map interactions
  - Map display and core data interchange/storage code properly encapsulated
    for maintainability, extensibility, flexibility.
---------------------------------------------------

These are obviously just a start, but I've tried to minimize the "feature 
specification" aspects, and focus on things that have either bitten us before
or which I expect could bite us in the future if we don't plan for them 
early in the system design.

I hope that gives a good sense of what I think of when I talk about 
"requirements" specification vs. feature requests, even if I haven't perfectly
eliminated the feature requests from my own thinking.  What I'm trying to get
at is the basic needs of the system that will constrain its design and 
guide design trade-offs.

There's my strawman.  Have at it.

-- 
Tom Russo    KM5VY   SAR502   DM64ux          http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236 AHTB#1 http://kevan.org/brain.cgi?DDTNM
 "It's so simple to be wise: just think of something stupid to say and
  then don't say it."  --- Sam Levinson