|
|
Software Requirements Levels
An 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.
|
| |
Who |
|
| |
Updated |
|
| |
Keywords |
Specs, requirements, functional specs,
specifications, design documents
|
The example information uses a product I have been involved with, Satori Group's proCube.
- Product Category Financial analysis software, business intelligence [previously OLAP]. Done by sponsor.
- Product Slogan Bringing database power to spreadsheet users. Done by Marketing.
- 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
|
