The system provides tickets and reservations valid for trains
in Sweden. It uses special terminals to be placed at
railway stations. The customer pays by bank- or credit
card using the standard procedures and protocols; payment
by cash is not (and will not be) possible. The system can
communicate with the ticket-and-reservation systems of several
operators (SJ, SL, Arlandatrain, Sydvästen, Tågkompaniet, Länstrafiken,
...) and issue
tickets that combine their services (Tågplus). The system is
ordered by Samtrafiken i
Sverige AB. You may use their information, but do not send
them mail asking for help!
Deliverables
The following documents should be produced
(you will probably want to prepare them concurrently):
a requirements definition based on the viewpoints of the
stakeholders,
a (not extremely detailed) requirements specification, including
a data dictionary,
a dataflow model of a transaction,
an architectural design. Motivate the choice of your design!
Remarks and hints
Naturally, you will identify yourself with the user of such a
system. But try to identify all other stakeholders and some of their
requirements (to the extent your domain knowledge reasonably allows).
Have a look at Figure 7.11 when working on non-functional
requirements.
Consult Figure 18.4 on reliability.
Be concrete! Invent values for response times, names of standards,
and the like. Determine what kind of tickets are sold/are not sold
by the system.
Write verifiable requirements! When doubtful, describe how to
verify the requirement.
The requirements definition and the requirements specification are
two separate documents, with different content. For example, "issue
tickets that
combine their services" belongs in the requirements definition;
this is made possible by "can communicate with the
ticket-and-reservation systems of several operators", which
is (in a more detailed form) part of the requirements specification.
Take care of traceability. Link requirements to stakeholders,
and the requirements specification to the requirements definition.
Do not concentrate heavily on the user-interface.
For example, describe when the user enters the destination, but
not whether it is typed, pointed at on a map, or spoken.
The data dictionary should contain all concepts that are
potentially ambiguous (ticket, reservation, payment) and define
them in an unambiguous way. Of course, the rest of the documents
must use the term in this way and in this way only.
A dataflow model or an architectural design is more than just a
picture.
Administrative
The assignment is made in pairs (2 is a pair, 3 isn't, 1 is if
it has to be). You are welcome to
discuss the assignment with others if it helps you clarify
your thinking, but submit your own work!