Combo Button Specification

OpenOffice.org 2.0

Document - ID	Specification Owner	Last Change	Status
	Christian Jansen	<Date>	<Draft or Final>
Conforms to	
Applies to	<Required - List of modules or applications affected.>
Task ID(s)	<Required - Tasklist comma separated.>
Category	<Feature or Bug Fix>

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)

	Name	E-mail Address
User Experience	<Name + Initials>	
Development		
Quality Assurance		
Documentation		

Approved for Implementation

	Approved by	Date
User Experience	<Name>	<Date>
Development		
Quality Assurance		
Documentation		
String Review		

Document Change History

Rev. Level	Change	Initials	Date
1.0			<DD/MM/YY>

Contents

Glossary	1

1	Motivation	1

2	User Scenarios	1

3	Goals	1

4	Requirements and Dependencies	1

4.1	Requirements	1

4.2	Technical Dependencies	1

5	Competitive Analyses	1

6	Detailed Specification	1

6.1	G11n	2

6.2	Error Conditions	2

7	Future Tasks	2

8	Notes	2

9	References	2

Glossary

Term	Description
<Term 1>	

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?>

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

Item	English	German	Comments
Button	~Delete	~Entfernen	

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>

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.>

<Required - Specification Title>

Page 2

<Required - Path to specification>

Christian Jansen

2004-01-09T13:47:30