Hi,

I wondered whether a BA with some solid experience could help me with a problem I'm struggling with!

What is a FUNCTIONAL SPECIFICATION? I seem to see so many different descriptions floating around, that it's hard to discern exactly what one is.

Some descriptions I've seen:

1) It's the same thing as a "Requirements Document" and documents the functional and non-functional requirements.

2) It's a requirements document that only documents "Functional" requirements

3) It's a high-level DESIGN document that describes how the "Functional" requirements (presumably documented elsewhere) are implemented as a SOLUTION. It doesn't cover technology or platform.

4) It's the same thing as a "Software Requirements Specification" (SRS) i.e. that defined by IEEE, where an SRS defines the full set of requirements for the system including external interfaces, design constraints, standards etc.

5) It forms "part" of the SRS


Needless to say, this has caused me a lot of confusion. I've only been working as an analyst for two years, and the development of internal apps in my organisation has a rather loose approach toward due process. Typically, developers ignore documenting requirements or uncovering problems/needs, and make a beeline for a "Functional Specification", which in this case constitutes the high-level design (or proposed SOLUTION). When "complete", this normally forms the "contract" between customer and development team.

To add some rigour, I've tried to introduce a "Business Requirements Document" as a first step, which analyses the business NEEDs and underlying problem(s), and assesses the existing situation and process(es). Following this, a "Software Requirements Specification" (based on IEEE standard) incorporating Use Cases, which describes the overall behaviour of the proposed solution, independent of any design details. It includes functional and non-functional requirements, business rules, external interfaces, user interface wire-frames, design constraints, standards etc.

Some people might argue that this SRS _IS_ a Functional Specification, especially since the behaviour is described in the form of Use Cases. Others (including some members of my team) argue that the SRS isn't enough on its own, and that a "Functional Specification" is required, where in this context, the Functional Specification is more akin to a high-level design document.

I'm still confused on the role of the FS, but in my view, the SRS as I've described it should be sufficient as the end-Analysis product. The DESIGN document should be produced by the development team using the SRS. This may or may not be shared with the customer.

I appreciate that this is a grey area, but would appreciate the thoughts of some experienced BAs on this subject.

Thanks in advance.

Graham

Forgot to mention there is no need for a SRS.    Think about how the agile folks work - they only create one set of models.  

Tony

I work as a freelancer and hence change jobs relatively frequently. One question I always ask at interview is "What are the deliverables?". Invariably I then have to ask a follow up to get them to explain what their version of a Business Requirements specification, System Requirements specification, Functional specification or whatever other name they come up with actually is.

Personally I think they are all the same thing and you just know more at different times in the process. I don't really care what people call them.

David made the key point though. Sounds like you need to define the process and the deliverables where you work. Interesting project for you. I've just started a new contract at an Insurance company and they have this notion of BRS and functional spec. I mostly see that in large staid companies and government departments. Smaller companies can't afford the commercial costs that such rigid overheads imply and tend to be more agile. That is not to say that they don't do thorough analysis of ccourse.

Kimbo