A Functional Specifications Document (FSD) is produced after the requirements gathering sessions are complete and the Business Requirements Document (BRD) is signed off. The Functional Specifications Document serves as an input to:
- System designers for the design of the solution
- Developers for the solution build out during development
- Testers to enable them to test the solution
- Stakeholders for their review, approval and sign off
- Project Managers for estimation of schedule and effort for completion of project
This document serves as the interface between the business users and the development team, focusing on what the system should do under certain conditions. The document effectively breaks down the requirements defined earlier (in the Business Requirements Document) into more detail.
Creating the Functional Specifications Document
The Functional Specifications Document (FSD) should be created by the Business Analyst. This document describes how the system will work from a user perspective. Hence technical language should be avoided when writing this document. The following sections would constitute the Functional Specifications Document:
- The project overview, objectives and the definition of scope, i.e., what functionalities are being covered (“in scope”) and what are excluded (“out of scope”). This ensures that the boundary of the solution is clearly defined and helps prevent “scope creep” at a later stage.
- All assumptions, constraints and dependencies should be mapped out explicitly. For example, constraints include choice of technology being dictated by current technology landscape. Dependencies would include internal (within the organization) and external dependencies.
- Types of users who would be using the application being developed and their roles. All users of the application would be mapped to specific roles that they may perform.
- A listing of all requirements that are a part of the baselined Requirements Specification Document and the priority for implementing them.
- Wherever screenshots/mock ups have been prepared, these should be included as well. Screenshots are especially helpful when an application that has a lot of front end screens is being developed. This would help stakeholders visualize the screen layouts and help iron out any mismatch in expectations at the time of review and sign off.
- Elaboration of non-functional requirements. These need to be validated by business stakeholders and portfolio architects and described in measurable terms.
- Diagrams that describe business processes.
- Models that describe the requirements. These models actually describe the requirements in greater detail and explain how external users use the application and how the application responds. One of the widely used models is the use case model.
- Traceability of requirements is an important feature that the functional specifications document should capture. This can be done by having a traceability matrix within the document that ensures that all requirements captured at a high level in the earlier stage have been detailed out and that none of the requirements have been missed out.
Conclusion
Upon completion of the initial draft of the Functional Specifications Document, this should be put through a rigorous review process. A review by the development team is recommended as this would help identify gaps in detailing and result in a robust document. A peer review is also recommended to ensure that the elaboration of the functionality is thorough. It is always recommended that standard tools and templates be used for documenting functional specifications so that all stakeholders have a common understanding of what is included in these documents.