Usability Institue Logo- A bolt that can be fastened with any of 4 tools
PicoSearch
Usability Consulting, Specializing in Schools and Non-Profits
Home Page- List of All Content Home Page- All content, in date order Resources: page describing tools you can use Morsels: just our short articles and blurbs Just our Before&After Articles Site Reviews and Critique About: details on who I am and what I do Address, phone, number,  and so on
Contact me for a FREE usability review!
 

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
  • 2006-June
  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

"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
Contact me for a FREE usability review!

2002, UsabilityInstitute.com   All Rights Reserved    jackbellis@hotmail.com
Any and all content may be reused without prior consent if you simply acknowledge the source, UsabilityInstitute.com