Software Requirements Specification (SRS)

A Software Requirements Specification (SRS) is a document that provides a detailed description of a software development project. The SRS outlines the technical requirements of the proposed system, defines the purpose of the system and its components, and includes sufficient detail for technical teams to build the system. The SRS should provide a complete overview of the project and will be used by everyone involved in the project to aid in its successful completion. Once the SRS is complete, a PPD would be produced that summarizes the findings of the SRS. The PPD would be presented to the customer for approval. See the next section of this chapter for a discussion of PPDs. We will explore these two documents using a fictitious project scenario for demonstration purposes.

Scenario

ABC Consulting Services, LLC, has been asked to propose a software solution for a new call center opening in Salt Lake City. The company needs a system for their call center agents to record customer information and receive customer support phone calls. The call center operates three shifts to handle 24/7 customer calls. The company owners have contracted ABC to conduct a requirements study and subsequently propose a software solution for their needs.

The size of an SRS document is dependent on the scale and complexity of the project. The document is usually produced by a team of professionals who contribute to the specifications based on their areas of expertise. A small project may warrant an SRS of ten pages, whereas a large-scale project may require hundreds. In any case, the goal is to produce a detailed project specification.

ABC Consulting will produce an SRS and PPD for the customer as deliverables in our example scenario. These documents will be the product of the consulting team working through Steps 1 and 2 of the SDLC process shown in Figure 4.2. While the approaches and content can vary by project, the following is an example of an SRS.

The SRS is a formal document written for approval by customer representatives. Figures 4.3 and 4.4 depict a standard format for the cover and approval pages. In addition to identifying the document’s purpose, it lists the authors of the SRS and their identifying and contact information. An approval page is provided to document the customer’s approval when they approve the SRS.

The contents of the SRS vary depending on the scope and size of the project. The detail needed between small-scale and large-scale projects is the same—a detailed account of the requirements. The difference from project to project is in the context of the project. For example, the customer’s request may require the new software to interact with the company’s existing computers, networks, and databases. In contrast, other projects may also require entirely new hardware and database software. As a result, the consulting team will structure the SRS to suit the project’s needs.

To prepare for writing an SRS, a format of the document can be chosen. A standard section-based structure is often used to group related information. Also, while there may be variation in content, standard sections in an SRS often include an overview, an exploration of existing systems, dependencies, constraints, requirements, and supporting documentation, as shown below.

Section 1 of an SRS document presents the overall purpose of the project and the software requested. It also addresses the project’s audience, scope, and staffing considerations. It is essential to the project’s success for the overview to be well written and accurately describe the project.

When developing new systems for a business, it is critical to consider processes and procedures that may already exist there. This genuine consideration requires focused attention and analysis during this process and is a vital part of the SDLC Part 2 Domain Research. The domain of the business must be considered for a new system to integrate well into the business’s existing infrastructure. This applies to existing hardware and software and to the other processes handled by humans and equipment if those processes will be affected by the new system. Well-written details surrounding the domain often reveal challenges and needs that are easy to overlook otherwise. This is an example of discovery during the SDLC research steps that can cause the process to loop between stages, and it is why well-written documentation is vital to the success of projects.

Section 2 of the SRS document outlines existing systems. This section will vary widely from project to project because existing hardware, software, and processes are often very different from one project to the next. Overall, this section provides a written inventory and overview of existing components and software and describes how those elements interact to accomplish their intended tasks. This section combines written documentation, diagrams, and process flowcharts to aid in understanding the existing infrastructure.

Section 3 is directly related to Section 2 and acts as a bridge between the existing and new systems. Dependencies are how the various components rely on each other to operate within the business context. Identifying and documenting these dependencies, primarily related to the proposed new system, is critical for SDLC Steps 1 and 2.

Section 4 of the SRS is generally the most detailed and lengthy part of the requirements document. This is where exact software product requirements are documented and become the source of task assignments later when the actual project work begins. Figure 4.9 demonstrates some of the specific requirements needed in an SRS. These types are selected based on the needs and goals of the project.

Section 5 and Section 6 shown in Figure 4.11 demonstrate additional types of documentation that may appear in an SRS. These provide space for supporting documentation and project-tracking details necessary for the project’s success. Other supporting sections that are often in SRS documents, beyond the References and Appendices sections, include glossaries, revision histories, requirements matrices, analysis models, test performance metrics, and others.

To conclude this example, it is essential to recognize that each section of the framework presented here may or may not be appropriate for all projects. Also, within each area, the content is directly tied to the actual requirements of each project as well.

The next section of this chapter presents the Project Proposal Document (PPD). If we revisit the steps of the SDLC, we note that the third step is to propose a solution. Once a requirements document is complete, a Project Proposal can then be formulated based on the requirements gathering and domain research.