openkylin
/
docs
mirror of https://gitee.com/openkylin/docs.git
9
0
Fork 1
Code Issues Projects Releases Wiki Activity

add README_RMS.md file

This commit is contained in:
YuanjZhang 2023-03-08 20:02:23 +08:00
parent d42c3e6b97
commit 3bc4e38e02
1 changed files with 34 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
Requirements_Management_Specification.md Normal file
View File

@ -0,0 +1,34 @@
# OpenKylin Requirements Management Specification
## 1.1 Demand collection
When the version release plan is clear, the product manager will release the relevant email to collect the requirements through the following two ways. The proponents of these two types of requirements and the specifications for submitting the issue in the code cloud are as follows:
* The technical planning requirements of the community version are put forward by the community technical committee. The product manager enters the demand issue into the Release-Management warehouse, selects the issue type as "demand", fills in the demand title and details, marks the release SIG and feature labels, and marks the version milestone.
* The planning requirements of each SIG project for this version are proposed by each SIG group. The maintainer of each SIG group enters the requirements into the SIG project warehouse, selects the issue type as "requirements", fills in the requirements title and details, marks the SIG and feature labels, and marks the version milestones.
* After all the requirements are entered into the code cloud, the product manager can filter and summarize all the requirements of the version through the community's full issue.
explain:
* By marking the SIG attribution tag, all requirement issues are mapped to the SIG group.
* Requirements details must be filled in clearly according to the template: requirements background, requirements description, implementation scheme, acceptance criteria.
* For requirements that need to be protected, you can select the content risk identification check box to prevent members outside the warehouse from accessing.
* During data statistics, the issue type is used to count the demand, and the tag feature is used to facilitate code cloud front page filtering.
## 1.2 Requirements review
After summarizing the requirements, the product manager organizes the technical committee to complete the review. After the review is passed, the review conclusion will be notified to all subscribers through the mailing list, and the following operations will be performed on the code cloud issue:
* Issue the requirements planned to be completed in this version, and confirm the correct milestones
* Issue the requirements planned to be completed in the future version, and confirm the correct milestones
* The audit confirms that there is no planned demand issue, which is not associated with the milestone, and the status is changed to "Rejected". When there is a new plan in the future, the status can be changed to "Confirmed", and the correct milestone can be associated.
## 1.3 Detailed requirements
After the completion of the requirements review, the requirements issues planned to be completed in this version must output the Requirements Description Document within one week, and the documents can be submitted in the following ways:
* Requirement description document: create a PR, select the target branch, fill in the title: "[Requirement issue title] Requirement description", the first line of PR detailed description states that this document is a detailed description of the requirement (issue number and link), and mark the label as PRD, select the version milestone
* After the PR is submitted and approved by the auditors, the PR will be consolidated
* Demand issue: After the PR of demand description is merged, the comment box of demand issue should indicate: PR link of demand description
## 1.4 Demand scheduling
After the release SIG group has clearly released the plan, the product manager can notify all subscribers of the version plan through the mailing list, and notify each SIG group to schedule the demand issue. The specific operations are as follows:
* The maintainer of each SIG group shall specify the completion plan of the issue required by the SIG group, mark the "start date" and "end date" of the issue in the code cloud, and set the "priority"
* After the demand issue scheduling is completed, the release SIG team release manager checks the demand issue scheduling, and can organize a review for the disputed demand.
explain:
* The review conclusion can be notified to all subscribers through the mailing list
## 1.5 Requirements change
In the version plan, if there is a change in the scope of requirements and plans, the product manager should organize the technical committee/release SIG group to review the change. After the review is completed, the product manager will notify all subscribers of the conclusion through the mailing list and carry out the following operations:
* In the comment box of the change request issue, mark the change reason and review conclusion of the request.
* For the demand issue with changed milestones, confirm the associated changed milestone plan and set the correct schedule. For the demand issue with no plans for the time being, change the status to "Rejected" if the milestone is not associated.
* For the requirement issue with changes in the scope of requirements, the person in charge of the requirements shall output the changed requirements document and submit the PR of the requirements document in the manner of 1.3.
explain:
* The review conclusion can be notified to all subscribers through the mailing list