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

© 2024 Ketryx Corporation