Difference between revisions of "Specification Template"

From Apache OpenOffice Wiki
Jump to: navigation, search
m (remove link to self)
 
(48 intermediate revisions by 10 users not shown)
Line 1: Line 1:
Specifications should be made using this template based on the official [http://specs.openoffice.org/collaterals/Specification_template.stw 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.
+
=Cleaning and Passivating=
This header text should be removed from the Specification, and the document footer should have the HTTP Link to the specification included.
+
  
= Specification Title =
+
{{Specification_Header|Kim Quinn||Preliminary}}
= Project =
+
  
{| border=1 cellspacing=0 cellpadding=5
+
== Abstract ==
| Document - ID
+
<START '''TYPING''' HERE>
| Specification Owner
+
__TOC__
| Last Change
+
 
| Status
+
== References ==
 +
 
 +
{| border="2" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0;  border: 1px #cccccc solid; border-collapse: collapse; width: 100%"
 
|-
 
|-
|
+
| width="300" bgcolor="#dddddd" | '''Reference Document''' || bgcolor="#dddddd" | '''Check''' || bgcolor="#dddddd" | '''Location (URL)'''
| <Author Name>
+
| <Date>
+
| <Draft or Final>
+
 
|-
 
|-
| Conforms to 
+
| |'''[http://wiki.services.openoffice.org/wiki/Specification#Before_Writing_a_Software_Specification_--_What_Else_Do_I_have_to_Do.3F Prerequisites]'''
|
+
| [passed/failed]
|
+
| n/a
|
+
 
|-
 
|-
| Applies to
+
| '''Product Requirement, RFE, Issue ID''' (required)
| <Required - List of modules or applications affected.>
+
| [available/not available]
|
+
| <PLEASE ENTER LOCATION HERE>
|
+
 
|-
 
|-
| Task ID(s)
+
| '''Accessibility Check''' (required)
| <Required - Tasklist comma separated.>
+
|  
|
+
| See accessibility section for check list
|
+
 
|-
 
|-
| Category
+
| '''[[Test case specification]]''' (required)
| <Feature or Bug Fix>
+
| [available/not available]
|
+
| <PLEASE ENTER LOCATION HERE>
|
+
|}
+
 
+
=== 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) ===
+
 
+
{| border=1 cellspacing=0 cellpadding=5
+
 
|-
 
|-
|
+
| IDL Specification
| Name
+
| [available/not available]
| E-mail Address
+
| <PLEASE ENTER LOCATION HERE>
 
|-
 
|-
| User Experience
+
| [http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications '''Software Specification Rules''']
| <Name + Initials>
+
| n/a
|  
+
| n/a
 
|-
 
|-
| Development
+
| Other, e.g. references to related specs, Product Concept Document
| <Name + Initials>
+
|
|  
+
| <PLEASE ENTER LOCATION HERE>
 
|-
 
|-
| Quality Assurance
 
| <Name + Initials>
 
|
 
|-
 
| Documentation
 
| <Name + Initials>
 
|
 
 
|}
 
|}
  
=== Approved for Implementation ===
+
== Contacts ==
  
{| border=1 cellspacing=0 cellpadding=5
+
{| border="2" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0;  border: 1px #cccccc solid; border-collapse: collapse; width: 100%"
 
|-
 
|-
|
+
| width="300" bgcolor="#dddddd" | '''Role''' || bgcolor="#dddddd" | '''Name''' || bgcolor="#dddddd" | '''E-Mail Address'''
| Approved by
+
| Date
+
 
|-
 
|-
| User Experience
+
| '''Developer'''
| <Name>
+
| <First Name, Last Name>
| <Date>
+
| <User@openoffice.org>
 
|-
 
|-
| Development
+
| '''Quality Assurance'''
| <Name>
+
| <First Name, Last Name>
| <Date>
+
| <User@openoffice.org>
 
|-
 
|-
| Quality Assurance
+
| '''Documentation'''
| <Name>
+
| <First Name, Last Name>
| <Date>
+
| <User@openoffice.org>
 
|-
 
|-
| Documentation
+
| '''User Experience'''
| <Name>
+
| <First Name, Last Name>
| <Date>
+
| <User@openoffice.org>
 
|-
 
|-
| String Review
 
| <Name>
 
| <Date>
 
 
|}
 
|}
  
