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?"
An SRS is basically an organization's understanding (in writing) or blueprint of a customer or client's system requirements and dependencies at a particular point of time (usually) prior to any actual design or development work. It's a two-way document that assures that both the client and the organization understand the other's requirements from that perspective at a given point of time.
The SRS document itself states in precise and explicit language those functions and capabilities a software system 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 that 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:
  1. 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, in an unambiguous manner that may also include charts, tables, data flow diagrams, decision tables, and so on.
  2. It decomposes the problem into component parts. The simple act of writing down software requirements in a well-designed format organize information, places borders around the problem, solidifies ideas, and helps break down the problem into its component parts in an orderly fashion.
  3. 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. Therefore, the SRS must contain sufficient detail in the functional system requirements so that a design solution can be devised.
  4. 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.
Unfortunately, much of the time, systems architects and programmers write SRSs with little (if any) help from the technical communications organization. And when that assistance is provided, it's often limited to an edit of the final draft just prior to going out the door. Having technical writers involved throughout the entire SRS development process can offer several benefits:
  • Technical writers are skilled information gatherers, ideal for eliciting and articulating customer requirements. The presence of a technical writer on the requirements-gathering team helps balance the type and amount of information extracted from customers, which can help improve the SRS.
  • Technical writers can better assess and plan documentation projects and better meet customer document needs. Working on SRSs provides technical writers with an opportunity for learning about customer needs firsthand--early in the product development process.
  • Technical writers know how to determine the questions that are of concern to the user or customer regarding ease of use and usability. Technical writers can then take that knowledge and apply it not only to the specification and documentation development, but also to user interface development, to help ensure the UI (User Interface) models the customer requirements.
  • Technical writers, involved early and often in the process, can become an information resource throughout the process, rather than an information gathered at the end of the process.
In short, a requirements-gathering team consisting solely of programmers, product marketers, systems analysts/architects, and a project manager runs the risk of creating a specification
that may be too heavily loaded with technology-focused or marketing-focused issues. The presence of a technical writer on the team helps place at the core of the project those user or
customer requirements that provide more of an overall balance to the design of the SRS, product, and documentation.
You probably will be a member of the SRS team (if not, ask to be), which means SRS development will be a collaborative effort for a particular project. In these cases, your company will have developed SRSs before, so you should have examples (and, likely, the company's SRS template) to use. But, let's assume you'll be starting from scratch. Several standards organizations (including the IEEE) have identified nine topics that must be addressed when designing and writing an SRS:
  1. Interfaces
  2. Functional Capabilities
  3. Performance Levels
  4. Data Structures/Elements
  5. Safety
  6. Reliability
  7. Security/Privacy
  8. Quality
  9. Constraints and Limitations
But, how do these general topics translate into an SRS document? What, specifically, does an SRS document include? How is it structured? And how do you get started? An SRS document typically includes four ingredients, as discussed in the following sections:
  1. A template
  2. A method for identifying requirements and linking sources
  3. Business operation rules
  4. A traceability matrix

 

Cheers,

Javed Nehal