To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
The Institute of Electrical and Electronics Engineers (IEEE) publishes several dozen software engineering standards. One is called IEEE Std 830-1998, 'IEEE Recommended Practice for Software Requirements Specifications.' Standard 830, last revised in 1998, can be purchased from the IEEE here. The standards are not in the public domain.
Like many of the IEEE software engineering standards, Standard 830 includes some 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 document is a detailed suggested template for organizing the different kinds of requirements information for a software product. This deliverable is called a software requirements specification or SRS.
The heart of the SRS consists of descriptions of both functional and nonfunctional requirements. The standard provides several suggestions of how to organize the functional requirements: by mode, user class, object, feature, stimulus, functional hierarchy, or combinations of these. There is no single 'correct' organizational approach. Use whatever makes sense for your project.
I have used the IEEE SRS template numerous times. Most of it makes good sense. I found a few quirks that led me to create a modified version of the template, which you can download here. A template like this is intended to be useful on a wide variety of projects. Organizations and project teams should feel free to tailor and customize such templates to best suit the nature and scale of their projects.
IEEE standards are developed through the collaboration of dozens of practitioners worldwide. They reflect the best of what is known about how to address a specific software engineering domain. However, just because the IEEE termed this document and template a 'standard' does not obligate anyone to follow it. Some organizations may mandate that their project teams or subcontractors follow certain standards. Otherwise, though, just view the standards as representing the collective knowledge of many smart people who have worked on software projects over the last 50 years or so. I recommend starting with existing materials like the IEEE standards rather than creating your own templates and processes from a blank piece of paper.
|
