In this Lecture
_______________________________________
(This introduction is not a part of IEEE Std 830-1993, IEEE Recommended Practice for Software Requirements
Specifications.)
This recommended practice describes recommended approaches for the specification of software requirements.
It is based on a model in which the result of the software requirements specification process is an
unambiguous and complete specification document. It should help
a)
b)
c)
Software customers to accurately describe what they wish to obtain
Software suppliers to understand exactly what the customer wants
Individuals to accomplish the following goals:
1)
2)
3)
Develop a standard software requirements specification (SRS) outline for their own
organizations
Define the format and content of their specific software requirements specifications
Develop additional local supporting items such as an SRS quality checklist, or an SRS writer’s
handbook
To the customers, suppliers, and other individuals, a good SRS should provide several specific benefits,
such as:
Establish the basis for agreement between the customers and the suppliers on what the somare
product is to do. The complete description of the functions to be performed by the software specified
in the SRS will assist the potential user to determine if the software specified meets their needs or
how the software must be modified to meet their needs.
Reduce the development effort. The preparation of the SRS forces the various concerned groups in
the customer’s organization to consider rigorously all of the requirements before design begins and
reduces later redesign, recoding, and retesting. Careful review of the requirements in the SRS can
reveal omissions, misunderstandings, and inconsistencies early in the development cycle when these
problems are easier to correct.
Provide a basis for estimating costs and schedules. The description of the product to be developed
as given in the SRS is a realistic basis for estimating project costs and can be used to obtain approval
for bids or price estimates.
Provide a baseline for validation and ver@cation. Organizations can develop their validation and
verification plans much more productively from a good SRS. As a part of the development contract,
the SRS provides a baseline against which compliance can be measured.
Facilitate transfel: The SRS makes it easier to transfer the software product to new users or new
machines. Customers thus find it easier to transfer the software to other parts of their organization,
and suppliers find it easier to transfer it to new customers.
Serve as a basis for enhancement. Because the SRS discusses the product but not the project that
developed it, the SRS serves as a basis for later enhancement of the finished product. The SRS may
need to be altered, but it does provide a foundation for continued production evaluation.
NOTE: The above content is directly copied from "IEEE Recommended Practice for
Software Requirements Specifications" by IEEE Standard Board.
No comments :
Post a Comment