I have been putting together some posts on program management and system development. One of the upcoming ones will be how to write well-formed requirements. As an example of why well-formed requirements are important, I would like to share some issues with a recent piece of my own work: the Basic Ethernet Switch Replacement Requirements.
IEEE Std 1233 defines a well-formed requirement as “a statement of system functionality (a capability) that can be validated, that must be met or possessed by a system to solve a customer problem or to achieve a customer objective, and that is qualified by measurable conditions and bounded by constraints.” Later it describes the properties of a requirement. They should be implementation independent. You should state them so they have only one interpretation. They should be traceable to a specific need. There should be a way to prove that the system satisfies them.
To break that down, each requirement:
-
can be validated
-
must be met (or possessed) to solve the problem
-
is measurable
-
is bounded by constraints
-
is implementation independent
-
has only one interpretation
-
is traceable to a specific need
-
can be proven to be met
With that in mind, look at some of my requirements.
AS3. Does not require the use of proprietary mechanisms, where an IEEE, IETF, or Internet RFC standards based mechanism is currently available
This sounds like a great requirement. Do you want ice cream with your motherhood and apple pie? It would be a wonderful world if everybody did everything in a standard way. On the other hand, it might stifle innovation. When it comes down to it, if we have specific traceable needs for things to be done in a standard way, we should ask specifically about them. In fact, we do regarding CDP, LLDP, LLDP-MED, CIP, and IEEE 802.3af. As for this requirement, we cannot validate it, it is not necessary to solve our problem, and it is unbounded. Worst of all, it has more than one interpretation. Is “Yes” or “No” the correct answer? (“Yes, we only use standard mechanisms,” or “No, we do not require any non-standard mechanisms.”) This is especially troublesome when you state a requirement in a negative way (“Does not do X.”)
For the purposes of the basic switch, I will strike this requirement. For future documents, I will keep it as a note to the writer that if a system can acceptably satisfy a specific need in a standard way, we should ask the system to do it in that way.
MN7. Propagates framing errors to the mirror port
MN10. Alerts the monitoring port or log record if mirror packets are dropped
These two requirements are troublesome because they are interdependent. The idea is that if you are monitoring traffic on a mirror port, you want to see everything. If there are errors in the traffic, you might want to see that, as well. Hence, MN7. However, you might consider this to be an error, which is acceptable, in which case we would at least like to know that you did not forward the error traffic by having you log the fact. So, if you answered MN7 and MN10 “Yes” and “No,” respectively, that would be OK. If you answered “No” and “Yes,” that might still be OK. If you answered “No” and “No,” that sounds bad. If you answered “Yes” and “Yes,” you clearly did not understand the question.
If you go back to the list above as to the properties of a well-formed requirement, you see that the problem with each of these is that individually the system does not need to meet them in order to solve the problem.
For the purposes of the basic switch, I am going to ignore responses to these requirements. We will still test to be sure the equipment does what we need. In the future, I will try to find a way to express our need more clearly.
SC1. Does not forward unicast packets not destined for an individual port
SC2. Does not forward packets to a port before learning the MAC address of the attached device
The basic switch has had a long life at Penn State — longer than many of the applicable standards. Today, the operation of a switch is well defined in IEEE Std 802.1D-2004.
For the purposes of the basic switch, I am going to ignore responses to these requirements. We will still test to be sure the equipment does what we need. In the future, I will try to find a way to express our need more clearly.
SC4. Can continue to operate when ports are placed in the loopback condition (pin 1 to pin 3 and pin 2 to pin 6)
I believe this requirement arose when devious individuals learned that shorting the indicated pins creates, in some very old devices, a condition where the switch sends itself a BPDU and then receives it on the same port and then spends all of its remaining time on this Earth forwarding the packet around at the expense of forwarding actual traffic. Eventually the IEEE modified the Spanning Tree Protocol to validate a received BPDU to be sure the same port that received it did not transmit it (Clause 9, section 9.3.4, Note 1). This is an obscure requirement and not normally listed in data sheets, though we expect most modern devices satisfy this requirement.
For the purposes of the basic switch, I am going to ignore responses to these requirements. We will still test to be sure the equipment does what we need. In the future, I will try to find a way to express our need more clearly.
Summary
I know some people think spending time creating well-formed requirements is time wasted. If I had spent more time up front, I might have been able to reduce the amount of hands on testing my group will now have to do. That is the trade off: more time now for less time later. I have heard it said this way: “Fail early, fail often.” Be like Gordon the Guided Missile.
——–