Commonsense CM Strategies to Meet Good Quality Requirements

[article]

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.

Summary:
Quality requirements are an elusive goal for any complex product development effort. A strong process and good tools can help advance requirements toward higher quality over time. 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 and change will occur. It's important that CM/ALM tools can clearly track requirements and their changes in a way that helps to 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 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.

Pages

About the author

Joe Farah's picture Joe Farah

Joe Farah is the President and CEO of Neuma Technology and is a regular contributor to the CM Journal. Prior to co-founding Neuma in 1990 and directing the development of CM+, Joe was Director of Software Architecture and Technology at Mitel, and in the 1970s a Development Manager at Nortel (Bell-Northern Research) where he developed the Program Library System (PLS) still heavily in use by Nortel's largest projects. A software developer since the late 1960s, Joe holds a B.A.Sc. degree in Engineering Science from the University of Toronto. You can contact Joe at farah@neuma.com

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Oct 12
Oct 15
Nov 09
Nov 09