Is a functional spec a part of the System requirement spec?

Question

I wonder, sources like wikipedia or templates I found shows that Functional spec is a part of System requirement documents. I always thought that SRD is just overall decsription of the system, with all functional and non functional requirements. Yet I thought that Functional spec is more detailed and it is a separate document, while SRD is high level customer-created description (how is this one called then?) Could anyone help to make this clear for me?

Answer 1

Disambiguation

• System Requirements (used in systems engineering)

• Software Requirements (used in software engineering)

Main Answer

System requirements outline the requirements for the whole system. A system is a set of hardware and software to support a specific business need.

Software requirements are only concerned with software. They are much more detailed than system requirements, so that the software can be actually built from these.

The Software Requirements Specification (SRS) is a standard: IEEE 830-1998. Functional requirements are a part of this standard.

Functional specification is a separate document which is no longer used today (at least in Software Engineering). It was a standard at times when waterfall was used as the best-known technique, and before the IEEE Software Requirements Specification became a standard. The SRS has replaced it because functional requirements are now defined as a part of a larger document (software requirements).

At the dark times of software crisis, I believe that functional specification was the best they knew (without all these amenities the full SRS gives us). They thought software requirements specification is only a specification of required functions. Today we know there is more to it. (see the SRS)

History and Current Use of the SRS

The SRS is from 1998 and it wasn't meant for OOP. I've used it in my company, but only as a basis for customization. Instead of describing functional requirements using natural language, like the old functional specification document, I've used UML (use case diagrams). This is something that wasn't considered by 1998 yet, so that engineers still described the needs quite inefficiently.

Conclusion

Functional specification is a part of the software specification document. The document is useful, but I wouldn't recommend adopting it as-is because it was defined in 1998; instead, I suggest considering UML where appropriate to replace natural language specification.

References

http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=720574

http://en.wikipedia.org/wiki/Software_requirements_specification

http://en.wikipedia.org/wiki/Use_case

http://en.wikipedia.org/wiki/Functional_specification

Answer 2

Typically, a systems requirements specification contains the top-level requirements for a system. A system is a set of software and/or hardware subsystems. Typically, this includes the functional and non-functional (performance, safety, security, quality, business, governance and regulatory, and so on) requirements for the system as a whole. Each subsystem in the system would have a requirements specification as well, with a software subsystem's specification typically called the software requirements specification. Each specific requirement of the software subsystem is mapped to at least one requirement in the systems requirement specification.

In some projects, there might also be the concept of customer requirements or a concept of operations. These are typically requirements as well, but provided by the customer in their domain language and may not be suitable for consumption by engineers. These are turned into systems requirements by engineers who understand the customer need as well as the business.

Note that different organizations may have different names for the same thing or may split content off into different repositories or documents. There are some standards that exist - the IEEE has a number of standards related to systems engineering and software engineering, for example - but organizations may not follow these standards or may tailor them to better suit their needs.

For more information, you may be interested in two books by Karl Wiegers - Software Requirements and More About Software Requirements.

Answer 3

I agree with your interpretation. Broadly speaking...

Requirements = What should it do?

Specifications = How should it do it?

Despite very rough, I think this rule of thumb describes pretty well the intent and scope of these documents. My 2 cents...

Answer 4

SRS broadly defines customer requirements and describes what is expected from the system. Functional specification further describes what functions are expected from domain and sub-domains described in SRS. SRS is the building block of any SDLC.

Answer 5

An SRS is a document that essentially prepared by the Business Analyst. As you said, it does include business goals and high level requirements.

Whereas a Functional Specs document encompasses details of purposes and processes of the entire system and is much more in depth. This document is prepared in liasion with the Software Engineer and System Anaylyst.

For more information visit the following links:

Functional Specs Document

SRS