Software Reuirements Specification (SRS)
A software requirements specification (SRS), a requirements specification for a software system.It is a complete description of the behavior of a system to be developed and may include a set of use cases that describe interactions the users will have with the software.
It also contains non-functional retirements.Non functional requirements impose constraints on the design or implements , (such as performance engineering requirement,quality standards,or design constraints). The software requirement specification document enlists all necessary requirement that are required for the project developed.
To derive the requirement we need to have clear and through understanding of the products to be developed. This is prepared after detailed communication with the project team and customer.
Purpose of SRS
1.Establish the basis for agreement between the customers and the suppliers on what the software products is to do: The complete description of the function to be performs by the softer 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.
2. Provide a basis for developing the software design: The SRS is the most important document of reference in developing a design.
3. Reduce the development effort: The preparation of the SRS forces the various concerned groups in the customers organization to thoroughly consider all of the requirements before design work begins.
A complete and correct SRS reduces effort waist-ed on redesign,re-coding 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.
4. Provide a basis for estimating costs and schedules: The description of the protect to be developed as given in SRS is a realistic basis for estimating project costs and can be used to obtain approval for bids or price estimates.
5. Provides a baseline for validation and verification: Organization can develop their test documentation much more productively from a good SRS. As a parts of the development contract,the SRS provides a baseline against which compliance can be measured.
6. Facilitate transfer: The SRS makes it easier to transfer the software products to new users or new machines.Customer 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.
7. 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 product evaluation.
Requirement Analysis
Software requirement document(SRD) describes in precise details what the customer wants.
SRD Provides:
(i) Agreement between customer and supplier
(ii) Costing and scheduling
(iii) Validation and verification
(iv) All form of maintenance
SRD characteristics
(i) Defines all software requirements
(ii) Must be unambiguous
(iii) Must be complete
(iv) Must be verifiable
(v) Must be consistent
(vi) Must be modifiable
(vii) Must be traceable
Techniques for gathering requirements:
(i) One-to-one interview
(ii) Group interview
(iii) Prototyping
(iv) Requests for proposals
(v) Questionnaires
(vi) Use cases
(vii) Brain storming
It also contains non-functional retirements.Non functional requirements impose constraints on the design or implements , (such as performance engineering requirement,quality standards,or design constraints). The software requirement specification document enlists all necessary requirement that are required for the project developed.
To derive the requirement we need to have clear and through understanding of the products to be developed. This is prepared after detailed communication with the project team and customer.
Purpose of SRS
1.Establish the basis for agreement between the customers and the suppliers on what the software products is to do: The complete description of the function to be performs by the softer 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.
2. Provide a basis for developing the software design: The SRS is the most important document of reference in developing a design.
3. Reduce the development effort: The preparation of the SRS forces the various concerned groups in the customers organization to thoroughly consider all of the requirements before design work begins.
A complete and correct SRS reduces effort waist-ed on redesign,re-coding 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.
4. Provide a basis for estimating costs and schedules: The description of the protect to be developed as given in SRS is a realistic basis for estimating project costs and can be used to obtain approval for bids or price estimates.
5. Provides a baseline for validation and verification: Organization can develop their test documentation much more productively from a good SRS. As a parts of the development contract,the SRS provides a baseline against which compliance can be measured.
6. Facilitate transfer: The SRS makes it easier to transfer the software products to new users or new machines.Customer 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.
7. 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 product evaluation.
Requirement Analysis
Software requirement document(SRD) describes in precise details what the customer wants.
SRD Provides:
(i) Agreement between customer and supplier
(ii) Costing and scheduling
(iii) Validation and verification
(iv) All form of maintenance
SRD characteristics
(i) Defines all software requirements
(ii) Must be unambiguous
(iii) Must be complete
(iv) Must be verifiable
(v) Must be consistent
(vi) Must be modifiable
(vii) Must be traceable
Techniques for gathering requirements:
(i) One-to-one interview
(ii) Group interview
(iii) Prototyping
(iv) Requests for proposals
(v) Questionnaires
(vi) Use cases
(vii) Brain storming
No comments