IEEE 1362-1998 en Guide for Information Technology - System Definition - Concept of Operations (ConOps) Document (IEEE Computer Society Document Incorporates IE.pdf

《IEEE 1362-1998 en Guide for Information Technology - System Definition - Concept of Operations (ConOps) Document (IEEE Computer Society Document Incorporates IE.pdf》由会员分享，可在线阅读，更多相关《IEEE 1362-1998 en Guide for Information Technology - System Definition - Concept of Operations (ConOps) Document (IEEE Computer Society Document Incorporates IE.pdf（29页珍藏版）》请在麦多课文档分享上搜索。

1、iIEEE Std 1362-1998 (R2007)(IncorporatesIEEE Std 1362a-1998)IEEE Guide for Information TechnologySystem DefinitionConcept of Operations (ConOps) DocumentSponsorSoftware Engineering Standards Committeeof theIEEE Computer SocietyApproved 19 March 1998Reaffirmed 5 December 2007IEEE-SA Standards BoardAb

2、stract: The format and contents of a concept of operations (ConOps) document are described. AConOps is a user-oriented document that describes system characteristics for a proposed system from theusers viewpoint. The ConOps document is used to communicate overall quantitative and qualitativesystem c

3、haracteristics 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), andorganizational objectives from an integrated systems point of view. Keywords: buyer, characte

4、ristics, concept of operation, concepts of operations document, ConOps,developer, operational requirements, scenario, software-intensive system, software system, system, user,user requirements, viewpointThe Institute of Electrical and Electronics Engineers, Inc.345 East 47th Street, New York, NY 100

5、17-2394, USACopyright 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 SH94615PDF: ISBN 0-7381-1407-3 SS94615No part of this publication may be reproduced in any form,

6、 in an electronic retrieval system or otherwise, without the prior written per-mission of the publisher.iiIEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating Committees ofthe IEEE Standards Board. Members of the committees serve voluntarily and without com

7、pensation. They are notnecessarily members of the Institute. The standards developed within IEEE represent a consensus of the broadexpertise on the subject within the Institute as well as those activities outside of IEEE that have expressed an interestin participating in the development of the stand

8、ard.Use of an IEEE Standard is wholly voluntary. The existence of an IEEE Standard does not imply that there are no otherways to produce, test, measure, purchase, market, or provide other goods and services related to the scope of the IEEEStandard. Furthermore, the viewpoint expressed at the time a

9、standard is approved and issued is subject to changebrought about through developments in the state of the art and comments received from users of the standard. EveryIEEE Standard is subjected to review at least every ve years for revision or reafrmation. When a document is morethan ve years old and

10、 has not been reafrmed, it is reasonable to conclude that its contents, although still of somevalue, do not wholly reect the present state of the art. Users are cautioned to check to determine that they have thelatest edition of any IEEE Standard.Comments for revision of IEEE Standards are welcome f

11、rom any interested party, regardless of membership afliationwith IEEE. Suggestions for changes in documents should be in the form of a proposed change of text, together withappropriate supporting comments.Interpretations: Occasionally questions may arise regarding the meaning of portions of standard

12、s as they relate tospecic applications. When the need for interpretations is brought to the attention of IEEE, the Institute will initiateaction to prepare appropriate responses. Since IEEE Standards represent a consensus of all concerned interests, it isimportant to ensure that any interpretation h

13、as 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 instantresponse to interpretation requests except in those cases where the matter has previously received formalconsidera

14、tion.Comments on standards and requests for interpretations should be addressed to:Secretary, IEEE Standards Board445 Hoes LaneP.O. Box 1331Piscataway, NJ 08855-1331USAAuthorization to photocopy portions of any individual standard for internal or personal use is granted by the Instituteof Electrical

15、 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 RosewoodDrive, Danvers, MA 01923 USA; (508) 750-8400. Permission to photocopy portions o

16、f any individual standard foreducational 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 mattercovered by patent rights. By publication of this standard, no position

17、 is taken with respect to the existence orvalidity of any patent rights in connection therewith. The IEEE shall not be responsible for identifying patents forwhich a license may be required by an IEEE standard or for conducting inquiries into the legal validity or scopeof those patents that are brou

18、ght to its attention.iiiIntroductionThis introduction is not a part of IEEE Std 1362-1998, IEEE Guide for Information TechnologySystem DenitionConcept ofOperations (ConOps) Document.PurposeThis guide presents format and contents of a concept of operations (ConOps) document to be used when developing

19、 ormodifying a software-intensive system. A software-intensive system is a system for which software is a majortechnical challenge and is perhaps the major factor that affects system schedule, cost, and risk. In the most generalcase, a software-intensive system is comprised of hardware, software, pe

20、ople, and manual procedures. To make thisguide more readable, the term system will be used to mean a software-intensive system that includes elements to bedeveloped or modied, in addition to software. The term software system will be used to mean a software-intensivesystem in which software is the o

21、nly 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 provideapproaches that might be used. Each organization that uses this guide should develop a set of practices and proceduresto provide detailed guidance

22、 for preparing and updating ConOps documents. These detailed practices and proceduresshould 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 3 through 5.Clause 3 de

23、scribes 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; andClause 5 describes the proposed system.The outlines for Clause 3 and Clause 5 are almost identical. This is not to say tha

24、t the contents of the nished ConOpsdocument will be identical. On the contrary, the contents should be very different. The outlines are the same to reminddevelopers of the items that should be included and the actions to be taken.Not all software projects are concerned with development of source cod

25、e for a new software product. Some softwareprojects consist of a feasibility study and denition of product requirements. Other projects terminate upon completionof product design or are only concerned with modications to existing software products. Applicability of this guideis not limited to projec

26、ts 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 byevery software project.The ConOps approach provides an analysis activity and a docume

27、nt that bridges the gap between the users needs andvisions 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 issuesthat shall be addressed during the sy

28、stems analysis activity.A mechanism for documenting a systems characteristics and the users operational needs in a manner thatcan be veried by the user without requiring any technical knowledge beyond that required to perform normaljob functions.A place for users to state their desires, visions, and

29、 expectations without requiring the provision of quantied,testable specications. For example, the users could express their need for a highly reliable system, andtheir reasons for that need, without having to produce a testable reliability requirement. In this case, theusers need for high reliabilit

30、y might be stated in quantitative terms by the buyer prior to issuing a requestfor proposal (RFP), or it might be quantied by the developer during requirements analysis. In any case, it isthe job of the buyer and/or the developer to quantify users needs.ivA mechanism for users and buyer(s) to expres

31、s thoughts and concerns on possible solution strategies. In somecases, design constraints dictate particular approaches. In other cases, there may be a variety of acceptablesolution strategies. The ConOps document allows users and buyer(s) to record design constraints, therationale for those constra

32、ints, and to indicate the range of acceptable solution strategies.Intended usesThis 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, will nd thecurrent guide sui

33、table 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, orenhance a system, software product or software service.Users who formerly applied MIL-STD-498, Software Development and Documentation, and relatedstan

34、dards will nd that the ConOps document described in this guide is very similar to the operationalconcept description (OCD) included in MIL-STD-498.Users of EIA/IEEE J-STD-016-1995, EIA/IEEE Interim Trial-Use Standard for Information TechnologySoftware Life Cycle Processes Software Development Acquir

35、erSupplier Agreement will nd that theConOps 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 aproject.Software as part of a larger systemSof

36、tware projects are sometimes parts of larger projects. In these cases, the software ConOps document may be aseparate document or it may be merged into the system level ConOps document.OverviewThis guide contains four clauses. Clause 1 denes the scope of this guide. Clause 2 provides references to ot

37、her IEEEstandards that should be followed when applying this guide. Clause 3 provides denitions of terms that are usedthroughout the guide. Clause 4 contains an overview and a detailed specication of the ConOps document, includingrequired components that should be included, and optional components t

38、hat may be included in project plans based onthis guide.Responsible organizationIdeally, the ConOps document should be written by representatives of the user community. In practice, otherindividuals or organizations may write the ConOps (e.g., the buyer, a third party consultant, and/or the software

39、developer). In these cases, it is essential that user representatives be involved in reviewing, revising, and approving theConOps document. The primary goal for a ConOps document is to capture user needs, and to express those needs inthe users terminology.AudienceThis guide is intended for users and

40、 buyers of software systems, software developers, and other personnel who prepareand update operational requirements for software-intensive systems and monitor adherence to those requirements.vEvolution of plansDeveloping the initial version of the ConOps document should be one of the rst activities

41、 completed on a softwareproject. As the project evolves, the nature of the work to be done and details of the work will be better understood. TheConOps document should be updated periodically to reect the evolving situation. Thus, each version of the documentshould be placed under conguration contro

42、l.TerminologyThis guide follows the 1996 edition of the IEEE Standards Style Manual. The terms should, may, might,and suggestare used to indicate actions that should be used to develop a good ConOps document but that are not mandatory.However, the authors of a ConOps document should consider using a

43、ll aspects of this guide to insure a complete andeffective document.The ConOps document is sometimes called an operational concept document (OCD).HistoryUse of a ConOps document was rst documented in Lano, R. J., A Structured Approach for Operational ConceptFormulation, TRW SS-80-02, TRW Defense and

44、 Space Systems Group, Redondo Beach, CA, 1980. In 1992 theSoftware Systems Technical Committee of the American Institute of Aeronautics and Astronautics (AIAA), developeda standard for an OCD. This ConOps guide originated in October 1993, as a Master of Science thesis at California State University,

45、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. The IEEE Standar

46、ds Board approved the project authorization request (PAR) for development of this guide inJune 1993. The rst draft was submitted to the Software Engineering Standards Committee (SESC) on 8 August 1995;it was returned on 1 November 1995 with a request that the guide be harmonized with certain other s

47、pecied softwareengineering standards. The second draft was submitted to the SESC on 28 February 1996. This draft was balloted on21 August 1996. ParticipantsThis guide was written by the IEEE Guide for a Concept of Operations Document Working Group, which is part of theIEEE Computer Society. The foll

48、owing three individuals are the authors of this guide:Richard H. ThayerRichard E. FairleyPer BjorkeOther individuals who supported the development of this guide are:Jed BartlettBoris I. CoganMerlin DorfmanRajko MilovanovicRandy PaulJane RadatzThe following persons were on the balloting committee:Mik

49、hail Auguston Robert E. BarryMordechai Ben-MenachemPeter A. BerggrenH. Ronald BerlackAudrey C. BrewerAlan L. BridgesKathleen L. BriggsThomas G. CallaghanviStuart Ross CampbellLeslie ChambersKeith ChanJohn P. ChihorekS. V. ChiyyarathAntonio M. CicuTheo ClarkeDarrell CookseyW. W. Geoff CozensGregory T. DaichHillary DavidsonNeil DavisBostjan K. DergancMichael P. DeWaltDave DikelCharles DrozJohn W. FendrichJulian ForsterEva FreundJuan Garbajosa-SopenaJulio Gonzalez-SanzL. M. GuntherJohn HarauzRob HarkerWilliam HefleyMa