In one of the projects that I have worked in, the list of the document requirements were quite long and *un*fortunately I was assigned to do them. On one hand it was boring and tedious, and it doesn't boost my morale when I am almost sure that no one will be reading them. On the other hand, this was a golden opportunity for me to disect a project and analyse it inside out.
Here is the document list that was passed down to me and expect a list of filenames (with content of course) in return:
- Software Architecture Document (SAD)
- Functional Specification
- Technical Specification
- Reusability Analysis (of some of the components from previous projects)
- Test Procedure
- Test Cases
- User Manual
It was a long list and I didn't know where to begin. In theory this is a list that needs to be completed by several people, but because the project was shorthanded I volunteered to complete as many and as much as possible to save some time for the others.
As I have only written some of the documents above only once in my entire life, I am not about to start teach you how those are written and every company have their own guidelines regarding them. I will just tell you the benefits by actually take some time and complete them in a detail manner. In the next post I will mention of how these documents can give you a better idea of what you do affects the whole picture.
In conclusion, documentations are important for leaving behind information for the others but at the same time by writing them it will also challenge you to think throroughly of the design and if it in fact is done correctly and serve the true purpose. So don't run away from the task, instead walk in when everyone walks out.
No comments:
Post a Comment