• Essential: The system would never be used without this feature, or it would be much harder to test, document, or package the product without this feature.
• Expected: Key stakeholders strongly desire and expect this feature. It may have been promised to them in a certain release. Its absence would substantially reduce the success of the project.
• Desired: Stakeholders desire this feature. Its absence would somewhat reduce the success of the project.
• Optional: This feature would be nice to have. Adding it could have some advantage, but delaying it would not have a big effect on the success of the project.

• Months: A very large feature that is too big to estimate and should be broken in to smaller, better-defined features.
• Weeks: A large feature that will take 40 to 160 hours to add.
• Days: An average or easy feature that would take less than 40 hours to add.
• Hours: A very easy feature that would take less than 8 hours to add
• Note that "adding" a feature means doing all of its design, implementation, technical documentation, user documentation, and testing. Even the easiest feature takes hours to add.

• A "risk factor" is a task or fact that is currently in doubt, but that must turn out well in order for the feature to be successfully implemented. Sometimes, feature risks come from project risks, or project risks come from feature risks.
• Dangerous: Implementing this feature successfully would require overcoming risk factors that are more than three or unknown in number. It should be broken down into parts, better specified, or risk factors should be eliminated prior to implementation.
• 3-Risks: Implementing this feature would require three risk factors to be overcome. Any single release should contain at most a few such high-risk features, and contingency plans should be considered. You should be able to list the risks.
• 2-Risks: Implementing this feature would require two risk factors to be overcome. This is normal for challenging features. You should be able to list the risks.
• 1-Risk: Implementing this feature as specified would require one risk factor to be overcome. This is normal for many features. You should be able to describe the risk.
• Safe: Implementing this feature as specified is just a matter of time and effort, there is no real risk of failure.

Describe each feature in enough detail that it could be implemented by any member of the development team (not only someone who already informally knows what to do).

• Interface: Describe the user interface or API to this feature. Link to a tiny mock-up, if needed.
• Input validation: Precisely define the set of valid input values. Consider using regular expressions or mathematical expressions. Specify units for measurements: e.g., hours or days, yards or meters.
• Logical constraint: Define the logical limits of this feature. E.g., a search function might only search for individual words rather than phrases.
• Business rule: List business rules in if-then format.
• Access controls: Specify who may use this feature.
• Implementation limits: Describe planned implementation limits. E.g., a spreadsheet can only be up to 9999 rows.
• Error handling: Describe what happens if the constraints or limits are violated.

Write down any questions that arise while writing the feature specification.