[Xastir-dev] Xastir Requirements Capture

[Gerry Creager]

Tom Russo wrote:
> 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.

A well-formed feature request with a valid use-case can become a 
requirement.  Requirements are consensus-derived but usually obvious to 
most/all.

In other words, if there's a feature we all agree is neat, it can become 
a requirement.

> 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.

My personal favorite is rampant fiction, where reality never enters into 
the discussion of the request.

> 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.

Yes.  Strongly concur.

> 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.
> ---------------------------------------------------

Yes.  Great start.

> 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.
> 

-- 
Gerry Creager -- gerry.creager at tamu.edu
Texas Mesonet -- AATLT, Texas A&M University	
Cell: 979.229.5301 Office: 979.458.4020 FAX: 979.862.3983
Office: 1700 Research Parkway Ste 160, TAMU, College Station, TX 77843