While a mountaineer might, only somewhat flippantly, tell you that she climb a mountain because “it’s there”, software is normally developed for a specific, singular purpose …
This article detail the development of the application called “TrainTrack”; a very simple, very focused piece of software written here at Greytower. It is not available to the public, and there’s really no plans to make it so. This is about the process.
The purpose of the software is clear: it will monitor train departure and –track information for the long–distance and InterCity trains in Sweden. It will do so in order to facilitate travelling, avoid the dependency on fixed installations such as display boards and monitors in train stations, and finally avoid mistakes such as heading for the wrong track.
When we know the purpose, we can start dealing with specific requirements. This is not a complex system by any measure, but it does have a few peculiarities.
I’m not a requirement expert, as several colleagues might willing attest to, but I do know a trick or two. My first stop is, without fail, the specification–of–specifications: RFC 2119 “Key words for use in RFCs to Indicate Requirement Levels”
This document define, fairly precisly, the phrases “MUST”, “MUST NOT”, “SHOULD”, “SHOULD NOT” and “MAY”. Some of those same requirement colleagues will hate me for it, so I shan’t insist, but personally it’s a set of definitions I prefer using.
These requirements will, in the final stage, be the starting–point for user acceptance, and so must be nailed down firmly. Another personal preference for the nailing process is to use a mindmapper – specifically I would recommend MindJet’s MindManager which, while costly, is probably the best of the bunch*. It’s easy to use and support inclusive modelling by coming very close to human brainstorming.
Let’s split the purpose into more manageable piece:
This can be rewritten as brief, high–level user stories:
The above outline the “what” of the project. During the various design phases, we’ll work out the “how”.
Before we get too far into the meat of the thing, let’s ask “Does something useful already exists”?
The short answer: no. Several *tools* exists, but none of them are useful in this context.
Fist, SJ’s (local train company) website into which you can add a train ID and glean whether it is in route. You won’t get any estimate on which departure is within reach, and it works poorly — to put it mildly — on anything but a desktop browser. Breaks two requirements.
The accompanying smartphone app requires a login (!) to see when a train is due and, again, no estimates, no alerts. Breaks one requirement.
During this phase we’ll try to determine how — in overall terms — to solve the “what”. The result (our output, what we hand over to the next step in the chain) can be referred to as “technical” requirements — and one technique is to turn the user stories above into statements:
“To achieve [insert requirement ID] we need [insert technical requirement]”
“To achieve R1 we need a list of departures” (Designate R1A1)
Based on these statements, we can do an analysis of the architecture. Another example:
“To achieve R3 we need to have the application work on a mobile device” (Designate R3A1)
With this in hand we can conclude:
This, in turn, create more statements:
“To achieve R1A1, we’ll need a configuration file” (Designate R1A2)
And so forth. Based on these results, we’ll decide on a rough architecture:
Principles: * If a value used in a program change often, and because of external events, make it configurable
Creating a functional layout, regardless of the purpose of the software, is a tricky endeavour — not only from the point of view of a developer/programmer, but in general. Experience suggest that even people with design expertise falter.
When it comes to software development, it has been suggested [Crispin; Gregory; 2009] that testers could use the “Wizard of Oz” — or “Paper prototyping” — methodology to test a layout prior to development start:
Developing user interfaces test–first can seem like an intimidating effort. The Wizard of Oz technique can be done before writing a single line of code. The team can test user interaction with the system, and gather plenty of information to understand the desired system behavior. </blockquote>
This is an apt description, but not of the test process, but rather the design and development part of the timeline. Keep in mind that a test will verify “Given X, then Y”, not “Do you like Y?” or “Is Y a good way to achieve X?”.
We will rather start with the requirements. From these, and the analysis done in the steps following, we can determine the elements that need be present:
and so forth. Once the list is complete, a designer would normally be brought in to take these elements, lay them out in an appropriate fashion, take heed of any stylistic guidelines, and go through the process with the end users.
This is also the step in which usability experts would be involved; their work would, in turn, feed back into the technical requirements. For example:
“To search for a specific train manually, the user must input the train ID, then either press CR *or* use a pointing device to activate the ‘search’ button”
“The drop–down should contain a list of departures, rendered one time per line in the HH:MM format”
will lead to
Again: and so forth.
First, an oddity. As you may have seen, proponents of an agile methodology suggest that
But developers have by necessity worked like this for many years:
two ways of “running” or “executing” tests:
1. MUST This word, or the terms “REQUIRED” or “SHALL”, mean that the definition is an absolute requirement of the specification.
2. MUST NOT This phrase, or the phrase “SHALL NOT”, mean that the definition is an absolute prohibition of the specification.
3. SHOULD This word, or the adjective “RECOMMENDED”, mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
4. SHOULD NOT This phrase, or the phrase “NOT RECOMMENDED” mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
5. MAY This word, or the adjective “OPTIONAL”, mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)
* Yes, I know about freemind. It has the same capabilities, but is practically useless due to the user interface. In short, the fonts are all bitmapped, and make reading menus etc. near impossible.