CM: THE NEXT GENERATION of Quality Requirements

Quality requirements are an elusive goal for any complex product development effort. A strong process and good tools can help requirements to march towards higher quality over time, especially when appropriate strategies are used in working with the customer on refining them. The product development team plays an important role in establishing quality requirements. In a well oiled customer/developer relationship, frequent feedback will go both ways.  Unknowns will be explored. Change will occur. It's important that the CM/ALM tools can clearly track requirements and their changes in a way that helps capture increasingly improved requirement baselines.
 
There are some common sense strategies that can be employed to help ensure good requirements. For example, the development team should clearly understand both the customer's business and the industry, along with its process requirements. This will involve working closely with the customer and with industry experts. 

Another bit of common sense is never to take a customer's requirements at face value. The customer may lack expertise in some areas resulting in loose or inadequate requirements. Or more frequently, you may have more advanced expertise, about the industry, or about the technology and how it is advancing. You may also have experience on your side from working with other customers on similar requirements. So passing this feedback to your customers will help you to establish trust, and may open the door for use of more generic product components to fulfill what otherwise might have been a more difficult set of requirements. 

A third bit of common sense is to realize that the customer's understanding of the problem space will change over time, for various reasons. By adapting a process which supports change, you'll remove a number of obstacles as your customer comes at you with requirements creep.

An Incomplete Requirements Spec

Requirement specification is an inexact art. It's difficult and at best you'll only specify a partial set of requirements prior to the start of development. You may think you have them down exactly, but read through your requirements document and you'll find something missing, or something that can be more completely specified. Perhaps for the design of a bolt, a window, or even a bicycle you might be able to fully and completely specify the requirements up front.  But move to an aircraft, a communications system or even a PDA, and things get more difficult. There are several reasons for this.

First of all technology is moving forward rapidly. Availability of a new component
may heavily influence requirements. Instead of asking for a low cost last mile copper or fibre connection, one might ask for wireless access for the last mile - dramatically improving costs.  Instead of a 100MB mini-hard drive, one might instead look at a 64MB SD card or thumb drive, that dramatically improves reliability while eliminating some of
the damping features to guard against sudden impact.

Second of all, product development has moved from a "build this" to a "release this" process, fully expecting that new releases will address the ever changing set of requirements. In fact, one of the key advantages of software is that you can change your requirements and still meet them after delivery. For example, it's nice that the Hubble telescope was originally designed to work with 3 gyroscopes, but it was even nicer
that in 2005 a software change allowed it to run with just 2 gyroscopes. And engineers have another change that will allow it to work with just a single working gyro. So one of the key requirements coming out of this demonstration is flexibility - you often want your
products to be flexible enough to be adapted after production. We've seen this with modems, cell phones and other common products where change was rapid over the years. The focus moves from ensuring that you have all of the right features, to ensuring that over time you can deliver more features to existing product.

Thirdly,