Software Requirements LevelsAn Answer to the Challenge of How Software Requirements
Should Be Structured

What

Here's my read on what to document to define a software product, presented as a tree of increasing detail level.

Why

Like the weather, everyone talks about documenting good requirements but nobody does (anything about) it. It's a struggle in most organizations to draw a good line between "business requirements" and the many levels that "functional requirements." The real issue is who should do what, and to what level of detail should they go.

Magazine Ad Highest level feature list. This and the next level might equate to "business requirements." Done by Marketing.

Feature List Detailed listing such as might be used in a competitive analysis. This is what I think many organizations mean when they use the phrase, "functional requirements." I propose that "functional requirements" is an oxymoron, or at least constitutes "cross purposes." The people close to the customer side should define "requirements" and not get involved in "functions," whether semantically or otherwise. For instance, they might say "we need to be able to sort by date so we can go immediately to the date we want."
This could get into the difference between sorting versus searching by date; that's fine, define it to the level that you need. The valid distinction that's often raised is that this level should describe "what," not "how." How the search or sort is facilitated is the next level.
Done by Marketing or Product groups.

Functional Design & User Interface Design This is where the industry struggles the most.
This design must be created by the development group and written by a professional communicator, but must be a give-and-take review with the other folks up the tree. See my article, "A Case for Specs" for a detailed discussion of the industry's challenges with this level.

Database Design (Not much confusion here. Done by a DBA, but the list of fields might be an appendix that starts at the Feature List level.)

Revisionist History

2006-Apr-1: Added to home page

2005-Nov: Created

"My interest in usability arose from the pain
and tears of patching the wounds of suffering interface designs
with the inadequate bandages of help files and user guides."
— Daniel Cohen