So how do we ensure we get meaningful requirements? We have a number of ways to understand our objective and learning about the Interviews customer clinics Simulation Digital mock ups Prototype physical mock ups Instrumentation Other information gathering (standards, regulations, etc.) We start with interviews of customers, stakeholders and project sponsors. Interviews also include customer […]
Requirements are fundamental to project success as the scope definition. Additionally, there are dependencies that impact the ability to produce suitable requirements. A few of those things are: Well defined scope of the work Sponsor and customer involvement Capability of the requirements authors Prioritized functions or abilities The needs or objectives of the customers or […]
“Scaffolding” is a term often used in education, but in our experience, rarely followed to a significant extent. Scaffolding allows us to grow a student in capability by starting easily and providing progressively more intricate and involved exercises. This approach actualizes Lev Vygotsky’s concept of the zone of proximal development. When training clients, we must […]
People in education often like to implement “programs.” In fact, we call this syndrome “program-itis” because it leads to inflammation of the budget. As with many corporation, we see people who want to improve a situation decide to follow “best practices” without verifying that these are, in fact, best practices. They can only be best […]
Creating a separate software test group has pluses and minuses. At a minimum, we may have more to manage. Some of the minuses are a product of human nature. When we know our work will be inspected, we will often assume the inspector will catch issues and we pay less attention to the issue ourselves. […]
The Pareto chart (not to be directly confused with the Pareto probability distribution function) is a simple approach to revealing significance in data. Before we plot our chart, we need to complete some initial work: Gather the data in a natural format (count, floating point [decimal], dollars, etc.) Sort the data from high to low […]
We have been on a bit a tear (or rant) about FMEAs. We suggest the FMEA documentation is part of the core of a design process. The ultimate approach we have seen is that of Michael Anleitner (The Power of Deduction: Failure Modes and Effects Analysis for Design, Quality Press, 2010), which uses functional analysis […]
There is only one way to describe this scenario and that is via a story. Consider the organization that is coming to the end of the project. The product is a complicated subassembly that goes into a larger system and has numerous interactions and incarnations of the design. They are late in the delivery of […]
We submit that a Failure Mode and Effects Analysis (FMEA) review is a form of design review. After all, one of the purposes of a design review is to try and remove defects before they appear in the product and that is the entire rationale for the FMEA in the first place. Yet, most of […]
We addressed the issue of the modular FMEA in a previous blog. We also suggest that the FMEA in its various guises is also a great place to capture lessons learned. In the medical, aerospace, automotive, and food industries, some kind of FMEA is a required document. Since we already must create these documents, why […]