Requirements can be goal-like (e.g., distributed work environment), close to design (e.g., builds can be started by right-clicking a configuration file and selecting the 'build' function), and anything in between.
If the software is expected to live for only a month or two (e.g., very small mobile phone applications developed specifically for a certain campaign) very little requirements documentation may be needed.
In Agile software development, requirements are often expressed as user stories with accompanying acceptance criteria.
It may suggest approaches for lower level design, but leave the actual exploration trade studies to other documents.
A good trade study document is heavy on research, expresses its idea clearly (without relying heavily on obtuse jargon to dazzle the reader), and most importantly is impartial.
It is perfectly acceptable to state no conclusion, or to conclude that none of the alternatives are sufficiently better than the baseline to warrant a change.
Today, a lot of high-end applications are seen in the fields of power, energy, transportation, networks, aerospace, safety, security, industry automation, and a variety of other domains.
There is evidence that the existence of good code documentation actually reduces maintenance costs for software.
[1] Code documents are often organized into a reference guide style, allowing a programmer to quickly look up an arbitrary function or class.
Often, tools such as Doxygen, NDoc, Visual Expert, Javadoc, JSDoc, EiffelStudio, Sandcastle, ROBODoc, POD, TwinText, or Universal Report can be used to auto-generate the code documents—that is, they extract the comments and software contracts, where available, from the source code and create reference manuals in such forms as text or HTML files.
Respected computer scientist Donald Knuth has noted that documentation can be a very difficult afterthought process and has advocated literate programming, written at the same time and location as the source code and extracted by automatic means.
Often, software developers need to be able to create and access information that is not going to be part of the source file itself.
API Writers are very well accomplished towards writing good user documents as they would be well aware of the software architecture and programming techniques used.
It is common to limit provided software documentation for personal computers to online help that gives only reference information on commands or menu items.
In the case of user documentation, the process as it commonly occurs in industry consists of five steps:[5] For many applications it is necessary to have some promotional materials to encourage casual observers to spend more time learning about the product.
"[10] This situation is particularly prevalent in agile software development because these methodologies try to avoid any unnecessary activities that do not directly bring value.
Specifically, the Agile Manifesto advocates valuing "working software over comprehensive documentation", which could be interpreted cynically as "We want to spend all our time coding.
"[11] A survey among software engineering experts revealed, however, that documentation is by no means considered unnecessary in agile development.