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 steps. When any of these 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 Requirement 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.
1.5. Authoring paths
As listed in the procedure description, requirements may be authored :
entirely in Jira
in Ketryx, leveraging the AI assistant for faster generation of compliant requirements, then synced to Jira
2. Jira Procedure description
Two authoring paths may be used. Jump to 2.14 to see the steps for authoring on Ketryx with the AI assistant.
2.1. Jira Step 1: Log into Jira
Anyone
Log into your Jira organization, e.g., your-company.atlassian.net.
2.2. Jira Step 2: Create
Anyone
Press the Create button in the top-level navigation to open the form to create a new Jira work item.
Ensure the desired space (formerly project) is selected, and select the Work type "Requirement". If that does not appear, check with your system administrator to ensure your space is connected to Ketryx.
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.)
Press the Create button at the end of the form to finalize the creation of the new Jira work item.
2.3. Jira Step 3: Navigate to the work item page
Anyone
Using the popover shown by Jira or by clicking the "All work" tab, navigate to the Jira page of the Requirement.
2.4. Jira Step 4: Change status to In Progress
Anyone
Change the work item status to In Progress using the work item status selector.
2.5. Jira 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. Jira 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. Jira 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. Jira 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. Jira 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. Jira 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. Jira 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 steps have approved the Requirement.
Ketryx automatically adds a comment to the Jira work item with a link to the effective controlled record in Ketryx.
2.12. Jira Step 12: Change
Item Assignee
Following a Change Request (i.e., the work item needs to be modified), reopen the Requirement to create a new record, and go back to Step 4.
2.13. Jira 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 work item (Step 6); and
approve the item (Steps 7-10).
3. Ketryx Procedure Description
3.1 Ketryx Step 1: Navigate to Ketryx Project
Anyone
Navigate to your Ketryx project in the web application at app.ketryx.com or, if applicable, your dedicated organization URL.
3.2 Ketryx Step 2: Create Requirement
Anyone
You have two options for creating a Requirement in Ketryx:
Option A (recommended): AI-Assisted Creation
Open the Ketryx AI Assistant sidebar (click the AI assistant icon 🪄 in the top right of the page)
Describe the requirement you want to create in natural language. Examples:
"Please create a new requirement for bluetooth connectivity"
"Create a requirement that the device must support wireless charging"
"I need a SMART requirement for user authentication with biometric login"
Review the AI-generated requirement suggestion that appears in the chat
Click the "Review Suggestion" button that appears in the Assistant response
Review all auto-populated fields (title, description, etc.)
Make any necessary adjustments in the review dialog
Click "Create Item" to finalize the creation
Note: The AI Assistant can create multiple related requirements at once. For example: "Create 3 requirements for device battery management" will generate 3 separate requirement items.
Option B: Manual Creation via UI
Click the "+ Create" button in the top navigation bar or on the All Items page
From the item type dropdown, select "Requirement"
Define an appropriate title in the Title field
Define an appropriate Assignee (the Item Assignee)
Provide preliminary information in available fields (all fields can be edited later)
Click "Create" to create the new Requirement item
3.3 Ketryx Step 3: Add assignee and status
Anyone
After creation, the all items page will automatically open, filtered on newly created item or items.
Then, for each item created:
Click on the item title to open the item record details page
Click on edit item
Add an assignee
Change status to in progress
Save changes
[optional] improve contents and traceability - see Ketryx step 4
Use the back function of you browser to come back to the all items page filtered on the newly created items
3.4. Ketryx step 4: improve contents and traceability
Item Assignee
3.4.1 AI-Assisted Field Completion and enhanced quality checks
Open the Ketryx Assistant sidebar
Request AI assistance to check, complete or improve fields. Examples:
"Elaborate on all fields for this requirement"
"Make this requirement SMART-compliant"
"Add more detail to the description field"
"Does this requirement duplicate or conflict with any existing requirements?"
"What risks might this requirement introduce?"
The Assistant can create Risk items automatically if risks are identified
Establish traceability links using the Introduced risks field
Review the AI-generated edit suggestions
Click the "Review Suggestion" button
Review the proposed changes in the dialog and edit as needed
If you wish to keep the suggested changes, click "Apply Changes" to update the Requirement
3.4.2 AI-Assisted Traceability Suggestions
For relationship fields (e.g., Parent requirements, Introduced risks), click the 🪄 Suggest button next to the field.
The Assistant will analyze your project and suggest relevant items to link. For example you can ask: "Check traceability for this item and suggest missing links", or "Verify this item has complete traceability per QMS requirements and suggest missing links"
Review the suggestions and select appropriate items
Click "Add" to establish the traceability links
4. Procedure flow diagram
5. 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.
6. 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
Was this helpful?