diff --git a/en/openKylin_Requirements_Management_Specification.md b/en/openKylin_Requirements_Management_Specification.md
new file mode 100644
index 0000000000000000000000000000000000000000..0d7fd36729db10b308e480fd7e9b6cb9546edc81
--- /dev/null
+++ b/en/openKylin_Requirements_Management_Specification.md
@@ -0,0 +1,48 @@
+# openKylin Requirements Management Specification
+
+## 1.1 Requirements Collection
+When the version release plan is scheduled, the product manager sends following two types of requirements. The proposer and code submission specification are described as follows.
+
+- **Technical planning requirements of the community version**: This kind of requirements are proposed by the community technology committee. Product manager are responsible for recording the requirement issues into the Release-Management repositories. The issue type should be selected as "requirement". Product manager should further fill in the requirement title and details, mark the release SIG and feature tags, mark the version milestone.
+
+- **Planning requirements for this version from separate SIG project**: This kind of requirements are proposed by separate SIG group. The maintainers of each SIG group are responsible for recording the requirements into the Release-Management repositories. The issue type should be selected as "requirement". Maintainers should further fill in the requirement title and details, mark the release SIG and feature tags, mark the version milestone.
+
+- After all the requirements are recorded on Gitee.com, the product manager can filter and summarize the requirements for this version, using the full issue library in the community.
+
+Notes:
+
+- All requirement issues should be associated with corresponding SIG group by marking the SIG belonging tag. 
+- Requirements should be filled in clearly according to the template, which includes requirement background, requirement description, implementation plan and acceptance standard. 
+- For requirements that need to be protected, the content risk identification check box should be checked. It can prevent access by members outside the repository. 
+- When dealing with the statistics, requirements are counted by issue type. Feature should be labeled to facilitate the filtering of foreground pages on Gitee.com.
+
+## 1.2 Requirements Review
+After summarizing the requirements, the product manager should organize the technical committee to review. After passing the review, the conclusion will be sent to all subscribers through the mailing list. Following operations will be performed on the issues on Gitee.com.
+
+- For the requirement issues planned to finish in this version, confirm that it is associated to appropriate milestone.
+- For the requirement issues planned to finish in future version, confirm that it is associated to appropriate milestone.
+- For the requirement issues that have not been scheduled for review, do not associate it with milestone and change its status to "Ignored". When it is reviewed in the future,replace its status with "Confirmed" and associate it with appropriate milestone.
+
+## 1.3 Requirements Detailed
+After the requirements review is completed, *Requirement Specification Documentation* of the requirement issues to be finished in this version should be written within a week. The documentation can be submitted through the following ways:
+- Create a PR for the *Requirement Specification Documentation* and select target branch. Fill the title with:"[The title of requirement issues]Requirement Specification Documentation". In the first line states that the documentation is a detailed description of the requirement(issue number and link). Select the label as PRD and choose the version milestone.
+- After submitting the PR, the reviewer will check and merge it if meet the requirements.
+- After the PR is merged, explain in the comment box of the requirement issue that this is the link of the requirement issue PR.
+
+## 1.4 Requirements Detailed
+After Release SIG group defines the release plan, the product manager should notify all subscribers of the version plan through mailing list. In addition, he should notify SIG groups to schedule requirement issues.
+- The maintainer of each SIG group should specify the issue completion plan of their own group. Mark the "start date" and "end date" on Gitee.com and set "priority".
+- After the requirement issues are scheduled, release manager of Release SIG group should check the requirment issues schedule. For those controversial requirements, he could organize a review.
+
+Notes:
+- The conclusion of the review can be notified to all subscribers via the mailing list.
+
+## 1.5 Requirements Detailed
+If the requirement range and plan change in the version plan, the product manager should organize the technical committee or Release SIG group to review the changes. After the review finished, the product manager should notify all subscribers of the conclusion through mailing list. Following steps should be taken:
+- In the comment box of the changing requirement issue, mark the changing reason and review conclusion of the requirement.
+- For the requirement issue that milestone changed, confirm the milestone plan after the changing association and set correct schedule. For requirement issue without planning, milestone should not be related and change its status to "Ignored".
+- For the requirement issue with changing requirement scope, the requirement principal should write the requirement documentation after change. The requirement documentation PR should be submitted with the way in 1.3.
+
+Notes:
+- All subscribers should be notified of the review conclusion through the mailing list.
+