What is a Software Requirements Specification?

Writing Software Requirements Specifications

by Donn Le Vie, Jr.

Here's the scenario: You're finishing up your latest HTML Help project...no more late nights or weekends...back to a " normal" 50-hour work week. That's when the development team lead strolls into your office and says she just got your manager's okay for you to help the development team " put together the functional requirements specification template for the next major project."

" A what? " you ask with a look of semi-shock. Panic sets in. " What did I do to deserve this? I don't even know where to start! Maybe someone on the TECHWR-L list can help...."

For technical writers who haven't had the experience of designing software requirements specifications (SRSs, also known as software functional specifications or system specifications) templates or even writing SRSs, they might assume that being given the opportunity to do so is either a reward or punishment for something they did (or failed to do) on a previous project. Actually, SRSs are ideal projects for technical writers to be involved with because they lay out the foundation for the development of a new product and for the types of user documentation and media that will be required later in the project development life cycle. It also doesn't hurt that you'd be playing a visible role in contributing to the success of the project.

This article will describe what an SRS is and why it's important, discuss how and why technical writers should be involved with them, and discuss the critical elements for writing an SRS. Although this article does not attempt to address all aspects of developing SRSs, it aims to help you determine the scope for such a project, to provide some guidelines for writing SRSs, and to provide additional resources. Hopefully with this information, you'll not be asking, " Why me? " but proclaiming " Why not me? "

What is a Software Requirements Specification?

An SRS is basically an organization's understanding (in writing) of a customer or potential client's system requirements and dependencies at a particular point in time (usually) prior to any actual design or development work. It's a two-way insurance policy that assures that both the client and the organization understand the other's requirements from that perspective at a given point in time.

The SRS document itself states in precise and explicit language those functions and capabilities a software system (i.e., a software application, an eCommerce Web site, and so on) must provide, as well as states any required constraints by which the system must abide. The SRS also functions as a blueprint for completing a project with as little cost growth as possible. The SRS is often referred to as the " parent" document because all subsequent project management documents, such as design specifications, statements of work, software architecture specifications, testing and validation plans, and documentation plans, are related to it.

It's important to note that an SRS contains functional and nonfunctional requirements only; it doesn't offer design suggestions, possible solutions to technology or business issues, or any other information other than what the development team understands the customer's system requirements to be.

A well-designed, well-written SRS accomplishes four major goals:

• It provides feedback to the customer. An SRS is the customer's assurance that the development organization understands the issues or problems to be solved and the software behavior necessary to address those problems. Therefore, the SRS should be written in natural language (versus a formal language, explained later in this article), in an unambiguous manner that may also include charts, tables, data flow diagrams, decision tables, and so on.
• It decomposes the problem into component parts. The simple act of writing down software requirements in a well-designed format organizes information, places borders around the problem, solidifies ideas, and helps break down the problem into its component parts in an orderly fashion.
• It serves as an input to the design specification. As mentioned previously, the SRS serves as the parent document to subsequent documents, such as the software design specification and statement of work. Therefore, the SRS must contain sufficient detail in the functional system requirements so that a design solution can be devised.
• It serves as a product validation check. The SRS also serves as the parent document for testing and validation strategies that will be applied to the requirements for verification.

SRSs are typically developed during the first stages of " Requirements Development, " which is the initial product development phase in which information is gathered about what requirements are needed--and not. This information-gathering stage can include onsite visits, questionnaires, surveys, interviews, and perhaps a return-on-investment (ROI) analysis or needs analysis of the customer or client's current business environment. The actual specification, then, is written after the requirements have been gathered and analyzed.