Autumn 2007

This course goes for the last time in Autumn 2007!!!

Karl Meinke,

This web page is under construction!

1. Goals and Methods.

The course 2D1343 part E2 has an associated practical project, which contributes 2 points to the overall course credits. (The remaining 6 points are obtained through the part E1.)

1.1. Goals.

The practical work for the course will consist of group project work to carry out a requirements analysis and build a "large" system according to principles studied in the 2 course lectures.

The main aims of the project work are (1) to give experience of working in a group, (2) to gain experience of writing and analysing software requirements, and (3) to gain experience of working in a large team (about 10 people) on a large piece of software based on a set of formal requirements.

This means that (with the possible exception of graphical user interface components, for which an evolutionary approach may be taken) requirements analysis takes place before implementation.

As a requirements documentation standard, we will use the ESA standard PSS 05. This standard can be found below. It will be discussed in class. Every student must read this document carefully.

Here is an annotated set of templates for the PSS 05 documents URD, SRD and ADD online. You can use these to help you write each document. The final software you submit will be evaluated by how closely it satisfies the requirements which you set out in your URD.

1.2. Project List.

Here is a list of project suggestions. You do not have to choose one of these. You can make your own suggestion.

1.3. Project Rules.

Here is an updated version of the project rules.

1.4. Tips for writing the URD. (!!!NEW!!!)

Here are some tips for writing the URD.

1.5. Course Text.

Students may buy a copy of:

Ian W. Ricketts, Managing Your Software Project: a Student's Guide, Springer Verlag, 1998. ISBN: 3-540-76046-6

if they feel the need for simple practical guidance in running a project.

1.6. Organisation of the Project.

The project will be divided into three phases (which loosely correspond with a waterfall model):

(1). Project Planning Phase

(2). User Requirements Specification,

(3). Software Design and Implementation.

The deliverable for phase 1 is a report of minimum length 3 pages (excluding title page). The deliverable for phase 2 is a report of minimum length 12 pages. The deliverable for Phase 3 is the software, which will be demonstrated to the teacher. To pass the course all deliverable must be submitted and accepted.

For phase 1 there is be an initial project selection and planning phase, which is summarised in a planning report. This is described below. The format of the other reports is described in PSS 05, and will be discussed in class.

The group will be marked as a whole unless there are exceptional reasons why the marks should be distributed differently for an individual group. (e.g. extended illness of a group member, dispute etc.) In the case of a project dispute (these sometimes happen.) I will step in to resolve the problem, if notified in time.

1.7. Progress Reporting.

Phases 1 and 2 will end with a written report. (See Section 5 below.) The delivery dates for reports are shown below. Each group must hand in a bound typed copy of their report.

1.7.1. Timetable.


Vecka 36, 2007 Kurser Moment Lokaler Anmärkning
  Tis 4 sep 15:00-17:00 Datalogi Frl E2 Group organisation and PPD  
Vecka 37, 2007
  Mån 10 sep 17:00 Deadline My mail tray, Plan 4 Submit 2 paper copies of PPD  
  Tis 11 sep 15:00-17:00 Datalogi Frl E2 User requirements and PSS05 reporting standard  
Vecka 46, 2007
  Mån 12 nov 17:00 Deadline My mail tray, Plan 4 Submit 2 paper copies of URD  
Vecka 12, 2008
  23 April Deadline Computer lab or my office Demo software  

2. Phase 1. Project Planning.

In order that your project progresses smoothly, it is important that you function "as a group". This may involve getting to know one another as students (perhaps with different skills, interests and experiences) as well as establishing standards for discussion, reaching agreement and resolving disagreements. These are all part of a normal and important parts of a software project. You will need considerable "team spirit" to function succesfully.

The project planning phase is not officially part of the PSS 05 standard. However, if carried out succesfully, it will connect you as a coherent group, with an agreed set of objectives and approaches. In particular, it should help you prepare for your second task: writing the User Requirements Document URD.

2.1. Goal.

As soon as possible you must meet as a group and establish a regular weekly meeting time that is convenient for everybody. You can meet in any location you wish. The meeting will be unsupervised. It is suggested that from time to time smaller working groups can meet. However, to maintain progress you should ideally meet once every two weeks.

Your first task is to assign yourselves a group name (legal and decent), and collect your names, e-mail addresses and telephone numbers.

