Difference between revisions of "Specification"

From Apache OpenOffice Wiki
Jump to: navigation, search
m
 
(8 intermediate revisions by 7 users not shown)
Line 1: Line 1:
__NOTOC__
+
{{Old|EN}}
 +
= OpenOffice.org Software Specifications =
 +
Welcome to the web based collaboration area of the [http://specs.openoffice.org OpenOffice.org Specification Project].
  
<big>'''OpenOffice.org Specifications'''</big>
+
Software specifications are an essential part of the [http://qa.openoffice.org/issue_handling OpenOffice.org development process]. Changes to OpenOffice.org be it adding new feature or enhancing existing ones will be done based on written software specifications. This is absolutely neccessary as there are always multiple persons or groups involved in a change to OpeOffice.org.
:Welcome to the Specification Projecte Wiki page.
+
Specifically software specifications serve as working base for:
:<big> [http://wiki.services.openoffice.org/wiki/Category:Specification Use this link to get the articles in category ''Specification'']</big>
+
 
 +
'''Development (DEV)
 +
DEV implements features based on the technical information covered in software specifications.
 +
 
 +
'''[[User Experience]] (UX)
 +
UX uses software specifications to define the user interface (UI) and its interaction model.
 +
 
 +
'''[http://qa.openoffice.org/ Quality Assurance] (QA)
 +
QA derives [[test case specification]]s based on software specifications.
 +
They test implemented features against the software specifications.
 +
 
 +
'''Documentation (DOCU)
 +
DOCU writes the end-user documentation based on software specifications.
 +
 
 +
<br>
 +
There is a [http://specs.openoffice.org/collaterals/template/2.0/OpenOffice-org-Specification-Template.ott '''Software Specification Template'''] which greatly simplifies the process of writing  software specifications and which helps you to avoid the common errors usually leading to rework, regressions and delays. 
 +
<br>
 +
 
 +
 
 +
== I Want to Change Something in OpenOffice.org - Do I Have to Write a Software 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 [http://specs.openoffice.org/ existing software specification].
 +
** Software specifications for OpenOffice.org 2.0.x can be found on the [http://specs.openoffice.org UI Specifications for OpenOffice.org 2.0.x] site
 +
** Older software specifications can be found in the section [http://ui.openoffice.org/proposals/index.html UI Specifications for OpenOffice.org 1.1.x]
 +
 
 +
 
 +
'''A software 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 OpenOffice.org master.
 +
** The change is an Extension which is distributed separately to OpenOffice.org
 +
 
 +
 
 +
'''If you are in doubt''', whether you need a software specification or not ask the responsible project lead of the application or area you are intending to change (see table below).
 +
 
 +
 
 +
 
 +
{| border="2" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse; width: 55%"
 +
 
 +
|- align="left"
 +
| style="background-color: #efefef; width: 20%" | '''Application'''
 +
| style="background-color: #efefef; width: 30%" | '''Project Lead'''
 +
| style="background-color: #efefef; width: 40%" | '''E-Mail'''
 +
|-
 +
| Writer || '''Mathias Bauer''' || Mathias.BauerATsun.com
 +
|-
 +
| Calc|| '''Niklas Nebel''' || Niklas.NebelATsun.com
 +
|-
 +
| Drawing|| '''Kai Ahrens''' ||Kai.AhrensATsun.com
 +
|-
 +
| Impress|| '''Christian Lippka''' || Christian.LippkaATsun.com
 +
|-
 +
| Database|| '''Frank Schönheit''' || Frank.SchoenheitATSun.com
 +
|-
 +
| Math|| '''Mathias Bauer''' || Mathias.BauerATsun.com
 +
|-
 +
| Chart|| '''Ingrid Halama''' || Ingrid.HalamaATsun.com
 +
|-
 +
| Framework|| '''Carsten Driesner''' || Carsten.DriesnerATsun.com
 +
|-
 +
| Other|| '''Martin Hollmichel''' || Martin.HollmichelATsun.com
 +
|}
 +
 
 +
== Before Writing a Software 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]:'''<br>
 +
Does an unambiguously clear feature or enhancement request exists?
 +
 
 +
 
 +
'''Q2 [Concept]:'''<br>
 +
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]:'''<br>
 +
Do you have a project team?
 +
An OpenOffice.org feature is always being developed by an Implementation Team ([http://tools.openoffice.org/dev_docs/child_workspace_policies.html i-Team]). An i-Team consists at least of two distinct persons:
 +
* A developer '''(required)'''
 +
* A QA representative '''(required)'''<br>Ask for a QA representative in the [mailto:dev@qa.openoffice.org dev@qa.openoffice.org] mailing list.
 +
* A [http://wiki.services.openoffice.org/wiki/OpenOffice.org_User_Experience_Community 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]:'''<br>
 +
Do all i-Team members agree on Q1 - Q3?
 +
 
 +
 
 +
'''What happens if I can't answer all questions mentioned above, with Yes?'''<br>
 +
The consequence could be that your valuable work won't be integrated into OpenOffice.org.
 +
<br>
 +
<br>
 +
 
 +
== Writing a Software Specification - How to Start? ==
 +
 
 +
OpenOffice.org software specifications will be written based on the official '''[[Image:ott.png]] [http://specs.openoffice.org/collaterals/template/2.0/OpenOffice-org-Specification-Template.ott OpenOffice.org Software Specification Template]'''. This template assists you in the process of creating your software specification quickly and helps you to avoid common errors and pitfalls.<br>
 +
 
 +
 
 +
The following iterative process fits mostly when developing software specifications for OpenOffice.org:
 +
 
 +
; Plan
 +
* I-Team Kickoff
 +
* Detailed feature / sub-feature planning
 +
* First design sessions
 +
 
 +
; Do
 +
* Create prototypes/first implementation
 +
* Write software specification according to the three essential rules for OpenOffice.org software specifications
 +
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Complete]<br>
 +
R2:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Clear]<br>
 +
R3:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Simple]
 +
* Put the spec online (even if preliminary) on http://specs.openoffice.org or the wiki and announce it on [http://specs.openoffice.org/servlets/ProjectMailingListList the mail alias announce@specs.openoffice.org].
 +
 
 +
; Review
 +
* i-Team reviews the software specification with regards to the three essential rules for OpenOffice.org software specifications mentioned above
 +
 
 +
; Improve
 +
* Remove defects in your software specification
 +
* Remove defects in your implementation
 +
 
 +
 
 +
More details on the process can be found [http://specs.openoffice.org/collaterals/presentations/Specification-Template-Presentation.odp here]
 +
 
 +
 
 +
'''Note:''' the [[Image:ott.png]] [http://specs.openoffice.org/collaterals/template/2.0/OpenOffice-org-Specification-Template.ott OpenOffice.org Software Specification Template] requires OpenOffice.org 2.0.2 or newer, make sure that the OpenOffice.org proxy settings are configured correctly. The proxy settings can be changed under Tools/Options/Internet/Proxy.
 +
 
 +
== Exiting the Software Specification Process ==
 +
 
 +
If the i-Team can agree on the following items
 +
 
 +
* The '''software 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
 +
* [http://tools.openoffice.org/dev_docs/child_workspace_policies.html CWS Policies] have been fulfilled
 +
* [http://qa.openoffice.org/issue_handling/ 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 member (see: [http://qa.openoffice.org/issue_handling/workflowcharts/taskhandling_workflow_feature_QA.html Issue Handling QA]) compares the implementation with the software specification.
 +
 
 +
== Feedback and comments ==
 +
Feedback or comments are welcome please feel free to submit them to "dev at specs dot openoffice dot org"
 +
 
 +
 
 +
 
 +
[[Category:Project]]
 +
[[Category:Specification]]
 +
[[Category:Outdated]]

Latest revision as of 12:46, 9 July 2018

Book-old.png    This article is outdated.    

OpenOffice.org Software Specifications

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

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

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


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


I Want to Change Something in OpenOffice.org - Do I Have to Write a Software 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 software specification.


A software 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 OpenOffice.org master.
    • The change is an Extension which is distributed separately to OpenOffice.org


If you are in doubt, whether you need a software 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 Mathias Bauer Mathias.BauerATsun.com
Calc Niklas Nebel Niklas.NebelATsun.com
Drawing Kai Ahrens Kai.AhrensATsun.com
Impress Christian Lippka Christian.LippkaATsun.com
Database Frank Schönheit Frank.SchoenheitATSun.com
Math Mathias Bauer Mathias.BauerATsun.com
Chart Ingrid Halama Ingrid.HalamaATsun.com
Framework Carsten Driesner Carsten.DriesnerATsun.com
Other Martin Hollmichel Martin.HollmichelATsun.com

Before Writing a Software 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 OpenOffice.org feature is always being developed 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 dev@qa.openoffice.org mailing list.
  • A 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 OpenOffice.org.

Writing a Software Specification - How to Start?

OpenOffice.org software specifications will be written based on the official Ott.png OpenOffice.org Software Specification Template. This template assists you in the process of creating your software specification quickly and helps you to avoid common errors and pitfalls.


The following iterative process fits mostly when developing software specifications for OpenOffice.org:

Plan
  • I-Team Kickoff
  • Detailed feature / sub-feature planning
  • First design sessions
Do
  • Create prototypes/first implementation
  • Write software specification according to the three essential rules for OpenOffice.org software specifications
R1:Complete
R2:Clear
R3:Simple
Review
  • i-Team reviews the software specification with regards to the three essential rules for OpenOffice.org software specifications mentioned above
Improve
  • Remove defects in your software specification
  • Remove defects in your implementation


More details on the process can be found here


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

Exiting the Software Specification Process

If the i-Team can agree on the following items

  • The software 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 member (see: Issue Handling QA) compares the implementation with the software specification.

Feedback and comments

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

Personal tools