Definition: This characteristic is the completeness of the specifying documents, their hardness, and the extent of effort that will be expended to verify that each requirement is being met. Typically these are found in a System Requirements Specification, but may be spread out among many documents. In larger programs, there will probably be a requirements matrix, and one or more system engineers managing it. For small systems, there may only be a few hard requirements, captured in a text document.
This characteristic has a very structured method that can be used, unlike some of the other characteristics. Each requirement or goal is captured as a record in a database, with other attributes as the company sees fit. As a minimum, what document the requirement came from, who is responsible, what procedure will be used to test it, and compliant/non compliant. Additional attributes may be design approach, projected completion, integration dependencies, performance measured, etc.
If Specification is the top priority, then you will certainly need:
A requirements matrix
A Verification Cross Reference Matrix
A method of tracking and implementing directed and proposed requirement changes
Expert players to bash out the wording at the start. If this is not done well, you will have a hard road ahead.
If Non Recurring Costs are also important, then, no, the customer is not always right. Specification as a top priority works both ways, and customers may grumble, but they know it.
Clearly, using Specification to control a product is labor intensive, and affects Non Recurring Costs. When managing a system group, I learned to bid between 4-8 hours per requirement, plus an offset of about a man month, for a formal requirements management system. Based on the number of requirements and your Schedule, you may find that you need more than one System Requirements Manager. Especially since most of the effort is at the very beginning of the job, when requirements are captured and parsed, and at the end during verification.
When Specification is high, and Resource Constraints are low, you can find and use a dedicated requirements management engineer. This person will build a requirements matrix, determine verification methods, maybe even organize and perform the testing, using training they have had. Since she should be good at it, it should be cheaper than doing it yourself, other than the brief in costs.
If Resource Constraints are also high, (you cannot find a trained system engineer), consider doing it yourself. Theoretically, this will reduce the Non Recurring Cost. Don't underestimate the effort to set up this matrix, but with Sharepoint, or DOORS, or any one of many tools, it is not that bad, and you may be able to get someone to do this setup for you.
Historically, I have been able to perform as a Project Engineer with 10% of the engineering hours (includes monthly reviews). System engineering comes in at about 12% to 20%, depending on the difficulty of the customer or stakeholders. Running through a few numbers, you can handle both jobs if your manloading works out to 4-5 equivalent engineers, and a good customer - a relatively small job. You may be able to squeeze it in with a difficult customer, but you will be challenged, in that the work for the planning and the requirements management are at about the same time. Or you may be able to get the designers to do a lot of the system work, further reducing costs.
Because Specification work (as defined here) is so structured, it is easy to parse out requirements work and track it. Lots of people can be working on the document at the same time. If you have no Resource Constraints, you can beef up to meet the Schedule. I always liked to get the designers involved in the requirements documents, but some functional managers did not agree with this.
Getting excellent Technical Performance is orthogonal to excellent Specification. Other than the possibility of sharing resources, there is little overlap. Designers may see that they can get better performance by changing the Specification. The Ford Pinto was designed to have terrific gas mileage during the EPA tests. In real life applications, the achieved gas mileage was less than many of its much more sporty competitors. Tight spec compliance, poor performance.
Recurring Costs can be a requirement, same as any other technical requirement. In that case, all the usual rules apply.
Process and Specification usually go hand in hand - unless the customer has directed you use some of his processes. If this is the case, then the ordering of these two priorities is very important. If our process says this, and their spec says something that doesn't quite fit - which way do you go? Company processes fit together, but a few customer processes in the middle of your standard processes may leave a lot of loose ends. I have seen this a lot in Printed Wiring Boards for high reliability. A vendor may have his high reliability methods, that differ wildly from the customers experience. Is the customer saying, " meet the spec and the processes you use are up to you" , or " use our processes, that will meet the spec"?
The quality of verification is a variable. Do you test at one temperature, three, or fifty? What are the functional modes during test? High rate? Low Rate? Do you verify at single points, statistically, or 100%? Do you use untrained operators to run the test, independent Verification and Validation? You can see that there is a wide range of quality here.
Here is the tough part: Based on failures in your verification procedure, the unit will have corrective action implemented. This certainly costs money, and may even affect the performance of the unit. This is very important if it failure would affect the customer, but what if you are fixing things the customer would have never encountered in actual operation? For features they have since rendered unnecessary, or operational conditions that will not be encountered? Then you have suboptimized - made things "better", that did not actually affect the value of a product. And once the verification is fixed, you have to correct the problems, or get dinged for not doing it. I have seen this take a product down. So the level of quality of your verification is very important, and affects all other characteristics. This should not be taken lightly.