STALE : need redirect to updated page

Requirements Process


For the requirements process we use a two-phase approach to build requirements: Product Requirements are defined, from which Technical Requirements are derived. The approach is basically as follows:

  1. TSC members volunteer for sponsoring selected key technical topics
  2. Topic sponsors and relevant technical leads work out Product Requirements
  3. Management and the TSC sign off on this set of requirements
  4. Technical Requirements are derived from the Product Requirements, again by sponsors and tech leads
  5. The TSC sign off on the technical requirements for the cycle
  6. Blueprints are finalized and submitted for sessions at Linaro@UDS

The requirements schedule can be found in each cycle's wiki page:


An outline of the logical structure for the process documentation might look like:

  • Technical Topic

    • Product Requirement (no more than 6 per topic)

      • Technical Requirement (maps to TR blueprint unless it is subdivided into second-order requirements)

        • [second-order Technical Requirement] (maps to TR blueprint)

Technical Topics

Topics are key work areas within Linaro, high-level enough to be understandable by non-technical readers. They may not map exactly to the EngineeringUnits, for instance due to work being shared across them. Each technical topic has a selected TSC member as its sponsor, and one or more tech leads that work on detailing product and technical requirements from it.

Product Requirements

Product requirements are high-level descriptions of areas needing work within a Technical Topic. A product requirement should outline a problem to be solved, a goal to be reached or research to be described, but in language and at a level which makes sense to non-technical management and the general public interested in Linaro work. Think "Improve kernel frequency control features", not "Implement CPUFreq extensions".

Product requirements do not need to be absolutely measurable, but they should clearly be answerable by the end of the cycle: "did we improve the kernel frequency control features?".

A topic should have few product requirements associated with it; for this cycle, the rule of thumb is no more than 6.

Technical Requirements

Technical Requirements identify specific areas of technical work that need implementing. They should be derived from product requirements, but they have the property of being concrete and absolutely measurable; for instance, they should identify named pieces of infrastructure ("Cairo Rendering Backends"), changes to be made to them ("Implement device-tree support"), and potentially measurements of progress ("Reduce Thumb-2 code size by 10%").

There can be multiple technical requirements linked to a product requirement (and in some odd cases, possibly linked to more than one). There can also be multiple levels of technical requirements.

One important category is that technical requirements are tracked as blueprints themselves; for cases where there are multiple levels of requirements, each of the "leaves" should be linked to blueprints.

Documenting Requirements

  • Technical topics and high-level requirements are stored in each release area
  • Blueprints should be recorded for the lowest-level technical requirements in the tables.
    • These blueprints are known as "TR Blueprints"
    • They should be registered against

    • Their names should be in the format "tr-unit-blueprint". For instance, "tr-kernel-android-upstreaming".
    • Their names should not contain the actual number of the requirement in the table.
  • At the end of the cycle, blueprints that are finalized are closed out; for TR blueprints that still apply, they can be kept open
  • Actual engineering blueprints should be registered against the Launchpad project to which the work applies to

To see a listing of technical requirements for the cycle, look at


Cycles/RequirementsProcessHowto (last modified 2013-08-30 22:32:42)