.NET Tutorials, Forums, Interview Questions And Answers
Welcome :Guest
Sign In
Win Surprise Gifts!!!

Top 5 Contributors of the Month

Home >> Fun Zone >> General >> Post New Resource Bookmark and Share   

SRS Document

Posted By:Nikhil Kumar       Posted Date: August 04, 2010    Points: 25    Category: General    URL: http://www.dotnetspark.com  

It is a reference document or contract between the customer and the development team. Once the customer agrees to the SRS document the development team proceeds to develop the product conforming to all the requirements mentioned in the SRS document.

SRS Document


It is a reference document or contract between the customer and the development team. Once the customer agrees to the SRS document the development team proceeds to develop the product conforming to all the requirements mentioned in the SRS document.

An SRS document should clearly document the following:

1.         Functional requirements of the system.

2.         Non-functional requirements of the system.

3.         Constraints on the system.

1.         Functional requirements of the system: Each function of the system can be considered as performing a transformation of a set of input data to the corresponding set of output data. The functional requirements of the system should clearly describe each of the functions that the system needs to perform along with the corresponding input and output data set.

2.         Non-functional requirements of the system: Non-functional requirements deal with the characteristics of the system that cannot be expressed functionally, e.g., maintainability, portability, Usability, etc. The non-functional requirements also include reliability issues, accuracy of results, human computer interface issues, operating and Physical constraints, etc.

3.         Constraints on the system: The constraints on the system may describe certain things that the system should or should not do.



Natures of SRS


The basic issues the SRS writer(s) shall address are the following:

1.         Functionality: What the software is supposed to do?

2.         External Interfaces: How does the software interact with people, the system's hardware other hardware and other software?

3.         Performance: What is the speed, availability, response time, recovery time, etc., of the various software fundamentals?

4.         Attributes: What are the considerations for portability, correctness, maintainability, security, reliability, etc.

5.         Design constraints imposed on an implementation: Are there any required standards or effect, implementation language, policies for database, integrity resource limits, operating environment, etc.

Characteristics of a good SRS

An SRS should be

·              Correct

·              Unambiguous

·              Complete

·              Consistent

·              Ranked for Importance and for Stability

·              Verifiable

·              Modifiable

·              Traceable

Correct: There is no tool or procedure that assures correctness. If the software must respond to all button presses within 5 seconds and the SRS stated that "the software shall respond to all button presses with in 10 seconds", then that requirement is incorrect.

Unambiguous: An SRS is unambiguous if and only if every requirement started therein has only are interpretation. In cases, where a term used in a particular context could have multiple meanings, the term should be included in a glossary where its meaning is made more specific.

Complete: An SRS is complete if and only if it includes of the following elements.

1.         All significant requirements, whether relating to functionality, performance, design constraints, attributes or external interfaces.

2.         Full labels and references to all figures, tables and diagram in the SRS and definition of all terms and units of measure.

Consistent: An SRS is consistent if no subset of individual requirements desorbed in it conflict.

 There are 3 types of likely conflicts in an SRS:

1.         The specified characteristics of real word objects may conflict, e.g. a. The format of an output report may be described in are requirements as tabular but in another as textual.

b.        One requirement may state that all lights shall be green while another states that all lights should be blue.

2.         There may be logical or temporal conflict between two specified actions, e.g. a. Are requirement may specify that the program will add 2 inputs and another may specify that the program will multiply them.

b.        Are requirement may state that 'A' must always follows B, while another requires that A&B occur simultaneously.

3.      Two or more requirements may describe the same real word object but use different terms for that object. The use of standard terminology and definitions promotes consistency.

Thank you !!


No response found. Be the first to respond this post

Post Comment

You must Sign In To post reply
Find More Computer, Technology related Jokes Here

Hall of Fame    Twitter   Terms of Service    Privacy Policy    Contact Us    Archives   Tell A Friend