3. Specification phase (for project leaders / architects)

Before the actual implementation of a project can begin the project must have specifications, the project must be divided into smaller tasks and these tasks must be assigned to proper people.

3.1. Specifications

The specification system in Sirid mainly tries to provide one single place where to put all specifications and where all project members can see the up-to-date versions of the specifications, removing the hassle created by the dozens of different documents normally emailed to all project members. The specification page is available via the project main page (Projects -> Project name).

The specifications are divided into two groups: Project notes and attachments. Project notes can be any (html formatted) text. Sirid naturally keeps track of the modification dates of the notes so everyone can see when, and by whom, the note was last modified. The project notes should generally be fairly short, 1000-2000 words or so, because reading documents longer than this can be tedious due to the restricted format of the texts. Longer texts should be made using some more advanced editor (such as MS Word) and stored as attachments.

Attachments can be any kind of files. Typical examples are Word documents, UML diagrams, Layout examples, and so on. Sirid allows you to specify versions for the attachments and keeps track of attachment history. If the files are already available on some other web server you can also, instead of uploading the attachment to the Sirid server, directly link to the "external attachment".

3.2. Tasks

After or while writing the specifications the project should be divided into smaller parts (2-10 h) and these parts, tasks, should be assigned to some staff members. New tasks can be added by clicking the Add new task link in the main menu. The tasks can naturally be modified later on and new tasks can be added at any time but successful projects are usually well defined from day one.

Most important properties of a task are its title which should be elaborative enough but still not too long, its description which should be covering enough, and the responsible person or persons. A task should usually have only one head responsible because often "shared responsibility is the same as no responsibility at all." For more information regarding responsible roles, see chapter chapter 1.3, Responsible roles.

After adding the task you can also add attachments to the task via the View task page. The attachments can again be of any type, usually being something similar to the attachments in the project specification. I.e. Word documents, UML diagrams, Layout examples, etc.