Linaro operations: requirements, traceability, change management

Registered by Ilias Biris

The Linaro operations subcommittee to the TSC - OPSCOM - will look into requirements process, traceability of effort and results, change management

Blueprint information

Status:
Complete
Approver:
Joey Stanford
Priority:
Undefined
Drafter:
Ilias Biris
Direction:
Needs approval
Assignee:
Ilias Biris
Definition:
Superseded
Series goal:
None
Implementation:
Unknown
Milestone target:
None
Completed by
Loïc Minier

Related branches

Sprints

Whiteboard

There are several wiki pages that describe the Linaro requirements process.
- https://wiki.linaro.org/Process/DevelopmentCycle (draft)
- https://wiki.linaro.org/Cycles/RequirementsProcessHowto
- https://wiki.linaro.org/Process/Roadmap

In OPSCOM we have already been looking into the concerns regarding Linaro's processes and tools to handle requirements, including how those are mapped into workable blueprints and how validated results are delivered and requirements are signed off. As part of this first analysis this session will discuss those concerns and also to give a short demo of the tools we have been looking into.

The listed points below have been a source of some concern in communication with the TSC

== Creating requirements ==
  + Creating requirements should be done through a traceable tool which hosts the requirement document + any metadata. Ideally there should be some way to visualise the roadmap. History of changes should be possible to trace.

Today we are using Papyrs to handle the requirement documents, kanbantool to handle metadata and visualisation.

  + It should be possible to create requirements starting as a private sandbox, and publishing it when ready for further comments

  + Each requirement should be possible to see and comment before appearing to TSC for review

== Transparency and traceability of implementation and results ==

  + It should be possible to trace the Launchpad blueprints representing the work chunks to complete a requirement
  + The work effort estimates related to each requirement should be available
  + Traceable validation results, eg in LAVA, should be made available
  + Once all blueprint work is done, the corresponding requirement should be clearly signed off

== Change management ==

  + Changes to approved requirements should be managed. Significant changes should be approved by the TSC
  + We need to document the management of changes in the requirements

== TOOLS ==
There is currently a number of tools used by different end users - papyrs to host the requirement documents and metadata, kanbantool to show a high level plan.

Requirements are linked manually to blueprints, and for tracking progress looking from the blueprints angle status.linaro.org has been revamped to a degree.

However there are other tools which are possibly useful and could substitute those tools mentioned above. A demo will be shown for the tools we have tried.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.