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 groups. When any of these approval group 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

Press the Create button in the top-level navigation to open the form to create a new Jira issue.
Ensure the desired project is selected, and select the Issue type “Software Item Spec”. If that does not appear, check with your system administrator to ensure your project 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 issue.

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

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

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 groups 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.
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.
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: 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