IEEE 1362-1998 pdf download IEEE Guide for Information Technology—System Definition— Concept of Operations (ConOps) Document
1.Scope
This guide prescribes the format and contents of the concept of operations (ConOps) document. A ConOps is a user.oriented document that describes system characteristics of the to-be-delivered system from the user’s viewpoint. TheConOps document is used to communicate overall quantitative and qualitative system characteristics to the user, buyerdeveloper, and other organizational elements (e.g.. training, facilities. stafhing. and maintenance). It describes the userorganization(s). mission(s) and organizational objectives from an integrated svstems point of view
This guide may be applied to all types of software-intensive systems: software-only or software/hardware/peoplesystems. The concepts embodied in this guide could also be used for hardware-only systems, but this mode of use isnot addressed herein. The size, scope, complexity, or criticality of the software product does not restrict use of thisguide. This guide is applicable to svstems that will be implemented in all forms of product media, including firmwareembedded systems code, programmable logic arrays, and software-in-silicon. This guide can be applied to any and allsegments of a system life cycle
This guide identifies the minimal set of elements that should appear in all ConOps documents. However, users of thisguide may incorporate other elements by appending additional clauses or subclauses to their ConOps documents. Inany case, the numbering scheme of the required clauses and subclauses should adhere to the format specified in thisguide. Various clauses and subclauses of a ConOps document may be included by direct incorporation or by referenceto other supporting documents.
2. References
This guide shall be used in conjunction with the following publications. In particular, the standards on requirementsand plans should be consulted in preparing the ConOps. When the following standards are superseded by an approvedrevision, the revision shall apply.
IEEE Std 610.12-1990. IEEE Standard Glossary of Software Engineering Terminology.
IEEE Std 828-1998, IEEE Standard for Software ConÞguration Management Plans.
IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements SpeciÞcations.
IEEE Std 1058-1998, IEEE Standard for Software Project Management Plans.
IEEE Std 1058.1-1987 (Reaff 1993), IEEE Standard for Software Project Management Plans.
IEEE Std 1061-1992, IEEE Standard for Software Quality Metrics Methodology.
IEEE 1062, 1998 Edition, IEEE Recommended Practice for Software Acquisition.
IEEE Std 1074-1997, IEEE Standard for Developing Software Life Cycle Processes.
IEEE 1233, 1998 Edition, IEEE Guide for Developing System Requirements SpeciÞcations.
3. Definitions
The definitions listed here establish meanings within the context of this guide. Definitions of other terms that may beappropriate within the context of this guide can be found in IEEE Std 610.12-1990.
3.1 analysis: The process of studying a system by partitioning the system into parts (functions, components, orobjects) and determining how the parts relate to each other.
3.2 buyer: (A) An individual or organization responsible for acquiring a product or service (for example, a softwaresystem) for use by themselves or other users. See also: customer. (B) The person or organization that accepts thesystem and pays for the project.
3.3 concept analysis: The derivation of a system concept through the application of analysis. See also: analysis3.4 concept of operations (Conps) document: A user-oriented document that describes a system’s operationalcharacteristics from the end user’s viewpoint. Synonym: operational concept description (OCD).
3.5 constraint: An externally imposed limitation on system requirements, design, or implementation or on the processused to develop or modify a system.
3.6 contract: In project management, a legally binding document agreed upon by the customer and the hardware oisoftware developer or supplier; includes the technical, organizational, cost, and/or scheduling requirements of aproject.
3.7 customer: (A) An individual or organization who specifies the requirements for and formally accepts delivery ofa new or modified hardware or software product and its documentation; the customer may or may not be the ultimateuser of the system. There are potentially many levels of customers, each with a different level of requirements tosatisfy. The customer may be internal or external to the development organization for the project. See also: user. (B)An individual or organization who acts for the ultimate user of a new or modified hardware or software product toacquire the product and its documentation. See also: buyer.
3.8 developer: An organization that develops software products; developsmay include new developmentmodification. reuse. reengineering, maintenance. or any other activity that results in software products. and includesthe testing, quality assurance, configuration management, and other activities applied to these products. Synonym.supplier
IEEE 1362-1998 pdf download
PS:Thank you for your support!
