Is functional spec a “design document”?

Question

So I have been a bit lost in the terms, so first of all I present you what I have learned so far:
System requirements specification - what users want, what the system should do Functional requirement - how the things, which users want, will actually work in the application

Also I would say that the latter is a design document. Is that right or is there another document in addition to these?

Answer 1

Functional specification is a design document - describes exactly the functionality of the system. What John Bode suggest is something else, system specification in OP's context means a specification of the software system, done by business analyst. System requirements specification describes the functionality of the system as wanted by users.

Answer 2

Basically, yes. Software Requirements Specification states what the business users want the system to do, while Functional specification describes the actual functions of the system, usually linked to the business requirements.
E.g: Business requirement (User): I want to see the number of trades and their exposures
Functional spec: A grid displaying in one column Trade with its ID and in the other column its exposure. The exposure is taken from the table TRADE_EXPOSURES...

The design should be separated from the requirements. FS is just lower level of SRS. FS is used for test case derivation in functional testing, SRS usually for acceptance testing. SRS is also used as a base for system testing, where the implenentation is validated against it (does it fit what the customer wanted?)

Answer 3

IME, system specs define the hardware and software environment that the new application will operate in, while functional specs define what the application will do (my experience may not be typical, however).

Design documents are a different animal. They define the structure of the application, breaking it into components, specifying the implementation of each component, the interfaces between components, the order in which components perform their operations, etc. ("component" is meant to be a very high-level, abstract term here; it could correspond to classes, modules, or even individual functions or methods). Design documents also often have a "traceability matrix" showing which requirements are satisfied by particular elements of the design.

For a stupidly simple example:

System specification: The application will run on Linux as a command-line app in a bash shell.

Functional specification: The application will print the text "Hello, World" to the console and then terminate.

Design document: The application will be implemented as a single C program consisting of the function main, taking no arguments. Upon entry, it will call the standard library function printf with the string literal "Hello, World\n" as its sole argument. After the printf call, the application will return a 0 to the execution environment.

The "design document" isn't usually so detailed as to specify individual lines of code, but you should get the idea.

Answer 4

Term design document is too broad

Besides the Software Requirements Specification (SRS), there are different design documents and their number increases with the complexity of the project.

For software design document may contain different sections like Data, Architecture, Interface, Structured Programming concepts, etc..

There is also an article How to Write an Effective Design Document that you may want to look and of course a wiki reference Software design document - that might be helpful to look.