I ve completed a web application and now i want to prepare functionality and technical documentation for the same. But i ve never done such documentations. Can someone provide how to prepare such documentations.
What are the necessary points to be included in functionality and technical documentation?
What are the factors to be considered while doing such documentations?
I know this might be too late if your software has already been built, but you may still be able to go for the "Zero Training" option.
Design help and tips into the interface itself so that users don't need to go to an external place to get the help they need.
Have your interface self-document. As in, let it be intuitive enough so that users "know" or can "discover" how it works for themselves.
Joel Spolsky goes through a series of blog post (4 posts) regarding Technical vs. Functional documentation. His series focusses on functional specifications.
One of the main points mentioned is The difference between a functional and technical spec:
A functional specification describes how a product will work entirely from the user's perspective. It doesn't care how the thing is implemented. It talks about features. It specifies screens, menus, dialogs, and so on.
A technical specification describes the internal implementation of the program. It talks about data structures, relational database models, choice of programming languages and tools, algorithms, etc.
He goes on to make a very important point IMO which is that "A spec is a document that you want people to read", and my 2c, and will continue to be read.
He also outlines numerous tips regarding the content of functional specs. The whole series is a good read. If I'm not mistaken he also provides a link to sample functional spec.
However, in all situations, I don't think you should be dogmatic about following any 'prescribed' method for creating such documents (including Joel's advice). Be practical and create documents that are easy to read and maintainable because we all know how quickly outdated they can become. Sounds like I'm talking about code - but I guess the same principles apply.
Both sets of documentation will have a different target audiences, so know your target audience.
A picture says a thousands words, so use simple diagrams where applicable.
I don't want to read a 13 volume series on what the system does or how it works. So be concise.
Document structure is important, but I would suggest don't focus on that initially. Understand and identify all the small pieces that make up the documentation and as a last step compile it into a readable document. Don't let the Table of Contents mantra drive your documentation creation. White board the idea/areas/content first.
Each section should have a decent introduction and conclusion.