=== Document Change History ===
+
== Acronyms and Abbreviations ==
 
+
{| border="2" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0;  border: 1px #cccccc solid; border-collapse: collapse; width: 100%"
{| border=1 cellspacing=0 cellpadding=5
+
 
|-
 
|-
| Rev. Level
+
| bgcolor="#dddddd" | '''Acronym / Abbreviation''' || bgcolor="#dddddd" | '''Definition'''
| Change
+
| Initials
+
| Date
+
 
|-
 
|-
| 1.0
+
| <WYSIWYG>
|
+
| <What You See Is What You Get>
|
+
| <Date>
+
|}
+
 
+
== Glossary ==
+
 
+
{| border=1 cellspacing=0 cellpadding=5
+
 
|-
 
|-
| Term
 
| Description
 
|-
 
| <Term 1>
 
|
 
 
|}
 
|}
  
== Motivation ==
+
== Detailed Specification ==
<What is the reason for pursuing this project?>
+
<START '''TYPING''' HERE>
 +
[[Specification_Template_Help#Detailed_Specification|Help]] | [[UI-Elements|User Interface Element Templates]] | [[Specification_Example|Example Spec]]
  
== User Scenarios ==
+
== Accessibility ==
<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.>
+
Accessibility is the responsibility of the I-Team, beginning with UX, DEV and QA, to ensure that the following requirements are fulfilled:
  
== Goals ==
+
# Is the feature '''fully keyboard accessible'''?''<br>(Ex: "I can go everywhere and use every function using the keyboard only"''<br/> ''<nowiki><START TYPING HERE></nowiki>''
<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.>
+
# Have I specified '''visual alternatives''' for the&nbsp;case that the&nbsp;specified feature includes audio as output? <br/> <nowiki><START TYPING HERE></nowiki>
 +
# Are '''text alternatives '''for all icons and graphics available?<br/> <nowiki><Start typing here></nowiki>
 +
# '''Don't provide important information in colors alone'''''<br>(Ex: marking important information hard coded in red)''<br/> ''<nowiki><START TYPING HERE></nowiki>''
 +
# Does the specified feature respect '''system settings''' for '''font, size, and color '''for '''all''' windows and user interface elements? <br/> <nowiki><START TYPING HERE></nowiki>
 +
# Have I ensured that&nbsp;'''flash rates''' do not exceed 2 hertz for blinking text, objects, or other elements? In any case, try to '''avoid flashing '''UI elements<br/> <nowiki><START TYPING HERE></nowiki>
 +
# Ensure that assistive technology (AT) (like ZoomText or Orca) is able to read everything.<br/> <nowiki><START TYPING HERE></nowiki>
  
== Requirements and Dependencies ==
+
QUESTIONS?
  
=== Requirements ===
+
If you need '''help''' while '''designing, implementing or testing''' the accessibility of the UI, ask/visit:
<State the requirement(s) of this feature here.>
+
  
=== Technical Dependencies ===
+
# The [http://wiki.services.openoffice.org/wiki/Accessibility_(A11y)_Quick_Test_Check_List accessibility check list at the OpenOffice.org Wiki]
<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?>
+
# [mailto:accessibility@ui.openoffice.org accessibility@ui.openoffice.org] (The accessibility mailing lists, preferred)
 +
# For specific implementation details, architecture: [mailto:mt@openoffice.org mt@openoffice.org] (Malte Timmermann)
 +
# For specific UX and testing questions: [mailto:es@openoffice.org es@openoffice.org] (Éric Savary)
  
== 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 ==
+
== Migration ==
<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.>
+
<START TYPING HERE --- If this part is irrelevant state a reason for its absence.>
  
<String Lists>
+
== Configuration ==
 +
<START TYPING HERE --- If this part is irrelevant state a reason for its absence.>
  
<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.>
+
[[Specification_Template_Help#Configuration|Help]] | [[Configuration-Table|Configuration Table Template]]
  
==== String list ====
+
== File Format ==
 +
<START TYPING HERE --- If this part is irrelevant state a reason for its absence.> [[Specification_Template_Help#File_Format|Help]]
  
{| border=1 cellspacing=0 cellpadding=5
+
[[Specification_Template_Help#File Format|Help]] | [[File Format Table|File Format Table Template]]
|-
+
| Item
+
| English
+
| German
+
| Swedish
+
| Comments
+
|-
+
| Button
+
| ~Delete
+
| ~Entfernen
+
|
+
|
+
|}
+
  
==== Tab Order ====
+
== Open Issues ==
<If necessary Describe or visualize the tabbing order. The description of the tab order has to contain which control has the initial focus.>
+
<State a bulleted list of issues Issue here>
  
==== Key Board Shortcuts ====
+
[[Category:Specification]]
<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.>
+

Latest revision as of 15:18, 18 June 2009

Cleaning and Passivating

Specification Status
Author Kim Quinn
Last Change
Status (Help) Preliminary

Abstract

<START TYPING HERE>

References

Reference Document Check Location (URL)
Prerequisites [passed/failed] n/a
Product Requirement, RFE, Issue ID (required) [available/not available] <PLEASE ENTER LOCATION HERE>
Accessibility Check (required) See accessibility section for check list
Test case specification (required) [available/not available] <PLEASE ENTER LOCATION HERE>
IDL Specification [available/not available] <PLEASE ENTER LOCATION HERE>
Software Specification Rules n/a n/a
Other, e.g. references to related specs, Product Concept Document <PLEASE ENTER LOCATION HERE>

Contacts

Role Name E-Mail Address
Developer <First Name, Last Name> <User@openoffice.org>
Quality Assurance <First Name, Last Name> <User@openoffice.org>
Documentation <First Name, Last Name> <User@openoffice.org>
User Experience <First Name, Last Name> <User@openoffice.org>

Acronyms and Abbreviations

Acronym / Abbreviation Definition
<WYSIWYG> <What You See Is What You Get>

Detailed Specification

<START TYPING HERE> Help | User Interface Element Templates | Example Spec

Accessibility

Accessibility is the responsibility of the I-Team, beginning with UX, DEV and QA, to ensure that the following requirements are fulfilled:

  1. Is the feature fully keyboard accessible?
    (Ex: "I can go everywhere and use every function using the keyboard only"

    <START TYPING HERE>
  2. Have I specified visual alternatives for the case that the specified feature includes audio as output?
    <START TYPING HERE>
  3. Are text alternatives for all icons and graphics available?
    <Start typing here>
  4. Don't provide important information in colors alone
    (Ex: marking important information hard coded in red)

    <START TYPING HERE>
  5. Does the specified feature respect system settings for font, size, and color for all windows and user interface elements?
    <START TYPING HERE>
  6. Have I ensured that flash rates do not exceed 2 hertz for blinking text, objects, or other elements? In any case, try to avoid flashing UI elements
    <START TYPING HERE>
  7. Ensure that assistive technology (AT) (like ZoomText or Orca) is able to read everything.
    <START TYPING HERE>

QUESTIONS?

If you need help while designing, implementing or testing the accessibility of the UI, ask/visit:

  1. The accessibility check list at the OpenOffice.org Wiki
  2. accessibility@ui.openoffice.org (The accessibility mailing lists, preferred)
  3. For specific implementation details, architecture: mt@openoffice.org (Malte Timmermann)
  4. For specific UX and testing questions: es@openoffice.org (Éric Savary)


Migration

<START TYPING HERE --- If this part is irrelevant state a reason for its absence.>

Configuration

<START TYPING HERE --- If this part is irrelevant state a reason for its absence.>

Help | Configuration Table Template

File Format

<START TYPING HERE --- If this part is irrelevant state a reason for its absence.> Help

Help | File Format Table Template

Open Issues

<State a bulleted list of issues Issue here>

Personal tools