On the Feasibility of Combining Standards 830 and 1233
Introduction
Since the beginning of IEEE Software Engineering standards, some 25 years ago, Standard 830
"Software Requirements Specifications", has been one of the most important. Therefore, the topic
of this study paper seems astonishing, that "There is no such thing as Software Requirements".
The point is that the requirements for a system exist outside of that system, where they specify
functionality, interfaces, environment, reliability and the other "ilities". But software has no
external interface because it is totally within computer hardware and so it cannot interface with the
outside and so cannot have requirements. Only a system can have requirements. However, some of
the system requirements are allocated to and accomplished by software.
How have systems and software designers struggled by with this discrepancy for all this time? The
answer is that it was never a problem and is not a problem today because, in almost all systems, it is
so obvious what gets done in hardware and what gets done in software, that the assignment of
functions is not even mentioned. Nevertheless, an increasing number of systems contain
programmable controllers, so it is not always obvious where software is located.
Motivation
But now the subject of merging the IEEE Standards for Software Requirements, 830, and for
System Requirements, 1233, is on the front burner. That desire to merge seems to be almost
universal. The IEEE Software Engineering Standards Committee has renamed itself the Systems
and Software Engineering Standards Committee. The yearly Software Technology Conference has
become the Systems and Software Technology Conference. And finally, the Software
Requirements section of the Software Engineering Body of Knowledge document (Ref. 1) contains
the claim that it is really addressing System Requirements:
". . . requirements engineering is fundamentally an activity of systems engineering rather
than one that is specific to software engineering. In this respect the term 'software
requirements engineering' is misleading because it implies a narrow scope concerned with
the handling of requirements that have already been acquired and allocated to software
components."
So why is there such an emphasis on change today? That is an interesting question but beyond the
scope of this paper. But, no doubt, it is related to the continuing evolution of the Software Industry.
This study has three objectives:



Create a feasibility draft to demonstrate that standards 830 and 1233 can be combined.
Do this within the context of the SWEBOK and the umbrella standard, 12207.
Include those changes that were specified for the upgrade of 830 itself, namely upgrade it
to full standard, incorporate the previous 12207 addendum, and convert the flavor from
product-oriented to process-oriented.
1

Realize that this treatment is only appropriate for software-intensive systems.
An IEEE Standard has prescribed high level subdivisions roughly as follows:
Generic Outline of a Standard
Abstract (informative)
Keywords (informative)
Introduction (informative)
1. Overview (normative)
2. References (normative)
3. Definitions (normative)
4. Optional Application of Standard (informative or normative)
5, 6, 7 etc. The Meat of the Standard (normative)
. . .
Appendix A. Glossary (informative)
Appendix B. Bibliography (informative)
Appendix C. Examples (informative)
The essential job of this paper is to propose how to handle the middle of the standard, section "5
and following". The informative sections ahead of that are filled in later to agree with the middle
and normative sections 1, 2 and 3 become obvious after the middle is completed. The Appendices
at the end are also optional and follow from the middle information.
There are four steps to creating the middle of the standard so as to merge Standards 830 and 1233:
1. Decide what parts of Standard 1233 should be included and where they should go.
2. Decide how to handle the interface between the present 830 and 1232, which presently is in
neither standard.
3. Decide what parts of Standard 830 should be included and where they should go.
4. Decide whether to include in the standard other topics and, if so, where they should go.
These steps are expanded in the following.
2
Handling Standard 1233
The present outline of Standard 1233 is as follows:
Standard 1233 Outline
1. Overview
1.1. Scope
2. References
3. Definitions
4. Systems Requirements Specifications
4.1. Definition
4.2. Properties
4.3. Purpose
4.4. Intended Use
4.5. Benefits
4.6. Dynamics of System Requirements
5. SyRS Development Process Overview
5.1. Customer
5.2. Environment
5.3. Technical Community
6. Well-formed Requirements
6.1. Definition of a Well-formed Requirement
6.2. Properties of a Requirement
6.3. Categorization
6.4. Pitfalls
7. SyRS Development
7.1. Identify Requirements
7.2. Build a well-formed Requirement
7.3. Organize Requirements
7.4. Present Requirements
A. System Requirements Specification Outline
B. Bibliography
C. Guidelines for Compliance with IEEE/EIA 12207.1-1997
As stated above, sections 1, 2, 3, A, B and C would be considered later. Therefore we need to
examine sections 4, 5, 6 and 7.
Sections 5 and 7 describe the System Requirements process so should certainly be in the combined
standard. Section 4 consists of general considerations, probably informative, and should go in the
front end of the combined standard, for example section 4 in the general outline above. Section 6
gives properties of system requirements and should be in the combined standard. It should not
divide sections 5 and 7, but instead should go after them.
3
Handling the Interface Between Systems and Software Standard Specification
In the SWEBOK this step is described as the allocation or distribution or partitioning of system
requirements to subsystems or components. There it is called "Architectural Design" but I think this
would be an unfortunate title because, in our standards, design is the step after requirements and is
typically performed by the software developer not by the customer who creates the requirements.
Therefore I propose to call it, in this document, "System Requirements Allocation" and therefore it
should be a new section in the combined standard.
Four situations can occur:
 A systems requirement may not lead to a software requirement.
 A systems requirement may, without change, really be a software requirement.
 A systems requirement may map directly into one or more software requirements, in which
