WI-01 Requirement
Work Instruction for Requirement configuration items
1. Introduction
1.1. Purpose
This Work Instruction provides the set of tasks required to be performed as part of the Requirement configuration item lifecycle.
1.2. Scope
This Work Instruction covers the complete Requirement lifecycle, from creation to obsolescence.
1.3. Records and evidence
Records for each Requirement will be held based on the records and retention policy. Requirements are used to generate the following artifacts:
Change management file
Change request verification report
Risk control matrix (risk control measures only)
Risk management file
Risk matrix
System requirement specification (with details)
System design specification
Test plan
Traceability matrix
1.4. Responsibilities
As listed in the procedure description, each task in the Requirement item’s lifecycle will be completed by a member that is part of one of the following approval groups. When any of these approval group members can perform the task, Anyone is listed.
Item Assignee: The person authoring and responsible for the Requirement. This organization member is responsible for managing/completing the Requirement lifecycle activities. This Item Assignee can change from time to time.
Product Managers: The person accountable for the Requirement. This organization member leads the product development, defines requirements, and ensures that the product meets customer demands. The Product Manager is accountable for the R_equirement_ being correct.
R&D Leads: The person that verifies the Requirement is executable. The R&D Lead is consulted to approve that the Requirement is actionable.
Quality Managers: The person that verifies the Requirement is correctly documented. The Quality Manager is consulted to approve the Requirement is correctly documented.
2. Procedure description
2.1. Step 1: Log into Jira
Anyone
Log into your Jira organization, e.g., your-company.atlassian.net.
2.2. Step 2: Create
Anyone
Define an appropriate title in the Summary field.
Define an appropriate Assignee (the Item Assignee).
Provide additional preliminary information in the extra fields. (All fields can still be edited later.)
2.3. Step 3: Navigate to the issue page
Anyone
Using the popover shown by Jira or through other means, navigate to the Jira page of the Requirement.
2.4. Step 4: Change status to In Progress
Anyone
Change the issue status to In Progress using the issue status selector.
2.5. Step 5: Draft/Author Requirement
Item Assignee
As needed, fill in the information in the fields of the Requirement.
Ensure that at least the following fields are filled out:
Summary (title)
Assignee
Description
Introduced in version (unless the Requirement is introduced from the start of the project)
Set the Parent requirements as appropriate. These constitute the design input for this Requirement.
The Requirement should be SMART (Specific, Measurable, Achievable, Relevant, and Testable). The Requirement should also:
be traceable to all other needed items, with clearly defined interfaces;
not conflict with another Requirement; and
conform to any provided design input.
If new risks emerge from this Requirement, Anyone can create a new Risk item and trace it to the Requirement by including it in the Risks field.
2.6. Step 6: Change status to Resolved (Ready for Review)
Anyone
Once the Requirement is completed and ready for design verification, change its status to Resolved.
2.7. Step 7: Review as Owner
Item Assignee
Review the Requirement to verify:
,The Requirement is traceable to all other needed items, and all interfaces are defined.
The Requirement is Specific, Measurable, Achievable, Relevant, and Testable (SMART).
The design output (the Requirement and its siblings) conforms to the design input (the Requirement’s Parent requirements).
If the verification fails, reopen the ticket and, if needed, provide a comment on the reason it failed, then go to Step 5. If verification passes, approve the Requirement and continue to Step 11.
2.8. Step 8: Review as Product Manager
Product Manager
Review the Requirement to verify:
The Requirement is traceable to all other needed items, and all interfaces are defined.
The Requirement is Specific, Measurable, Achievable, Relevant, and Testable (SMART).
The design output (the Requirement and its siblings) conforms to the design input (the Requirement’s Parent requirements).
If the verification fails, reopen the ticket and, if needed, provide a comment on the reason it failed, then go to Step 5. If verification passes, approve the Requirement and continue to Step 11.
2.9. Step 9: Review as R&D Lead
R&D Lead
Review the Requirement to verify:
The Requirement is traceable to all other needed items, and all interfaces are defined.
The Requirement is Specific, Measurable, Achievable, Relevant, and Testable (SMART).
The design output (the Requirement and its siblings) conforms to the design input (the Requirement’s Parent requirements).
If the verification fails, reopen the ticket and, if needed, provide a comment on the reason it failed, then go to Step 5. If verification passes, approve the Requirement and continue to Step 11.
2.10. Step 10: Review as Quality Manager
Quality Manager
Review the Requirement to verify:
The Requirement is traceable to all other needed items, and all interfaces are defined.
The Requirement is Specific, Measurable, Achievable, Relevant, and Testable (SMART).
The design output (the Requirement and its siblings) conforms to the design input (the Requirement’s Parent requirements).
If the verification fails, reopen the ticket and, if needed, provide a comment on the reason it failed, then go to Step 5. If verification passes, approve the Requirement and continue to Step 11.
2.11. Step 11: Transition to a controlled state
Ketryx
Only Ketryx can move a Requirement to a controlled and effective state by transitioning its status to Closed. Ketryx moves the Requirement to a Closed state after all approval rules have been passed, i.e., all required groups have approved the Requirement.
Ketryx automatically adds a comment to the Jira issue with a link to the effective controlled record in Ketryx.
2.12. Step 12: Change
Item Assignee
Following a Change Request (i.e., the issue needs to be modified), reopen the Requirement to create a new record, and go back to Step 4.
2.13. Step 13: Mark as obsolete
Item Assignee
To mark a Requirement as obsolete (i.e., as not effective anymore, starting with a given version),
reopen it for change (Step 12);
set the version it will be obsolete in (i.e., where the first version that it will not be effective in anymore) in the Obsolete in version field;
resolve the issue (Step 6); and
approve the item (Steps 7-10).
3. Procedure flow diagram
4. Item schema
Description (rich text): The Requirement description. Requirements should be Specific, Measurable, Achievable, Realistic, Testable (SMART).
Introduced in version (version reference): The first version this item is effective in. If empty, the item is considered effective from the start of the project.
Obsolete in version (version reference): The version the item is becoming obsolete in, i.e. the first version that this item is not effective anymore.
Parent requirements (-> Requirement): Parent requirement(s) this requirement fulfills and refines, if any.
Relevant standards (short text): Standards, regulation, and guidance relevant to this requirement.
Requirement type: The type of this requirement.
Context: The context of this requirement.
Clinical
Safety
Security
Regulatory
Introduced risks (-> Risk): Risks introduced by this item.
Rationale (rich text): The rationale behind this item.
5. Traceability to other configuration items
The following relations can be defined from a Requirement to other configuration items:
Requirement introduces risk Risk
Requirement has parent Requirement
The following relations can be defined from other configuration items to a Requirement:
Requirement has child Requirement
Requirement is fulfilled by Software Item Spec, Hardware Item Spec
Requirement is implemented by Task
Requirement risk-controls Risk
Requirement is tested by Test Case
Requirement is affected by CAPA, Change Request, Anomaly
Requirement resolves Anomaly, Complaint
Requirement results from Change Request, CAPA
Last updated
