Assignment 1

Software Engineering Autumn 2002

A traveller information system

Short description

The aim of the system is to provide users of public transport inside Sweden up-to-date information on the best way to reach their destination, before and during travel.

Some obvious questions

• What is the best way?
• Who are the stakeholders, besides the users?
• What are the data sources?
• Who is/are paying for this system? How much? How good a system can one realistically expect for that amount?
• How will the system communicate with the user?

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 (3-6 pages),
• a rough architecture of the system, showing the over-all data-flow,
• a system requirements specification (3-6 pages).
• Accompanying the specification (as parts/appendices):
  • a glossary of abbreviations and terms (about 1-2 pages),
  • a sequence diagram showing that an event (like an accident) causes the system to propose an alternative itinerary to a user during travel.

Issues

• Proper organisation of the requirements definition and specification.
• Proper division between the requirements definition and specification.
• Traceability.
• Proof of prioritisation, conflict detection and resolution.
• Validity, proper focus on what the system does.
• Testability.
• Almost all stakeholders are represented.
• All kinds of requirements are represented.
• Proper use of pictures and associated text for the architecture/data-flow model and use case.

Non-issues

The following topics should be avoided, or dealt with very briefly. Not because they are uninteresting or unimportant, but because they are not part of the assignment (detailed design) or the course.

• Details of the user interface.
• Details of the data communication.
• Details of the hardware.
• Solving the problem of what is the optimal way from A to B given the current timetable.
• Solutions (=design!) to problems of privacy and security.
• Exceptional cases. Note that disruptions of public transport are not exceptional (in any way, alas): they are the main motivation of the system.
• Completeness would require hundreds of pages, I want to see between 10 and 20 pages (depending on point-size and density of the text). So completeness in the usual sense is not an issue. However, as stated above, all kinds of requirements should be represented.

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 5.3 when working on non-functional requirements.
• Consult Figure 17.1 on reliability.
• Be concrete! Invent values for response times, names of standards, and the like. Take decisions! A bad decision is a sign of lack of domain knowledge. No decision is bad software engineering.
• Write verifiable requirements! When doubtful, describe how to verify the requirement.
• The glossary should define in an unambigugous way every term used in the document that might be unknown (like "POTS = Plain Old Telephone System") or ambiguous ("delay").

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!
• Deadline: 25/11, 10:15.
• Use this front page.
• Staple the pages together. (Yes, I prefer to get them on paper.)
• Put the papers in Annika's mailbox (Polacksbacken house 1, floor 4, number 46).
• You may write in Swedish or English.