Software Requirement Specifications in Software Engineering

One of the important reasons for most of the software bugs is mistakes in requirements. Or, we can the mistakes found in the Software Requirement Specifications document.

Sometimes requirements are not clear and inaccurate which results in errors in code, ultimately leading to a bug. Even if the development team tries to write perfect code, if requirements have errors in them, the software will contain bugs.

Reviewing the requirements is also an important step in any software development life cycle. Usually, it is not given enough emphasis. It becomes very difficult to recode everything if certain missed requirements are found later in the development life cycle.

This tutorial discusses a Software Requirement Specifications (SRS) document, its importance, and things that should be tested or reviewed in the same.

What is Software Requirement Specifications?

A software requirements specification (SRS) is a description of an agreement between the customer and the supplier/contractor. This contains the functional and non-functional requirements of the software system to be developed. This document is used as a reference base for the development process. 

Usually, the customers are not able to understand the development process and not clear on what they want from the system, at the same time the development team does not understand customers’ requirements. Usually, Business Analysts fill this communication gap by preparing an SRS document.  

Typically, an Software Requirement Specifications document consists of following sections (this is based on IEEE guide to software requirements specifications and this list may vary from organization to organization)-

1. Introduction – This section is written for the requirements document i.e. the purpose, scope, etc. of the requirements document is included.
   • Purpose
   • Scope
   • Definitions, Acronyms, and Abbreviations
   • References
   • Overview
2. Overall Description – This section contains an overview of all the requirements of the system.
   • Product Perspective
   • Product Functions
   • User Characteristics
   • General Constraints
   • Assumptions and Dependencies
3. Detailed Requirements – This is the most important part of the document; it contains details of product requirements that the development team and testing team need to know in order to code and test the system respectively.
   1. External Interface Requirements
      • User Interfaces
      • Hardware Interfaces
      • Software Interfaces
      • Communication Interfaces
   2. Functional Requirements
      • Module 1
        • Functional Requirement 1.1
        • Functional Requirement 1.2
          …
      • Module 2
        • Functional Requirement 2.1
        • Functional Requirement 2.2
          …
   3. Performance Requirements
   4. Design Constraints
   5. Attributes
   6. Other Requirements

Advantages or Uses of SRS

The following are some important advantages or uses of an SRS:

• It is an agreement between the client and the supplier on what the software will do.
• It includes all the functional and non-functional requirements of the system. 
• SRS works as a base for any further development and testing documents that need to be prepared for the development and testing processes. These documents include design documents, test plans, test scenarios, etc. 
• It is used for the schedule and cost estimation process. 
• SRS acts as a basis for any further enhancements in the product. 
• It is used for validation of the final product i.e. once the final product is ready, the client, the development team, and the testing team can be assured that the product matches all the requirements in the document.

Desirable Characteristics of an SRS

This section discusses, in brief, some characteristics that describe a good SRS:

Correct – Requirements should be correct and should reflect exactly what the client wants. Every requirement should be such that it is required in the final product.

User review is used to ensure the correctness of requirements stated in the SRS. SRS is said to be correct if it covers all the requirements that are actually expected from the system.

Complete – SRS is said to be complete if everything the software is supposed to do is covered in the document. It should include all the functional and non-functional requirements, the correct numbering of the pages, any diagrams if required.

Unambiguous – All the requirements should have the same interpretation.

Verifiable – SRS is said to be verifiable if and only if each requirement is verifiable; there must be a way to determine whether every requirement is met in the final product.

Consistent – SRS is said to be consistent if there aren’t any conflicts between the requirements.

Ranking for importance and stability – Each requirement should be ranked for its importance or stability.

Modifiability – An SRS is said to have modifiability quality if it is capable of adapting changes in the future as much as possible.

Traceability – Tracing of requirements to a design document, particular source code module or test cases should be possible.

Design Independence – SRS should include options of design alternatives for the final system; it should not have any implementation details.

Testability – An SRS is said to be testable if it is easier for the testing team to design test plans, test scenarios, and test cases using an SRS.

Understandable by the customer – An SRS should be written with easy and clear language so that the customer can understand the document.

How an SRS should be tested?

The development team will use an SRS as a base for coding. The testing team uses SRS to create a test plan, test scenarios, and test cases. So, the development and testing team should have a detailed knowledge of each section of an SRS. Their understanding of the requirements should be clear so that any discrepancies in the source code and further testing documents can be avoided.

Ideally, a Business Analyst should schedule a review meeting with required parties. Reviewers can be the client, developers, testers, project managers among others.

Instead of giving the final document for review, a BA can arrange a periodic meeting with the reviewers whenever an incrementally updated version of the SRS is available. This way it becomes easier to find errors as the reviewers need to review a small piece of document in every meeting rather than reviewing a whole document. Also, a BA can work on these errors and bring an improved document apart from the newly added information for the next periodic meeting.

Once all the review meetings are completed, all the errors in the document have been resolved, a sign off from the client should be taken on the final version of the document. This final version will then be used for the development and testing process mainly among other processes.

What should be tested in an SRS?

This section discusses various points that should be considered while reviewing an SRS-

• Reviewers should check for any missing requirements. All the features of the system should be written clearly without any missing piece of information.
• Reviewers should check the feasibility of the requirements. As most of the clients are not aware of the implementation aspects of the technology, it becomes necessary for a BA to have a discussion with the development team to make sure all the requirements are the realistic and technical implementation of the same is possible.
• Reviewers should make sure that the requirements are unambiguous. Nowadays, due to outsourcing, the BA team, development team, and the testing team sit in different countries and work in different time zones. Now, it is possible that each team member has a different understating of the requirements if they are not documented clearly. An SRS needs to be clear and unambiguous so that every member has the same interpretation of the requirements.
• An SRS should be consistent. Reviewers should make sure that the document has consistent requirements for all the features, it uses correct terminology (for example, in some places ‘Log out’ phrase is used while in other section ‘Sign out’ phrase is used).
• Reviewers should make sure that the document is complete i.e. all the use cases have expected results, pre-conditions are stated correctly and completely, all the requirements are assigned a requirement ID, any assumptions and dependencies are stated clearly, external interface requirements are included, security and performance criteria and mentioned, etc.

It is important to note that each and every version of the document should be maintained correctly, and the respective teams should make sure to use the latest version.

Conclusion

A Software Requirement Specifications is the most important document of any software development project as it serves as a base for further development and testing processes. This document includes functional and non-functional requirements. A good SRS helps in creating a system that is bug-free and reduces development costs.

An SRS also acts as an agreement between the client and the supplier, it gives confidence to the client that the requirements are documented correctly.

Еще об этом:

Top Agile Methodology Interview Questions You Must Prepare Manual Testing Interview Questions and Answers Software Development Life Cycle Requirements Traceability Matrix Software Engineering Interview Questions and Answers Game Testing Top 40 SQL Query Interview Questions and Answers for Practice Principles of Software Testing Quality Assurance What is Robustness Testing in Software Testing?