case this mapping should be documented.
 A software requirement may have no specific corresponding systems requirement, but
rather derive from good design practice and thus from some general systems characteristic.
All these situations need to be considered in the combined standard.
Handling Standard 830
Standard 830 has already been the subject of a revision process that ended unsuccessfully. The
outline below is of that draft, not the published standard 830. For that reason the outline is given in
somewhat greater detail.
Standard 830 Outline
Abstract
Keywords
Introduction
1. Overview (normative)
2. References (normative)
3. Definitions (normative)
4. Application of this Standard (informative)
Nature of the SRD.
Environment of the SRD.
5. Performing Software Requirements (normative)
5.1. Obtaining or Eliciting Software Requirements Information
5.2. Specifying Software Requirements
5.3. Information that shall not be specified as part of the SRD
Activity
5.4. Correctness of Software Requirements
5.5. Compatibility of Software Requirements
5.6. Improving the Software requirements Activity
6. Typical Arrangement of an SRD (informative)
Supporting Information.
4
Annex A (informative) SRD Templates
Again, the sections up through 3 would go in the front of the combined standard. Section 4 would
go in a combined section 4. Section 6 and the Annex would go in the Appendices.
The correspondence of section 5 of Standard 830 is as follows:
Standard 830
5.1: Obtain & Elicit
5.2: Specifying
5.3: Info not specified
5.4: Correctness
5.5: Compatibility
5.6: Process Improve
Standard 1233
7.1: Process
6.1: Well-formed
6.4: Pitfalls
4.2: Properties
6.2: Properties
after 7.4
Therefore, all of standard 830 merges rather smoothly into corresponding sections of standard
1233. 830 is more detailed than 1233 but that is a good thing.
What Else
The SWEBOK Requirements chapter states several activities as part of requirements:






