Software Requirement Specification(SRS)

1. Software Requirement Specification(SRS)

2. Topics Covered: Software requirement specification(SRS) Authors of SRS Need of SRS Characteristics of SRS Components of SRS Behavioral /Non-behavioral requirements

3. Software Requirement Specification(SRS) SRS is a set of documents that specify the functional, performance, design and interface requirements of the proposed system. In SRS the external behavior of the problem, user interfaces, erroneous situations, performance and design constraints, standard compliance, recovery etc are included which can not be modeled during problem analysis. Thus an SRS clearly defines: • External interfaces of the system. • Functional and non-functional requirements of the system.

4. Authors of SRS document- SRS written by customer-> It defines the needs and expectations of the user. SRS written by the developer of the system-> It serves as a contract document between customers and developers.

5. Need of SRS: A basic purpose of software requirements specification is to bridge the communication gap between the parties involved in the development project. SRS is the medium through which the client and user needs are accurately specified to the developer. Some of the benefits or needs of SRS are as follows: • An SRS establishes the basis for agreement between the client and the supplier on what the software product will do. • An SRS provides a reference for validation of the final product.

6. A high quality software is a pre-requisite to high quality software. • A high quality SRS reduces problem of changes and rework. • SRS bridges communication gap between developer and clients.

7. Characteristics of SRS: To satisfy the basic goals SRS should have certain properties. Some of the desirable properties or characteristics are: -Correct -Consistent -Complete -Ranked for importance and/or stability -Unambiguous -Modifiable -Verifiable -Traceable

8. Correctness: • An SRS is correct if every requirement included in the SRS represents something required in the final system. • Correctness basically involves examining each requirement to make sure it represents user requirements. Completeness: • An SRS is complete if everything software has to do and the responses of the software to all classes of input data are specified in the SRS.

9. Unambiguous: • An SRS is unambiguous if and only if every requirement stated in it has only one interpretation. • Unambiguity can be achieved by using formal specification language. Verifiable: • An SRS is verifiable if and only if every stated requirement can be checked whether the final software meets the requirements. • Verification of requirements is done through reviews.

10. Consistent: • An SRS is consistent if there is no requirement conflicts with other. • Inconsistencies or conflicts in SRS may lead to major problems, so specifications should be consistent. Ranked for importance/stability: • In SRS for each requirement the importance and stability of the requirement can be ranked as critical, important, desirable etc. Some requirements have more chances of changes in future but some are not likely to change, accordingly ranking should be done.

11. Modifiable: • An SRS is modifiable if its structure and style could be changed easily while preserving completeness and consistency. Traceable: • An SRS is traceable if the origin of each of its requirements is clear and it facilitates the referencing of each requirement in future. • Traceability aids verification and validation.

12. Components of SRS: • Functional requirements: Functional requirements specify which outputs should be produced from the given inputs, relationship between the input & output of the system, source of data input, range of valid inputs etc. • Performance requirements: This component of an SRS specifies the performance constraints on the software. It is of 2 types: • Static Requirements • Dynamic Requirements

13. Static requirements: are one which do not impose the constraints on execution behavior of the system. These include number of terminals to be supported, number of simultaneous users & the number of files to be processed & their sizes. • Dynamic requirements: are one which specify constraints on execution behavior of the system. These include response time and throughput constraints. These requirements should be stated in measurable units.

14. Design constraints: An SRS should specify all constraints related to design such as standards to be followed, resource limits, operating environment, reliability, security requirements & policies. • External interface requirements: All the interactions of the s/w with people, h/w & other s/w should be clearly specified. A user manual should be created with all user commands, screen formats, feedbacks, error messages. The h/w interface requirements like memory restrictions, current use & load of the h/w should be given. The s/w interface includes interface with OS & other applications.

15. Behavioral/Non-behavioral requirements • Behavioral requirements: These define precisely what inputs are expected, what outputs will be generated & details of relationship between inputs and outputs. • Non-behavioral requirements: All applications have additional requirements that define the overall qualities or attributes of the s/w. Some of the attributes which can be specified in SRS are: -Reliability -Efficiency -Testability -Reusability -Usability -Maintainability -Portability -Robustness

16. Thanks!!