Читать книгу Design for Excellence in Electronics Manufacturing - Cheryl Tulkoff - Страница 21

Requirements Verification Assessment for Accuracy and Completeness

Historically, many software discrepancies can be traced back to specification inadequacies, such as inconsistent, incomplete, imprecise, or vague requirements. Therefore, the first step in any functionality/software validation effort is for the responsible software design organization to perform an analytical review with the specifying organization. The review facilitates an understanding of the requirements, ensures accurate requirements communication, weeds out obvious discrepancies before they are incorporated into the code design, and determines and documents the readiness of the specification for starting the design effort. With this knowledge, corrections can be rapidly implemented.

The review results should be documented in an electronic format (spreadsheet or database) that allows it to be a living document for program tracking, management, and corrective action purposes. It should be organized around the functionality requirement number and title of the software specification. For each requirement line item, there should be a category field or cell to document the following requirement status:

 Requirement is missing.

 Requirement is incomplete or contains to‐be‐determined items (TBDs).

 Requirement is vague or not understood.

 Requirement is inconsistent or incompatible with other requirements.

 Missing identification of requirements that involve regulatory certification.

 Requirement is not optimized or not user‐friendly. Include why and recommendations.

 Requirement is not robust.

 Requirement is inadequate or undefined. Include specifics and recommendations.

 Resolution responsibility and/or owner.

 Date the issue was resolved.

 Resolution comment. Upon resolution, move the original issue(s) to a cleared‐issue field, and add a summary of the corrective action.

The knowledge and requirements understanding gained in the specification review should also be used in the creation of the software development validation plan.

Software Development/Validation Plan

The software design organization or supplier is required to develop, maintain, and track performance against a software development validation plan that complies with the requirement of ANSI/IEEE 829, “Standard for Software Test Documentation.” Customers may request the use of an alternative, similar format pending approval by the product team. The plan should be in an electronic format (spreadsheet or database) that allows it to be a living document for program tracking and management purposes. The purpose of the software plan is to facilitate an effective test‐planning process and to communicate to the entire product, systems engineering, and software team the scope, approach, resources, and schedule of the development validation activities.

The plan also identifies the input/output (I/O), items and features to be tested, testing tasks to be performed, and person responsible for each task. Since it is impossible to test every aspect and I/O configuration of complex software, the plan should also identify any items or features scheduled for limited testing or not to be tested along with the related rationale and risk. Finally, the test plan should also identify and lead to the creation of feature‐specific test procedure scripts as needed.