Revision as of 20:21, 21 February 2006

Specifications should be made using this template based on the official Specification Template in stw format. Wiki pages should be able to be created based on this template, then they should be converted back to a document using the official template. This header text should be removed from the Specification, and the document footer should have the HTTP Link to the specification included.

Specification Title

Project

Abstract

<The Abstract is a formal summary of the completed specification. An abstract is an important tool for several different usage scenarios for example it can be reused as an information source for a What's new guide. Abstracts are typically 150 to 250 words long and shall cover the main points of the specification.>

i-Team Members (The specification owner is part of the i-Team)

Approved for Implementation

Document Change History

Glossary

Motivation

<What is the reason for pursuing this project?>

User Scenarios

<A user scenario is a idealized description of a specific interaction. This description shall be written short and specific. User scenarios can describe a leak of functionality, or based on the requirements, a solution.>

Goals

<The goals section must be short but also provide a clear statement of the goals, to achieve with this feature, project or task. A clear statement in this section gives Development, Quality Assurance and Documentation guidance.>

Requirements and Dependencies

Requirements

<State the requirement(s) of this feature here.>

Technical Dependencies

<Are there any technical dependencies for this feature? Does the implementation of this feature create any technical dependencies to other program parts? Or very important any issues for automatedd GUI Testing?>

Competitive Analyses

<Describe or reference to solutions which are already on the market. Describe what is done well or what is done bad.>

Detailed Specification

<First of all the concept section should give the audience an overview of how the new feature will work. When this is done this section has to cover the necessary things to finish this feature. This is the crucial part of the specification. If images are used in the concept, it is very important that these images provide a caption. The caption should be short and has to describe shortly the image. UI Mockups has to provide a caption too, if possible the mockups shouldn't be scaled and our standard user interface font, Andale Sans UI has to be used for strings on dialogs.>

<String Lists>

<First of all the concept section should give the audience an overview of how the new feature will work. When this is done this section has to cover the necessary things to finish this feature. This is the crucial part of the specification. If images are used in the concept, it is very important that these images provide a caption. The caption should be short and has to describe shortly the image. UI Mockups have to provide a caption too, if possible the mockups shouldn't be scaled.For making Screen shots use Alt+Print on Window to capture only the dialog. On JDS, launch from a Terminal window the 'gnome-panel-screenshot' tool. This tools shoots the whole desktop, so you have to crop out the dialog with a tool like Gimp for example.>

String list

Tab Order

<If necessary Describe or visualize the tabbing order. The description of the tab order has to contain which control has the initial focus.>

Key Board Shortcuts

<Key Board shortcuts used in dialogs have to be listed in a table with a small description.>

G11n

<Globalization related topics should be stated here. A globalization related topic is for example when a feature needs to be enhanced to satisfy special regional needs.>

Error Conditions

<List all error conditions, and the action the system takes about them. If an alert box comes up, which kind is it? Include exact text of messages, or say what points need to be covered. Error Messages need a string list>

Migration

<Any migration issues have to be stated here. For example how can users migrate from one version of a database to another?>

Future Tasks

<If there are features which couldn't be implemented but have to be implemented in the future. State these in here with a description why the feature couldn't be implemented right now.>

Notes

<Questions will arise during the writing of the specification. State these in here.>

References

<Give references to related documentation, such as engineering designs, technical specs, and other sources for related units. Also include links to documents that other sections in this spec need to refer to, such as user opinions usability test reports.>