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 -- [EMAIL PROTECTED]
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
_______________________________________________
Xastir-dev mailing list
[email protected]
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir-dev
