Reading: Jackson

The second paper I will ask you to read concerns requirements analysis and specification:

Jackson, M. 1995. The world and the machine. In Proceedings of the 17th international Conference on Software Engineering (Seattle, Washington, United States, April 24 - 28, 1995). ICSE '95. ACM, New York, NY, 283-292. DOI= http://doi.acm.org/10.1145/225014.225041

This is among the most lucid accounts I know of what it means to write a specification. The writing is light-hearted (the paragraph about steering mechanisms for cars busts me up laughing), but it's a very serious and deep consideration of the topic ... it's worth reading more than once, and thinking carefully about.

The paper accompanied an invited (keynote) talk at the International Conference on Software Engineering. Two years later, Jackson and Zave published a journal paper which encompasses some of the same material. If you like this paper, you might (at your option) follow on with:

Zave, P. and Jackson, M. 1997. Four dark corners of requirements engineering. ACM Trans. Softw. Eng. Methodol. 6, 1 (Jan. 1997), 1-30. DOI= http://doi.acm.org/10.1145/237432.237434

Quantitative and ordinal attributes

In discussion of what the OSB map should include, two quantitative attributes were mentioned:

• Incline (e.g., slope of a path or lawn)
• Width of a sidewalk

Incline is the most interesting of these, because unlike the width of a sidewalk (which would be at least represented by width of an area in the map display), we currently don't have a way to represent incline at all. Note that it is distinct from, and perhaps orthogonal to, the kind of object — a sidewalk can have an incline, and a lawn can also have an incline. Moreover, incline is relative and directional: We care about grade, not altitude, and the same location can be inclined upward, downward, or level depending on which direction one is walking.

In tactile maps, there are symbols indicating incline.

The current soundscape map system has no provision for such attributes, nor is there a way to describe them in the style sheet language. My first thought is that we probably need ways of modulating existing sound cues (e.g., altering pitch) in a way that maintains the meaning of the cue ("this is a sidewalk") and conveys additional information. It might be ok to discretize quantitative attributes, for example representing incline only by one of the discrete categories "steep down", "down", "level", "up", "steep up".

We don't absolutely have to come up with ways of handling such attributes this term, but it's on the "wish list" for things that you may consider if it fits in your development schedule. As I said in class Wednesday, your project should be structured as a sequence of increments, so that the question is not when you are done but rather what you get done. (This is a very common approach to system design and project planning when deadlines are inflexible.)

Notes from OSB visit, 3 Oct 2008

I accompanied Prof. Amy Lobben to Oregon School for the Blind (OSB) in Salem Friday, along with a geography student who is gathering raw data for the OSB map using a GPS unit. We met primarily with Bob Disher, Technology Specialist at OSB. Here are a few notes on that visit and what I learned.

The OSB campus is smaller than University of Oregon campus, and the map will be quite a bit simpler, with fewer layers (classes of object). Objects to be included in the map include at least the following:

• Buildings
• Some rooms within buildings
  
  • Auditorium, media center, main office, infirmary, dining hall
• Some main doors to outside
• Parking lot
• Sidewalks
• Campfire pit (a meeting place)
• Sensory garden (as a single object)
• Major features of the immediately surrounding area
  
  • Cross streets
  • Intersections

An interesting issue that came up, and one that has not been considered in our soundscape map work to date, is representing attributes like incline (slope) and the width of sidewalks. I'll make a separate post about that.

In discussions about longer term trajectory for the project, Bob asked about producing maps from data that is not in a geographic information system, e.g., from a plan of a building that is in terms of relative positions but not referenced to lattitude and longitude. This seems conceptually straightforward (it really shouldn't matter to us whether the coordinate system is degrees or feet, or where the origin is), but it does suggest that our earlier discussion about not tying our input data format too tightly to a fixed GIS data source is in fact relevant.

In a separate discussion with Amy, on the way to Salem, I asked whether we should be considering GIS systems other than those of ESRI (the company that makes ArcGIS). Amy said that, while GIS systems sometimes do provide some limited interoperability by reading other data formats, in practice ESRI dominates the field so strongly that supporting ESRI formats is enough for handing pretty much all GIS data we are likely to encounter.

The meeting was quite loosely structured, and in addition to needs for the current project, we discussed the way the project has evolved and the way it involves students. Bob Disher extended an invitation for us to visit OSB as a group. I'll write a separate post to discuss that possibility.