The Functional Specification Document (FSD) or functional specifications or software requirements specifications (SRS) is a much-misunderstood document amongst Business Analysts (BAs). Often the task of delivering the Functional Spec falls into the project tasks of the Business Analyst. The textbook description of a Functional Spec is ‘a formal document used to describe in detail for software developers a product’s intended capabilities, appearance, and interactions with users’. It should describe how (THE HOW) the system should work or more accurately how a system should deliver the desired functionality agreed as needed by stakeholders. The understanding is that the stakeholders have analysed and agreed what is needed (THE WHY). Principally, the needs analysis and gaining of consensus is the primary value add of the BAs work on the project. Analysing the business using the BAs investigative techniques and helping stakeholders articulate and validating their needs. This culminates in a validated understanding of the importance of the system to the business and the desired business capabilities. This is what we call a view of the WHY and is written from the voice of the Stakeholders.
The Functional Spec is written once the WHY is understood. It aims to express how the project delivery team is going to deliver the functional capabilities – the HOW. Typically in a software project, this will be how software organises and presents information that delivers the WHY. It should be written from the voice of the system. Many project teams tasked with developing requirements start with the functional spec without fully understanding the WHY. This risks project failure – the delivering of a system that is not useful or not used, not aligned to business needs, rework requests due to change requests.
Before starting a Functional Spec, ensure that the WHY analysis has taken place and that you have the right people involved. Often the team needs input from business, technical and quality/ testing representatives. If the Functional Spec team is given a clear mandate on what needs to be delivered and we have the right technical and business people involved, the process of delivering a fit for purpose, useful and well thought out Functional Spec will go more smoothly. The Functional Spec is used by developers to build, testers to test against, system architects to plan infrastructural needs and BAs to deliver business value.