Monthly Archives: September 2007

Other Clarifications

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.

Labels: ,

——–

Environmental Clarification

In our Basic Ethernet Switch Replacement Requirements we specified an equipment environment with temperatures between 32 and 120�F and humidity up to 90% non-condensing. Of the nine vendors we asked, only one could meet this requirement. Rather than throw out everybody, we reviewed the requirement.

We have been copying this requirement from specification to specification for years now, without really considering how the Penn State environment has changed. Since we are not environmentally bent, we went to the director of the TNS Special Projects group for help with what we should be looking for now.

He told us that the temperature specification we are currently designing to specifies a low of 32�F, a continuous high temperature of 86�F with 104�F for up to two hours. The humidity does not specify a percentage, just non-condensing.

With these changes, everybody satisfied the environmental requirements.

Labels:

——–

Steve Jobs on the Technology Road

Apple — To all iPhone customers: “I can attest to the fact that the technology road is bumpy. There is always change and improvement, and there is always someone who bought a product before a particular cutoff date and misses the new price or the new operating system or the new whatever. This is life in the technology lane. If you always wait for the next price cut or to buy the new improved model, you’ll never buy any technology product because there is always something better and less expensive on the horizon.”

——–

What is a PM?

Different people call them different things — product managers, program managers, and project managers — depending on their culture, organizational structure, and the type of work their group performs. However, they all count as P.M. to me. Here is one perspective on their work from the New York Times technology editor, David Pogue:

When I’m reviewing something for my Times column, the first line of defense for the company whose product I’m trying out is usually the P.R. person. Often, though, I’m then put through to the person who really has the answers: the product manager.

The product manager (P.M.) is an interesting beast, sort of a crossbreed: somebody who knows a lot about the product and its target audience, as the engineers and programmers do, but who’s also there to promote the product, as the P.R. people do. (Just as the P.R. person is a gatekeeper for the P.M., the P.M. is a gatekeeper for the engineers if the questions get too tough.)”

References

David Pogue, ‘Amusing Tales of Product Managers’, The New York Times (September 6, 2007) <http://www.nytimes.com/2007/09/06/technology/circuits/06pogue-email.html> [accessed September 6, 2007] (para 1–2)

Labels:

——–