• Table of Contents

Introduction

After completing the comprehensive process of requirement analysis, we can now direct our attention towards the final step of this methodology, which involves documenting the requirements in a detailed and structured manner, commonly known as requirement specification.

Figure 9.1 Stages of the methodology.

Once requirements have been gathered and analyzed, it is essential to formalize them through documentation — to provide a clear and unambiguous understanding of the system being developed.

• This is typically in the form of a Software Requirement Specification (SRS) document.
• This serves as a reference for the development team, ensuring alignment with stakeholder needs and expectations.

The requirement specification process aims to capture requirements in a manner that can be effectively used to design and develop the system.

Software Requirements Specification

The purpose of the SRS is to provide a clear and unambiguous description of the software system to be developed, including its functional and non-functional requirements, as well as any constraints, assumptions, and acceptance criteria.

Figure 9.2 IEEE Software Requirements Specification template.

The SRS serves as a reference for all stakeholders involved in the development process, including including the client, user groups, developers, and testers. It is designed to accomplish four major goals:

1. To provide feedback to the customer.
2. To decompose the problem into component parts.
3. To serve as an input to design specifications.
4. To serve as a product validation check.

There are several templates that can be used for a SRS. The choice of template may vary depending on the specific needs of the project.

IEEE 830-1998 Standard

<aside> <img src="/icons/map-pin_gray.svg" alt="/icons/map-pin_gray.svg" width="40px" /> Refer to IEEE Recommended Practice for Software Requirements Specifications

</aside>