Software documentation: Difference between revisions

Revision as of 15:56, 4 July 2022

Revision as of 08:29, 5 July 2022

Line 13:

[[Requirement]]s documentation is the description of what a particular [[software]] does or shall do. It is used throughout [[Software development|development]] to communicate how the software functions or how it is intended to operate. It is also used as an agreement or as the foundation for agreement on what the software will do. Requirements are produced and consumed by everyone involved in the production of software, including: [[end user]]s, [[customer]]s, [[project manager]]s, [[sales]], [[marketing]], [[software architect]]s, [[usability engineering|usability engineers]], [[interaction design]]ers, [[software developer|developer]]s, and [[Software testing|testers]].

Requirementsrequirements comes in a variety of styles, notations and formality. 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 select the 'build' function''), and anything in between. They can be specified as statements in [[natural language]], as drawn figures, as detailed [[mathematical formula]]s, and as a combination of them all.

The variation and complexity of requirements documentation makes it a proven challenge. Requirements may be implicit and hard to uncover. It is difficult to know exactly how much and what kind of documentation is needed and how much can be left to the architecture and design documentation, and it is difficult to know how to document requirements considering the variety of people who shall read and use the documentation. Thus, requirements documentation is often incomplete (or non-existent). Without proper requirements documentation, software changes become more difficult — and therefore more error prone (decreased [[software quality]]) and time-consuming (expensive).