Requirements and Performance are not the same thing. It is possible for a device to meet all its requirements, but have poor performance. There are many automobiles that meet both verification and validation of the basic spec, but have widely differing performances, for example.
In a general sense, requirements are discrete points of functionality, that can be verified specifically. Performance is a continuum, that covers the entire product use.
Performance in this case means:
How much a typical unit exceeds the requirements, both in quantity and magnitude
The design safety margin - how much padding is included to make sure that the unit meets the requirements
How certain the customer is that each unit meets all the requirements (quality)
How wide a range of conditions the unit will tolerate and provide specified or usable performance
How forgiving the unit is intermittent or unusual conditions, or abuse
How easily the unit can be reconfigured or reused in another application
How widely the unit conforms to voluntary or extensive industry standards
How little training or education is needed to be able to use the unit as intended
Of course, you could pin all of these things down by writing requirements, but it would be very difficult to know what the needs are of unmet customers and situations. This can be very, very difficult in the human interface area of displays and controls, especially if the product is to be used both inside and outside, over a wide geographical range, by many cultures.
In general, a standard product needs good Value, so many users will find it attractive. A custom unit only needs to meet the spec - unless you are trying to reuse it in another design. Then performance comes into play.
Example: At ADS, an important performance parameter of their standard boards was depopulation. Many parts could be left off the assembly if the customer did not need the functionality, and the unit will still function properly without additional engineering. This was performed very efficiently, so our contract manufacturers were not troubled and the customer up front charge was very reasonable. So this was a performance parameter, which was embraced by our sales and customers.
If a product has good Performance, and a good Price, it will be a good Value, and many customers will find it attractive. If you can produce it at a low Cost, you can sell it at a higher Margin, making everyone lots of money.
If the product passes Verification, indicating it has met the Requirements, but has poor Performance, it may do poorly in Validation.
Example: A vehicle unit passes formal vibration testing, but has problems in an actual vehicle vibration environment. Test conditions cannot exactly duplicate all operational conditions.
If a product does not do well in Validation, corrective action would typically involve additional Requirements. These may be design requirements, or added as qualification tests.
If a Standard Product, does not do well in Validation, the vendor may elect to make changes to improve the Performance. The product will then be resubmitted for Validation. If it is acceptable, the final design of the standard product is then put under change control to make sure that the customer continues to receive a product that will perform acceptably.
The Mars Rovers and the Voyager Spacecraft may or may not have met their design specifications, but it is their performance that has kept them in the news.
When I was at Smiths, I was the Project Engineer on two similar projects. One emphasized Requirements, one Performance. The two products appear to be very similar when placed side by side, but were very different in design and execution.
Emphasis: Requirements
This was a PCMCIA card loader for a specific Army armed reconnaissance helicopter.
Facts:
Exactly 357 aircraft were to be fitted with these units.
Three PCMCIA card slots - all dedicated for exactly one function, using only the card designed for them. The unit was not to function with any other PCMCIA card than the exact one designed for that spot. Although there was room for a fourth slot, we were directed not to implement it.
Read/Write speed, vibration, operational temperatures and other parameters were exactly known, since the equipment would only be used for this dedicated function, in a very mature aircraft environment. Any numbers we needed could be provided as a result of test.
Only specifically designed PCMICA cards were to be used in the unit.
Only one Ethernet protocol was used to interface with the aircraft systems.
Recurring and Non Recurring Cost were very important.
So this equipment was to be designed as close as possible to the Requirements without going over. The customer even provided us with the exact external systems to verify that the unit functioned properly. Since the Kiowa was nearing end of life, only one expansion was planned, to add a video recording capability.
Emphasis: Technical Performance
This was also a PCMCIA card loader, for use in the UH-60 Blackhawk in all variants, and many other rotary wing aircraft.
Facts:
Quantities were to be very high, there were 4000 UH-60s in service at the time, with many variants in service and planned.
The system was to be made attractive to other aircraft as well. Configurability was important.
Four PCMICA slots, and must be as compliant as possible with PCMCIA memory cards. A successful product would host any existing or future card, and work in a wide range of environments.
The better the unit worked environmentally, the more platforms that it could be used in. A more robust design meant more sales.
I/O was added to handle a wide range of applications
The 10/100 Ethernet interfaces were required to run at 8 Mbytes/second, continuously - basically at the theoretical limit of the standard. Verification was problematical.
We were to support as many protocols as we could afford, again, to make it compatible with a wider range of equipment.
It is clear from this example, that if we could show that a functional change or improvement would increase sales, we would go ahead and implement it.
So the whole philosophy for the design of the Kiowa Warrior PCMCIA card loader was different from the Microserver. While the Kiowa had a pretty rigid Requirements Management and Cost Control process in place, the Microserver was more wide open - emphasizing value rather than strict cost and requirement adherence.