Requirements specification is the task of documenting the precise external behavior of the system that is to be built. It takes the features selected during requirements triage and expands them into considerable detail. The primary purposes of doing this are to ensure that (1) customers and developers have the same understanding of what is to be built, (2) all developers have identical understanding of what is to be built, (3) testers are testing for the same
qualities that developers are building, (4) management is applying resources to the same set of tasks that the developers are performing. Traditionally,
these requirements have been documented in a software requirements specification. However, more recently there is a trend toward maintaining the requirements in a database or repository of discrete requirements, rather than a formal document.
Replaced/Superseded by document(s)
|File||MIME type||Size (KB)||Language||Download|
Requirements management has been discussed for at least fifteen years. As a discipline and as a practice, it has become more and more complex. We have lost sight of the fact that requirements management was created to simplify software development, to
reduce its cost, and reduce the inherent risk associated with building software. Instead, requirements management has become yet one more chore, one more error-prone activity. The purpose of this paper is to distill the common wisdom of requirements management, and to return it to a simple method of ensuring that software development organizations build the right software.
Requirements are those externally observable
characteristics of a system that a user, buyer,
customer, or other stakeholder desires to have
present in the system. Requirements management
is the set of activities encompassing the
collection, control, analysis, filtering, and
documentation of a system’s requirements.