TGFR Consulting LLC The development of the final set of requirements closely couples to the development of the architecture. Architecture embodies the breakdown of the system into subsystems, and the final system requirements development should consider the architecture. Many approaches to medical device development advocate for design inputs that are “concept free”, but a concept free approach can lead issues when the design inputs are translated to lower level requirements. Specific areas that can be addressed through consideration of the architecture of the system include
- Subsystem Development and Integration – a system where requirements map more directly to the subsystems lessens the pressure to ensure that subsystems and interfaces are consistent during development. Subsystem development can proceed without the necessity to review and evaluate design through the development cycle.
- Subsystem Verification – Verification at the subsystem level can satisfy the overall system verification, usually with much less cost. As an example, a single drug delivery subsystem with that delivers all of the critical requirements for accuracy may be tested using “white box” methods that are much more efficient and accurate.
Overall, the careful consideration of the structure of the requirements and the associated architecture results in a system more amenable to parallel subsystem development, cleaner integration and simpler verification.
Architecture Evaluation Criteria
The elaboration process begins with identifying the goals for the subsystem decomposition. Manufacturing capability, the development approach (insource/outsource) and organizational factors drive the development of goals for the subsystem decomposition. Key business elements for consideration include
- Voice of the Business – in some texts this is referred to as “non-functional requirements”, but represents the product from an institutional view
- Manufacturing Capability – this is the “how” for the production, and needs to consider make/buy and other critical factors.
- Pre-existing Systems – in almost all system development, pre-existing systems or components exist
In addition to the business considerations, design considerations should be established. These should include
- Coupling – the degree to which subsystems depend upon each other
- Cohesion – the degree to which the elements of a subsystem functionally belong together.
- Subsystem Structure – This should consider organizational structure and the alignment of the architecture with the structure of the development group. A old saying, “the system architecture reflects the organization” should not be ignored.
The elements should be formed into a set of “needs” and given the familiar 1/3/9 weighting. Only one or two of the design or business needs should be assigned a 9 weighting. The following figure shows the Pugh Matrix for architecture
The process of developing the system architecture relies on the same iterative techniques used in the development of the concept. At least two passes, with the development of a super concept, should be performed. This will drive the development and evaluation of alternatives for the architecture and prevent rushing to an unsuitable partitioning with issues that will only surface during the subsequent stages of development.
Definition of the architecture is best performed prior to the finalization of requirements. As will become apparent, tailoring the final system requirements to the architecture will result in a system that is easier to integrate and verify. The following illustrates the general flow
This workflow replicates the workflow used in concept development. Wherever possible several sub-teams should develop proposed architectures. The whole development team evaluates the proposals and develops the super concept for the iteration. This should continue until the team decides that further iteration will not substantively change the outcome.