FAQTraining Videos

WI-02 Software Item Specification

Work Instruction for Software Item Specification configuration item

1. Introduction

1.1. Purpose

This Work Instruction provides the set of tasks required to be performed as part of the Software Item Specification (Software Item Spec) configuration item lifecycle.

1.2. Scope

This Work Instruction covers the complete Software Item Spec lifecycle, from creation to obsolescence.

1.3. Records and evidence

Records for each Software Item Spec will be held based on the records and retention policy. Software Item Specs 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 design specification (with details)

  • System design structure matrix

  • System architecture chart

  • Test plan

  • Traceability matrix

1.4. Responsibilities

As listed in the procedure description, each task in the Software Item Spec 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 Software Item Spec. This organization member is responsible for managing/completing the Software Item Spec lifecycle activities. This Item Assignee can change from time to time.

  • R&D Leads: The person accountable for the Software Item Spec. The R&D Lead verifies the Software Item Spec can be implemented and is accountable for it. The R&D Lead is consulted to approve the Software Item Spec.

  • Quality Managers: The person that verifies the Software Item Spec is correctly documented. The Quality Manager is consulted to approve the Software Item Spec.

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

  3. Define an appropriate title in the Summary field.

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

  5. 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 Software Item Spec, e.g., _your-company.atlassian.net/browse/SIS-1.

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 Software Item Spec

Item Assignee

As needed, fill in the information in the fields of the Software Item Spec.

Ensure that at least the following fields are filled out:

  • Summary (title)

  • Assignee

  • Description

  • Introduced in version (unless the Software Item Spec is introduced from the start of the project)

Set the Parent software items and Fulfilled requirements as appropriate. These constitute the design input for this Software Item Spec.

The Software Item Spec should be SMART (Specific, Measurable, Achievable, Relevant, and Testable). The Software Item Spec should also:

  • be traceable to all other needed items, with clearly defined interfaces;

  • not conflict with another Software Item Spec; and

  • conform to any provided design input.

Set the Safety risk class and the Security risk class as appropriate.

If new risks emerge from this Software Item Spec, Anyone can create a new Risk item and trace it to the Software Item Spec by including it in the Risks field.

2.6. Step 6: Change status to Resolved (Ready for Review)

Anyone

Once the Software Item Spec is completed and ready for design verification, change its status to Resolved.

2.7. Step 7: Review as Owner

Item Assignee

Review the Software Item Spec to verify:

  • The Software Item Spec is traceable to all other needed items, and all interfaces are defined.

  • The Software Item Spec is Specific, Measurable, Achievable, Relevant, and Testable (SMART).

  • The design output (the Software Item Spec and its siblings) conforms to the design input (the Software Item Spec’s Parent software items and its Fulfilled 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 Software Item Spec as seen in the screenshot below and continue to Step 10.

2.8. Step 8: Review as R&D Lead

R&D Lead

Review the Software Item Spec to verify:

  • The Software Item Spec is traceable to all other needed items, and all interfaces are defined.

  • The Software Item Spec is Specific, Measurable, Achievable, Relevant, and Testable (SMART).

  • The design output (the Software Item Spec and its siblings) conforms to the design input (the Software Item Spec’s Parent software items and its Fulfilled 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 Software Item Spec as seen in the screenshot below and continue to Step 10.

2.9. Step 9: Review as Quality Manager

Quality Manager

Review the Software Item Spec to verify:

  • The Software Item Spec is traceable to all other needed items, and all interfaces are defined.

  • The Software Item Spec is Specific, Measurable, Achievable, Relevant, and Testable (SMART).

  • The design output (the Software Item Spec and its siblings) conforms to the design input (the Software Item Spec’s Parent software items and its Fulfilled 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 Software Item Spec as seen in the screenshot below and continue to Step 10.

2.10. Step 10: Transition to a controlled state

Ketryx

Only Ketryx can move a Software Item Spec to a controlled and effective state by transitioning its status to Closed. Ketryx moves the Software Item Spec to a Closed state after all approval rules have been passed, i.e., all required steps have approved the Software Item Spec.

Ketryx automatically adds a comment to the Jira issue with a link to the effective controlled record in Ketryx.

2.11. Step 11: Change

Item Assignee

Following a Change Request (i.e., the issue needs to be modified), reopen the Software Item Spec to create a new record, and go back to Step 4.

2.12. Step 12: Mark as obsolete

Item Assignee

To mark a Software Item Spec as obsolete (i.e., as not effective anymore starting with a given version),

  • reopen it for change (Step 11);

  • 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-9).

3. Procedure flow diagram

4. Item schema

  • Description (rich text): The Software Item Specification description. The Software Item Specification should define clearly and precisely what the software architecture should do and not do, i.e., constraints. Software Items 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 software items (-> Software Item Spec): Parent item(s) this software item is contained in.

  • Fulfilled requirements (-> Requirement): The requirements fulfilled by this item.

  • Software item type: The type of this software item.

    • SOUP

    • MDD

    • Safety

    • Security

    • Function

    • Library

    • Contracted

    • 'Medical Device'

    • Interface

  • Safety risk class: The software item risk class.

    • Class A: No injury or damage to health is possible.

    • Class B: Non-serious injury is possible.

    • Class C: Death or serious injury is possible.

  • Security risk class: The security risk class of this software item.

    • Low

    • Medium

    • High

  • Inputs (rich text): Inputs to this software item.

  • Outputs (rich text): Outputs of this software item.

  • Used items (-> Software Item Spec, Hardware Item Spec, Configuration Item): Items that this item uses or interfaces with.

  • Rationale (rich text): The rationale behind this item, i.e., why this particular method to fulfill the Software Item Specification and its design input was chosen.

  • Introduced risks (-> Risk): Risks introduced by this item.

  • Context: The context of this software item.

    • Clinical

    • Safety

    • Security

    • Regulatory

5. Traceability to other configuration items

The following relations can be defined from a Software Item Spec to other configuration items:

  • Software Item Spec fulfills Requirement

  • Software Item Spec has parent Software Item Spec

  • Software Item Spec introduces risk Risk

  • Software Item Spec uses Hardware Item Spec, Software Item Spec, Configuration Item

The following relations can be defined from other configuration items to a Software Item Spec:

  • Software Item Spec has child Software Item Spec

  • Software Item Spec is implemented by Task

  • Software Item Spec is used by Software Item Spec, Hardware Item Spec

  • Software Item Spec is tested by Test Case

  • Software Item Spec is affected CAPA, Change Request, Anomaly

  • Software Item Spec results from Change Request, CAPA

  • Software Item Spec resolves Anomaly, Complaint

  • Software Item Spec risk-controls Risk

PreviousWI-01 RequirementNextWI-03 Task

Last updated

Ketryx

ketryx.comWhat is Ketryx?

Resources

FAQTraining Videos

© 2024 Ketryx Corporation