In his CM: the Next Generation series, Joe Farah gives us a glimpse into the trends that CM experts will need to tackle and master based upon industry trends and future technology challenges.
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 concept is to never take a customer's requirements at face value. The customer may lack expertise in some areas, resulting in loose or inadequate requirements. More frequently, you may have more advanced expertise about the industry or technology and how it is advancing. You may also have experience on your side from working with other customers on similar requirements. 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 point is to realize that the customer's understanding of the problem space will change over time, for various reasons. By adapting a process that 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 fiere 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 can dramatically improve 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. 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.