From Apache OpenOffice Wiki
Revision as of 13:50, 29 June 2006 by Jsi (Talk | contribs)

Jump to: navigation, search Specifications

Welcome to the web based collaboration area of the Specification Project.

Specifications are an essential part of the development process. Changes to be it adding new feature or enhancing existing ones will be done based on written specifications. This is absolutely neccessary as there are always multiple persons or groups involved in a change to Specifically specifications serve as working base for:

Development (DEV)
DEV implements features based on the technical information covered in specifications.
User Experience (UX)
UX uses specifications to define the user interface (UI) and its interaction model.
Quality Assurance (QA)
QA derives Test Case Specifications based on specifications. They test implemented features against the specifications.
Documentation (DOCU)
DOCU writes the end-user documentation based on specifications.

There is a Specification Template which greatly simplifies the process of writing specifications and which helps you to avoid the common errors usually leading to rework, regressions and delays.

I Want to Change Something in - Do I Have to Write a Specification?

In general the answer is YES. This applies to:

  • Features
  • Enhancements
  • Defects requiring the following type of changes:
    • Behavioral changes of the UI (e.g. changing a dialog from modal to modeless)
    • Visual changes of the UI (e.g. changing the icon size, the splash screen, the about box)
    • Configuration changes (e.g. changing application defaults such as Spellchecking ON/OFF)
  • Features, enhancements, defects which are already covered by an existing specification.

A specification needs NOT to be written if:

You do the following kind of changes:

  • Fixing a typo in the UI.
  • Rearranging UI controls without changing functionality.
  • The changes are not going to be integrated into the master.
    • The change is an Extension which is distributed separately to

If you are in doubt, whether you need a specification or not ask the responsible project lead of the application or area you are intending to change (see table below).

Application Project Lead E-Mail
Writer Andreas Martens
Calc Niklas Nebel
Drawing Kai Ahrens
Impress Christian Lippka
Database Frank Schoenheit
Math Mathias Bauer
Chart Kai Ahrens
Framework Mathias Bauer
Other Martin Hollmichel

Before Writing a Specification -- What Else Do I have to Do?

You should be able to answer each of the following questions marked with the letter Q with YES:

Q1 [Feature/Enhancement]:
Does an unambiguously clear feature or enhancement request exists?

Q2 [Concept]:
For changes requiring modifications in more than one application: Is there a product concept available, which is understandable to the intended readership?

Q3 [Project-Resources]:
Do you have a project team? An feature is always being devoloped by an Implementation Team (i-Team). An i-Team consists at least of two distinct persons:

  • A developer (required)
  • A QA representative (required)
    Ask for a QA representative in the mailing list.
  • An User Experience member (required only if the feature or bug fix affects the user interface or the behavior of the application)

Q4 [i-Team Agreement]:
Do all i-Team members agree on Q1 - Q3?

What happens if I can't answer all questions mentioned above, with Yes?
The consequence could be that your valuable work won't be integrated into

Writing a Specification - How to Start? specifications will be written based on the official Ott.png Specification Template. This template assists you in the process of creating your specification quickly and helps you to avoid common errors and pitfalls.

The following iterative process has been proven most suiteable when developing specifications for

  • Plan
    • I-Team Kickoff
    • Detailed feature / sub-feature planning
    • First design sessions

  • Do
    • Create prototypes/first implementation
    • Write specification according to the three essential rules for specifications

  • Review
    • i-Team reviews the specification with regards to the three essential rules for specifications mentioned above

  • Improve
    • Remove defects in your specification
    • Remove defects in your implementation

More details on the process can be found here

Note: the Ott.png Specification Template requires 2.0.2 or newer, make sure that the proxy settings are configured correctly. The proxy settings can be changed under Tools/Options/Internet/Proxy.

Exiting the Specification Process

If the i-Team can agree on the following items

  • The specification reflects the implementation in the child workspace (CWS) and has been set to standard status
  • Also all required documents (i.e. test case specification) exist, are available, and have standard status
  • CWS Policies have been fulfilled
  • Issue Handling rules have been fulfilled
  • All additional automated an manual tests have been run successfully and the results have been logged

the CWS can be set to Approved by QA and the Release Engineering will integrate the CWS which makes the new implementation available in the MASTER workspace (MWS).

Recommendation: To be sure that the transfer from CWS to MWS was also successfull it makes sense that the i-Team and not only the QA mmember (see: Issue Handling QA) compares the implementation with the specification.

What Else do I Have to Follow?

Feedback and comments

Feedback or comments are welcome please feel free to submit them to "dev at specs dot openoffice dot org"


This category has the following 5 subcategories, out of 5 total.




Pages in category "Specification"

The following 61 pages are in this category, out of 61 total.








I cont.










S cont.




Personal tools