Ketryx Documentation
Book a DemoFAQTraining Videos
  • Introduction
  • 📄Manuals
    • MAN-01 Ketryx Lifecycle Management
    • MAN-02 Software Release Process
    • MAN-03 Supply Chain Management: Software Dependencies
      • Threat Modeling
      • Vulnerability Management
      • Working with CycloneDX
      • Working with SPDX
    • MAN-04 Supply Chain Management: Cloud Dependencies
    • MAN-05 Milestones
    • MAN-06 Test Management
    • MAN-07 Traceability
    • MAN-08 Risk Management
    • MAN-09 Git-Based Configuration Items
    • MAN-10 Managing items in Ketryx
    • MAN-11 Approval Rules
    • MAN-12 Computational Controls
    • MAN-13 Data Export
  • 🛠️Work Instructions
    • WI-01 Requirement
    • WI-02 Software Item Specification
    • WI-03 Task
    • WI-04 Test Case
    • WI-05 Test Execution
    • WI-06 Anomaly
    • WI-07 Complaint
    • WI-08 Change Request
    • WI-09 Corrective and Preventive Action (CAPA)
    • WI-10 Risk
    • WI-11 Document
  • 🌐Integrations
    • Jira
    • Azure DevOps
    • TestRail
    • Jama
    • Polarion
    • Chrome extension
    • Source Code
      • Azure DevOps
      • Bitbucket
      • GitHub
      • GitLab
      • Code Change Reviews
    • Release documents
      • Google Workspace
    • Authentication
  • 📚Reference
    • Ketryx Query Language
    • Advanced Settings
    • Glob Pattern Matching Algorithm
    • Traceability Configuration
    • Document Templating
    • Project Settings
    • Custom Item Types
    • Assistant
    • Agents
    • Release Notes
  • 🔃API
    • Authentication
    • Build API
    • Project API
    • Item API
    • Webhooks
Powered by GitBook

Ketryx

  • ketryx.com
  • What is Ketryx?

Resources

  • FAQ
  • Training Videos

© 2025 Ketryx Corporation

On this page
  • 1. Introduction
  • 1.1. Purpose
  • 1.2. Scope
  • 1.3. Records and evidence
  • 1.4. Responsibilities
  • 2. Procedure description
  • 2.1. Step 1: Log into Jira
  • 2.2. Step 2: Create
  • 2.3. Step 3: Navigate to the work item page
  • 2.4. Step 4: Change status to In Progress
  • 2.5. Step 5: Draft/Author Requirement
  • 2.6. Step 6: Change status to Resolved (Ready for Review)
  • 2.7. Step 7: Review as Owner
  • 2.8. Step 8: Review as Product Manager
  • 2.9. Step 9: Review as R&D Lead
  • 2.10. Step 10: Review as Quality Manager
  • 2.11. Step 11: Transition to a controlled state
  • 2.12. Step 12: Change
  • 2.13. Step 13: Mark as obsolete
  • 3. Procedure flow diagram
  • 4. Item schema
  • 5. Traceability to other configuration items

Was this helpful?

Export as PDF
  1. Work Instructions

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 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

  1. Define an appropriate title in the Summary field.

  2. Define an appropriate Assignee (the Item Assignee).

  3. Provide additional preliminary information in the extra fields. (All fields can still be edited later.)

2.3. Step 3: Navigate to the work item 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 work item status to In Progress using the work item 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 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. 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. 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. 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

PreviousMAN-13 Data ExportNextWI-02 Software Item Specification

Last updated 17 days ago

Was this helpful?

Press the Create button in the top-level navigation to open the form to create a new Jira work item.

Ensure the desired project is selected, and select the Work type "Requirement". If that does not appear, check with your system administrator to ensure your project is connected to Ketryx.

Press the Create button at the end of the form to finalize the creation of the new Jira work item.

🛠️
Navigate to the created work item
Change work item status to In Progress
Fill in work item details
Change work item status to Resolved
Approve as owner
Approve as R&D Lead
Work item transitioned to Closed by Ketryx