Data Driven Process
- Missing or poorly communicated system requirement
- Missing or poorly communicated software requirement or software design specification
- Software coding error
- Error in custom authored software, open source software or other acquired software
- Improper use or interface with open source software or other acquired software
Using this information for example, we can address the process by which system requirements are elicited and generated from the Design Input. It could be that the problem might be addressed with earlier review and evaluation of system requirements, or involving subject matter experts to breakdown the medical impact at a system level so that the variability from software can be critically reviewed earlier. Certainly defects in software requirements and/or design should cause us to analyze how software requirements are generated or design is actually done (if at all) and reviewed. Coding defects may lead to changes in coding standards.
Another useful metric is when and where was the defect found in the lifecycle? This can help us consider methods and processes to find and eliminate defects easier in the process. A defect found early in the lifecycle is a “gift” – it is a good thing. Celebrate it. That is the goal.