I want to build a list of useful documentation that a client can find useful, both during and after use of the system built in a project.

I think that system requirements, high level and low level design, and user manual are useful. Known bugs and not implemented features can be nice as well...

Do you think documents can be useful for the client? If yes, what documents would you put in the list.

  • downvote without any input... that was helpful. thanks.
    – Asaf
    Apr 4, 2017 at 13:12
  • Downvoted, because it is too broad and opinionated as what is useful for my project might not be for others. Apr 4, 2017 at 16:03
  • You want the list as a recommendation for deliverables for future projects? Otherwise the answer is: the deliverables...
    – Tob
    Apr 4, 2017 at 18:44
  • @tob... do you know of a document or metodolody to collect those recomendations... during run time... there is no time and after nobody cares /remembers
    – Asaf
    Apr 4, 2017 at 18:53
  • 1
    @Asaf Regarding technical systems, esp. within EU, there are applicable standards defining the required documentation. You should know the applicable standards / regulations. If not, ask your customer.
    – Tob
    Apr 4, 2017 at 19:27

3 Answers 3


Artifacts and deliverables are part of project definition. It is up to you to work with the client (contractually or collaboratively) to identify the project artifacts (including documentation) that they expect as part of your project's deliverables.

No one but you and the client can actually define this list accurately. That's why you have to work with them to determine what's needed.


Whatever the clients finds useful. Ask them.

If we focus on requirements here the software product is leading, not the documentation as most often it is incomplete and not updated under time pressure.

That is why the Agile manifesto states:

Working software over comprehensive documentation

As most documentation is useless and never used it is important to verify with your clients if it is useful. Let the define how they are going to use it, just to be sure they will not say: "Yes, we want it.". Also charge them for it.


@Niels: You are right its all about the money and no body wants to pay for huge books that nobody will read.

yet my projects are about reverse engineering, refactoring and other type of renewing aging systems....

Agile is great but not all knowledge aquired during the project can be found in the code. What about things that got out of the scope.. good ideas that cost too much, bad calls - what we did wrong, future development for things we developed quick and dirty and want to improve... is the system scalable can the db grow is there an interface for other system... are there limitation...

when i renew an old system. all this missing information gets really valuable..

like agile that looks for the thinest progect managemt... I look for the thinest documentation...

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