Sergey Nivens - Fotolia
Software requirements specification and IEEE standards
What does the IEEE outline for requirements specifications, and how strictly should you abide by that standard? Expert Karl E. Wiegers digs into the details of an SRS.
The Institute of Electrical and Electronics Engineers publishes several dozen software engineering standards, including IEEE Std 830-1998, "IEEE Recommended Practice for Software Requirements Specifications." Standard 830, last revised in 1998, has since been replaced by Standard ISO/IEC/IEEE 29148:2011, with an update in 2018.
Editor's note: IEEE 29148 covers the processes and information it recommends for a software requirements specification (SRS) document, as well as its format. Use the standard to understand what makes for a good software requirement, as well as how to apply these requirements throughout the software's lifecycle. While it can be adopted independently, IEEE 29148-2018 also includes information on how to work with standard 15288, a common framework of process descriptions related to systems' lifecycles, and 12207, a common framework for software lifecycle processes.
Like many IEEE standards for software engineering, Standard 830 includes guidance and recommended approaches for specifying software requirements. It's not a complete tutorial on requirements development, but it does contain some useful information. The bulk of the text is a detailed suggested template for organizing the different kinds of requirements information for a software product -- an SRS.
The heart of the SRS consists of descriptions of both functional and nonfunctional requirements. The IEEE standard provides several suggestions of how to organize functional requirements: by mode, user class, object, feature, stimulus, functional hierarchy or combinations of these criteria. There is no single organizational approach that's best; use whatever makes sense for your project.
I have used the IEEE SRS template numerous times. While most of it makes sense, I found a few quirks of IEEE standards that led me to create a modified version of the template. Organizations and project teams should tailor and customize such templates to best suit the nature and scale of their projects.
What to include in an SRS
While standards might change for requirements documentation over time, they remain vital to projects, as they ensure software is developed as intended. If your team develops software features on a whim, it can dig itself a deep hole on a project. Documentation helps keep agendas aligned, which makes it well worth the extra effort.
Senior Technology Editor Stephen Bigelow explained the goals and benefits of an SRS. When it comes to enterprise software development, an SRS should detail compliance, security, performance, database and customer needs to eliminate guesswork for developers.
But what should the SRS specifically include? Bigelow provided some recommendations for how to structure an SRS to make it as comprehensive as possible.
Evaluate your standards
IEEE standards result from the collaboration of dozens of practitioners worldwide. They're meant to reflect the best of what is known about how to address a specific software engineering domain. However, companies don't have to follow IEEE standards, as no outside agency enforces a universal standard. Some organizations might mandate that their project teams or subcontractors follow certain standards but not others.
Generally, view IEEE standards for SRS documentation as a representation of the collective knowledge of many smart people who have worked on software projects over the last several decades. I recommend that you start with existing materials, like the IEEE standards, rather than create your own SRS model from scratch.
