Requirements documents appear in many different formats. All too often these documents are so voluminous, dense, and complex that the eyes glaze over and the architects, designers, and most of all, the engineers never turn page one. So, the key is to create documentation (and not necessarily paper) that speaks to the various stakeholders in the software development process. These stakeholders include:

-Business Partners

-Technology Partners

-External Partners (such as Vendors, Customers, Governing Authorities, etc.)

The challenge in uncovering, gathering, and documenting requirements is that each stakeholder cares about that which is important to them. Additionally, each stakeholder uses language that is unique to their perspective of the business. Creating documentation that is useful and useable by each stakeholder is difficult.

S R S

The software requirements specification (SRS) document is started after the problem analysis is complete, or at least when the problem analysis results in enough information to begin capturing certain requirements.

Davis [1993] enumerates the attributes of a well-written SRS as:

There are several types of SRS frameworks that are used in various industries such as:

The IEEE/ANSI SRS is, probably, the most popular framework from which many organizations begin. That is, there is not, usually, an initial strict conformance to the document but a refinement that meets that organization's needs.

Below is a high level framework of the IEEE/ANSI SRS: