Functional Specifications

Question

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.

1. The template plans to link top level requirements to lower level requirements in a hierarchy.

2. 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.

3. If any of the technical aspect for a requirement is marked as non-feasible, the requirement is flagged for reconsideration.

4. 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.

5. 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.

Answer 1

You might want to add a mapping between low level requirements and tests (like "design test", not "unit test".
That way you can establish a broad functional testing coverage needed for that project.

Answer 2

"Can I have an informed opinion about this proposal?"

Who are your users for this spreadsheet?

What do your users do with this spreadsheet? What are their use cases for requirements gathering, planning and project approval?

If you are the user, then it's perfect for you.

If you are not the user, you need to meet with your users, determine the following:

• What actions do the users of requirements take? Do they approve, reject, confirm, deny?

• What decisions do they make?

• What information do they need to make those decisions?

If your spreadsheet meets your users needs, then it's good.

Requirements are slippery things and must be reprioritized and reconsidered in very many ways. Too much spreadsheet automation can be a hinderance.

Mostly, folks need to be able to add an unlimited number of extra columns and sort them into innumerable organizations and reorgnizations.

Answer 3

Hi,

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

Answer 4

You may need a supplemental to the spreadsheet for listing use cases and any user interface specs.