SRS Document in Software Engineering

SRS Document in Software Engineering-

SRS Document is a detailed description of the software system. It is to be developed with help of its functional and non-functional requirements. The SRS is developed based on the agreement between the customer and  the contractors. It may also include the use cases that how a user is going to interact with a software system. The software requirement specification document consists of all the necessary requirements that are required for project development. To develop the software system, we must have clear understanding of Software system. To achieve this goal, we need to do continuous communication with customers to gather all the requirements.

A good Software Requirement specification defines that how the Software System will interact with all internal modules, hardware, communication with other programs and human user interactions. It is more important that testers must be cleared with his specified detail. In order to avoid faults or errors  in test cases and its expected result.

It is highly recommended to review the tested SRS documents before start writing test cases and making any plan for  the testing.

 Let’s see how to test SRS and the important point to keep in mind while testing it are as follows:-. 

Correctness of SRS must be checked-

Since the entire testing phase is dependent on SRS. So, it is very important to check its correctness and accuracy. There are some standards with which we can compare it and verify completely.

Ambiguity must be avoided-

Sometimes in SRS document, some words have more than one meaning and this may confused  the testers making it difficult to get the exact meaning . It is advisable to check for such ambiguous words.  Should make the meaning clear for better understanding.

Requirements must  be complete-

When tester starts  writing  test cases, what  is required from the application,  that is the first thing which needs to be clear. For instance :’ if application needs to send the specific data of specific size then it should be clearly mentioned in SRS that how much data and what is its size limit that can be send.

Consistent requirement-

The SRS should be consistent within itself . If you call an input “Start and Stop” in one place and don’t call it “Start/Stop” in another. This is the standard and should be followed throughout the entire  testing phase.

Verify the expected result-

 SRS should not have statements like “Work as expected”.,  it means that   what is expected since different testers would have different thinking aspects .and may draw different results .

Testing environment-

some applications need specific conditions to test  them and also a particular environment for the best result up.

Pre-conditions defined clearly-

 one of most important part of (test cases) is pre-conditions. If they have not met properly then actual result will always be different from expected result. .

Requirements ID-

these are the base of test case templates. Based on the requirement Ids, test case ids are written. Also, the requirements ids make it easy to categorize the  modules so just by looking at them, tester will know  that which module is  to refer which . SRS must have them such like  id  that defines a particular module.

Security and the Performance criteria-

security is priority when a software is tested especially when it is  is built in such a way that it contains some crucial information which , when leaked can cause harm to business. Tester should check  are all the security related requirements are properly defined or not. he must also know when and how much stress  testing should be done to test the performance.

Assumption should be avoided-

sometimes when a requirement is not cleared to tester, he tends to make some more assumptions related to it, which is not a right way to do testing, as many assumptions can go wrong and hence, test results may vary different results. It is better to avoid use assumptions and ask clients about all the “missing requirements” to have a better u expected results.

Deletion of the irrelevant requirements-

there are more than two teams who work on SRS so that it might be possible that some irrelevant requirements can be deleted included in SRS. Based upon the understanding of the software, tester can find out which are the 

The  Freezing  requirements-

when an ambiguous ,incomplete requirement is sent to client  for analyzing then tester gets a reply, that the requirement result will be updated in the next SRS version .freezes here means that  the result will not change again    and again until and unless some major addition or modification is introduced in the software.

Most of the defects which we find during testing are only because of incomplete requirements or of ambiguity in SRS Document. To avoid such errors s it is very important to test software  requirements  specification before writing  test cases.  U should Keep the latest version of SRS with you for further  reference. Keep yourself updated with the latest change that is  made to the SRS. Best practice is to go  on through the document very carefully and note down all the confusions, assumptions and also  incomplete requirements and then have a meeting with the client to get them more  clear before development phase starts. It becomes very  costly to fix the bugs after the software is developed. After all the requirements are cleared to the  tester . Frester, it becomes  more easy for him to write effective test cases and accurate them forexpected results.

 Qualities of SRS are as follows :

  • Correct
  • Unambiguous
  • Complete
  • Consistent
  • Ranked for importance and/or  # stability
  • Verifiable
  • Modifiable
  • Traceable

Types of Requirements are as folows :

The below diagram  shows  the various types of requirements that are captured or use  during SRS.

 Stability Testing :- 

Stability testing is a software testing technique  that is adopted to verify if  the application can continuously  be performed  well within or just above the acceptable period.

It is the NON-Functional Testing technique conducted as a part of performance testing often referred  to Endurance testing.

What is the Static Testing?

Static Testing is a software testing technique in which the software is tested  been without executing the real  code. It has two parts as writtem below:

  • Review – Typically it is  used to find and eliminate  the errors or ambiguities in  a documents such as requirements, design, test cases, and so on. 
  • The Static analysis – The code written by developers are analysed (usually by tools) for structural defects .

Speak Your Mind

*