...
- Navigate to
Jira Legacy showSummary false server System Jira serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176 key REQ-1 - Select More==>Clone++
- Follow the steps in the dialog to clone the issue in the same project (i.e., REQ). Make sure that the checkbox, "copy issues in epic" is selected.
- Modify the "epic name" and "description" fields for your requirement.
- Set the "Fix Version" field to the release name for which the use case is intended (e.g., "Frankfurt")
- Set the "Assignee" field to the requirement owner.
- If the requirement has other requirements or tasks as dependencies, add the requirements in the "Issues in Epic" field.
- Add a link to the JIRA issue in the appropriate column of the table on the release requirements page.
- Once the TSC has determined the priority for the requirement (0 - 4), set the value in the "TSC Priority" field.
- The template includes three sub-tasks for the TSC approvals at MS1, MS3, and MS4. As these approvals are achieved, add a comment to the sub-task with a link to the approval documentation and mark the task as done.
Structure and Organization of Related Issues
The purpose of the Release Requirements (REQ) JIRA project is to create a single point from which all issues related to a particular release requirement may be found. This association is nicely accomplished using the JIRA linking capability. We will use two links, in particular: 1) "is blocked by"; and 2) "is related to". Notice that we do not use "blocks". This is because we want the REQ issue to be at the root of a network of related issues. The REQ issue served an administrative function by creating a single connecting point for the network, while all of the other issues fill in the user story, features, tasks, and bugs.
Gliffy | ||||||
---|---|---|---|---|---|---|
|