Requirements Engineering Process: Standard 12207 covers this.
Requirements Elicitation: Covered in this proposal and in Standard 1362.
Requirements Analysis: Correctness and compatibility of requirements are covered in this
proposal.
Requirements Specification: Covered in this proposal.
Requirements Validation: Validation must be treated outside of the standard. Standards
829, 982.1, 1012, 1028, 1074, 1220 and 1471 relate to it.
Requirements Management: Treated in standard 1058.
5
Proposed Combined Standard Outline
Abstract (informative)
Based on both 830 and 1233
Keywords (informative)
Based on both 830 and 1233
Introduction (informative)
Based on both 830 and 1233
1. Overview (normative)
1.1. Scope
Based on both 830 and 1233
1.2. Purpose
Based on both 830 and 1233
1.3. Field of Application
Based on both 830 and 1233
1.4. Conformance
New conformance statement because a full standard.
From 830 section 1.4.
1.5. Disclaimers
Based on both 830 and 1233
2. References (normative)
Based on both 830 and 1233
3. Definitions (normative)
Based on both 830 and 1233
4. Application of this Standard (informative)
Requirements Engineering Process [from SWEBOK]
Process models [from SWEBOK]
Process actors [from SWEBOK]
Process support [from SWEBOK]
Application of the Standard (informative)
Nature of the SRD [from 830 section 4]
Environment of the SRD [from 830 section 4].
Purpose [from 1233 section 4.3]
Intended Use [from 1233 section 4.4]
Benefits [from 1233 section 4.5]
Dynamics of System Requirements [from 1233 section 4.6]
5. System Specification Process
5.1. SyRS Process Overview
Customer [from 1233 section 5.1]
Environment [from 1233 section 5.2]
6
Technical Community [from 1233 section 5.3]
5.2. SyRS Development Process Steps
Identify Requirements [from 1233 section 7.1]
Requirements Specification [from SWEBOK]
Requirements Elicitation [from SWEBOK]
Requirements sources [from SWEBOK]
Elicitation technique [from SWEBOK]
Obtaining or Eliciting Software Requirements Information
[from 830 section 5.1]
Build a well-formed Requirement [from 1233 section 7.2]
Organize Requirements [from 1233 section 7.3]
Present Requirements [from 1233 section 7.4]
5.3. SyRS Process Management
Change management [from SWEBOK]
Improving the Software requirements Activity
[from 830 section 5.6]
Requirements Management [from SWEBOK]
6. System Process Requirements Allocation
Allocation to Software [All new]
Allocation to Hardware [All new]
Allocation to Operations [All new]
7. Requirements attributes [from SWEBOK]
Definition of a well-formed requirement
[from 1233 section 6.1]
Categorization [from 1233 section 6.3]
Requirements definition document [from SWEBOK]
Software requirements specification [from SWEBOK]
document structure [from SWEBOK]
document quality [from SWEBOK]
7.1. Types of Requirements [from 830 section 5.2]
Functionality Requirements
Functionality Requirements
Interface Requirements
Performance Requirements
Product Support Requirements
Qualification Requirements
Design & Implementation Constraint Requirements
Interface Requirements
Performance Requirements
Product Support Requirements
Qualification Requirements
Design & Implementation Constraint Requirements
7.2. Correctness of Software Requirements [from 830 section 5.4]
Clarity (lack of Ambiguity)
Completeness
7
Internal Consistency
Feasibility
Properties [from 1233 section 4.2]
7.3. Compatibility of Software Requirements
[from 830 section 5.5]
Verification
Traceable
Modifiable
Ranked for Importance
Ranked for Stability
Properties [from 1233 section 6.2]
7.4. Requirements Validation [from SWEBOK]
Conduct of requirement reviews [from SWEBOK]
Prototyping [from SWEBOK]
Prototyping [from 830 section 5.1.1]
Model validation [from SWEBOK]
Acceptance tests [from SWEBOK]
7.5 Problems with Specifying Requirements
Requirement tracing [from SWEBOK]
Embedding Design in the SRD. [from 830 section 5.3.1]
Embedding Project Requirements in the SRD.
[from 830 section 5.3.2]
Requirements Analysis [from SWEBOK]
Requirements classification [from SWEBOK]
Conceptual modeling [from SWEBOK]
Requirements negotiation [from SWEBOK]
Annex A Typical Arrangement of an SRD (informative)
[from 830 section 6]
Introduction (Clause 1 of the SRD).
The Overall Description (Clause 2 of the SRD).
Specific Requirements (Clause 3 of the SRD).
SRD Templates
A.1 Template
A.2 Template
A.3 Template
A.4 Template
A.5 Template
A.6 Template
A.7 Template
Hierarchy
A.8 Template
of
of
of
of
of
of
of
SRD
SRD
SRD
SRD
SRD
SRD
SRD
Clause
Clause
Clause
Clause
Clause
Clause
Clause
3
3
3
3
3
3
3
Organized
Organized
Organized
Organized
Organized
Organized
Organized
by
by
by
by
by
by
by
Mode (Version I)
Mode (Version II)
Operator Class
Object
Feature
Stimulus
Functional
of SRD Clause 3 Showing Multiple Organizations
Annex B Glossary (informative)
8
Annex C Bibliography (informative)
----------------------------------
Summary and Conclusions
1. It is certainly possible to combine standards 830 and 1233
2. The primary reason to do this is because there is more emphasis on systems today and less
on software details.
3. Combination requires an additional step, namely mapping system requirements to
subsystem attributes.
4. This is only applicable to software-intensive systems.
5. Regardless of the fact that there would be one standard for systems requirements, including
software, it might still be desirable to create two separate documents.
References
1. Guide to the Software Engineering Body of Knowledge (SWEBOK), available from IEEE
Computer Society
<8301233.doc>
9