Have you ever had a project where you’ve thought, “If I had known the requirements were going to be used this way, I would have written them differently to make this process easier.” In a consulting environment this can happen a lot. Every customer is likely to have a slightly different way of consuming the requirements for a project. This situation reminds me that understanding how your documents will be consumed should drive how your documents are written. Let me give an example. The following is an incomplete list of requirements, with their development estimates, related to using an ATM:

Estimates for Functional Requirements (in hours):
10 hrs FR_01 System shall read user name, account number, and bank ID from ATM card.
5 hrs FR_02 System shall accept 4 digit number input from user.
3 hrs FR_03 System shall never display 4 digit number.
5 hrs FR_04 System shall not store 4 digit number.
20 hrs FR_05 System shall contact bank indicated by ATM card, provide account number and 4 digit number, and ask bank indicated whether a transaction may occur.
30 hrs FR_06 System shall support withdrawing funds from checking account.
0 hrs FR_07 System shall support withdrawing funds from savings account.
5 hrs FR_08 System shall support checking for balance.
5 hrs FR_09 System shall support depositing funds.

Now let’s say the development manager and product manager are asked to cut “all unnecessary requirements”. Look at requirement FR_04. Does this get cut? The product manager has asked that the system NOT store the 4 digit pin. The development team has indicated that NOT storing the 4 digit pin will require 5 hours of work. Does this mean that if the system DID store the PIN it would require no work?

Let’s look at requirements FR_06 and FR_07. FR_06 has a value of 30 hours and FR_07 has a value of 0 hrs. This could mean that once the work to withdraw from checking is complete, the system can withdraw from savings for no additional work or it could mean the development manager has estimated the tiny extra bit of additional work to withdraw from savings as part of the withdraw from checking requirement. What if the product manager knows that withdraw from savings is an optional feature and could be cut? With the above estimates she gains nothing for cutting this feature.

How might a product manager write these requirements differently if she knows how they will be consumed by development? The Product Manager needs to write the requirements in a way that allows for easier in/out scope discussions based on the estimates returned. An example:

FR_01 System shall accept and validate the PIN.
Must Have:
a) System shall read the account number and bank ID from the ATM card.
b) System shall accept a 4 digit number indicated by the user.
c) System shall not display the number.

Optional:
a) System shall not store the number

FR_02 System shall support feature to withdraw funds from user account.
Must Have:
a) System shall support contacting user’s bank.
b) System shall indicate amount to be withdrawn.
c) System shall indicate the checking account.

Optional:
a) System shall indicate the savings account.

The above approach allows the developer to offer an estimate for the must have requirements and an “additional” estimate for the optional requirements. This will make scope discussions easier for both the developer and the Product Manager. It will also help communicate the business needs to the developer without having to review the exact priority of each requirement.