Whereever I have looked, the functional specifcations are some sort of documents with the requirements/proposed features represented and elaborated. I was recently in a position to make a standard template for our company for functional specifications.
The format I have settled for, tentatively, is an excel file with a quite a bit of automation.
-
The template plans to link top level requirements to lower level requirements in a hierarchy.
-
The lower level requirements can then be mapped to the technical aspects of the design, similar to the house of quality. The corelation is idetified as in the HOQ, but in addition, for each pair of requirements and technical aspect, a feasibility is estimated.
-
If any of the technical aspect for a requirement is marked as non-feasible, the requirement is flagged for reconsideration.
-
After all requirements are either flagged feasible or removed appropriately, each requirement-technical aspect pair is extracted and estimations sought for each of them in terms of time and budget.
-
The estimations help us in planning the project.
Can I have an informed opinion about this proposal? This seemed to me the best way to link requirements with technical aspects and then to project planning.
In my experience the functional specification was generally a use case document (with or without a corresponding diagram or diagrams). The spreadsheet sounds pretty cool, but functional requirements are generally for communicating with the business stakeholders with the goal of obtaining agreement and ultimately sign-off so the project’s budget can be approved. Unless your spreadsheet can somehow format the requirements for print output, I’m a bit confused as to how you propose to share the contents for discussion and feedback.
My two cents…
Hope this helps,
Bill