0

I have been asked to write the technical documentation for a legacy system, which I am working on.

The documentation is trying to target new joinee developers and QAs.

I have few confusion about it:

  • What are the details needed:
  • Figures and diagram needed like flowchart and others
  • Do we need to describe class or db tables and all?
Improve this question
3
  • Why would you think documening legacy systems is any different to modern systems?
    – Chenmunka
    Commented Dec 5, 2023 at 7:52
  • I am not confused between technical documentation for legacy or modern system, but for documentation itself.
    – Anuj Karki
    Commented Dec 5, 2023 at 8:19
  • This question(/s) is way too broad, so isn't going to promote good responses.
    – Zayne S Halsall
    Commented Dec 16, 2023 at 13:19

2 Answers 2

Reset to default
1

I'm a bit confused about your question. Either you don't know how to write technical documentation. Then the scope of your question is too wide to be answered in a single answer here and you should probably at least get one or a few books or take a course on technical documentation to learn the basics. Or you don't know what the conventions and expectations are for this specific job, and then you need to ask those in your company who are in charge of that project what they want or those who will have to use the documentation what they need or both.

Improve this answer
2
  • Yes, I am new to technical writing. Can you provide me few blogs or other online content to help me in this journey
    – Anuj Karki
    Commented Dec 5, 2023 at 7:26
  • @AnujKarki When I google for something like "learning technical writing", I find many websites that explain technical writing from the ground up.
    – Ben
    Commented Dec 5, 2023 at 12:08
0

Here's a universal documentation tip: Look at documentation for similar products, systems, languages or software (depending on what your thing to be documented is). Copy (in the sense of replicate) the structure, depth of detail, and content categories. This helps you develop a foundation or blueprint for your documentation. This is where all documentation writers aim when they have to start from scratch.

Then pair that foundation with the universal documentation requirement: Know your audience! What do the people who will use your documentation already know, need to know, want to know, and don't need to know? This understanding will help you decide what you must include and what you can leave out. It can also help you decide on format and structure -- are they developers who are familiar with API-style syntax, or users who need recipe-like procedures?

Improve this answer
1
  • I hate to ruin your apparent faith in documentation, but a lot of it's terrible, incomplete or missing entirely. There are some niches where you have to buy the product to access the documentation (and it's usually enterprise software, which means you can't just go and buy it to look at the docs). So this advice is hardly universal, though it's hopefully helpful in a lot of cases.
    – Laurel ♦
    Commented Feb 9 at 17:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.