Good Requirements - Part II - Be Complete

Every requirement that is produced should express a whole idea or statement. Not multiple ideas and not parts of one.
Consider the following:

1. The screw must be 4" long, require a Philips screwdriver and be able to withstand 500 degrees Kelvin.
2. The screw is for woodwork.

The first statement has multiple components to it. If one meets 2 of the 3 parts, would one consider the requirement to be met? It is easier to look at the requirements when they are decomposed into separate statements such as, "The screw must be 4" long. The screw will require a Philips screwdriver. The screw will be able to withstand a temperature of 500 degrees Kelvin."

The second statement tells one what the screw will be used for however, it does not provide any additional details. Is the screw for holding together arts and crafts or will the screw be required to support load bearing structures such as shelves and chairs? The requirement does not provide sufficient clarity.

Complete requirements aid understanding which increases the likelihood that a viable solution can be provided.

As an aside note:
One practice that I employ is to create my initial set of requirements at a very high-level. As the requirement gathering process continues I will decompose a high-level requirement into more atomic statements. I find this to be a useful exercise because some of my stakeholders enjoy seeing the big picture while others want to look at the details. This practice allows me to be able to meet both of their needs. There are also traceability gains from doing this, but that will be discussed another time.