ReqCycle/developmentProcess

Big picture

This is the summary of all concepts used in ReqCycle development process.

Requirement Based Engineering (RBE)

• Requirement Based Engineering: ReqCycle is driven by use of tool requirements that support end user needs. See Link title to get elements on those end user and tool requirements
• Technical features shall be traceable to tool requirements and tool requirements shall be traceable to end user needs.

Industrial maturity

• Tool requirements will have applicability attribute to precise tool versions on which requirement makes sense (some requirements might not be available on first versions)
• Each tool requirement shall be verifiable through on the following means: inspection, analysis, demonstration or test.
• in case a tool requirement is verified by test, there shall be at least one testing procedure associated.
• In case one user or developer identified a case when an applicable tool requirement is violated, he/she shall open a defect for that (a bug in bugzilla) and illustrate deviation through a testing procedure (existing or new). See link ReqCycle bugzilla

Change management

• Change requests shall be controlled and managed: improvements (changes in existing set of tool requirements) and fix requests
• Improvements shall precise new and modified requirements
• Fix requests shall precise the list of defects (bugs) to process (and associated tool requirements)
• on a change request, there shall be an analysis provided by ReqCycle development team that will list impacts and will quote duration and cost. In case of agreement with end users/funding partners there will be common agreement on applicability, planning and funding. Roadmap will be updated.
• Each change shall lead to at least one new repository revision when change is fully processed. There can be intermediate revisions that reflect partial change (for instance partial implementation, partial testing...)
• some revisions will be tagged as "versions" (or "releases") when specific maturity state is reached.

Release rhythm

It was decided to get two releases a year for incubation phase. One is planned for september 2015 and one is planned for end of year.

Releases will be driven by maturity state: it means that final delivery date of release will be adjusted and delayed if needed in order to ensure good validation and removal of all critical and major (blocking ) bugs. It is expected that release can be delayed up to one month and half to reach expected maturity. In case a release needs more than one month and half delay to finalize some features, those features will be rescheduled for next release.