Software documentation plays a very important role in all the phases of a software system life cycle. It is not only relevant from the software engineering point of view, in all the software development process from the requirement definition to the maintenance activities [3, 7, 20], but also from the user point of view. Actually the user needs to know, with reference how to install and use to a software system, to import and manage data, to elaborate information and so on. The software is usually documented by the textual documentation required by the software engineering standards IEEE Std 830-1998, IEEE Std 1028-2008, IEEE Std 1063-2001, ISO/IEC 9126:2001, ISO/IEC 25010:2005, ISO/IEC 26514:2008 [11, 12, 13, 14, 15, 16], and so on. This documentation mostly consists of documents aiming to explain the functionalities the software performs, its architecture, how it is structured and implemented, and can be used. It generally includes the following documents: software requirements specifications, software design documents, code, quality and testing documents. Additional documents can exist, formalized as API documentation, Wiki pages. For describing different aspects of the software system. Such a kind of documents can be easily accessed by both developers and users, and can be considered documentation as well. API documentation specifies how software components can be used and interact with each other. Wiki pages allow for web-based visualization and knowledge management. It offers semantic-enhanced search facilities such as filtering, faceting, and graph-like exploration of knowledge. The hyper textual features make this type of documentation easy to find and consult. In addition, source code comments can represent a useful source of information helping to understand the software product [4], and it can be used as documentation as well, once extracted and adequately formatted. The proposed study uses the term “software documentation” for referring the different types of documents indicated above [2] For being really useful, software system documentation should include reliable, complete and unambiguous information regarding the software system. In addition, it should have a structure that makes the different documentation section easily recognizable. The relevance of the documentation is also confirmed in surveys and papers including the results of interviews with software engineers and developers working in organizations. Unfortunately, the results also indicate that the documentation is not always available and it only partially addresses the developers and users’ needs, as it is often wrong, incomplete, out-of-date and ambiguous. In addition, while in the case of closed source software, the documentation exists as it is foreseen by the internal quality procedures and is clear and complete [19], it can happen that it is not available for open source systems, where these documents may not exist, or not represent any official documentation. In the context of ERP – Enterprise Resource Planning, the relevance of the software documentation is even more important due to the complexity of such a kind of software systems and the strategic role they have within operative organizations. This paper focuses on the evaluation of the quality of the various types of documents that may be useful for understanding a software artefact. It mainly considers the user point of view and analyses both structural and content aspects that a good software system document should include for being effectively used.