| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> |
| <html> |
| <head> |
| <meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8"> |
| <title></title> |
| <meta name="GENERATOR" content="StarOffice 7 (Linux)"> |
| <meta name="CREATED" content="20040421;16480100"> |
| <meta name="CHANGED" content="20040630;15235600"> |
| <style type="text/css"> /* <![CDATA[ */ |
| @import "/css/qa.css"; |
| /* ]]> */</style> |
| </head> |
| <body lang="en-US" dir="ltr"> |
| <h1 class="western">Proposed approach for consolidating IssueTracker RFEs |
| (request for enhancement) into product requirements</h1> |
| <h2 class="western">Introduction</h2> |
| <p>The goal of this exercise is to convert a huge number of unqualified |
| IssueTracker (formerly known as IssueZilla) RFEs into a smaller number of |
| cleaned-up (marketing) product requirements that can be understood both by |
| users and developers.</p> |
| <p>The goal of this exercise is to:</p> |
| <ol> |
| <li> |
| <p>Eliminate duplicate RFEs</p> |
| </li> |
| <li> |
| <p>Increase quality of RFEs</p> |
| </li> |
| <li> |
| <p>Get to a manageable number of requirements that the community can vote on and |
| that a commercial contributor (e.g. Sun) can handle as part of a product |
| definition process</p> |
| </li> |
| </ol> |
| <p>In this process description we distinguish between RFEs submitted by community |
| members and the (marketing) product requirements that are derived from the |
| original RFEs. The RFEs can be high-level or low-level, very detailed or vague, |
| can include examples or not, etc. The new requirements however should be easy |
| to understand and coherent.</p> |
| <p>All requirements should also include information about the importance of a |
| requirement to a specific user group as well as relevant market data. For |
| example, a specific use case how a feature would be used by a user would help |
| to understand why a feature is needed and what the significance to the market |
| is.</p> |
| <p>Since the implementation is up to the developer who eventually picks up a |
| requirement, it is more important to describe the desired functionality and |
| typical use cases instead of explaining how something should be implemented.</p> |
| <h2 class="western"><br> |
| <br> |
| </h2> |
| <h2 class="western" style="page-break-before: always;">Overview Diagram</h2> |
| <p><br> |
| <br> |
| </p> |
| <p><img src="/images/handling_RFEs_overview.gif" name="Graphic1" align="left" width="519" height="323" border="0"><br clear="left"> |
| <br> |
| <br> |
| </p> |
| <h2 class="western">Query RFEs submitted by community members</h2> |
| <p>The various RFEs will be sorted, evaluated and consolidated by topic, i.e. by |
| component. A set of pre-defined queries will be provided by the QA and RFE |
| team, but in order to view all open RFEs, the following fields are important:</p> |
| <table width="100%" class="with_border" cellpadding="3" cellspacing="0"> |
| <col width="128*"> |
| <col width="128*"> |
| <thead> |
| <tr valign="top"> |
| <td width="10%"> |
| <b> Field </b> |
| </td> |
| <td> |
| <b> Selection </b> |
| </td> |
| </tr> |
| </thead> |
| <tbody> |
| <tr valign="top"> |
| <td width="50%"> |
| Issuetype |
| </td> |
| <td width="50%"> |
| |
| Enhancement and Feature |
| </td> |
| </tr> |
| <tr valign="top"> |
| <td width="50%"> |
| Status |
| </td> |
| <td width="50%"> |
| Unconfirmed, New, Started and Reopened |
| </td> |
| </tr> |
| <tr> |
| <td colspan="2" width="100%" valign="top"/> |
| </tr> |
| <tr> |
| <td colspan="2" width="100%" valign="top"> |
| IssueTracker queries can be saved. It is also possible to search for submitters |
| using the fields Username and Reporter. The query can be narrowed down using |
| the fields Component, Target Milestone, Date, etc. |
| </td> |
| </tr> |
| </tbody> |
| </table> |
| <p><br> |
| <br> |
| </p> |
| <h2 class="western">Convert low-level RFEs into high-level requirements</h2> |
| <p>Different IssueTracker RFEs that belong together because they talk about the |
| same requirement will be merged into one NEW requirement in IssueTracker, by |
| assigning the original RFE's to a completely new “meta” issue, i.e. the |
| requirement. The summary of the new requirement should summarize the key |
| elements of the old RFEs.</p> |
| <p>For example Writer RFE's like “implement styles preview in the Stylist”, |
| “dynamic styles” and “add default shortcuts to increase/decrease font size” |
| could be merged into a (summary) requirement like “Simplify formatting and font |
| handling in Writer”.</p> |
| <p>Users, developers and marketing project members should be able to understand |
| the requirement summary without having to read all the old RFEs. However, the |
| new requirement should contain links to the old RFEs (i.e. the RFE entries |
| should block the requirement entry in IssueTracker), because the old RFE's |
| provide more detailed information about the requirement and the use cases.</p> |
| <p>The Issuetype of the new requirement should be "Feature". It should be |
| assigned to someone from the requirements team, e.g. Erwin Tenhumberg (erwint). |
| Since this is a marketing task, the requirements should not be assigned to the |
| engineers directly.</p> |
| <p>The priority should be left at the default value (3), and the target milestone |
| will not be set for the new requirements. The priority will be determined |
| through the OpenOffice.org voting mechanism once all requirements are known. |
| The target milestone can only be set by the party/developer that promises to |
| work on the requirement.</p> |
| <p>The status has to be “New”. It will be set to “Started” as soon as someone |
| promises to implement a particular requirement. A special keyword "requirement" |
| has to be set. The description should also start with "Requirement:". It also |
| allows to search for the word "Requirement" in the description. |
| </p> |
| <p>Requirements ARE NOT the same as the regular RFEs submitted by the community |
| members as FEATUREs and ENHANCEMENTs. If an RFE is well written it should be |
| very easy to turn it into a requirement, but in many cases this will require |
| some clean-up work.</p> |
| <p>For the original/old RFEs the issue ID of the new requirement will be set in |
| the “Issue xxx blocks” field. This ensures that no data gets lost and that |
| progress can be monitored on a high level.</p> |
| <p>At this stage we have a list of requirements that is much shorter than the |
| original RFE's. |
| </p> |
| <h2 class="western">Prioritization of requirements</h2> |
| <p>Once all old RFEs have been converted into "clean and polished" requirements |
| the new requirements get a priority. This is a separate step because |
| prioritization is difficult or even impossible when the total number of |
| requirements is unknown. Due to the fact that engineering resources are |
| limited, a "first come first serve" approach does not work. In addition, using |
| something like voting on the original RFEs does not work because they are |
| either hard to understand by the people who are supposed to vote or there are |
| multiple RFEs for exactly the same product requirement. The prioritization will |
| happen through the IssueTracker voting mechanism.</p> |
| <p>At this stage we have a list of requirements that also include information |
| about the priority from a user point of view.</p> |
| <h2 class="western">Implementation of the requirements</h2> |
| <p>Sun as one of the key code contributors to the OpenOffice.org project will |
| decide to work on requirements that have a high priority and are aligned with |
| Sun's product and strategy goals. However, that also means that some |
| requirements will not be addressed by Sun. This can even happen with priorities |
| with a relatively high user priority if they don't fit into Sun's strategy.</p> |
| <p>For all requirements that Sun decides to implement, Sun will create a PCD item |
| in IssueTracker, i.e. the Summary contains the abbreviation “PCD” and also a |
| keyword “PCD” will be set (PCD is short for Product Concept Document). The |
| original requirement has to get a comment referring to the new PCD item.</p> |
| <p>A PCD item explains the concept what our engineering team will implement. |
| Thus, a PCD item does not talk about the “nitty gritty” implementation details, |
| but outlines the functionality that will get implemented. |
| </p> |
| <p>Since Sun might decide not to fully implement a product requirement, the |
| original requirement will stay open. The PCD item will however depend on the |
| requirement for tracking purposes.</p> |
| <p>The existence of a PCD item makes it possible to track the progress on a |
| particular requirement. The (potential) difference between a requirement and |
| its corresponding PCD item is the gap between the requirement and its |
| implementation.</p> |
| <p>Someone can either fill the gap by implementing the rest or creating a |
| completely independent second implementation that covers everything.</p> |
| <p>At this point we have a list of requirements and a list of PCD items. Every |
| PCD item must have a corresponding requirement, but there will also be |
| requirements that don't have a PCD item yet.</p> |
| <h2 class="western">Closing requirements</h2> |
| <p>Once the engineering work on the PCD items has been completed (i.e. a working |
| build can be downloaded and tested) the PCD item will be closed. If the PCD |
| item fully implements a requirement the requirement will also be closed. If the |
| PCD item only partly implemented the requirement, the original submitters have |
| to decide if the requirement should stay open or if the existing implementation |
| is sufficient.</p> |
| <p>Depending on the number, open requirements will stay open until the next |
| release cycle. If still nobody wants to address it, it will either get closed |
| or transferred to some kind of general to-do list.</p> |
| <h2 class="western">An example</h2> |
| <p>John submits an RFE with IssueTracker ID 00001 saying that “It should be easy to |
| exchange files in a well known and widely used read-only file format.”</p> |
| <p>Peter submits an RFE with IssueTracker ID 00002 demanding that “It should be |
| easier to generate PDF files”.</p> |
| <p>Jane creates yet another RFE with IssueTracker ID 00003 asking for “PDF export |
| solution that is 100% compatible with Acrobat Distiller”.</p> |
| <p>Finally, Susy opens an RFE with IssueTracker ID 00004 saying that “My friend |
| should be able to read my files without having to download OpenOffice.org”.</p> |
| <p>All these independent RFEs can be merged into just one product requirement. |
| Thus, the requirements team creates a new requirement that looks like this: |
| “OpenOffice.org should have a PDF export feature that is 100% compatible with |
| Acrobat Distiller version XYZ”.</p> |
| <p>After some voting Sun would decide to work on the requirement and thus create |
| a PCD item. However, since Sun does not have enough resources, Sun decides not |
| to created a Distiller clone (at least not in the first step). Instead the PCD |
| item says “OpenOffice.org will get basic PDF export support for all |
| applications. The functionality will cover X, Y, and Z, but not implement the |
| following Acrobat Distiller features: ....”</p> |
| <p>As a consequence, someone else can create a PCD item for the “rest |
| requirement”, create a completely independent additional implementation or just |
| live with the fact that the requirement might never get fully implemented.</p> |
| </body> |
| </html> |
