A contract between the customer and the software vendor - A good SRS document specifies all the features required in the final system including technical requirements and interface requirements. SRS document is used by the customer to determine whether the software vendor has provided all the features in the delivered software system. To the Software vendor it provides a solid foundation to fix the scope of the software system.
Enables costing and pricing of the project - A well defined SRS enables software developers to accurately estimate the amount of effort required to build the software product. Function point analysis and SMC are some the techniques adopted for estimating effort.
Input for detailed design - A good SRS enables experienced developers to convert the requirements directly to a technical design. For example, a well defined data dictionary can be easily converted to a database specification
Management of customer expectations - Since SRS precisely defines project scope, it ensures that customer expectations don't change during software development. If they do, SRS can be modified and costing/pricing can be done again on the changes required.
SRS is about "what is needed" i.e. what software should do! Design docuemnt is about how Developer will achieve specified SRS.
Q#3: Draw the figure about when the preparation of the SRS document can begin.[5]
Hi i need srs for search engine indexing .so if any of u have search engine indexing srs kindly send me the srs to (subasharun74@jahoo.com), pleasethank you
It should only specify what the system should do and refrain from stating how to do these. This means that the SRS document should specify the external behavior of the system and not discuss the implementation issues. The SRS document should view the system to be developed as black box, and should specify the externally visible behavior of the system. For this reason, the SRS document is also called the black-box specification of a system.
If you get the answer forward me too........
An SRS document is formed after requirement engineering. The SRS stands for Software Requirement Specification.
read pressman...
It should only specify what the system should do and refrain from stating how to do these. This means that the SRS document should specify the external behavior of the system and not discuss the implementation issues. The SRS document should view the system to be developed as black box, and should specify the externally visible behavior of the system. For this reason, the SRS document is also called the black-box specification of a system.
document
SRS if I am assuming correct a Software Requirement Specification Document, can begin from day 1. One can start taking rough notes, and with more functional information gathered , the SRS can be continually refined. Though at the same time, the Business Analyst should consider the limitations of the technology used for development or depending on the reqs an appropriate platform must be chosen. After a thorough analysis of functional and technical scope an SRS can move towards finalization and can be later signed off by business users and Technical Project Managers I hope that helps
SRS in context of Software Engineering stands for System Requirements Specification. It is a document that specifies the complete description of the behavior of the system. For example, if the group of software engineers are to design a software for a bank. Assuming they are provided with BRD (Business Requirement Design), the engineers first need to describe and design the behavior of the software. The various entities the software has to react with, the various properties it should possess and so on. These specification can be a type of SRS.
System specification refers to each and every detail about the project. SRS document is used as a contract between the users and the developers.