Your next task is to examine the skills available in the group, and the technical strengths possesed by group members (e.g. Unix expert, Windows expert, graphics expert, etc.)

On the basis of skills, interests and personalities you must assign the following roles to group members (note that one member can have more than one role.)

Project leader

(responsible for overall co-ordination, and ultimate decisions and responsibility, deep understanding of the project and the PSS 05 standard)

Project secretary

(responsible for writing/delegating documentation and report writing, taking minutes of meetings, deep understanding of the PSS 05 standard)

Chief programmer

(an optional role, but a model favoured by many in industry, main responsibility for programming, delegates simpler tasks)


( usual tasks plus documentation and testing responsibilities )

Documentation Manager

(an optional role that could be separated from the secretary, writes and produces reports)

Report Writer

( a technical writer, assigned tasks by the secretary or documentation manager)


( testing responsibilities, assigned by project leader or chief programmer )


( problem analysis and software design at some stage in the project, duties assigned by project leader )

GUI expert

( an optional but common specialist role, a chance for specialist skills to shine and deepen, duties assigned by project leader/ chief programmer)

Project planner

( an optional role that could support the project leader and/or secretary )

End user

( a "pretend role", simulating the behaviour and wishes of an end user - projects with industrial connections may have a real end user)

NOTE: with the exception of the optional roles, all the above roles must be manned by some person. These roles will be recorded in the planning document. Although you may have specific technical roles, everyone is expected to contribute to the project ideas and decision making. You will be democratic, although in the case of dispute the project leader will have the final say.

2.2. Phase Deliverable: the Project Planning Document (PPD).

The output from this phase is the Project Planning Document (PPD). This document describes your initial project management decisions. It summarises your background research into the problem. It also identifies any learning which must be done in order to carry out the project.

The PPD must have the following standard structure.

Cover, Contents, Abstract

This document must have a title page, giving the date, group name, project title and authors. There must be a contents page, followed by an abstract on a separate page which summarises the contents of the document (1 paragraph).

1. Statement of the Problem

You must describe the problem chosen.

1.1. Short Statment of the Problem.

A description of the problem, in significantly greater detail than the description handed out in the project list. You must provide your own thoughts and interpretation of the problem.

1.2. Motivation.

Explain why you chose this project. Why is it important for the group? Does it enhance job skills. Does it satisfy some interests?

1.3. Goals

What do you hope to achieve with this project (a) technically, i.e. what will you build? (b) educationally, i.e. what will you learn?

1.4. Skills Baseline

What skills do you have in the group. Are there individuals with specialist skills? Will you need to learn any new skills? How will you learn these?

2. Background to the Problem

A study of this type of system based on a literature survey: (books, magazines, trade newspapers) and a web search.

2.1. Commercial background

(if appropriate)

What commercial tools exist of this kind? (You can include freeware, shareware). Who makes them? What do they cost? Who buys them? Are they for computer experts or beginners? Are they national or international? What skills does a typical user have? Is the market established or new?

What is the "best available product" of this type. Why is it best? What properties make it the best? How many of these properties could you implement in the time available? What features could be classified as (a) economy version, (b) standard version, (c) deluxe version.

Expect to use a web search, magazines and trade newspapers extensively here.

2.2. Scientific background.

Expect to use course notes and library books extensively here. What algorithms and data structures might be needed for the project. What research subjects are related to this project. What could a product look like in the future? Are there experts at KTH in this subject?

2.3. Technical background.

What platform, Operating System and programming language(s) would be appropriate. Can you use any commercial off the shelf products (available within NADA) to solve parts of the problem? e.g. a database, or tools, e.g. Yacc, Lex, Javacc, Swing.

3. Appendix

The document must contain an appendix with the list of all group members and their e-mail addresses (for my records). The Appendix must list all the project roles used in the project, and against each the name (or names) of individuals with that responsibility.

2. Phase 2. User Requirements Capture.

In order for you to divide up the programming work among group members, and in order for the teacher to have objective criteria for assessing you final software solution, it is necessary to write a user requirements document (URD). This is normal on all large software engineering projects, irrespective of what kind of software lifecycle model is adopted.

2.1. Goal.

Here is an example of a URD written according to the PSS05 model.

Karl Meinke
Last modified: 3 October 2007