Requirement Specifications: An Oxymoron

Good requirements (R) describe how features of a product are going to solve particular existing or potential problems. Good features (F), sometimes called functionality, are added to products to address those important problems. Requirements are captured by salespeople or created by software project managers.

• We can't sell the product outside of the United States.(R) We need to provide internationalization and location support.(F)
• Users have to click 5 buttons to complete a very simple task. They get frustrated and never complete the task. We need to simplify the user interface (R) and reduce the number of button clicks to 2 or less to complete the same tasks.(F)

Specifications (S) on the other hand, describe exactly how problems will be solved and the requirements will be met. Using the examples above, the following specifications might be written by systems architects.

• We will extract all text strings, including popup messages, and place them in external resource bundles.(S)
• The application will be enhanced so that all text displayed on the screen will be retrieved from these resource bundles.(S)
• Localization can be performed by creating specific resource bundles for the locales required.(S)
• The functionality achieved through clicking buttons 1, 2 and 3 will be bundled into a single button click on Button A.(S)
• Existing buttons 4 and 5 functionality will be bundled into Button B.(S)

Blurring the lines between requirements and specifications leads to the wrong people making the decisions. You either end up with the software developers making decisions about what features are important to a user, or with a software project manager telling a developer how to structure code. Either way, the result is a poor final software product.

Developers aren't usually out talking to customers, users, marketing, sales, and potential partners, trying to understand what new features are most important. On the other hand, software project managers usually aren't skilled developers who understand how best to implement a feature, and how their untrained, although well-meaning, specification suggestions would affect other aspects of the product. Each group has a unique skill set.

Having good requirements that describe the problem you are trying to solve, and why it is so important to solve this particular problem, lets the programmer be more flexible, efficient, and motivated during the development process. Coders can make independent design decisions as they work on the problem and understand it more thoroughly. They should only be bound by the technologies they have chosen to use, not by strict, brittle specifications created by a non-programmer.

Specifications still need to be written, but they will change. Have you come to the end of the product development cycle and only then fully understood how this product should have been built in the first place?

Keep the what you are trying to build separate from the how to build it. Then, let the properly trained team member make decisions based on his/her project role.