Hardware/software design requirements planning: Part 3 - Performance requirements analysis
Design Constraints Analysis
Design constraints are boundary conditions within which the designer must remain while satisfying performance requirements. All of them can be grouped into the three kinds, described below.
Performance requirements can be defined prior to the identification of the things to which they are ultimately allocated. Design constraints generally must be defined subsequent to the definition of the item to which they apply. Performance requirements provide the bridge between the problem and solution planes through allocation.
Once we have established the product entity structure, we can apply three kinds of constraints analysis to these items. In the case of each constraint category, we need a special tool set to help us understand in some organized way what characteristics we should seek to control.
Interface Requirements Analysis. Systems consist of things. These things in systems must interact in some way to achieve the need. A collection of things that do not in some way interact are a simple collection of things, not a system. An interface is a relationship between two things in a system.
This relationship may be completed through many different media, such as wires, plumbing, a mechanical linkage, or a physical bolt pattern. These interfaces are also characterized by a source and a destination—that is, two terminals, each of which is associated with one thing in the system.
Our challenge in developing systems is to identify the existence of interfaces and then to characterize them, each with a set of requirements mutually agreed upon by those responsible for the two terminals. Note the unique difference between the requirements for things in the system and interfaces. The things in systems can be clearly assigned to a single person or team for development. Interfaces must have a dual responsibility where the terminals are things with different responsibilities.
This complicates the development of systems because the greatest weakness is at the interfaces, and accountability for these interfaces can be avoided by one terminal party, the other, or both if the program does not apply a sound interface development management approach.
The opportunities for accountability avoidance can be reduced by assignment of teams responsible for development as a function of the product entity structure rather than the departments of the functional organization.
This results in perfect alignment between the product cross-organizational interfaces (interfaces with different terminal organizational responsibilities) and the development team communication patterns that must take place to develop them. Responsibility and accountability is very clear.
The reader is encouraged to refer to the author’s System Requirements Analysis for a thorough discussion of schematic block and n-square diagramming techniques. As a result of having applied these techniques during the product entity structure synthesis of allocated functionality, the system engineer will have exposed the things about which interface requirements must be written.
Once again, the purpose of our tools is to do just this, to help us understand what to write requirements about. The use of organized methods encourages completeness and avoidance of extraneous requirements that have the effect of increasing cost out of proportion to their value.
Once it has been determined what interfaces we must respect, it is necessary to determine what technology will be used to implement them, such as electrical wiring, fluid plumbing, or physical contact, for example. Finally, the resultant design in the selected media is constrained by quantified requirements statements appropriate to the technology and media.
Each line on a schematic block diagram or intersection on an n-square diagram must be translated into one or more interface requirements that must be respected by the persons or teams responsible for the two terminal elements.
The development requirements for the two terminal items may be very close to identical, such as a specified data rate, degree of precision, or wire size. The product requirements, however, will often have an opposite nature to them, such as male and female connectors, bolt hole or captive bolt and threaded bore hole, or transmitter and receiver.
Loading comments... Write a comment