Fog Creek Software
Discussion Board




Functional spec vs. product requirement doc

I just read the great series on writing a functional spec on 'joel on software'.  I work for a young start-up that is struggling with product lifecycle management.  Can someone explain the difference between the two??

David Levin
Saturday, September 13, 2003

Everyone's struggling with product lifecycle management, so don't feel too badly.  The problem is that the powers that be would like a perfect process that optimizes everything and manages itself.  In other words they want to absolve themselves from having to actually think and manage by checklist instead.  Whew!  glad I got that off my chest.

Anyhow, over where I work, the product requirements talks mostly about the business problem that is to be solved, typically describing what kind of characteristics a successful solution would have.  Functional requirements, however, describe the behavior of a software system (or other engineered product).  The idea is that if the software behaves correctly (according to the functional spec), then it will play a successful role in the solution to the business problem.

Some other differences of note:

1.  Product requirements are usually written in the language of the domain.  Functional specs are usually written in technical language.  Lately, we've been using automated software tests as a big part of the functional specification, in essence saying that if it passes these tests then it behaves correctly.

2.  Product requirements are generally much broader than the functional specs since the software is usually only a part of the solution.  There are also descriptions of business processes, usually a frighteningly large number of them.  These cover all kinds of areas.  Who has access, how does data get into the system, how bugs get reported and addressed, what actions require approval from whom, and so forth.  The requirements also talk about other things like how long the product is expected to last, what the roadmap for it looks like, and so on, even though these things aren't necessarily requirements.

anon
Saturday, September 13, 2003

Take a look at "Practical Software Requirements" by Ben Kovitz for an excellent discussion of requirements documents and specification documents.

rwh
Monday, September 15, 2003

*  Recent Topics

*  Fog Creek Home