Proposed approach for consolidating IssueTracker RFEs (request for enhancement) into product requirements

Introduction

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.

The goal of this exercise is to:

1. Eliminate duplicate RFEs

2. Increase quality of RFEs

3. 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

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.

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.

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.

Overview Diagram

Query RFEs submitted by community members

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:

Field	Selection
Issuetype	Enhancement and Feature
Status	Unconfirmed, New, Started and Reopened
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.

Convert low-level RFEs into high-level requirements

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.

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”.

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.

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.

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.

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.

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.

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.

At this stage we have a list of requirements that is much shorter than the original RFE's.

Prioritization of requirements

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.

At this stage we have a list of requirements that also include information about the priority from a user point of view.

Implementation of the requirements

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.

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.

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.

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.

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.

Someone can either fill the gap by implementing the rest or creating a completely independent second implementation that covers everything.

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.

Closing requirements

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.

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.

An example

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.”

Peter submits an RFE with IssueTracker ID 00002 demanding that “It should be easier to generate PDF files”.

Jane creates yet another RFE with IssueTracker ID 00003 asking for “PDF export solution that is 100% compatible with Acrobat Distiller”.

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”.

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”.

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: ....”

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.