Answering questions that may arise related to the meaning of portions of an IEEE standard concerning specific applications.

IEEE Standards Interpretation for IEEE Std 1362™-1998 IEEE Guide for Information Technology—System Definition—Concept of Operations Document

Copyright © 2002 by the Institute of Electrical and Electronics Engineers, Inc., 3 Park Avenue, New York, New York 10016-5997 USA. All Rights Reserved.

This is an interpretation of IEEE Std 1362-1998.

Interpretations are issued to explain and clarify the intent of a standard and do not constitute an alteration to the original standard. In addition, interpretations are not intended to supply consulting information. Permission is hereby granted to download and print one copy of this document. Individuals seeking permission to reproduce and/or distribute this document in its entirety or portions of this document must contact the IEEE Standards Department for the appropriate license. Use of the information contained in this document is at your own risk.

IEEE Standards Department, Copyrights and Permissions, 445 Hoes Lane, Piscataway, New Jersey 08855-1331, USA

November 2002

Interpretation Request #1
Relevant Clause:
4.4.1 and 4.4.2

Subclause 4.4.1 "Justification for changes" states:

"This subclause should:

(a) Briefly summarize new....."

Subclause 4.4.2 "Description of desired changes" states:

"This subclause summarizes new....."

Please further define what "summarize" includes. Should this include all of the detail of the functional requirement as presented by the user? List what level of detail and what document do you recommend to use for presenting the detail information from the user?

Interpretation Response #1
To summarize a document (and in this case a list of requirements from the user) would depend on:
  1. The size of the ConOps
  2. The size of the original document

Therefore, the summary should be less than the original requirements document, (although it still exists for future reference), otherwise it is not a summary. And the summary should be keeping in size with the rest of the document, i.e. it should not dwarf the rest of the ConOps nor should it be small and apparently insufficient.

A set of requirements that is very large and detailed restricts the developer. A set of requirement that is too short might not give the user really what he wants.

But most important: How much detail does the user want to put in the document? The user (or acquirer) has the final say so. It is as big or as small as they want it.