A while back, I had written why a functional spec is needed in addition to a PRD. So what does a good functional spec need to contain?
Here is what I consider elements of a good functional spec. I tend to use smaller paragraphs or bullets to make it readable. People tend not to read lengthy sentences or large paragraphs.
1. Problem statement: This section should clearly explain the problem you are trying to solve. This should not contain anything about the solution to the problem. You want readers to clearly understand the problem first.
2. Proposed solution: Now briefly explain the solution you are proposing to solve the problem.
3. Marketing Information/Justification: Things such as how big is the customer base that has this problem and why should we solve this problem (differentiation, tablestakes etc.)
4. Target Users: Who are the typical users who will use this? Internal to your company? External users? Experienced users? New users? All users?
5. Committed or Minimum Requirements: The requirements that have been reviewed and committed by Product Management and Engineering should be listed here. Unless all of these requirements have been implemented, the project will not solve the problem it is intended to solve to customer expectations. Or in other words, the new thing cannot be shipped in the product. Number the requirements instead of using bullets so that it is easier to refer to them during reviews, in emails, during discussions etc.
6. Requirements under Consideration: The requirements that needs to be considered by Engineering for implementation should be listed here. These are not committed to make this release. If time permits, Engineering will try to implement these in the current release (this never happens by the way). However, more importantly, Engineering has agreed to take them into account such that the current implementation will be able to support these requirements in the future. Again, number the requirements instead of using bullets so that it is easier to refer to them during reviews, in emails, during discussions etc.
7. Out of Scope Requirements: These would be requirements that have been agreed upon by Product Management and Engineering as out of scope for the current implementation. However, Engineering has agreed to take them into account such that the current implementation will be able to support these requirements in the future.
8. Proposed User Interface: This is where you would propose as to what the user interface needs to look like, what the interaction needs to be. This section will be written by an interaction designer or a graphics artist and if you don’t have such people, you should write them. I would not leave it to engineering to design the UI, you very well know what that will end up to be.
9. Typical Use Cases: Here you should list the most common use cases that should be supported by the current implementation. QA should be able to generate test plans based on these use cases. Flow charts are a very nice way to document use cases because it would mimic the workflow you expect the user to experience and are also very easy to understand. Doing flow charts also makes you realize the requirements you may not have accounted for.
I have used such a format for about 14 years now and engineering have always liked them because it tells them why to do something, how it needs to work etc.
7 thoughts on “9 elements of a good functional spec”
Good post Gopal. Some other things that should be part of functional specs (again this could be part of PRD as well, have just started to appreciate the difference)
1. Non Functional Requirements – An important area that usually is missed out in Functional Specs or PRD’s e.g. Performance, Availability, Security, Reporting, Software Quality etc. should be mentioned specifically. The cost of incorporating these later in the development is huge, and also QA team would happily miss writing test cases on these.
2. Business Concept Diagram – There is another tool that I quite frequently use is “Business Concept Diagram”. It would list main business entities and their association. Great tool to put business in one screen shot.
3. Operating Environment – Hardware, Software, Services to be used etc., Data Exchange Standards
Very great read, thanks for it.
Great post! Do you have any example of specs that you can post. That would be very helpful.
I agree. You can have all brainstorming sessions with customers, engineering, other PM’s etc. to figure out how to best solve the problem. Once you figure this out, the spec will document the solution that everyone has agreed to be the best way to solve the problem.
As always, your tips are not only highly thoughtful but also damn practical.
On the second element, proposed solution, do you make an assumption that the PM has strong business domain expertise and medium-to-high technology knowledge? Otherwise, what are the odds of PM proposed solution being very practical and cost effective? In my opinion, the proposed solution would be superior if the PM arrives to it through “brainstorm” collaboration with the development and other stakeholders.