Informal working document – DO NOT DISTRIBUTE BEYOND S2ESC
3/8/2016
1 of 3
Discussion framework for combining Standards 830 and 1233
Introduction
Two distinct IEEE standards address requirements:
IEEE Std 830-1998 Recommended Practice for Software Requirements Specifications
Abstract: The content and qualities of a good software requirements specification
(SRS) are described, and several sample SRS outlines are presented. This
recommended practice is aimed at specifying the requirements of software to be
developed, but can also be applied to assist in the selection of in-house and
commercial software products. Guidelines for compliance with IEEE/EIA Std
12207.1-1997 are also provided.
IEEE Std 1233, 1998 and 1233-1996 -- IEEE Guide for Developing System Requirements
Specifications
Abstract: Guidance for the development of the set of requirements, System
Requirements Specification (SyRS), that will satisfy an expressed need is provided.
Developing an SyRS includes the identification, organization, presentation, and
modification of the requirements. Also addressed are the conditions for incorporating
operational concepts, design constraints, and design configuration requirements into
the specification. This guide also covers the necessary characteristics and qualities of
individual requirements and the set of all requirements.
Today the opportunity exists to combine these two standards into a single standard. Of the
several motivating factors two stand out: (1) many complex systems involve both hardware
and software, and (2) the commonality (in both content and elicitation process) between
Software Requirements Specifications and System Requirements Specification.
Two proposals have been presented for going forward, these will be discussed below – first
more basic questions should be addressed – also which of the following questions should be
addressed by the S2ESC and which should be left for the working committee:
1. Should there be a combined standard?
2. How would this combined standard (or two separate standards) interface with / coexist
with other standards?
3. What type of standard(s) – Recommended Practices, Guides, ….
4. What is the applicability of a combined standard – is it only for software intensive
systems (define please)?
5. Should this standard be product-oriented, process-oriented or both?
6. What is best composition of a working group / who?
Two proposals have been presented to the S2ESC: Ted Byrne has written a paper discussing
which discusses the motivation behind this effort and provides a proposed working outline for
the combined document. Rob Schaaf has prepared a powerpoint presentation outlining his
approach to this effort.
Carl A. Singer
70 Howard Avenue Passaic, NJ 07055
(973) 472-2531
casinger@optonline.net
3/8/2016
Informal working document – DO NOT DISTRIBUTE BEYOND S2ESC
2 of 3
Ted Byrne’s paper – overview

Motivation for combining the two standards.

Three objectives:
1. Feasibility draft
2. w/i context of SWEBOK & (umbrella) 12207
3. upgrade 830 to full standard, incorporate 12207 addendum and convert from productoriented to process-oriented.

Only appropriate for Software Intensive Systems.

High level generic outline

Four steps for creating “middle standard” to combine 830 & 1233:
1. Decide what parts of 1233 to include
2. Decide how to handle interface between the two standards (not in either)
3. Decide what parts of 830 to include
4. Decide what else to include in the combined standard and where.
Each is then expanded to next level of detail.
Carl A. Singer
70 Howard Avenue Passaic, NJ 07055
(973) 472-2531
casinger@optonline.net
Informal working document – DO NOT DISTRIBUTE BEYOND S2ESC
3/8/2016
Rob Schaaf’s presentation - overview:

Purpose of combined standard
1. Set performance standard for actors in requirements engineering
2. Guide actors in their activities and provide links to other standards
3. Serve as benchmark for assessment of requirements engineering capability

Defines System

Defines Scope and Nature of combined standard

Discusses stakeholders

Detailed “Tutorial” – Needs / Requirements, the “ilities”, derived requirements

Outline for proposed combined standard w/ details of “activities and outcomes”

Process for developing the combined standard:
1. Iterative development from expanded outline
2. Submit change requests to editor for iterations
3. Qualify through extensive review / change requests
4. All via e-mail – no meetings or websites
5. (Rob’s) role as WG co-chair and editor

Time line
Carl A. Singer
70 Howard Avenue Passaic, NJ 07055
(973) 472-2531
casinger@optonline.net
3 of 3