《IEEE-1362-1998-R2007.pdf》由会员分享，可在线阅读，更多相关《IEEE-1362-1998-R2007.pdf（29页珍藏版）》请在三一文库上搜索。
1、i IEEE Std 1362-1998 (R2007) (Incorporates IEEE Std 1362a-1998) IEEE Guide for Information TechnologySystem Definition Concept of Operations (ConOps) Document Sponsor Software Engineering Standards Committee of the IEEE Computer Society Approved 19 March 1998 Reaffirmed 5 December 2007 IEEE-SA Stand
2、ards Board Abstract: The format and contents of a concept of operations (ConOps) document are described. A ConOps is a user-oriented document that describes system characteristics for a proposed system from the users viewpoint. The ConOps document is used to communicate overall quantitative and qual
3、itative system characteristics to the user, buyer, developer, and other organizational elements (for example, training, facilities, staffing, and maintenance). It is used to describe the user organization(s), mission(s), and organizational objectives from an integrated systems point of view. Keyword
4、s: buyer, characteristics, concept of operation, concepts of operations document, ConOps, developer, operational requirements, scenario, software-intensive system, software system, system, user, user requirements, viewpoint The Institute of Electrical and Electronics Engineers, Inc. 345 East 47th St
5、reet, New York, NY 10017-2394, USA Copyright 1998 by the Institute of Electrical and Electronics Engineers, Inc. All rights reserved. Published 31 December 1998. Printed in the United States of America. Print: ISBN 0-7381-0185-2 SH94615 PDF: ISBN 0-7381-1407-3 SS94615 No part of this publication may
6、 be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written per- mission of the publisher. Copyright The Institute of Electrical and Electronics Engineers, Inc. Provided by IHS under license with IEEELicensee=IHS Employees/1111111001, User=Japan, IHS Not for
7、 Resale, 07/30/2008 01:31:28 MDTNo reproduction or networking permitted without license from IHS -,-,- ii IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating Committees of the IEEE Standards Board. Members of the committees serve voluntarily and without co
8、mpensation. They are not necessarily members of the Institute. The standards developed within IEEE represent a consensus of the broad expertise on the subject within the Institute as well as those activities outside of IEEE that have expressed an interest in participating in the development of the s
9、tandard. Use of an IEEE Standard is wholly voluntary. The existence of an IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to the scope of the IEEE Standard. Furthermore, the viewpoint expressed at the
10、time a standard is approved and issued is subject to change brought about through developments in the state of the art and comments received from users of the standard. Every IEEE Standard is subjected to review at least every ve years for revision or reafrmation. When a document is more than ve yea
11、rs old and has not been reafrmed, it is reasonable to conclude that its contents, although still of some value, do not wholly reect the present state of the art. Users are cautioned to check to determine that they have the latest edition of any IEEE Standard. Comments for revision of IEEE Standards
12、are welcome from any interested party, regardless of membership afliation with IEEE. Suggestions for changes in documents should be in the form of a proposed change of text, together with appropriate supporting comments. Interpretations: Occasionally questions may arise regarding the meaning of port
13、ions of standards as they relate to specic applications. When the need for interpretations is brought to the attention of IEEE, the Institute will initiate action to prepare appropriate responses. Since IEEE Standards represent a consensus of all concerned interests, it is important to ensure that a
14、ny interpretation has also received the concurrence of a balance of interests. For this reason, IEEE and the members of its societies and Standards Coordinating Committees are not able to provide an instant response to interpretation requests except in those cases where the matter has previously rec
15、eived formal consideration.Comments on standards and requests for interpretations should be addressed to: Secretary, IEEE Standards Board 445 Hoes LaneP.O. Box 1331 Piscataway, NJ 08855-1331 USA Authorization to photocopy portions of any individual standard for internal or personal use is granted by
16、 the Institute of Electrical and Electronics Engineers, Inc., provided that the appropriate fee is paid to Copyright Clearance Center. To arrange for payment of licensing fee, please contact Copyright Clearance Center, Customer Service, 222 Rosewood Drive, Danvers, MA 01923 USA; (508) 750-8400. Perm
17、ission to photocopy portions of any individual standard for educational classroom use can also be obtained through the Copyright Clearance Center. Note: Attention is called to the possibility that implementation of this standard may require use of subject matter covered by patent rights. By publicat
18、ion of this standard, no position is taken with respect to the existence or validity of any patent rights in connection therewith. The IEEE shall not be responsible for identifying patents for which a license may be required by an IEEE standard or for conducting inquiries into the legal validity or
19、scope of those patents that are brought to its attention. Copyright The Institute of Electrical and Electronics Engineers, Inc. Provided by IHS under license with IEEELicensee=IHS Employees/1111111001, User=Japan, IHS Not for Resale, 07/30/2008 01:31:28 MDTNo reproduction or networking permitted wit
20、hout license from IHS -,-,- iii Introduction This introduction is not a part of IEEE Std 1362-1998, IEEE Guide for Information TechnologySystem DenitionConcept of Operations (ConOps) Document. Purpose This guide presents format and contents of a concept of operations (ConOps) document to be used whe
21、n developing or modifying a software-intensive system. A software-intensive system is a system for which software is a major technical challenge and is perhaps the major factor that affects system schedule, cost, and risk. In the most general case, a software-intensive system is comprised of hardwar
22、e, software, people, and manual procedures. To make this guide more readable, the term system will be used to mean a software-intensive system that includes elements to be developed or modied, in addition to software. The term software system will be used to mean a software-intensive system in which
23、 software is the only component to be developed or modied. This guide does not specify the exact techniques to be used in developing the ConOps document, but it does provide approaches that might be used. Each organization that uses this guide should develop a set of practices and procedures to prov
24、ide detailed guidance for preparing and updating ConOps documents. These detailed practices and procedures should take into account the environmental, organizational, and political factors that inuence application of the guide. The heart of the ConOps described in this guide is contained in Clauses
25、3 through 5. Clause 3 describes the existing system (manual or automated) that the user wants to replace; Clause 4 provides justication for a new or modied system and any restrictions on that system; and Clause 5 describes the proposed system. The outlines for Clause 3 and Clause 5 are almost identi
26、cal. This is not to say that the contents of the nished ConOps document will be identical. On the contrary, the contents should be very different. The outlines are the same to remind developers of the items that should be included and the actions to be taken. Not all software projects are concerned
27、with development of source code for a new software product. Some software projects consist of a feasibility study and denition of product requirements. Other projects terminate upon completion of product design or are only concerned with modications to existing software products. Applicability of th
28、is guide is not limited to projects that develop operational versions of new products, nor is it limited by project size or scope. Small projects may require less formality than large projects, but all components of this guide should be addressed by every software project. The ConOps approach provid
29、es an analysis activity and a document that bridges the gap between the users needs and visions and the developers technical specications. In addition, the ConOps document provides the following: A means of describing a users operational needs without becoming bogged down in detailed technical issue
30、s that shall be addressed during the systems analysis activity. A mechanism for documenting a systems characteristics and the users operational needs in a manner that can be veried by the user without requiring any technical knowledge beyond that required to perform normal job functions. A place for
31、 users to state their desires, visions, and expectations without requiring the provision of quantied, testable specications. For example, the users could express their need for a highly reliable system, and their reasons for that need, without having to produce a testable reliability requirement. In
32、 this case, the users need for high reliability might be stated in quantitative terms by the buyer prior to issuing a request for proposal (RFP), or it might be quantied by the developer during requirements analysis. In any case, it is the job of the buyer and/or the developer to quantify users need
33、s. Copyright The Institute of Electrical and Electronics Engineers, Inc. Provided by IHS under license with IEEELicensee=IHS Employees/1111111001, User=Japan, IHS Not for Resale, 07/30/2008 01:31:28 MDTNo reproduction or networking permitted without license from IHS -,-,- iv A mechanism for users an
34、d buyer(s) to express thoughts and concerns on possible solution strategies. In some cases, design constraints dictate particular approaches. In other cases, there may be a variety of acceptable solution strategies. The ConOps document allows users and buyer(s) to record design constraints, the rati
35、onale for those constraints, and to indicate the range of acceptable solution strategies. Intended uses This guide is intended for use in a variety of situations by a variety of users including the following: Acquirers using ISO/IEC 12207:1995, Information technologySoftware life cycle processes, wi
36、ll nd the current guide suitable for satisfying the requirements of 5.1.1.1: The acquirer begins the acquisition process by describing a concept or a need to acquire, develop, or enhance a system, software product or software service. Users who formerly applied MIL-STD-498, Software Development and
37、Documentation, and related standards will nd that the ConOps document described in this guide is very similar to the operational concept description (OCD) included in MIL-STD-498. Users of EIA/IEEE J-STD-016-1995, EIA/IEEE Interim Trial-Use Standard for Information Technology Software Life Cycle Pro
38、cesses Software Development AcquirerSupplier Agreement will nd that the ConOps document described in this guide is substantively identical to the OCD included in EIA/IEEE J- STD-016-1995. Other users will nd this guide useful in facilitating communication among the various stakeholders in a project.
39、 Software as part of a larger system Software projects are sometimes parts of larger projects. In these cases, the software ConOps document may be a separate document or it may be merged into the system level ConOps document. Overview This guide contains four clauses. Clause 1 denes the scope of thi
40、s guide. Clause 2 provides references to other IEEE standards that should be followed when applying this guide. Clause 3 provides denitions of terms that are used throughout the guide. Clause 4 contains an overview and a detailed specication of the ConOps document, including required components that
41、 should be included, and optional components that may be included in project plans based on this guide. Responsible organization Ideally, the ConOps document should be written by representatives of the user community. In practice, other individuals or organizations may write the ConOps (e.g., the bu
42、yer, a third party consultant, and/or the software developer). In these cases, it is essential that user representatives be involved in reviewing, revising, and approving the ConOps document. The primary goal for a ConOps document is to capture user needs, and to express those needs in the users ter
43、minology. Audience This guide is intended for users and buyers of software systems, software developers, and other personnel who prepare and update operational requirements for software-intensive systems and monitor adherence to those requirements. Copyright The Institute of Electrical and Electroni
44、cs Engineers, Inc. Provided by IHS under license with IEEELicensee=IHS Employees/1111111001, User=Japan, IHS Not for Resale, 07/30/2008 01:31:28 MDTNo reproduction or networking permitted without license from IHS -,-,- v Evolution of plans Developing the initial version of the ConOps document should
45、 be one of the rst activities completed on a software project. As the project evolves, the nature of the work to be done and details of the work will be better understood. The ConOps document should be updated periodically to reect the evolving situation. Thus, each version of the document should be
46、 placed under conguration control. Terminology This guide follows the 1996 edition of the IEEE Standards Style Manual. The terms should, may, might, and suggest are used to indicate actions that should be used to develop a good ConOps document but that are not mandatory. However, the authors of a Co
47、nOps document should consider using all aspects of this guide to insure a complete and effective document. The ConOps document is sometimes called an operational concept document (OCD). History Use of a ConOps document was rst documented in Lano, R. J., A Structured Approach for Operational Concept
48、Formulation, TRW SS-80-02, TRW Defense and Space Systems Group, Redondo Beach, CA, 1980. In 1992 the Software Systems Technical Committee of the American Institute of Aeronautics and Astronautics (AIAA), developed a standard for an OCD. This ConOps guide originated in October 1993, as a Master of Sc
49、ience thesis at California State University, Sacramento, and was supported by the U.S. Ofce of Research and Development. It was accepted as MIL-STD-498, Data Item Description (DID), by the DoD-Std-2167A Harmonizing Working Group with few changes. MIL-STD-498- 1995 became IEEE Std 1498-1995, which was redesignated J-STD-016-1995.