Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie

Writing up a technical manual

Options
  • 26-04-2004 5:20pm
    #1
    L5
    Closed Accounts Posts: 2,951 ✭✭✭


    Now this isnt a programming question as such. More of a documentation question :)
    I have 3 big documents to write up for my final year project. Installation guide, and user manual. I have them both done. Now im moving onto the one i left till last because i dont know what to put in it! :/ I presume its a description of the methods used etc. But can anyone give me some headings that should definitely be in it?


    Thanks


Comments

  • Options
    #2
    Auburn
    Closed Accounts Posts: 302 ✭✭Auburn


    By technical manual, I presume you mean a report-style document? If so, I would basically go along the lines of:

    1. Summary: A short (maybe 2 pages) description of what you originally set out to achieve. It should be understandable by someone who wouldn't have in-depth knowledge of your subject matter (but assume they have some background knowledge - i.e. make it simple but don't dumb it down too much).
    2. Introduction: Describe the domain, what development languages you used, deployment platform, lifecycle model, etc
    3. The middle section is up to yourself. Further headings could be: Requirements (functional + non), Analysis + Design (design patterns used, class diagrams, state diagrams, etc), Implementation + testing (basically how you implemented the project and why you did it that way, describe testing methods used).
    4. Conclusions: Look at the finished project objectively. Go through your requirements and say whether you achieved them satisfactorily. If there is scope for future developments, describe them here. Be very honest. You will be more respected for saying that you didn't exactly achieve what you wanted and give the reasons why, rather than saying that your project is brilliant and it does everything exactly as you wanted it to. Be critical, but don't run yourself down either.
    5. References, bibliography, appendices. Keep most bulky things for the appendices and refer to them where needed, eg. API, research, etc. If you are not going to discuss something directly, put it in the appendices, it will only clog up the report and make it more difficult to read.

    That's my opinion anyway, it's up to yourself really how you want to approach it.


  • Options
    #3
    L5
    Closed Accounts Posts: 2,951 ✭✭✭L5


    ok, thanks, thats a start for me anyway


Advertisement