|
|
| Line 1: |
Line 1: |
| | + | =State Specification Title here= |
| | | | |
| | + | {| border="2" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0; border: 1px #cccccc solid; border-collapse: collapse; width: 100%" |
| | | | |
| − | __NOTOC__
| + | |- align="left" |
| − | | + | | colspan="2" bgcolor="#cccccc" | '''Specification Status''' |
| − | | + | |
| − | | + | |
| − | = THIS PAGE IS DATED PLEASE USE THE TEMPLATE LINKED BELOW =
| + | |
| − | | + | |
| − | http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott
| + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | ----
| + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | 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.
| + | |
| − | 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 =
| + | |
| − | | + | |
| − | {| border=1 cellspacing=0 cellpadding=5
| + | |
| − | | Document - ID
| + | |
| − | | Specification Owner | + | |
| − | | Last Change
| + | |
| − | | Status
| + | |
| | |- | | |- |
| − | |
| |
| − | | <Author Name>
| |
| − | | <Date>
| |
| − | | <Draft or Final>
| |
| | |- | | |- |
| − | | Conforms to | + | | width="150" | '''Author''' || YOUR NAME HERE |
| − | | | + | |
| − | | | + | |
| − | | | + | |
| | |- | | |- |
| − | | Applies to | + | | width="150" | '''Last Change''' || [[User:Cj|Cj]] 14:39, 2 November 2006 (CET) |
| − | | <Required - List of modules or applications affected.> | + | |
| − | | | + | |
| − | | | + | |
| | |- | | |- |
| − | | Task ID(s) | + | | width="150" | '''Status''' || Preliminary |
| − | | <Required - Tasklist comma separated.> | + | |
| − | | | + | |
| − | | | + | |
| | |- | | |- |
| − | | Category
| |
| − | | <Feature or Bug Fix>
| |
| − | |
| |
| − | |
| |
| | |} | | |} |
| | | | |
| − | === Abstract ===
| + | == 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
| + | |
| − | |-
| + | |
| − | |
| + | |
| − | | Name
| + | |
| − | | E-mail Address
| + | |
| − | |-
| + | |
| − | | User Experience
| + | |
| − | | <Name + Initials>
| + | |
| − | |
| + | |
| − | |-
| + | |
| − | | Development
| + | |
| − | | <Name + Initials>
| + | |
| − | |
| + | |
| − | |-
| + | |
| − | | Quality Assurance
| + | |
| − | | <Name + Initials>
| + | |
| − | |
| + | |
| − | |-
| + | |
| − | | Documentation
| + | |
| − | | <Name + Initials>
| + | |
| − | |
| + | |
| − | |}
| + | |
| − | | + | |
| − | === Approved for Implementation ===
| + | |
| − | | + | |
| − | {| border=1 cellspacing=0 cellpadding=5
| + | |
| − | |-
| + | |
| − | |
| + | |
| − | | Approved by
| + | |
| − | | Date
| + | |
| − | |-
| + | |
| − | | User Experience
| + | |
| − | | <Name>
| + | |
| − | | <Date>
| + | |
| − | |-
| + | |
| − | | Development
| + | |
| − | | <Name>
| + | |
| − | | <Date>
| + | |
| − | |-
| + | |
| − | | Quality Assurance
| + | |
| − | | <Name>
| + | |
| − | | <Date>
| + | |
| − | |-
| + | |
| − | | Documentation
| + | |
| − | | <Name>
| + | |
| − | | <Date>
| + | |
| − | |-
| + | |
| − | | String Review
| + | |
| − | | <Name>
| + | |
| − | | <Date>
| + | |
| − | |}
| + | |
| − | | + | |
| − | === Document Change History ===
| + | |
| − | | + | |
| − | {| border=1 cellspacing=0 cellpadding=5
| + | |
| − | |-
| + | |
| − | | Rev. Level
| + | |
| − | | Change
| + | |
| − | | Initials
| + | |
| − | | Date
| + | |
| − | |-
| + | |
| − | | 1.0
| + | |
| − | |
| + | |
| − | |
| + | |
| − | | <Date>
| + | |
| − | |}
| + | |
| − | | + | |
| − | == Glossary ==
| + | |
| − | | + | |
| − | {| border=1 cellspacing=0 cellpadding=5
| + | |
| − | |-
| + | |
| − | | 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? 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 ====
| + | |
| − | | + | |
| − | {| border=1 cellspacing=0 cellpadding=5
| + | |
| − | |-
| + | |
| − | | Item
| + | |
| − | | English
| + | |
| − | | German
| + | |
| − | | Swedish
| + | |
| − | | 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>
| + | |
| − | | + | |
| − | === 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.>
| |
| | | | |
| | [[Category:Specification]] | | [[Category:Specification]] |
