A few years ago, bioMérieux began building a global systems development group that would put more emphasis on systems engineering approaches to product development. As a member of the Research & Development Engineering group at bioMérieux for the past 10 years, I was interested in how this new focus would affect my role. I therefore began looking for systems engineering programs, a search that led me to the certificate program offered by MIT's System Design and Management (SDM) program.
Although I discovered SDM barely in time to apply, I was able to secure support from bioMérieux within days. What sold bioMérieux on this opportunity was the required capstone project, a research endeavor designed to benefit the student's employer. As soon as I started at MIT, I began brainstorming ideas with the company's systems engineering manager, Fabienne Kappeller, and its systems test and support manager, Dennis Connor.
Both suggested that I review previous attempts by bioMérieux to implement systems engineering principles as well as current initiatives in common components and platforms. This led me to focus my capstone work on creating a common product requirements document (PRD), optimizing systems engineering document templates, and developing a proposal for integrating these documents into our product development and design controls process.
The purpose of the PRD was to provide a set of generic requirements that would remain the same across all systems developed. In addition to regulatory requirements, this would include requirements for interfacing with current bioMérieux products and for common architectural components. Because bioMérieux is a global company, a common PRD would allow us to optimize our system development efforts, focus on what is specific to each new product, and transfer knowledge across sites.
With the help of my bioMérieux colleagues, I began examining three current projects from our development sites in the United States, France, and Italy. I evaluated the existing set of product requirements for each project using the following criteria:
Is the requirement at the system level?
What are the system's broad external interactions with people, physical interfaces, functional interfaces, and immaterial factors such as regulatory standards?
Is the requirement design independent?
Are the common product requirements solution-neutral? This criterion centers on function rather than implementation. A requirement at this level should describe what the product should do, not how it should be done.
Is the requirement generic?
Can the requirements be applied to every system as written? For example, if all our products are used in a microbiology lab, they might all have the same generic requirements for decontamination or biohazard waste disposal.
In addition to declaring a generic requirement, it also might be helpful to consider if a requirement is reusable—that is, the requirement in its basic form is the same from product to product, but requires value adaptation from one system to another. All systems might have an operating environment requirement, for example, but the temperature range could vary.
Does the requirement relate to the usability aspects of the system?
Usability includes characteristics that establish effectiveness, efficiency, ease of user learning, and user satisfaction.
Is the requirement SMACC-able?
For the last criterion, the requirements are evaluated to see if they are:
- Specific: unambiguous and understandable, having only one interpretation or meaning
- Measurable: defined in quantifiable terms that can be verified or validated by an objective method of analysis, inspection, or testing
- Attainable: achievable with existing technologies or demonstrated as feasible through research of new technologies
- Consistent: not in conflict with any other requirement
- Complete: all elements are identified, adequately defined, and can be approved for use in subsequent design activities
|Click for larger image|
Table 1. The requirements count for each project examined illustrates the need for some commonality and more efficiency.
|Click for larger image|
Figure 1. This chart shows what documents are required for each level of the system as well as which ones will serve as inputs to verification and validation testing. This documentation structure help development sites to speak the same language in terms of planning, traceability, usability, and risk analysis.
Having completed SDM's one-year Graduate Certificate Program in Systems and Product Development this past summer, I am looking forward to applying the systems engineering methods I learned to product development at bioMérieux. Now that we have a common PRD and an agreed-upon documentation structure, my colleagues and I can work on updating documentation templates to provide guidance for creating requirements, specifications, and test guidelines. Once these are in place, we will be able to map the documentation deliverables and guidelines to our design control and product development process. I plan to present this work to our quality and project management organization this fall.