www.gowland.ca

The following is the result of some lessons learned generating functional specs for work.

Feature Level

• Identify a min/max/default for all values the user can enter or import.
• Identify failure conditions and responses for all actions.
• Identify under which conditions a feature will be available.
• What is the result of running the feature multiple times? (Eg. What changes on subsequent executions? Is the result cumulative?)
• Describe management and use of shared and stored data. (Eg. What entity is the data stored with?)
• Describe all design trade-offs.
• Match every detail back to a requirement where possible.
• Describe any dependencies on configuration. (Eg. Can this feature can be turned off? If so, per user or per install?)
• Describe any exceptions to any rule you lay out.
• Determine if each feature described is actually a customer requirement as opposed to an implementation detail.
• For GUI changes pretend to use the proposed GUI on paper, doing ridiculous things, paying attention to interactions between widgets.
• Use cases can illuminate missing requirements and missing functionality, and expose misunderstanding between the requirements gatherers and the implementers.
• Insist on having the FS reviewed by others in development. (Feb 12, 2009)
• Review existing GUI elements and patterns for inspiration when designing new screens and layouts to maintain consistency within the product. (Feb 13, 2009)
• Try to break the code, even at the FS level. Consider all possible inputs and how the system will handle them. (June 10, 2009)
• Define what happens if the user performs tasks in a different order than described. (Jan 27, 2010)

Document Level

• Are all internal cross references correct?
• Are all external cross references to other documents correct?
• Reread all text and diagrams for grammatical correctness.

Philosophical Level

• Accept that the FS may take a while to get right. Time spent here make everything go more smoothly down stream. (June 10, 2009)