J-STD-016-1998 30 September 1995Trial Use Standard Standard for Information Technology Software Life Cycle Processes Software Development Key Words: Builds/incremental development Database Joint Technical/management reviews Operational concept Reusable software Risk management Security/privacy protection Software Software configuration management Software development Software documentation Software implementation Software management indicators Software product evaluation Software quality assurance Software requirements definition Software safety Software maintenance Software testing Software unit Tailoring Prepared by a Joint IEEE / EIA Working Group This is a joint IEEE/EIA Standards Project, subject to change. Permission is hereby granted for IEEE/EIA Standards Committee participants to reproduce this document for purposes of IEEE/EIA standardization activities, including balloting and coordination. If this document is to be submitted to ISO or IEC, notification shall be given to the IEEE/EIA. Permission is also granted for member bodies and technical committees of ISO and IEC to reproduce this document for the purpose of developing an international position. Other entities seeking permission to reproduce portions of this document for these and other uses must contact the IEEE or EIA. Use of the unapproved draft is at your own risk. Institute of Electrical and Electronic Engineers, Inc. 345 East 47th Street New York, NY 10017, USA Copyright © 1995. All rights reserved. Electronic Industries Association 2500 Wilson Blvd. Arlington, VA 22201-3834 Notice EIA Engineering Standards and Publications are designed to serve the public interest through eliminating misunderstandings between manufacturers and purchasers, facilitating interchangeability and improvement of products, and assisting the purchaser in selecting and obtaining with minimum delay the proper product for his particular need. Existence of such Standards and Publications shall not in any respect preclude any member or nonmember of EIA from manufacturing or selling products not conforming to such Standards and Publications, nor shall the existence of such Standards and Publications preclude their voluntary use by those other than EIA members, whether the standard is to be used either domestically or internationally. Recommended Standards and Publications are adopted by EIA in accordance with the American National Standards Institute (ANSI) patent policy. By such action, EIA does not assume any liability to any patent owner, nor does it assume any obligation whatever to parties adopting the Recommended Standard or Publication. This standard is based upon the major technical content of ISO/IEC 12207 Information Technology Software Life Cycle Process, 22 February 1995, for the software development process. It conforms in all essential respects with this process of the ISO/IEC Standard. This publication is not intended to preclude or discourage other approaches that similarly represent good engineering practice, or that may be acceptable to, or have been accepted by, appropriate bodies. Parties who wish to bring other approaches to the attention of the formulating committee to be considered for inclusion in future revisions of the Publication are encouraged to do so. It is the intention of the formulating committee to revise and update this Publication from time to time as may be occasioned by changes in technology, industry practice, or government regulations, or for other appropriate reasons. (Developed by the Joint EIA/IEEE Working Group on Software Development.) Published by ©ELECTRONIC INDUSTRIES ASSOCIATION 1995 Engineering Department 2500 Wilson Boulevard Arlington, VA 22201 PRICE: Please refer to the current Catalog of EIA, IEEE, JEDEC, and TIA STANDARDS and ENGINEERING PUBLICATIONS or call Global Engineering Documents, USA and Canada (1-800-854-7179) International (303-397-7956) All Rights Reserved Printed in U.S.A. J-STD-016-1998 Contents CLAUSE PAGE Annex A..........................................................................................................................................................................................................36 Tailoring this standard for a project..............................................................................................................................................36 A.1 Scope.............................................................................................................................................................................................36 A.2 Tailoring process....................................................................................................................................................................36 A.3 Identifying the project environment............................................................................................................................36 A.4 Soliciting input.........................................................................................................................................................................36 A.5 Selecting processes, activities, and tasks................................................................................................................36 A.6 Specifying tailoring decisions.........................................................................................................................................37 Annex B..........................................................................................................................................................................................................38 B.1 Scope.............................................................................................................................................................................................38 B.2 Candidate development strategies..............................................................................................................................38 B.3 Selecting an appropriate development strategy..................................................................................................39 B.4 Relationship of this standard to development strategies.................................................................................39 B.5 Planning software builds and tailoring this standard.........................................................................................39 B.5.1 Identifying builds and their objectives...................................................................................................39 B.5.2 Identifying the activities to be performed in each build................................................................48 B.5.3 Recording tailoring decisions.....................................................................................................................48 B.5.4 Scheduling the selected activities in each build...............................................................................48 Annex C.........................................................................................................................................................................................................50 Guidance on ordering deliverables...............................................................................................................................................50 C.1 Scope.............................................................................................................................................................................................50 C.2 Ordering deliverables..........................................................................................................................................................50 C.3 Scheduling deliverables....................................................................................................................................................50 C.4 Format of deliverables.........................................................................................................................................................50 C.5 Tailoring the content requirements for deliverables...........................................................................................51 Annex D..........................................................................................................................................................................................................52 Interpreting this standard for incorporation of reusable software products..........................................................52 D.1 Scope.............................................................................................................................................................................................52 D.2 Evaluating reusable software products......................................................................................................................52 D.3 Interpreting this standard's activities for reusable software products....................................................52 Annex E..........................................................................................................................................................................................................56 -i- J-STD-016-1998 Planning software product descriptions....................................................................................................................................56 E.1 Scope..............................................................................................................................................................................................56 E.2 Software products covered................................................................................................................................................56 E.2.1 Contents of the Software Development Plan (SDP)..............................................................................57 E.2.2 Contents of the Software Test Plan (STP).................................................................................................69 E.2.4 Contents of the Software Transition Plan (STrP)...................................................................................79 Annex F...........................................................................................................................................................................................................84 Concept and requirements software product descriptions..............................................................................................84 F.1 Scope..............................................................................................................................................................................................84 F.2 Software products covered................................................................................................................................................84 F.2.1 Contents of the Operational Concept Description (OCD)..................................................................85 F.2.2 Contents of the System/Subsystem Specification (SSS)................................................................90 F.2.3 Contents of the Interface Requirements Specification (IRS).......................................................99 F.2.4 Contents of the Software Requirements Specification (SRS).....................................................104 Annex G........................................................................................................................................................................................................113 Design software product descriptions.......................................................................................................................................113 G.1 Scope............................................................................................................................................................................................113 G.2 Software products covered..............................................................................................................................................113 G.2.1 Contents of the System/Subsystem Design Description (SSDD)...............................................114 G.2.2 Contents of the Interface Design Description (IDD).........................................................................121 G.2.3 Contents of the Database Design Description (DBDD)...................................................................126 G.2.4 Contents of the Software Design Description (SDD).......................................................................133 Annex H........................................................................................................................................................................................................141 Qualification testing software product descriptions..........................................................................................................141 H.1 Scope............................................................................................................................................................................................141 H.2 Software products covered..............................................................................................................................................141 H.2.1 Contents of the Software Test Description (STD)...............................................................................142 H.2.2 Contents of the Software Test Report (STR).........................................................................................148 Annex I.........................................................................................................................................................................................................152 Maintenance software product descriptions.........................................................................................................................152 I.1 Scope.............................................................................................................................................................................................152 I.2 Software products covered...............................................................................................................................................152 I.2.1 Contents of the Software Product Specification (SPS).....................................................................153 I.2.2 Contents of the Software Version Description (SVD)........................................................................157 I.2.3 Contents of the Computer Programming Manual (CPM)................................................................160 I.2.4 Contents of the Firmware Support Manual (FSM)...............................................................................163 -ii- J-STD-016-1998 Annex J.........................................................................................................................................................................................................166 User/operator software product descriptions......................................................................................................................166 J.1 Scope............................................................................................................................................................................................166 J.2 Software products covered..............................................................................................................................................166 J.2.1 Contents of the Software User Manual (SUM)........................................................................................167 J.2.2 Contents of the Software Input/Output Manual (SIOM)....................................................................172 J.2.3 Contents of the Software Center Operator Manual (SCOM)..........................................................180 J.2.4 Contents of the Computer Operation Manual (COM).........................................................................185 Annex K........................................................................................................................................................................................................188 Software product description format and structure...........................................................................................................188 K.1 Scope...........................................................................................................................................................................................188 K.2 Software products covered..............................................................................................................................................188 K.3 Format and structure for all software products....................................................................................................188 K.3.1 Structure................................................................................................................................................................188 K.3.2 Format.....................................................................................................................................................................188 K.3.3 Title page or identifier...................................................................................................................................192 K.3.4 Table of contents and index........................................................................................................................192 K.3.5 Page numbering/labeling............................................................................................................................192 K.3.6 Response to tailoring instructions..........................................................................................................192 K.3.7 Multiple clauses and their subordinates.............................................................................................192 K.3.8 Alternative presentation styles................................................................................................................192 K.3.9 Substitution of existing documents........................................................................................................192 K.3.10 Standard data descriptions......................................................................................................................193 K.3.11 Applicability of required contents.........................................................................................................193 Software product evaluations.........................................................................................................................................................194 L.1 Scope............................................................................................................................................................................................194 L.2 Required evaluations..........................................................................................................................................................194 L.3 Criteria definitions...............................................................................................................................................................194 L.3.1 Accurately describes (an item)...................................................................................................................194 L.3.2 Adequate test cases, procedures, data, results.................................................................................199 L.3.3 Consistent with indicated product(s)....................................................................................................199 L.3.4 Contains all applicable information in (a specified annex)........................................................199 L.3.5 Covers (a given set of items).......................................................................................................................199 L.3.6 Feasible..................................................................................................................................................................199 L.3.7 Follows Software Development Plan........................................................................................................199 L.3.8 Internally consistent......................................................................................................................................200 L.3.9 Meets delivery requirements, if applicable.......................................................................................200 L.3.10 Meets SOW, if applicable............................................................................................................................200 L.3.11 Presents a sound approach.......................................................................................................................200 L.3.12 Shows evidence that (an item under test) meets its requirements.....................................200 L.3.13 Testable...............................................................................................................................................................200 L.3.14 Understandable...............................................................................................................................................200 -iii- J-STD-016-1998 Annex M......................................................................................................................................................................................................201 Category and priority classifications for problem reporting.........................................................................................201 M.1 Scope..........................................................................................................................................................................................201 M.2 Classification by category..............................................................................................................................................201 M.3 Classification by priority.................................................................................................................................................201 Annex N.......................................................................................................................................................................................................203 Candidate joint management reviews......................................................................................................................................203 N.1 Scope..........................................................................................................................................................................................203 N.2 Assumptions...........................................................................................................................................................................203 N.3 Candidate reviews..............................................................................................................................................................203 N.3.1 Software plan reviews...................................................................................................................................203 N.3.2 Operational concept reviews....................................................................................................................203 N.3.3 System/subsystem requirements reviews.......................................................................................203 N.3.4 System/subsystem design reviews.......................................................................................................204 N.3.5 Software requirements reviews...............................................................................................................204 N.3.6 Software design reviews..............................................................................................................................204 N.3.7 Test readiness reviews.................................................................................................................................204 N.3.8 Test results reviews.......................................................................................................................................204 N.3.9 Software usability reviews.........................................................................................................................204 N.3.10 Software maintenance reviews.............................................................................................................205 N.3.11 Critical requirement reviews...................................................................................................................205 Annex O.......................................................................................................................................................................................................206 Candidate management indicators............................................................................................................................................206 O.1 Scope..........................................................................................................................................................................................206 O.2 Candidate indicators.........................................................................................................................................................206 Annex P........................................................................................................................................................................................................207 Questionnaire on use of this standard.......................................................................................................................................207 Index........................................................................................................................................... 207 -iv- J-STD-016-1998 Contents (continued) FIGURES 1 2 3 4 5 6 7 8 9 10 11 12 13 One possible mapping of this standard's activities to multiple builds.......................... 15 Key features of three development strategies............................................................. 39 Sample risk analysis for determining the appropriate development strategy.............. 41 One possible way of applying this standard to the Once-Through development strategy.................................................................................................. 42 One possible way of applying this standard to the Incremental development strategy................................................................................................. 43 One possible way of applying this standard to the Evolutionary development strategy................................................................................................. 44 One possible way of applying this standard to a reengineering project....................... 45 Example of build planning........................................................................................... 47 Interpreting this standard for incorporation of reusable software................................ 52 Overview of software products................................................................................... 187 Software products and associated evaluation criteria................................................ 193 Categories to be used for classifying problems in software products......................... 200 Priorities to be used for classifying problems............................................................. 200 -v- J-STD-016-1998 Foreword 1. This standard defines a set of software development activities and resulting software products. It provides a framework for software development planning and engineering. 2. This standard is written in contractual language. However, it is not intended for contractual use, but rather, for voluntary adoption by an organization in establishing its software development process. 3. This standard addresses only the development process of IEEE/EIA 12207, Software Life Cycle Processes. IEEE/EIA 12207 addresses the complete software life cycle, including acquisition, supply, development, operation, and maintenance, as well as supporting and organizational processes. Organizations adopting this standard should have a long range goal of compliance with IEEE/EIA 12207. Those activities of the maintainer that are the same as those of a developer are covered in this standard. For purposes of this implementation, the "supplier" of ISO/IEC 12207 is always the "developer," and the term "developer" is used throughout this standard. 4. This standard is meant to be tailored to ensure that only necessary and cost-effective requirements are applied. It is not intended to specify or discourage the use of any particular software development method. The developer is responsible both for tailoring the standard for use within the developer’s organization and for selecting software development methods that support the achievement of organizational requirements. 5. This standard emphasizes that information resulting from the activities required by this standard is intrinsic to the software development process, to be recorded regardless of whether a deliverable is required. When information is not required to be delivered, the software products cited in this standard are to be used as checklists of items to be covered, as applicable, in the planning and engineering activities for the project. 6. This standard allows information to be recorded in representations other than traditional documents (for example, computer-aided software engineering (CASE) tools) and provides relaxed requirements for the format and structure of that information for such representations. 7. This version of the standard contains a new annex, Annex Q, that addresses changes to the body of the standard that have been made to underscore proper application of the standard through voluntary adoption rather than contractual imposition and to place focus on the organizational context of the development process. -vi- sufficient for a large. incremental. It establishes uniform requirements for developing. It is meant to be applicable regardless of the language used. by the organization adopting the standard. etc. It is applicable to software development activities in the context of a software life cycle. the standard requires the developer to perform architectural design.A distinction is made between the task of generating and recording planning or engineering information and the task of generating a deliverable containing that information. complex project. The standard provides flexibility regarding documentation: . the software portion of firmware. not how to do it. modifying. Instead. reusable software. . It can be applied to any type of software. such as reliability. spiral. The activities in the standard form a comprehensive set. The standard does not specify or depend on any design or programming language. This emphasis on required performance can allow a developer to provide quality products at reduced costs when unique product solutions are not required. It is independent of any particular methodology. tasks. and products for a software development project. and software employed to develop deliverable software.). or reusability.Information and deliverables can be in hardcopy form (using contractor or software product format) or in computer-aided software engineering (CASE) tools. The standard provides a performance-based distinction between requirements for a product and design of a product. The standard is intended to be adopted voluntarily be an organization and is not intended to be used within contractually between two parties. The standard is intended to be responsive to the rapidly evolving software discipline. or the development activities associated with a software maintenance project. ensuring the acquirer's right to specify the product and the developer's right to be technologically creative and innovative. and documenting software.J-STD-016-1998 Introduction J-STD-016-1998 is a standard for the software development process. evolutionary. but does not require use of the object-oriented design method. It defines standard terminology and establishes activities. operating system software. The standard does not specify or encourage any software life cycle model (waterfall. including application software. This choice is left to each project. For example. the standard provides the building blocks needed to create a life-cycle model for a software project. maintainability. as needed for each project. The standard does not emphasize any particular software quality factor. The standard is meant to be tailored. - - -vii- . A requirement is a characteristic that a system or software item is required to possess in order to be acceptable to the acquirer while design is a characteristic that the acquirer is willing to leave up to the developer. In particular: The activities and tasks in the standard tell what to do. J-STD-016-1998: a) Is usable with any development strategy. J-STD-016-1998 has enhanced software supportability requirements. 3) acknowledges data in CASE tools as a substitute for traditional documents. To improve compatibility with object-oriented and other methods not using functional decomposition. and 4) provides guidance to prevent unnecessary deliverables. It is structured to avoid time-oriented dependencies and implications. The standard: 1) separates planning and engineering activities from preparation of deliverables to make it easier to call for one without the other. J-STD-016-1998 allows the developer to define in the software development plan the design and implementation structures to be used. It has incorporated a requirement to identify and apply such indicators. It provides a role for the software developer both in the case of a hardware-software system and where the software (possibly with the computers on which it will run) is considered to constitute the system. evolutionary. and to use that structure in the documentation. -viii- . such as CASE tools. the standard: 1) identifies criteria for use in evaluating reusable software. 2) provides language that permits the recording of project information in forms other than traditional documents. J-STD-016-1998 recognizes that many projects incorporate or are based on reusable software. d) Provides requirements for software reuse. J-STD-016-1998 recognizes that software exists in the context of a system. Examples are requirements to: 1) record the rationale for key decisions made on the project. and 3) demonstrate that those resources are sufficient to maintain the software. e) Supports the use of software management indicators. f) Emphasizes software supportability. and 2) provides guidance on interpreting J-STD-016-1998's activities and deliverables when applied to reusable software. J-STD-016-1998 has been structured to better accommodate incremental. and explains how to apply the standard across multiple builds or iterations. and other development models than the traditional "waterfall" model. g) Provides a role for software in the system. 2) identify all resources the maintenance organization will need to maintain the software. provides alternatives to formal reviews (that can force a waterfall development model). J-STD-016-1998 supports the use of software management indicators. and included an annex of candidate indicators that might be used.J-STD-016-1998 J-STD-016-1998 specifically removes key problems found in the use of predecessor standards. c) Is compatible with CASE tools. To provide clearer requirements when this is the case. J-STD-016-1998 recognizes that much of the significant work on a software development project does not involve writing documents. b) Is usable with any development methods. Phippen Larry Reed Dennis Rilling Keith Shewbridge Katsutoshi Shintani Carl A. Carl Theo Clarke Jack Cooper Paul Cooley Rita Costello Kenneth Costello Geoff Cozens Gregory Daich Neil Davis Chris Denham Bostjan K. EIA Co-chair Stuart Campbell John Chihorek Richard Evans Lewis Gray Robert Hegland Jim Heil Raghu Singh. D.J-STD-016-1998 Participants At the time this trial use standard was completed. Derganc Dave Dikel Treasure Diehl Peter Eirich Bob Elston SueEllen Eslinger Eva Freund William Gess Gregg Glesler Lawrence Gunther Ranwa Haddad John Hamlin Nancy Hannon John Harauz Carl Hirshfield John Horch Stephen Huffman George Jackelen Allan Jaworski Diana Kang Ron Kenett Judy Kerner John Kerr Larry Klos Rick Kreke Dorothy Kuckuck Jerome Lake Dennis Lawrence Jim Longbucco Joan Lovelace Stan Magee John Marshall Judy McCloskey P. Szymanski Booker T. Ourada Mark Paulk Sherry Paquin John G. IEEE Co-chair Myrna Olson Al Peschel Alex Polack Norma Stopyra Leonard Tripp Helmut Hummel Tim Janes Capt Jonathan Liles Marv Lubofsky David Maibor James Moore Other individuals who have contributed review and comments are the following: Dennis Ahern Mordechai Ben-Menachim Dave Benson Ron Berlack William J. Thomas Patricia Trellue Ann Turner Dennis Turner Theodore Urbanowicz Howard Vern Delores Wallace Steven Wang Scott Whitmire Charles Wilson Audrey Winston Paul Wolfgang Paul Work Grady Wright Gene Yancy Natalie Yopconka Geraldine Zimmerman Peter Zoll Robert Harley Rick Hefner Peter Poon Lawrence Przybylski Ken Ptack Jane Radatz -ix- . Boll John Bowers Don Calvert Andrew Campbell Jaya R. Singer Melford E. McCray Jack McGarry Archibald McKinley Celia Modell Dennis Nickle Bart Nigro James Orr Gerald L. the Joint Industry Working Group on Software Development had the following membership: Perry DeWeese. Smyre Don Sova Richard Storch Richard Summers David J. reengineering. 1. and "maintenance organization" for the organization that will have responsibility for modifying and otherwise maintaining the software after transition from the development organization.1 Candidate uses This standard can be: a) Included or referenced in contracts or similar agreements. and all other processes or activities resulting in software products. reuse.2. It is also intended to merge commercial and Government software development requirements within the framework of the software life cycle process requirements of the Electronic Industries Association (EIA). The term "software development" is used as an inclusive term encompassing new development.1 Candidate uses.J-STD-016-1998 1. to systems consisting of software alone. and to stand-alone software products.1 Purpose This standard establishes uniform requirements for software development activities and resulting software products. "subcontractor" for any organization tasked by the developer to perform part of the required effort. "contract" for the agreement between these parties.1 Purpose.2. "user" for the persons or organizations that will operate and/or use the software. the term "acquirer" is used for the organization requiring the technical effort.2 Organizations and agreements. Institute of Electrical and Electronics Engineers (IEEE). "Statement of Work" (SOW) for the list of tasks to be performed by the developer. Scope 1. -x- . subcontractors.2.2. maintenance. or in-house organizations performing software development. with the parties (called the acquirer and the developer) agreeing that the developer will perform software development in accordance with the standard b) Adopted as an in-house standard by a project or organization that decides to perform software development in accordance with the standard c) Used as the basis for an organization's software development process 1. "developer" for the organization performing the technical effort. 1.2 Application. Scope. This standard is intended to be applied as follows. modification.2 Application The requirements in this standard are intended for application to the development of systems that contain software (such as software embedded in hardware-software systems). and International Organization for Standardization (ISO). For uniformity.2 Organizations and agreements This standard can be applied to contractors. 1 Compliance with the "as tailored" standard Compliance with the "as tailored" standard is defined as: a. The acquirer is expected to specify the types of software to which the standard applies.2.4 In-house application When this standard is used to assist an organization in defining and establishing its software development process. Examples of types of software include deliverable versus non-deliverable.2. The tailoring requirements of this standard are normative (that is. Tailoring guidance can be found in annexes B and C.2. Recording applicable information resulting from the performance of the selected activities .2. 1. Tailoring requirements. This standard does not apply to the hardware element of firmware. When the standard is applied on an in-house development project. Performing the activities that resulted from tailoring this standard for a specific project as recorded in the contract b. Care is to be taken to eliminate tasks and data that add unnecessary costs or that do not add value to the activity or the product for the project. alteration of requirements to more explicitly reflect the application to a particular effort.2.6. binding) to be performed in accordance with this standard. or addition of requirements as needed.J-STD-016-1998 Page 1 1. 1. regardless of storage medium.2.4 In-house application. it is intended to be used as a source for selecting software development activities and products to satisfy specific project needs. 1. it is intended for reference as a source of recommended software development activities and products on which to build specific organizational practices and procedures.3 Contract-specific application When this standard is invoked in a contract.5 Tailoring This standard is meant to be tailored for each type of software to which it is applied. or contractual structure. and software designed to meet one user need versus software designed to meet another. Software installed in firmware is subject to all of the aforementioned provisions.6 Compliance Compliance with this standard means "compliance with the standard as tailored for the project and recorded in the contract." NOTE--Regulatory and legal requirements are invoked separately through the contract.2.3 Contract-specific application. The standard is to be tailored to the specific requirements of a particular program.6. tailoring may be performed jointly with prospective or selected developers. 1. are not subject to tailoring. to the extent specified in the contract. While final tailoring decisions are the responsibility of the acquirer. specified in annex A.2.2. it applies to each software product and to each type of software covered by the contract. program phase.1 Compliance with the "as tailored" standard. Tailoring takes the form of deletion of unnecessary requirements.6 Compliance. software designed to meet user needs versus software in the engineering and test environments.5 Tailoring. All other requirements of this standard are considered tailorable.2. but clarifications of their use. have been accomplished and applicable information has been recorded. reengineering.7. If a contract is based on alternatives to systems and subsystems. a payroll system) for which this standard governs overall development. but the hardware is not.2. company." "define.2.2.2.2. person." etc.7 Interpretation of selected terms.2 Interpretation of "participate" in system development The term "participate" in subclauses regarding system-level activities is to be interpreted as follows: if the software covered by this standard is part of a hardware-software system. as specified in the contract. Throughout this standard.7. a radar system) for which this standard covers only the software portion. industrial association." "establish.1 Interpretation of "system" The following interpretations apply: a) The term "system. reuse.7. as described in the Software Development Plan.3 Compliance stipulation Any entity (such as." "define.2 Activity completion criteria. the term "participate" is to be interpreted as "be responsible for." as used in this standard. b) If a system consists of subsystems.6." or "identify" information are to be interpreted to include new development. 1.2. 1. may mean: (1) a hardware-software system (for example.2. the term "participate" may also be interpreted as "be responsible for.3 Interpretation of "develop. 1.6. organization) imposing this standard as a condition of trade is responsible for identifying and making public the minimum set of activities and resulting software products that is required to be fulfilled by a developer.7 Interpretation of selected terms The following terms have a special interpretation as used in this standard. These are not ." "define." 1. or (2) a software system (for example.7. the requirements in this standard concerning the system and its specification apply to these alternatives and their specifications.J-STD-016-1998 Page 2 1.2 Interpretation of "participate" in system development.2.7.6." etc.2.3 Compliance stipulation.3 Interpretation of "develop. 1." If the software in a hardware-software system is changed.2. requirements to "develop.2. modification. all requirements in this standard concerning systems apply to the subsystems as well.1 Interpretation of "system".2. "definitions" of the terms. the term "participate" is to be interpreted as "take part in. Military Service. maintenance..6.2 Activity completion criteria An activity is complete when all items constituting the activity.7. or any other activity or combination of activities resulting in software products." If the software (possibly with its computers) is considered to constitute a system. J-STD-016-1998 Page 3 1. including.2.2.4 Interpretation of "record" Throughout this standard." The result may take many forms.7.7. requirements to provide "applicable" information and perform "applicable" activities are to be interpreted to mean "provide the information and perform the activities that are natural by-products created by performing the activities required for the project in accordance with the tools. "Applicability" is to be agreed upon jointly by the acquirer and developer. requirements to "record" information are to be interpreted to mean "set down in a manner that can be retrieved and viewed.7. and data recorded in computer-aided software engineering (CASE) and project management tools. hand-written notes. methods. 1.7.2.5 Interpretation of "applicable" Throughout this standard. but not limited to.4 Interpretation of "record"." The term "applicable" conveys the meaning that not all projects will generate the information or require the activity.5 Interpretation of "applicable". hard-copy or electronic documents. . and procedures described in the software development plan.2. Glossary for Computer Systems Security IEEE Std 610. IEEE Standard Glossary of Software Engineering Terminology/(ANSI) .J-STD-016-1998 Page 4 2. FIPS PUB 39. Referenced documents.12-1990. Referenced documents This standard shall be used in conjunction with the following publications. or producing control outputs. or other aspects of the project appear to be sound and can be used as the basis for further work. and with the detailed design of those components. 3. .1.12-1990). ignoring the internal implementation of the system or software item.J-STD-016-1998 Page 5 3. subcontractor. contract.1. control. 3.2 acquirer: An organization that procures software products for itself or another organization.4 architecture: The organizational structure of a system or a software item.1. maintenance organization. but who has a development role on the same or related system or project.1. identify. or other logical functions. software development. define. developer. a build may be released in several parallel versions (such as to different sites). 3. clause 1 describes this standard's interpretation or special usage of the following terms: acquirer. 3. 3.7 build: (1) A version of software that meets a specified subset of the requirements that the completed software will meet.1.1. Definitions NOTE--In addition to the definitions and acronyms provided here. (Source IEEE Std 610. Such devices can perform substantial interpretation. 3. in meeting its requirements.3 approval: Written notification by an authorized representative of the acquirer that a developer's plans.5 associate developer: An organization that is neither prime contractor nor subcontractor to the developer. applicable. or the terms may be used as synonyms. system. establish.9 computer hardware: Devices capable of accepting and storing computer data. design. executing a systematic sequence of operations on computer data. and user. 3. subsystem.1. participate. identifying its components. (2) The period of time during which such a version is developed. develop. from a user's point of view.8 computer database: See: database.1. and a concept of execution among them.1. their interfaces.1.1 Terms 3. computation. This design contrasts with architectural design. Such approval does not shift responsibility from the developer to meet contractual requirements.6 behavioral design: The design of how an overall system or software item will behave. it may take several versions to reach a build. which identifies the internal components of the system or software item. for example. 3. Definitions.1 acceptance: An action by an authorized representative of the acquirer by which the acquirer assumes ownership of software products as partial or complete performance of a contract. record. NOTE--The relationship of the terms "build" and "version" is up to the developer.10 computer program: A combination of computer instructions and data definitions that enable computer hardware to perform computational or control functions. Statement of Work.1 Terms. communication. 3. 3. 1. modify. software unit.1.1. or any other activity that results in software products. such as definitions of all error messages in response to a requirement to display error messages. a relationship among two or more entities (such as software item . 3. configuration management.21 independent verification and validation (IV&V): Systematic evaluation of software products and activities by an organization that is not responsible for developing the product or performing the activity being evaluated. 3. 3. (Adapted from IEEE Std 610. others will be implementation related. and other activities applied to these products).12-1990). regardless of the medium on which it is recorded. that generally has permanence and can be read by humans or machines. IV&V is not within the scope of this standard. Some will match the requirements. (Adapted from IEEE Std 610. and maintain the integrity of a database. (Adapted from IEEE Std 610. or other purposes. 3. others will be elaborations of requirements. .1.11 computer software: See: software.J-STD-016-1998 Page 6 3. 3.16 developer: An organization that develops software products ("develops" may include new development.1. An interface is not a software item.20 hardware item: An aggregation of hardware that is designated for purposes of specification. 3.1. reuse. or software unit .1.software unit) in which the entities share.22 interface: In software development. it is a relationship among them.1.1. 3. 3. quality assurance. such as decisions about what software units and logic to use to satisfy the requirements.13 database management system: An integrated set of computer programs that provide the capabilities needed to establish.12-1990).18 evaluation: The process of determining whether an item or activity meets specified criteria. maintenance.1.17 document/documentation: A collection of data. software item . provide.1. 3. software item .1.15 design: Those characteristics of a system or a software item that are selected by the developer in response to the requirements. interfacing. and includes the testing.12 database: A collection of related data stored in one or more computerized files in a manner that can be accessed by users or computer programs via a database management system. reengineering. configuration management. testing. make available.software item.14 deliverable software product: A software product that is required by the contract to be delivered to the acquirer or other designated recipient. or exchange data. 3.19 firmware: The combination of a hardware device and computer instructions and/or computer data that reside as read-only software on the hardware device.hardware item.12-1990). modification. 3. or other system component.user. 30 requirement: (1) A characteristic that a system or a software item is required to possess in order to be acceptable to the acquirer.). Examples include.1.27 process: An organized set of activities performed for a given purpose. for example. 3. (2) A binding statement in this standard or another portion of the contract.31 reusable software product: A software product developed for one use but having other uses. but are not limited to.1. reengineering. Software development may include new development.1. such as design from code). 3. to produce a new system).33 software development: A set of activities that results in software products. restructuring (transforming a system from one representation to another at the same level of abstraction).1. technical. May include reverse engineering (analyzing a system and producing a representation at a higher level of abstraction.24 maintenance (of software): See: software maintenance. together with new requirements. this standard limits the definition to computer programs and computer databases. and pre-existing developer software products. 3.J-STD-016-1998 Page 7 3. etc. modification.23 joint review: A process or meeting involving representatives of both the acquirer and the developer. Requirements are expressed using the word "shall.25 non-deliverable software product: A software product that is not required by the contract to be delivered to the acquirer or other designated recipient. Note--Although some definitions of software include documentation. software products in reuse libraries.1. and translation (transforming source code from one language to another or from one version of a language to another)." 3.1. or one developed specifically to be usable on multiple projects or in multiple roles on one project. and physical safeguards to ensure the security and confidentiality of data records and to protect both security and confidentiality against any anticipated threats or hazards that could result in substantial harm. 3. 3. (Source FIPS PUB 39) 3. during which project status. the software development process. acquirer-furnished software products.28 qualification testing: Testing performed to demonstrate to the acquirer that a software item or a system meets its specified requirements.26 privacy protection: The establishment of appropriate administrative. Each use may include all or part of the software product and may involve its modification. embarrassment. and/or project issues are examined and discussed. software products. or any other activities that result in software products.1. redocumentation (analyzing a system and producing user or maintenance documentation). commercial off-the-shelf software products.32 software: Computer programs and computer databases. reuse. maintenance. 3. . not just to software itself. 3.1. inconvenience or unfairness to any individual about whom such information is maintained.29 reengineering: The process of examining and altering an existing system to reconstitute it in a new form. 3. architectures.1.1. forward engineering (using software products derived from an existing system. This term can be applied to any software product (for example.1. retargeting (transforming a system to install it on a different target system). requirements. 3. interfacing. 3. configuration management.1.1. 3.41 software system: A system consisting solely of software and possibly the computer equipment on which the software operates. requirements. 3. modified. 3.38 software maintenance: The set of activities that takes place to ensure that software installed for operational use continues to perform as intended and fulfill its intended role in system operation. and implementation.40 software quality: The ability of software to satisfy its specified requirements.1. a major subdivision of a software item.1.43 software unit: An element in the design of a software item. and associated tools and procedures used to facilitate the orderly development and subsequent maintenance of software.1. and other factors. a class. developer-internal test information.35 software development library (SDL): A controlled collection of software. need to be separately documented and controlled. databases. etc. A software item is made up of one or more software units. usually the organization that will perform software maintenance. that satisfies an end use function and is designated for purposes of specification.2 Abbreviations and acronyms CASE Computer-Aided Software Engineering COM Computer Operation Manual CPMComputer Programming Manual DBDD Database Design Description FSM Firmware Support Manual HW Hardware IDD Interface Design Description . design. other intermediate and final software products.J-STD-016-1998 Page 8 3.42 software transition: The set of activities that enables responsibility for software development to pass from one organization. Software units in the design may or may not have a one-to-one relationship with the code and data entities (routines. design. support strategy. data files. 3. rationale. developer. criticality. 3.) that implement them or with the computer files containing those entities. and manuals. procedures. for example. Software items are selected based on tradeoffs among software function. usually the organization that performs initial software development. 3. and schedule and status information. a component of that subdivision.1. interface considerations. Contents typically include (either directly or by reference) considerations. test information. routine. databases. or database. host or target computers.2 Abbreviations and acronyms. to another. such as a computer program or database.1. documentation. plans for reuse. Software maintenance includes improvements. qualification testing. module.37 software item: An aggregation of software.1. 3. size. 3.44 transition (of software): See: software transition.36 software development process: An organized set of activities performed to translate user needs into software products. Examples include plans.1. and related activities. Software units may occur at different levels of a hierarchy and may consist of other software units. object. 3. aid to users.34 software development file (SDF): A repository for material pertinent to the development of a particular body of software.39 software product: Software or associated information created. or other purposes. and constraints related to requirements definition. function. code.1. or incorporated to satisfy a contract.1. J-STD-016-1998 Page 9 IRS Interface Requirements Specification IV&VIndependent Verification and Validation OCDOperational Concept Description SCOM Software Center Operator Manual SDD Software Design Description SDF Software Development File SDL Software Development Library SDP Software Development Plan SIOM Software Input/Output Manual SIP Software Installation Plan SOW Statement of Work SPS Software Product Specification SRS Software Requirements Specification SSDD System/Subsystem Design Description SSS System/Subsystem Specification STD Software Test Description STP Software Test Plan STR Software Test Report STrPSoftware Transition Plan SUMSoftware User Manual SVD Software Version Description SW Software . 1) Establishing a software development environment (5. The developer's software development process shall be described in the Software Development Plan.12) Preparing for software transition (5.9) Software/hardware item integration and testing (5.23) 11) Coordinating with associate developers (5.19) 7) Software management indicators (5.J-STD-016-1998 Page 10 4.21) 9) Managing subcontractors (5.7) Unit integration and testing (5. and need not be performed in the order listed below.8) Software item qualification testing (5. The software process established may use or reference an organization's existing process for performing these activities.25) 4. may be applied differently to different elements of software. The software development process shall include the following major activities. which may overlap.1 Software development process. a) b) c) d) e) f) g) h) i) j) k) l) m) n) Project planning and oversight (clause 5.22) 10) Interfacing with software IV&V agents (5.24) 12) Project process improvement (5. Annex B provides examples.20) 8) Administrative security and privacy protection (5.10) System qualification testing (5.6) Software implementation and unit testing (5.13) Integral processes: 1) Software configuration management (5.2 General requirements for software development The developer shall meet the following general requirements in carrying out the detailed requirements in clause 5 of this standard.11) Preparing for software use (5.2 General requirements for software development.2) System requirements definition (5.14) 2) Software product evaluation (5.1 Software development process The developer shall establish a software development process consistent with contract requirements. .4) Software requirements definition (5.15) 3) Software quality assurance (5.5) Software design (5.17) 5) Joint technical and management reviews (5.18) 6) Risk management (5.16) 4) Corrective action (5. may be applied iteratively. General requirements.3) System design (5. General requirements 4. acquirer-furnished. code. 4.4). Database Design Description (see G. Annex D provides candidate evaluation criteria and interprets this standard for incorporation of reusable software products.5 Assurance of safety. The result shall include all applicable traceability items of the System/Subsystem Specification (see F.2.2. test cases.2. NOTE--The intent of this requirement is to trace both upward and downward to 1) ensure that all requirements are implemented and tested and 2) provide information for software maintenance.2). Interface Design Description (see G. and Software Product Specification (see I. or environmental harm) .2.1 Software development methods The developer shall use systematic. Software Test Description (see H.2. System/Subsystem Design Description (see G.. and pre-existing developer software products).2.2.3 Traceability The developer shall perform traceability between levels of requirements. security. or referenced from. develop a strategy.1). to assure that the requirements. and between computer hardware resource utilization requirements and measured computer hardware resource utilization. 4. 4. privacy protection. implement the strategy. The developer shall identify by type. or other critical requirements. or other critical requirements If a system relies on software to satisfy requirements deemed critical by the contract or by system specifications.2. Interface Requirements Specification (see F. and develop strategies for.2). that meet specified requirements and are cost-effective over the life of the system. between requirements and design. commercial off-theshelf. design. design. loss of property. or referenced from. between requirements and qualification test information. record the strategy in the Software Development Plan.2 Standards and practices for software products.2. as part of the required software products. 4. privacy protection.2.2.4 Reusable software products. software products in reuse libraries. for use in fulfilling the requirements of the contract.4).2 Standards and practices for software products The developer shall establish and apply standards and practices for representing requirements.g.2.2.5 Assurance of safety. and operating procedures for the identified software minimize or eliminate the potential for such violations.J-STD-016-1998 Page 11 4. documented methods for all software development activities. These methods shall be described in. NOTE--In addition.3).2. injury. The scope of the search and the criteria to be used for evaluation and incorporation shall be as described in the Software Development Plan. the Software Development Plan.2.2. and test results. Software Requirements Specification (see F. between design and the software that implements it.2). security.2. Software Test Plan (see E. Software Design Description (see G. implementation.2. the developer may be required by the contract to develop software products specifically for reuse.1). and produce evidence.1 Software development methods.2. test procedures. These standards and practices shall be described in. including both test and analyses.4 Reusable software products The developer shall identify and evaluate reusable software products (e. that the assurance strategy has been carried out. the developer shall identify those software items or portions thereof whose failure could lead to violation of those critical requirements. the Software Development Plan.3 Traceability.3).1). the following types of critical requirements: a) Safety-critical: those software items or portions thereof whose failure could lead to a hazardous system state (one that could result in unintended death.2. or other media that will transition to the maintenance organization. or disclosure of computer software or computer data. and criteria used to make the decisions. security is concerned with any accidental or malicious modification. destruction.7 Recording rationale The developer shall record rationale that will be useful to the maintenance organization for key decisions made in specifying. and reallocate or identify the need for additional resources as necessary to meet contract requirements.8 Access for acquirer review The developer shall provide the acquirer or its authorized representative access to developer and subcontractor facilities. input/output device capacity. privacy protection is concerned with preventing unauthorized disclosure of confidential data such as salary information. and testing the software.. 4.2.2.2.6 Computer hardware resource utilization. auxiliary storage device capacity.7 Recording rationale. including the software engineering and test environments. analysis methods. for review of software products and activities required by the contract. memory capacity. monitor the utilization of these resources for the duration specified in the contract. The developer shall analyze contract requirements concerning computer hardware resource utilization (such as maximum allowable use of processor capacity.2. code comments.2. designing.J-STD-016-1998 Page 12 b) Security-critical: those software items or portions thereof whose failure could lead to a breach of system security c) Privacy protection-critical: those software items or portions thereof whose failure could lead to a breach of system privacy protection NOTE--For purposes of this standard. 4. and communications/network equipment capacity). The rationale shall be recorded in documents. implementing.2. The rationale shall include trade-offs considered. 4. .6 Computer hardware resource utilization.8 Access for acquirer review. The meaning of "key decisions" and the approach for providing the rationale shall be described in the Software Development Plan. The developer shall allocate computer hardware resources among the software items. This task is recognized to be separate from the task of generating and recording the required information and to require additional time and effort on the part of the developer. the developer is required to format. 5. and distribute the deliverable in accordance with the contract. Annex B provides guidance for planning builds. and c) planning for future builds covered under the contract to a level of detail compatible with the information available.2. and 3) Permit representations other than traditional documents for recording the information (for example. 2) Use software products in annexes E through J as checklists of items to be covered in the planning and engineering activities. and activities and software products may not be complete until several or all builds are accomplished. different software products may proceed at different paces. b) detailed planning for the current build. 2--If the contract specifies delivery of the information generated by this or any other subclause. This planning shall be consistent with system-level planning and shall include all applicable items in the Software Development Plan (SDP) (see E. others may be performed only in selected builds. computer-aided software engineering (CASE) tools).1 Software development planning The developer shall develop and record plans for conducting the activities required by this standard and by other software-related requirements in the contract. Detailed requirements The order of the requirements in this clause is not intended to specify the order in which they are required to be carried out. some activities may be performed in every build. NOTE--If a system or software item is developed in multiple builds. planning for each build is interpreted to include: a) overall planning for the contract.J-STD-016-1998 Page 13 5. Portions of the plan may be bound or maintained separately if this approach enhances the usability of the information. If the software is developed in multiple builds. Some activities may not apply to the project or the contracted effort. Detailed requirements. 5. Many of the activities may be ongoing at one time. 3--The Software Development Plan covers all activities required by this standard. Annex K provides information on format and structure of deliverable information. Non-binding notes throughout clause 5 explain how to interpret each activity on a project involving multiple builds.1 Project planning and oversight. determining which activities apply to each build. and activities specified in early subclauses may depend on input from activities in later subclauses.1. copy. mark.1).1 Project planning and oversight The developer shall perform project planning and oversight in accordance with the following requirements.1. NOTES 1--The wording here and throughout this standard is designed to: 1) Emphasize that the development and recording of planning and engineering information is an intrinsic part of the software development process.1 Software development planning. A project involving a single build will accomplish all required activities in that build. to be performed regardless of whether a deliverable is required. Examples include separate plans for software quality assurance and software configuration management. . and scheduling these activities. assemble. Figure 1 provides an example of how each activity may be applied in one or more builds. 4--The requirement to develop and record software development planning information may be satisfied by referencing an organization's existing practices and procedures that comply with the requirements of the contract. 11 System qualification testing 5.17 Corrective action 5.15 Software product evaluation 5.8 Unit integration and testing 5.14 Software configuration management 5.10 Software/hardware item integration and testing 5.4 System design 5.16 Software quality assurance 5.20 Software management indicators 5.18 Joint technical and management reviews 5.7 Software implementation and unit testing 5.13 Preparing for software transition Integral processes: 5.24 Coordinating with associate developers 5.5 Software requirements definition 5.23 Interfacing with software IV&V agents 5.25 Project process improvement x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x Build 2 x x x x x x x x x x x x x x x x x x x x x x x x x x x x Build 3 x x Build 4 x x Figure 1--One possible mapping of this standard's activities to multiple builds .12 Preparing for software use 5.22 Managing subcontractors 5.2 Establishing a software development environment 5.21 Administrative security and privacy protection 5.J-STD-016-1998 Page 14 Builds Activity Build 1 5.19 Risk management 5.1 Project planning and oversight 5.6 Software design 5.3 System requirements definition 5.9 Software item qualification testing 5. 1.1.2). (The intent for software systems is a single Software Test Plan covering both software item and system qualification testing..5 Software transition planning.2.) 5. and database management systems) to perform the software engineering effort.3).2. loaders. This planning shall include all applicable items in the Software Test Plan (STP) (see E. such as computer-aided software engineering (CASE) tools. 5. this planning shall include all applicable items in the Software Test Plan (STP) (see E. software. operating systems. linkers.2 Software item test planning. debuggers.2 Establishing a software The developer shall establish a software development environment in accordance with the following requirements. hardware. assemblers.2.6 Following and updating plans Following acquirer approval of any of the plans in this clause. NOTE--If a system or software item is developed in multiple builds. simulators.2 Software test environment . and documentation. firmware.1.4 Software installation planning. The developer shall ensure that each element of the environment performs its intended functions prior to its use on the project. This planning shall include all applicable items in the Software Transition Plan (STrP) (see E.2 Establishing a software development environment development environment.2.1.2.2 Software test environment. 5.2.3 System test planning The developer shall participate in developing and recording plans for conducting system qualification testing.5 Software transition planning The developer shall identify all software development resources that will be needed by the maintenance organization to fulfill the support strategy specified in the contract. This planning shall include all applicable items in the Software Installation Plan (SIP) (see E. 5.1.6 Following and updating plans. compilers.1. establishing the software development environment in each build is interpreted to mean establishing the environment needed to complete that build. updates to plans shall be subject to acquirer approval.2.1 Software engineering environment The developer shall establish. 5.4 Software installation planning The developer shall develop and record plans for performing software installation and training at the user sites specified in the contract.J-STD-016-1998 Page 15 5.3 System test planning. 5.2).g. For software systems. documentation tools. 5.1.1. The developer shall develop and record plans identifying these resources and describing the approach to be followed for transitioning deliverable items to the maintenance organization.2. the developer shall conduct the relevant activities in accordance with the plan. and maintain a software engineering environment (e. With the exception of developer-internal scheduling and related staffing information.1. The developer's management shall review the software development process at intervals specified in the Software Development Plan to assure that the process complies with the contract and adheres to the plans. the facilities.4). emulators.1 Software engineering environment.2 Software item test planning The developer shall develop and record plans for conducting software item qualification testing. control. procedures.1. 3 System requirements definition The developer shall participate in system requirements definition in accordance with the following requirements. surveys. firmware. for logical groups of software items. or other user input or feedback. 5. This input may take the form of need statements.2. (such as user. System requirements definition for a given build is interpreted to mean defining the system requirements so identified for that build. The developer shall ensure that each element of the environment performs its intended functions prior to its use on the project.5 Non-deliverable software. and.5 Non-deliverable software The developer may use non-deliverable software in the development of deliverable software provided: 1) the operation and maintenance of the deliverable software after delivery to the acquirer do not depend on the non-deliverable software. or 2) the acquirer has or can obtain the same software.2.2.2.3 System requirements definition.1 Analysis of user input.2. 5. its requirements may not be fully defined until the final build. testing of software.. procedures. The SDL may be an integral part of the software engineering and test environments. feedback on prototypes.3 Software development library. 5.1 Analysis of user input The developer shall participate in analyzing user input provided by the acquirer to gain an understanding of user needs. and maintain a software development library (SDL) to facilitate the orderly development and subsequent maintenance of software. such as simulators. The developer shall maintain the SDL for the duration specified in the contract. the facilities. and maintain a software test environment (e. and maintenance and test organizations). control. control. as applicable. maintain on-going communications regarding user needs throughout the development of the system. NOTE--If a system is developed in multiple builds. and maintain a software development file (SDF) for each software unit or logically related group of software units. code analyzers. for subsystems. The developer shall ensure that all non-deliverable software used on the project performs its intended functions prior to its use on the project.4 Software development files. control. test case generators. and path analyzers. 5. NOTE--The intent of this requirement is to ensure that all interested parties. and for the overall system.3. The result shall include all applicable items in the Operational Concept Description (OCD) (see .2 Operational concept. software. The developer shall record information about the development of the software in appropriate SDFs and shall maintain the SDFs for the duration specified in the contract. acquirer. interviews. and documentation. for each software item. 5.2.3.2 Operational concept The developer shall participate in defining and recording the operational concept for the system. problem/change reports. and possibly other items of the software engineering environment) to perform qualification.3 Software development library The developer shall establish.g. 5.3.J-STD-016-1998 Page 16 The developer shall establish. The developer's planning will identify the subset of system requirements to be defined in each build and the subset to be implemented in each build. hardware.3.4 Software development files The developer shall establish. developer. and possibly other. operational concepts. The developer's planning will identify the portion of the system design to be defined in each build.1). the activity in 5. the developer shall participate in defining and recording the requirements to be met by the system and the methods to be used to ensure that each requirement has been met.1). The result shall include all applicable items in the architectural design and traceability clauses of the System/Subsystem Design Description (SSDD) (see G. this should be interpreted to cover organizing a system into subsystems. their interfaces.2 System architectural design The developer shall participate in defining and recording the architectural design of the system (identifying the components of the system. Depending on contract provisions. and other considerations. its design may not be fully defined until the final build.1 System-wide design decisions The developer shall participate in defining and recording system-wide design decisions (that is. but their fulfillment need not be demonstrated to the acquirer. organizing a subsystem into hardware items.2.1). design pertaining to interfaces may be included in the SSDD or in Interface Design Descriptions (IDDs).3 System requirements Based on analysis of user needs. and other considerations.3 is intended to be performed iteratively with the activities in 5.2.4. the methods to be used to ensure that each requirement has been met.2. System design for a given build is interpreted to mean defining the portion of the system design identified for that build.2.2). system design. 5.3 System requirements. Depending on contract provisions. and so on. design pertaining to interfaces may be included in the SSDD or in Interface Design Descriptions (IDDs). NOTE--Design decisions act as developer-internal "requirements. decisions about the system's behavioral design and other decisions affecting the selection and design of system components). design the subsystems and identify their components. The result shall include all applicable items in the System/Subsystem Specification (SSS) (see F. 5.3.5 Software requirements definition Based on analysis of system requirements. software items.4 System design. 5. requirements concerning system interfaces may be included in the SSS or in Interface Requirements Specifications (IRSs). design the system and identify its subsystems.5 Software requirements definition. NOTE--If a system consists of subsystems. 5. if applicable. Depending on contract provisions. and design pertaining to databases may be included in the SSDD or in Database Design Descriptions (DBDDs).4 System design The developer shall participate in system design in accordance with the following requirements. and a concept of execution among them) and the traceability between the system components and system requirements. this clause is written in terms of organizing a system into components. and the traceability between . the developer shall define.4.4. NOTE--If a system is developed in multiple builds. define the requirements for those subsystems.4 (System design) to define system requirements.4. or other variations as appropriate.3. The result shall include all applicable items in the system-wide design clause of the System/Subsystem Design Description (SSDD) (see G. However.1 System-wide design decisions. and design pertaining to databases may be included in the SSDD or in Database Design Descriptions (DBDDs)." to be implemented.3. NOTE--For brevity. imposed on subcontractors. and manual operations. and record the software requirements to be met by each software item. 5. and confirmed by developer-internal testing.2 System architectural design.J-STD-016-1998 Page 17 F. 2.7 Software implementation and unit testing The developer shall perform software implementation and unit testing in accordance with the . and design pertaining to databases may be included in SDDs or in Database Design Descriptions (DBDDs). The result shall include all applicable items in the architectural design and traceability clauses of the Software Design Description (SDD) (see G. The result shall include all applicable items in the software item-wide design clause of the Software Design Description (SDD) (see G.2.4).4). 5.2. Depending on contract provisions.J-STD-016-1998 Page 18 the software item requirements and system requirements. Depending on contract provisions. and a concept of execution among them) and the traceability between the software units and the software item requirements.4). NOTE--If a software item is developed in multiple builds. their interfaces.6 Software design. decisions about the software item's behavioral design and other decisions affecting the selection and design of the software units comprising the software item).3 Software item detailed design The developer shall develop and record a description of each software unit. design pertaining to interfaces may be included in SDDs or in Interface Design Descriptions (IDDs). and design pertaining to databases may be included in SDDs or in Database Design Descriptions (DBDDs).6.6.2.1 Software item-wide design decisions. The result shall include all applicable items in the Software Requirements Specification (SRS) (see F.7 Software implementation and unit testing. 5. The result shall include all applicable items in the detailed design clause of the Software Design Description (SDD) (see G. NOTE--If a software item is developed in multiple builds. NOTE--Software units may be made up of other software units and may be organized into as many levels as are needed to represent the software item architecture.6 Software design The developer shall perform software design in accordance with the following requirements. Software design in each build is interpreted to mean the design necessary to meet the software item requirements to be implemented in that build.1 Software item-wide design decisions The developer shall define and record software item-wide design decisions (that is. its requirements may not be fully defined until the final build.3 Software item detailed design. design pertaining to interfaces may be included in SDDs or in Interface Design Descriptions (IDDs).2 Software item architectural design The developer shall define and record the architectural design of each software item (identifying the software units comprising the software item. a software item may be divided into three software units.6. each of which is divided into additional software units. its design may not be fully defined until the final build. Depending on contract provisions. 5. 5. and so on. design pertaining to interfaces may be included in SDDs or in Interface Design Descriptions (IDDs).4). Software requirements definition for a given build is interpreted to mean defining the software item requirements so identified for that build.6. and design of software units that are databases or that access or manipulate databases may be included in SDDs or in Database Design Descriptions (DBDDs).6. Depending on contract provisions. The developer's planning will identify the subset of each software item's requirements to be defined in each build and the subset to be implemented in each build.2 Software item architectural design. 5. requirements concerning software item interfaces may be included in SRSs or in Interface Requirements Specifications (IRSs).6. For example. data files. If a software item is developed in multiple builds.7. . 5. The test cases shall cover the unit's design. The term "implementation" means converting software design into computer programs and computer databases.7. The developer shall record this information in the appropriate software development files (SDFs). populating databases and other data files with data values. expected results.2 Preparing for unit testing The developer shall establish test cases (in terms of inputs. 5. procedures.3 Performing unit testing The developer shall test the software corresponding to each software unit. databases.) that implement them or with the computer files containing those entities. NOTE--The term "software" includes both computer programs and computer databases. etc. This activity shall include.1 Software implementation The developer shall develop and record software corresponding to each software unit in the software item design. test procedures. software implementation and unit testing of that software item is complete when the final build is complete.7. needed to meet the software item requirements to be implemented in that build. The testing shall be in accordance with the unit test cases and procedures. and other activities needed to implement the design. building databases. and test data for testing the software corresponding to each software unit. as applicable.3 Performing unit testing.7. NOTE--Software units in the design may or may not have a one-to-one relationship with the code and data entities (routines. or parts of units.7.J-STD-016-1998 Page 19 following requirements. For deliverable software. coding computer instructions and data definitions.1 Software implementation. and evaluation criteria). the developer shall use the programming language specified in the contract. Software implementation and unit testing in each build is interpreted to include those units.7. 5.2 Preparing for unit testing. perform necessary retesting. some unit integration and testing may take place during unit testing.4 Revision and retesting. testing the resulting software to ensure that it works together as intended.4 Analyzing and recording unit integration and test results. The last stage of this testing is developer-internal software item testing. and test data for conducting unit integration and testing. and testing the results.J-STD-016-1998 Page 20 5.4 Revision and retesting Based on the results of unit testing. the developer shall make necessary revisions to the software. 5.1 Preparing for unit integration and testing The developer shall establish test cases (in terms of inputs.8 Unit integration and testing. The developer shall record this information in the appropriate software development files (SDFs).8. perform necessary retesting. the developer shall make necessary revisions to the software. 5. 5.8. .8. 5. The testing shall be in accordance with the unit integration test cases and procedures.7. The requirements in this clause are not meant to duplicate those activities. Unit integration and testing in each build is interpreted to mean integrating software developed in the current build with other software developed in that and previous builds. NOTES 1--Unit integration and testing means integrating the software corresponding to two or more software units.8 Unit integration and testing The developer shall perform unit integration and testing in accordance with the following requirements.8.2 Performing unit integration and testing.7.2 Performing unit integration and testing The developer shall perform unit integration and testing.5 Analyzing and recording unit test results.7.8. 2--If a software item is developed in multiple builds. and evaluation criteria). and update the software development files (SDFs) and other software products as needed.3 Revision and retesting. 5. 5. The test cases shall cover the software item-wide and software item architectural design.8.7. expected results.3 Revision and retesting Based on the results of unit integration and testing.8. unit integration and testing of that software item will not be completed until the final build. and update the software development files (SDFs) and other software products as needed.5 Analyzing and recording unit test results The developer shall analyze the results of unit testing and shall record the test and analysis results in appropriate software development files (SDFs). test procedures. Since units may consist of other units.4 Analyzing and recording unit integration and test results The developer shall analyze the results of unit integration and testing and shall record the test and analysis results in appropriate software development files (SDFs).8.1 Preparing for unit integration and testing. and continuing this process until all software in each software item is integrated and tested. The developer shall record the results of this activity in appropriate software development files (SDFs) and shall update the software item test cases and procedures as appropriate. The testing shall be in accordance with the software item test cases and procedures.2 Testing on the target computer system Software item qualification testing shall include testing on the target computer system or an alternative system approved by the acquirer.9.4 Dry run of software item qualification testing If software item qualification testing is to be witnessed by the acquirer. or possibly until later builds involving items with which the software item is required to interface. 2--If a software item is developed in multiple builds.9.9 Software item qualification testing The developer shall perform software item qualification testing in accordance with the following requirements. The result shall include all applicable items in the Software Test Description (STD) (see H.1 Independence in software item qualification testing. by contributing test cases that rely on knowledge of the software item's internal implementation. Software item qualification testing in each build is interpreted to mean planning and performing tests of the current build of each software item to ensure that the software item requirements to be implemented in that build have been met. for example.3 Preparing for software item qualification testing The developer shall define and record the test preparations.2 Testing on the target computer system.5 Performing software item qualification testing.2.9. 5. 5.5 Performing software item qualification testing The developer shall perform qualification testing of each software item. test cases. NOTES 1--Software item qualification testing is performed to demonstrate to the acquirer that software item requirements have been met.9 Software item qualification testing. performed as the final stage of unit integration and testing. the developer shall dry run the software item test cases and procedures to ensure that they are complete and accurate and that the software is ready for witnessed testing.J-STD-016-1998 Page 21 5. 5.4 Dry run of software item qualification testing.9. .9. 5. and test procedures to be used for software item qualification testing and the traceability between the test cases and the software item requirements.9. This does not preclude persons who performed detailed design or implementation of the software item from contributing to the process. 5. This testing contrasts with developer-internal software item testing.9.1).9.9.3 Preparing for software item qualification testing.9. its software item qualification testing will not be completed until the final build for that software item.1 Independence in software item qualification testing The person(s) responsible for qualification testing of a given software item shall not be the persons who performed detailed design or implementation of that software item. It covers the software item requirements in Software Requirements Specifications (SRSs) and in associated Interface Requirements Specifications (IRSs). The developer shall prepare the test data needed to carry out the test cases and provide the acquirer advance notice of the time and location of software item qualification testing. 6 Revision and retesting. .2.10.1 Preparing for software/hardware item integration and testing. The testing shall be in accordance with the software/hardware item integration test cases and procedures.10.3 Revision and retesting.10. and evaluation criteria).9. The results shall include all applicable items in the Software Test Report (STR) (see H. and update the software development files (SDFs) and other software products as needed. The test cases system architectural design. and test data for conducting shall cover the system-wide and software-related information in 5.2 Performing software/hardware item integration and testing The developer shall participate in software/hardware item integration and testing.10 Software/hardware item integration and testing The developer shall participate in software/hardware item integration and testing activities in accordance with the following requirements. test procedures.10.9. participate in necessary retesting. 2--If a system or software item is developed in multiple builds. NOTES 1--Software/hardware item integration and testing means integrating software items with interfacing hardware items and software items.1 Preparing for software/hardware item integration and testing The developer shall participate in developing and recording expected results.3 Revision and retesting Based on the results of software/hardware item integration and testing. software/hardware item integration and testing may not be complete until the final build. The last stage of this testing is developer-internal system testing. and continuing this process until all software items and hardware items in the system are integrated and tested. Software/hardware item integration and testing in each build is interpreted to mean integrating the current build of each software item with the current build of other software items and hardware items and testing the results to ensure that the system requirements to be implemented in that build have been met. the developer shall make necessary revisions to the software. 5. conduct necessary retesting.2 Performing software/hardware item integration and testing. software/hardware item integration and testing.7 Analyzing and recording software item qualification test results The developer shall analyze and record the results of software item qualification testing. provide the acquirer advance notice of retesting. the developer shall make necessary revisions to the software. 5.10. The developer shall record appropriate software development files (SDFs).J-STD-016-1998 Page 22 5. test cases (in terms of inputs. 5.10. 5.2).9.9.6 Revision and retesting Based on the results of software item qualification testing.10 Software/hardware item integration and testing.7 Analyzing and recording software item qualification test results. testing the resulting groupings to determine whether they work together as intended. and update the appropriate software development files (SDFs) and other software products as needed. qualification testing of the completed system will not occur until the final build. and test procedures to be used for system qualification testing and the traceability between the test cases and the system requirements. test cases.1 Independence in system qualification testing The person(s) responsible for fulfilling the requirements in this clause shall not be the persons who performed detailed design or implementation of software in the system. This does not preclude persons who performed detailed design or implementation of software in the system from contributing to the process. 5.1 Independence in system qualification testing.11.11.2 Testing on the target computer system. The developer shall participate in preparing the test data needed to carry out the test cases and in providing the acquirer advance notice of the time and location of system qualification testing.11.1).4 Dry run of system qualification testing. 2--If a system is developed in multiple builds.4 Analyzing and recording test results The developer shall participate in analyzing the results of software/hardware item integration and testing.11. performed as the final stage of software/hardware item integration and testing. This testing contrasts with developer-internal system testing. 5.5 Performing system qualification testing. the results shall include all applicable items in the Software Test Description (STD) (see H. 5.11 System qualification testing The developer shall participate in system qualification testing in accordance with the following requirements.3 Preparing for system qualification testing The developer shall participate in developing and recording the test preparations. It covers the system requirements in the System/Subsystem Specifications (SSSs) and in associated Interface Requirements Specifications (IRSs).11 System qualification testing. For software systems.4 Dry run of system qualification testing If system qualification testing is to be witnessed by the acquirer. The developer shall record the software-related results of this activity in appropriate software development files (SDFs) and shall participate in updating the system test cases and procedures as appropriate. 5.3 Preparing for system qualification testing. 5.11.2 Testing on the target computer system The developer's system qualification testing shall include testing on the target computer system or an alternative system approved by the acquirer. Software-related analysis and test results shall be recorded in appropriate software development files (SDFs).J-STD-016-1998 Page 23 5. the developer shall participate in dry running the system test cases and procedures to ensure that they are complete and accurate and that the system is ready for witnessed testing.11.11.10.2. by contributing test cases that rely on knowledge of the system's internal implementation.4 Analyzing and recording test results.11. for example. NOTES 1--System qualification testing is performed to demonstrate to the acquirer that system requirements have been met.11. System qualification testing in each build is interpreted to mean planning and performing tests of the current build of the system to ensure that the system requirements to be implemented in that build have been met.11.5 Performing system qualification testing . 5.10. 6 Revision and retesting. 5.3 Preparing user manuals. the developer's planning identifies what software.12. . provide the acquirer advance notice of retesting.12. Preparing for software use in each build is interpreted to include those activities necessary to carry out the distribution plans for that build.7 Analyzing and recording system qualification test results. data files.12 Preparing for software use. the acquirer can order an SPS. participate in necessary retesting. 5. the developer shall make necessary revisions to the software.1).12. command files.2.11.12.11.3 Preparing user manuals The developer shall prepare user manuals in accordance with the following requirements.12 Preparing for software use The developer shall prepare for software use in accordance with the following requirements.2). if any. tailoring out all but the executable software clause of the SPS. The result shall include all applicable items in the executable software clause of the Software Product Specification (SPS) (see I. 5.2.11. NOTE--If software is developed in multiple builds. 5. including any batch files. is to be distributed to users in each build and the extent of distribution (for example.2 Preparing version descriptions for user sites.6 Revision and retesting Based on the results of system qualification testing. and update the software development files (SDFs) and other software products as needed.7 Analyzing and recording system qualification test results The developer shall participate in analyzing and recording the results of system qualification testing. For software systems.12.2).11.J-STD-016-1998 Page 24 The developer shall participate in system qualification testing.1 Preparing the executable software The developer shall prepare the executable software for each user site. the result shall include all applicable items in the Software Test Report (STR) (see H.2 Preparing version descriptions for user sites The developer shall identify and record the exact version of software prepared for each user site. full distribution or distribution to selected evaluators only). NOTE--To order only the executable software (delaying delivery of source files and associated maintenance information to a later build).2. 5. or other software files needed to install and operate the software on its target computer(s). The information shall include all applicable items in the Software Version Description (SVD) (see I. 5.1 Preparing the executable software. This testing shall be in accordance with the system test cases and procedures.12. 2. if any. systems will need all of the manuals in this clause.2).13 Preparing for software transition The developer shall prepare for software transition in accordance with the following requirements. 5. ready for use in software item testing.12. The manuals in this clause are normally developed in parallel with software development.12.3.2.4 Computer operation manuals. 5. The information shall include all applicable items in the Software Center Operator Manual (SCOM) (see J.3).12. .12. b) Provide training to users as specified in the contract. to determine which manuals are appropriate for a given system and to require the development of only those manuals. 5. and receive output from.3.12.12.4).12. The information shall include all applicable items in the Software User Manual (SUM) (see J. Commercial or other manuals that contain the required information can be substituted for the manuals specified in this standard.2 Software input/output manuals.4 Computer operation manuals The developer shall identify and record information needed to operate the computers on which the software will run. the developer's planning identifies what software.3.2 Software input/output manuals The developer shall identify and record information needed by persons who will submit input to. 5. The information shall include all applicable items in the Software Input/Output Manual (SIOM) (see J. c) Provide other assistance to user sites as specified in the contract.1 Software user manuals The developer shall identify and record information needed by hands-on users of the software (persons who will both operate the software and make use of its results).3. NOTE--If software is developed in multiple builds.J-STD-016-1998 Page 25 NOTE--Few.3 Software center operator manuals The developer shall identify and record information needed by persons who will operate the software in a computer center or other centralized or networked software installation.2.3. The intent is for the acquirer.12.3 Software center operator manuals.13 Preparing for software transition. is to be transitioned to the maintenance organization in each build.3. 5.4 Installation at user sites. 5. if any.12. with input from the developer. so that it can be used by others.1 Software user manuals.12. the software. Preparing for software transition in each build is interpreted to include those activities necessary to carry out the transition plans for that build.1). relying on others to operate the software in a computer center or other centralized or networked software installation.3.2.3.4 Installation at user sites The developer shall: a) Install and check out the executable software at the user sites specified in the contract. The information shall include all applicable items in the Computer Operation Manual (COM) (see J. and "manufacturing" consists of electronically duplicating the software.2.13. The result shall include all applicable items in the System/Subsystem Design Description (SSDD) (see G. The "as built" design is included in the Software Product Specification not as the product but as information that may help the maintenance organization understand the software in order to modify. including any batch files. The result shall include all applicable items in the source file clause of the Software Product Specification (SPS) (see I. command files. data files. including any batch files. the measured computer hardware resource utilization for the software item. not recreating it from the design.13.13. The result shall include all applicable items in the Software Requirements Specification (SRS) (see F.13. and traceability clauses of the Software Product Specification (SPS) (see I. or other files needed to regenerate the executable software.13.2. The result shall include all applicable items in the executable software clause of the Software Product Specification (SPS) (see I.13. software maintenance.13.13. NOTE--In hardware development. the final product is the software.3 Preparing version descriptions for the maintenance site The developer shall identify and record the exact version of software prepared for the maintenance site.13.5 Updating the system design description. or other software files needed to install and operate the software on its target computer(s).13.1). and traceability between the software item's source files and software units and between the measured computer hardware resource utilization and the software item requirements concerning them.4 Preparing the "as built" software item design and related information The developer shall update the design description of each software item to match the "as built" software and shall define and record: the methods to be used to verify copies of the software.2. by contrast.3). not its design. and otherwise maintain it.2 Preparing source files The developer shall prepare the source files to be transitioned to the maintenance site.5 Updating the system design description The developer shall participate in updating the system design description to match the "as built" system. 5.2 Preparing source files.3 Preparing version descriptions for the maintenance site.2.13.13.6 Updating the software requirements The developer shall update the software and interface requirements for each software item to match the approved "as built" software. In software development.6 Updating the software requirements.2.1 Preparing the executable software. data files.2).1). 5. 5. 5.1).7 Updating the system requirements.13. the final product is an approved design from which hardware items can be manufactured.4 Preparing the "as built" software item design and related information.7 Updating the system requirements .J-STD-016-1998 Page 26 5.2. 5. enhance.1 Preparing the executable software The developer shall prepare the executable software to be transitioned to the maintenance site.1).4) and in the Interface Requirements Specification (IRS) (see F.13. The result shall include all applicable items in the qualification. other information needed to maintain the software.2. The information shall include all applicable items in the Software Version Description (SVD) (see I. 5. command files. 3 are also useful to maintenance personnel. 5. NOTE--Not all systems will need the manuals in this clause. The result shall include all applicable items in the System/Subsystem Specification (SSS) (see F.9 Transition to the designated maintenance site The developer shall: a) Install and check out the deliverable software in the maintenance environment designated in the contract.9 Transition to the designated maintenance site.8 Preparing maintenance manuals The developer shall prepare maintenance manuals in accordance with the following requirements. The intent is for the acquirer. with input from the developer. c) Provide training to the maintenance organization as specified in the contract.2.1 Computer programming manuals The developer shall identify and record information needed to program the computers on which the software was developed or on which it will run.1 Computer programming manuals.13.13.2. which serve as the primary sources of information for software maintenance. The user manuals cited in 5.8.4). 5. Commercial or other manuals that contain the required information can be substituted for the manuals specified in this standard.2 Firmware support manuals.8. acquirer-owned.13. 5.3).3). to determine which manuals are appropriate for a given system and to require the development of only those manuals.8. 5.8 Preparing maintenance manuals.2.13. d) Provide other assistance to the maintenance organization as specified in the contract.2 Firmware support manuals The developer shall identify and record information needed to program and reprogram any firmware devices in which the software will be installed.13.J-STD-016-1998 Page 27 The developer shall participate in updating the system requirements and associated interface requirements to match the approved "as built" system.13. The manuals in this clause supplement the System/Subsystem Design Description (SSDD) and the Software Product Specifications (SPSs).13.12. b) Demonstrate to the acquirer that the deliverable software can be regenerated (compiled/linked/loaded into an executable product) and maintained using commercially available.8.13.2. The information shall include all applicable items in the Computer Programming Manual (CPM) (see I. The information shall include all applicable items in the Firmware Support Manual (FSM) (see I. or contractually deliverable software and hardware designated in the contract or approved by the acquirer. .2) and in the Interface Requirements Specification (IRS) (see F. and delivery. track changes. computer files. These entities shall include the software products to be developed or used under the contract and the elements of the software development environment. and preserve past versions. hardware items.1 Configuration identification The developer shall participate in selecting software items. shall identify the entities to be placed under configuration control. if any. 5. 5. and delivery of deliverable software products. storage. documents.14. software products of previous builds.14. The identification scheme shall include the version/revision/release status of each entity. for example.14.1 Configuration identification.4.14. handling.14. These audits shall ensure that each entity incorporates all approved changes.2 Configuration control. Changes that affect an entity already under acquirer control shall be proposed to the acquirer in accordance with contractually established forms and procedures. and no other changes.J-STD-016-1998 Page 28 5.14. 5. the software products of each build may be refinements of. as performed under system architectural design in 5. process change requests. storage. author control.5 Packaging. 5. They shall include. the current version/revision/release of each entity. NOTE--If a system or software item is developed in multiple builds. software items. Annex K provides guidance on the structure and format . and shall assign a project-unique identifier to each software item and each additional entity to be placed under configuration control. handling. distribute changes. or additions to.14 Software configuration management The developer shall perform software configuration management in accordance with the following requirements.14.4 Configuration audits. the Software Development Plan states how these requirements map to the selected levels.4 Configuration audits The developer shall perform periodic audits of all entities that have been placed under project-level or higher configuration control. electronic media." If "project-level" is not a level of control selected for the project. The identification scheme shall be at the level at which entities will actually be controlled. and delivery The developer shall establish and implement procedures for the packaging. NOTE--A number of requirements in this standard refer to "project-level or higher configuration control. 5. Software configuration management in each build is understood to take place in the context of the software products and controls in place at the start of the build.14. a record of changes to the entity since being placed under project-level or higher configuration control. the acquirer). software units. the project manager.14 Software configuration management. project-level control. the persons or groups with authority to authorize changes and to make changes at each level (for example. the programmer/analyst.2 Configuration control The developer shall establish and implement procedures designating the levels of control each identified entity is required to pass through (for example. as applicable. acquirer control).14. These records shall be maintained for the life of the contract.3 Configuration status accounting. handling. storage. the software lead. and the status of problem/change reports affecting the entity.5 Packaging. scheduled for inclusion at the time of the audit.3 Configuration status accounting The developer shall prepare and maintain records of the configuration status of all entities that have been placed under project-level or higher configuration control.14. and the steps to be followed to request authorization for changes.2. NOTE--If a system or software item is developed in multiple builds. criteria to be used. the software products of each build are evaluated in the context of the objectives established for that build. 5.15 Software product evaluation The developer shall perform software product evaluation in accordance with the following requirements. .1 In-process and final software product evaluations. Planning for software quality assurance is included in software development planning (see 5.1 In-process and final software product evaluations The developer shall perform in-process evaluations of the software products generated in carrying out the requirements of this standard.3 Independence in software product evaluation The persons responsible for evaluating a software product shall not be the persons who developed the product.17 (Corrective action).15. 5.15.15.15.2 Software product evaluation records. and definitions for those criteria are given in annex L. A software product that meets those objectives can be considered satisfactory even though it is missing information designated for development in later builds. Problems in software products under project-level or higher configuration control shall be handled as described in 5.1). An activity or software product that meets those objectives can be considered satisfactory even though it is missing aspects designated for later builds.2 Software product evaluation records The developer shall prepare and maintain records of each software product evaluation. The software products to be evaluated. the developer shall perform a final evaluation of each deliverable software product before its delivery.J-STD-016-1998 Page 29 of deliverable software products.16 Software quality assurance. NOTE--If a system or software item is developed in multiple builds. 5. the activities and software products of each build are evaluated in the context of the objectives established for that build. In addition.15.1. This does not preclude the persons who developed the software product from taking part in the evaluation (for example. The developer shall maintain master copies of delivered software products for the duration specified in the contract. 5.3 Independence in software product evaluation. as participants in a walk-through of the product).16 Software quality assurance The developer shall perform software quality assurance in accordance with the following requirements. 5. These records shall be maintained for the duration specified in the contract.15.15 Software product evaluation. These records shall be maintained for the duration specified in the contract. 5. responsibility.17 Corrective action. performed the activity.16.1 Problem/change reports The developer shall prepare a problem/change report to describe each problem detected in software products under project-level or higher configuration control and each problem in activities required by the contract or described in the Software Development Plan. testing. the corrective action needed.17 Corrective action The developer shall perform corrective action in accordance with the following requirements.17.1 Problem/change reports.17 (Corrective action). or are responsible for the software product or activity.2 Software quality assurance records The developer shall prepare and maintain records of each software quality assurance activity.16.J-STD-016-1998 Page 30 5. authority. and organizational freedom to permit objective software quality assurance evaluations and to initiate and verify corrective actions. 5.16. The problem/change report shall describe the problem.3 Independence in software quality assurance The persons responsible for conducting software quality assurance evaluations shall not be the persons who developed the software product. 5. and corrective action as required by this standard and by other contract provisions.1 Software quality assurance evaluations.3 Independence in software quality assurance. .16. This does not preclude such persons from taking part in these evaluations.16. and the actions taken to date. These reports shall serve as input to the corrective action system.1 Software quality assurance evaluations The developer shall conduct on-going evaluations of software development activities and the resulting software products to: a) Assure that each activity required by the contract or described in the Software Development Plan is being performed in accordance with the contract and with the Software Development Plan. b) Assure that each software product required by this standard or by other contract provisions exists and has undergone software product evaluations. The persons responsible for assuring compliance with the contract shall have the resources. Problems in software products under project-level or higher configuration control and problems in activities required by the contract or described in the Software Development Plan shall be handled as described in 5.2 Software quality assurance records. 5.16.17. within the authority of those present. resolution is achieved.1 Joint technical reviews The developer shall plan and take part in joint technical reviews at locations and dates proposed by the developer and approved by the acquirer. review and demonstrate proposed technical solutions. e) Ensure on-going communication between acquirer and developer technical personnel. and records of the problems are maintained for the duration specified in the contract. 5.J-STD-016-1998 Page 31 5. c) Each problem shall be classified by category and priority. c) Arrive at agreed-upon mitigation strategies for identified risks. provide insight and obtain feedback on the technical effort. using the categories and priorities in annex M or acquirer approved alternatives.and long-term risks regarding technical. The system shall meet the following requirements: a) Input to the system shall consist of problem/change reports. The reviews shall have the following objectives: a) Review evolving software products. ensuring that all detected problems are promptly reported and entered into the system. b) Review project status. rather than materials generated especially for the review. the types of joint reviews held and the criteria applied will depend on the objectives of each build.1 Joint technical reviews.2 Corrective action system The developer shall implement a corrective action system for handling each problem detected in software products under project-level or higher configuration control and each problem in activities required by the contract or described in the Software Development Plan. Software products that meet those objectives can be considered satisfactory even though they are missing information designated for development in later builds.17. cost. and schedule issues. status is tracked. using as criteria the software product evaluation criteria in annex L.18 Joint technical and management reviews. b) The system shall be closed-loop. 5. .17. e) Corrective actions shall be evaluated to determine whether problems have been resolved. d) Analysis shall be performed to detect trends in the problems reported. The reviews shall focus on inprocess and final software products. adverse trends have been reversed. d) Identify risks and issues to be raised at joint management reviews.2 Corrective action system. and changes have been correctly implemented without introducing additional problems.18. These reviews shall be attended by persons with technical knowledge of the software products to be reviewed. surface near. NOTE--If a system or software item is developed in multiple builds.18 Joint technical and management reviews The developer shall plan and take part in joint (acquirer/developer) technical and management reviews in accordance with the following requirements. surface and resolve technical issues.18. action is initiated on them. or schedule risks.18. or both.2 Joint management reviews The developer shall plan and take part in joint management reviews at locations and dates proposed by the developer and approved by the acquirer. and implement the strategies in accordance with the plan. d) Identify and resolve management-level issues and risks not raised at joint technical reviews. interpret. and report on those indicators as described in the plan. 5. e) Obtain commitments and acquirer approvals needed for timely accomplishment of the project. and the planned reporting mechanism. These requirements may affect access to and control of the software development effort. the methods to be used to interpret and apply the data.18. and overall status of evolving software products. and prioritize the areas of the software development project that involve potential technical. record the risks and strategies in the Software Development Plan. c) Arrive at agreed-upon mitigation strategies for near.22 Managing subcontractors. Examples of such reviews are identified in annex N. technical agreements reached.19 Risk management The developer shall perform risk management throughout the software development process.21 Administrative security and privacy protection. 5. a) Keep management informed about project status.21 Administrative security and privacy protection The developer shall meet the administrative security and privacy protection requirements specified in the contract. cost. The developer shall identify and define a set of software management indicators. Candidate indicators are given in annex O. The developer shall identify. analyze. 5. 5. the developer shall include in subcontracts all contractual requirements necessary to ensure that software products are developed in accordance with prime contract requirements. b) Resolve issues that could not be resolved at joint technical reviews. develop strategies for managing those risks.22 Managing subcontractors If subcontractors are used. The developer shall record this information in the Software Development Plan and shall collect.20 Software management indicators The developer shall use software management indicators to aid in managing the software development process and communicating its status to the acquirer.2 Joint management reviews. These reviews shall be attended by persons with authority to make cost and schedule decisions and shall have the following objectives.20 Software management indicators.19 Risk management. directions being taken. apply. including the data to be collected.and long-term risks that could not be resolved at joint technical reviews. the resulting software products.J-STD-016-1998 Page 32 5. . shall identify these improvements to the acquirer in the form of proposed updates to the Software Development Plan and.23 Interfacing with software IV&V agents The developer shall interface with the software Independent Verification and Validation (IV&V) agent(s) or independent auditors as specified in the contract.24 Coordinating with associate developers The developer shall coordinate with associate developers.25 Project process improvement The developer shall periodically assess the processes used on the project to determine their suitability and effectiveness. .J-STD-016-1998 Page 33 5. and interface groups as specified in the contract. shall implement the improvements on the project. 5. working groups. 5. the developer shall identify any necessary and beneficial improvements to the project-specific processes. Based on these assessments.24 Coordinating with associate developers. if approved.25 Project process improvement.23 Interfacing with software IV&V agents. 1 J.13. 5. 5.13.2.1.2.1 5.1. 5.3 F.) 6.2.4 5.6 5.3 5.13.2.2.13. 5.6.17.2 G.3 I. 5.3.2.12.11.1 5.3.1.4 G.5 5.6.8.25 5. 5.4 5.2.17.2.2. 5. 5.2.1 Cross reference of standard subclauses to annex subclauses Given below is a cross reference from the subclauses of the standard to subclauses of the annexes that specify the software products cited in each subclause of the standard.2 E.3.6.5 5.5.1.9.4 F.2.4. 5.13. 5. 5. 5.20.16.13. 5.2.4 H. 5.13.2.2.2.1 Title of Software Product Software Development Plan (SDP) E.6.2.2 5.J-STD-016-1998 Page 34 6.4.2.2.4.1.7 5. 5.2 F.1.2. 5.3.3 J.3.3 5. Notes (The contents of this clause are for information only.5. 5.13.2.7 5.2.2. 5.2 J.1 I.12. 5.6.6. Standard 5.1.4 Software Test Plan (STP) Software Installation Plan (SIP) Software Transition Plan (STrP) Operational Concept Description (OCD) System/Subsystem Specification (SSS) Interface Requirements Specification (IRS) System/Subsystem Design Description (SSDD) Interface Design Description (IDD) Database Design Description (DBDD) Software Requirements Specification (SRS) Software Design Description (SDD) Software Test Description (STD) Software Test Report (STR) Software Product Specification (SPS) Software Version Description (SVD) Software User Manual (SUM) Software Input/Output Manual (SIOM) Software Center Operator Manual (SCOM) Computer Operation Manual (COM) Computer Programming Manual (CPM) Firmware Support Manual (FSM) .6.2.1 F.13. 5.3.3 5.2.4.3.1.13.4 I. 5. 5.2.3 G.12. Notes.12.4 5.1 Cross reference of standard subclauses to annex subclauses.1.2.2.2 J.3 5. 5.4.3 E.8.3.1 H.12.4.1.2 I.2.7 5.7.2.3. 5.19.2.11.2 Annex E.9.2.1.1.1 G. 5.3 5.3.3 5.2. 5.1.2 5.6. 5.1.13. 5.3 5. 5.12.6.1.2.6. 5. if not already available to the designated recipients.2 Delivery of tool contents Depending on contract provisions.2 Delivery of tool contents. the developer may be permitted to satisfy delivery requirements by delivering: 1) a repository or database containing the information specified in the standard. 2) a means of accessing that repository or database. and 3) a hard-copy or electronically stored table of contents. .J-STD-016-1998 Page 35 6. such as a CASE tool. specifying how and where to access the information required in each subclause. c) Modify.4 Soliciting inputA. requirements in this standard to reflect unique or special needs of the project. demonstrating capabilities. A. activities. if necessary. and strategies. system and software requirements. b) Decide which requirements in this standard are applicable and cost-effective over the life of the project. . activities and products applicable to the project shall be identified.1 Scope This annex contains requirements for tailoring this standard for a project. existing software products. should be specified. activities. and potential (or selected) development organizations should be involved in tailoring. manufacturing). contracts. and number of personnel and organizations involved. size. and is not subject to tailoring by either the acquirer or developer.5 Selecting processes. A. organizational policies.1 ScopeA.5 Selecting processes.3 Identifying the project environmentA. binding). if any. a) Evaluate the requirements in J-STD-016-1998 to determine whether each requirement is applicable based on the project environment characteristics. The following guidance should be applied when selecting applicable activities and products for the project. This annex is normative (that is. criticality. User. and tasks The processes.J-STD-016-1998 Page 36 Annex AAnnex A Tailoring this standard for a projectTailoring this standard for a project (normative) A.2 Tailoring process The tailoring process consists of the following activities: a) b) c) d) Identifying the project environment Soliciting input Selecting activities and products Specifying tailoring decisions A. procedures. maintenance. and tasksA. Examples of characteristics include: objectives of this phase of the development (such as exploring concepts.4 Soliciting input Input from the organizations affected by tailoring decisions shall be solicited. and type of system.3 Identifying the project environment Characteristics of the project environment that influence tailoring decisions shall be identified. Annexes B and C provide guidance on tailoring this standard.2 Tailoring processA. A. d) Decide which additional requirements not found in this standard. A. g) Record tailoring decisions and their rationale. .6 Specifying tailoring decisionsA. f) Determine applicable requirements.J-STD-016-1998 Page 37 e) Evaluate comments on tailoring decisions solicited from affected organizations.6 Specifying tailoring decisions Tailoring decisions for the project shall be specified in the contract. but differs from the incremental strategy in acknowledging that the user need is not fully understood and all requirements cannot be defined up front. a) Once-through. Three of these strategies are summarized below and in figure 2.1 Scope This annex describes three candidate development strategies and shows how this standard can be applied under each of these strategies and on a project involving reengineering.2 Candidate development strategiesB. It is informative only. define requirements. The first build incorporates part of the planned capabilities. user needs and system requirements are partially defined up front. b) Incremental. and build planning (informative) B. In this strategy.1 ScopeB. The "evolutionary" strategy also develops a system in builds. tailoring.J-STD-016-1998 Page 38 Annex BAnnex B Guidance on development strategies. and so on. B. Development strategy Once-Through Incremental (Preplanned Product Improvement) Evolutionary Define All Requirements First? Yes Yes No Multiple Development Cycles? No Yes Yes Distribute Interim Software? No Maybe Yes Figure 2--Key features of three development strategies . provided to aid in using this standard. and deliver. test. c) Evolutionary. then performs the rest of the development in a sequence of builds. The "once-through" strategy consists of performing the development process a single time. the next build adds more capabilities.2 Candidate development strategies There are many different development strategies that can be applied to software development. design the system. until the system is complete. implement the system. Simplistically: determine user needs. then are refined in each succeeding build. fix. The "incremental" strategy determines user needs and defines the system requirements. two of which will be prototypes distributed to a selected set of users. and making a decision on which strategy to use based on a trade-off among the risks and opportunities. Figures 4. An actual project would expand on these objectives. B. select an overall development strategy.5 Planning software builds and tailoring this standardB. An actual analysis may use others. All four figures are.5. B.5 Planning software builds and tailoring this standard Planning the software builds on a project for each build may be accomplished in several ways. and 6 show how this standard might be applied under each of the development strategies identified in B. The subclauses below provide guidelines for planning the builds and tailoring the standard without attempting to identify who performs each of the activities. B. and two of which will be distributed to all users.2. The approach selected will be project-dependent. the System/Subsystem Specification (SSS) already exists and fulfillment of its requirements is divided into four builds. without depicting early drafts or updates. . A further objective of Build 4 is transitioning the software to the designated maintenance organization.3 Selecting an appropriate The development strategy is selected by the acquirer. Figure 3 illustrates a risk analysis approach for selecting an appropriate strategy. for example. assigning each item a risk or opportunity level of High.5. The acquirer might. For example.J-STD-016-1998 Page 39 B.1 Identifying builds and their objectives The first step in software build planning is to lay out a series of one or more builds and to identify the objectives of each build. The approach consists of listing risk items (negatives) and opportunity items (positives) for each strategy. Alternatively. the acquirer might lay out the software builds as part of the contract.4 Relationship of this standard to development strategies The development strategy usually applies to the overall system. The fill-ins shown are sample considerations only. or iterative. Medium. Figure 7 shows how this standard might be applied on a reengineering project. The top part of figure 8 illustrates such planning.1 Identifying builds and their objectivesB. In the example. and they show each software product as a single entity. such as requiring that all software be finalized in the first build of the system. by necessity. simplified. The "DECISION" entry on the bottom line shows which strategy was selected.4 Relationship of this standard to development strategiesB. The software within the system may be acquired under the same strategy or under a different one. overlapping.3 Selecting an appropriate development strategy development strategyB. 5. leaving it to the developer to lay out the software builds. but may be proposed by prospective or selected developers. they show the standard's activities in sequence when they might actually be ongoing. or Low. Level H M H H Figure 3--Sample risk analysis for determining the appropriate development strategy . Level H M H Opportunity Item (Reasons to use this strategy) Early capability is needed System breaks naturally into increments Funding/staffing will be incremental User feedback and monitoring of technology changes is needed to understand full requirements DECISION: USE THIS STRATEGY Opp. Level M L Opportunity Item (Reasons to use this strategy) Early capability is needed System breaks naturally into increments Funding/staffing will be incremental Opp.J-STD-016-1998 Page 40 Once-Through Risk Item (Reasons against this strategy) Requirements are not well understood System too large to do all at once Rapid changes in technology anticipated--may change the requirements Limited staff or budget available now Opportunity Item (Reasons to use this strategy) User prefers all capabilities at first delivery User prefers to phase out old system all at once Risk Level H M H Incremental Risk Item (Reasons against this strategy) Requirements are not well understood User prefers all capabilities at first delivery Rapid changes in technology are expected--may change the requirements Risk Level H M H User prefers all capabilities at first delivery M Evolutionary Risk Item (Reasons against this strategy) Risk Level JSTD0161995 Page 40 - M Opp. ┌─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ─────────────────────┐ │ Project planning and oversight │ └─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ─────────────────────┘ SDP STP SIP/STrP ┌───────────┐ ┌────────┴─┐ SW Item│ ┌───────────┴─┐ Unit │ Qual ├────────────────┐ ┌──────────┐ Software Item 1: ┌───────────┴─┐ Software │ Integ/ │ Test │ │ │ Prepare │ ┌───────┴──┐ Software │ Implemen/ │ Test ├─────────┘ │ ┌──┤ for SW │ │ Software │ Design │ Unit Test ├────────┘ STR │ │ │ Use │ ┌─┤ Req'ts │ ├───────────┘ STD │ │ └──────────┘ │ │ Def'n ├──────────┘ │ │ Executable SW │ └──────────┘ SDD/IDD/DBDD │ ┌───────────┐ │ SVDs │ SRS/IRS ┌───────────┐ │ ┌────────┴──┐ System │ │ User/op manual │ ┌───────┴──┐SW Item │ │ │ SW/HW │ Qual ├──┤ │ ┌───────────┴─┐ Unit │ Qual ├──────┼────┤ Item │ Test │ │ ┌──────────┐ │ Software Item 2: ┌──────────┴─┐ Software │ Integ/ │ Test │ │ │ Integ/Test├────────┘ │ ┌───────────┐ ┌────────┴─┐ System │ │ ┌────────┴─┐ Software │ Implemen/ │ Test ├────────┘ │ └───────────┘STD STR │ │ Prepare │ │ System │ Design │ │ │ Software │ Design │ Unit Test ├────────┘ STR │ └──┤ for SW │ │ Req'ts │ ├─┼────────────┤ Req'ts │ ├───────────┘ STD │ │ Transition│ │ Def'n ├────────┘ │ │ Def'n ├──────────┘ │ └───────────┘ └──────────┘ SSDD/IDD│ └──────────┘ SDD/IDD/DBDD │ Executable SW OCD SSS/IRS │ SRS/IRS │ Source files │ │ SVDs │ │ SPSs │ ┌──────────────────────────────────────────────────┐ │ Updated SSDDs └──────────┤ Hardware item(s) (Not covered by this standard) ├─────────┘ Maintenance manuals └──────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ─────────────────────┐ │ SW devel environment, SW configuration management, SW product evaluation, SW quality assurance, corrective action, joint reviews, risk management, │ │ software management indicators, security/privacy protection, interface with IV&V, coordination with associate developers, improvement of project │ │ processes │ └─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ─────────────────────┘ J-ST D-01 6-19 95 Page 41 Note: All activities may be more ongoing, overlapping, and iterative than the figure is able to show. Figure 4--One possible way of applying this standard to the Once-Through development strategy BUILD 1: Establish system and software requirements and install software implementing a subset of those requirements at user sites ┌─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ─────────────────────┐ │ Project planning and oversight │ └─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ─────────────────────┘ SDP (focus on Build 1) STP for Build 1 ┌──────────┐ SIP for Build 1; Preliminary STrP ┌──────────┐ ┌────────┴─┐SW Item │ │ Prepare │ ┌───────────┴─┐ Unit │ Qual ├─────────────────┐ ┌──┤ for SW │ Software Item 1: ┌───────────┴─┐ Software │ Integ/ │ Test │ │ │ │ Use │ ┌───────┴──┐ Software │ Implemen/ │ Test ├────────┘ │ │ └──────────┘ │ Software │ Design │ Unit Test ├────────┘ STR for Build 1 │ │ Executable SW ┌─┤ Req'ts │ ├───────────┘ STD for Build 1 │ ┌───────────┐ │ SVDs │ │ Def'n ├──────────┘ ┌───────────┐ │ ┌────────┴──┐ System │ │ User/op manuals for │ └──────────┘ Partial SDD/IDD/DBDD ┌───────┴──┐SW Item │ │ │ SW/HW │ Qual ├──┤ Build 1 │ SRS/IRS* ┌───────────┴─┐ Unit │ Qual ├──────┼────┤ Item │ Test │ │ ┌──────────┐ │ ┌──────────┴─┐ Software │ Integ/ │ Test │ │ │ Integ/Test├────────┘ │ ┌────────────┐ ┌────────┴─┐ System │ │ SW Item 2:┌────────┴─┐ Software │ Implemen/ │ Test ├────────┘ │ └───────────┘STD STR │ │ (No │ │ System │ Design │ │ │ Software │ Design │ Unit Test ├────────┘ STR for │ for Build 1 └──┤ Software │ │ Req'ts │ ├─┼────────────┤ Req'ts │ ├───────────┘ STD for Build 1 │ │ Transition)│ │ Def'n ├────────┘ │ │ Def'n ├──────────┘ Build 1 │ └────────────┘ └──────────┘ SSDD/IDD*│ └──────────┘ Partial SDD/IDD/DBDD │ OCD* SSS/IRS* │ SRS/IRS* │ (All activities may be more │ │ ongoing, overlapping, and iterative *Intended to be │ ┌──────────────────────────────────────────────────┐ │ than the figure is able to show) complete and stable └──────────┤ Hardware item(s) (Not covered by this standard) ├─────────┘ └──────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ─────────────────────┐ │ SW devel environment, SW configuration management, SW product evaluation, SW quality assurance, corrective action, joint reviews, other activities │ └─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ─────────────────────┘ BUILD 2: Install the completed software at user sites and transition the software to the software maintenance organization ┌─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ─────────────────────┐ │ Project planning and oversight │ └─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ─────────────────────┘ SDP updated STP updated for Build 2 ┌──────────┐ SIP for Build 2; completed STrP ┌──────────┐ for Build 2 ┌────────┴─┐SW Item │ │ Prepare │ ┌───────────┴─┐ Unit │ Qual ├─────────────────┐ ┌──┤ for SW │ Software Item 1: ┌───────────┴─┐ Software │ Integ/ │ Test │ │ │ │ Use │ ┌───────┴──┐ Software │ Implemen/ │ Test ├────────┘ │ │ └──────────┘ │(Software │ Design │ Unit Test ├────────┘ STR for Build 2 │ │ Executable SW ┌─┤ Req'ts │ ├───────────┘ STD for Build 2 │ ┌───────────┐ │ SVDs │ │ Def'n) ├──────────┘ ┌───────────┐ │ ┌────────┴──┐ System │ │ User/op manuals for │ └──────────┘Complete SDD/IDD/DBDD ┌───────┴──┐SW Item │ │ │ SW/HW │ Qual ├──┤ Build 2 │ (SRS/IRS)* ┌───────────┴─┐ Unit │ Qual ├──────┼────┤ Item │ Test │ │ ┌──────────┐ │ ┌──────────┴─┐ Software │ Integ/ │ Test │ │ │ Integ/Test├────────┘ │ ┌───────────┐ ┌────────┴─┐(System │ │ SW Item 2:┌────────┴─┐ Software │ Implemen/ │ Test ├────────┘ │ └───────────┘STD STR │ │ Prepare │ │(System │ Design)│ │ │(Software │ Design │ Unit Test ├────────┘ STR for │ for Build 2 └──┤ for SW │ │ Req'ts │ ├───┼────────────┤ Req'ts │ ├───────────┘ STD for Build 2 │ │ Transition│ │ Def'n) ├────────┘ │ │ Def'n) ├──────────┘ Build 2 │ └───────────┘ └──────────┘(SSDD/IDD)* │ └──────────┘Complete SDD/IDD/DBDD │ Executable SW (OCD)* (SSS/IRS)* │ (SRS/IRS)* │ Source files │ │ SVDs *(Updated only if │ ┌──────────────────────────────────────────────────┐ │ SPSs, updated SSDDs necessary; not intended └──────────┤ Hardware item(s) (Not covered by this standard) ├─────────┘ Maintenance manuals to change) └──────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ─────────────────────┐ │ SW devel environment, SW configuration management, SW product evaluation, SW quality assurance, corrective action, joint reviews, other activities │ └─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── J-ST D-01 6-19 95 Page 42 ─────────────────────┘ Figure 5--One possible way of applying this standard to the Incremental development strategy BUILD 1: Establish preliminary system/software requirements and install a prototype implementing a subset of those requirements at selected user sites ┌─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ─────────────────────┐ │ Project planning and oversight │ └─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ─────────────────────┘ SDP (focus on Build 1) (No STP for Build 1: ┌──────────┐ SIP for Build 1; Preliminary STrP ┌──────────┐ no qual testing) ┌────────┴─┐ (No │ │ Prepare │ ┌───────────┴─┐ Unit │ Qual ├─────────────────┐ ┌──┤ for SW │ Software Item 1: ┌───────────┴─┐ Software │ Integ/ │ Test) │ │ │ │ Use │ ┌───────┴──┐ Software │ Implemen/ │ Test ├────────┘ │ │ └──────────┘ │ Software │ Design │ Unit Test ├────────┘ (No STR for Build 1) │ │ Executable SW ┌─┤ Req'ts │ ├───────────┘(No STD for Build 1) │ ┌───────────┐ │ SVDs │ │ Def'n ├──────────┘ ┌───────────┐ │ ┌────────┴──┐(No Sys │ │ User/op manuals for │ └──────────┘ Partial SDD/IDD/DBDD ┌───────┴──┐ (No │ │ │ SW/HW │ Qual ├──┤ Build 1 │ Partial SRS/IRS ┌───────────┴─┐ Unit │ Qual ├──────┼────┤ Item │ Test) │ │ ┌──────────┐ │ ┌──────────┴─┐ Software │ Integ/ │ Test) │ │ │ Integ/Test├────────┘ │ ┌────────────┐ ┌────────┴─┐ System │ │ SW Item 2:┌────────┴─┐ Software │ Implemen/ │ Test ├────────┘ │ └───────────┘(No STD/STR│ │ (No │ │ System │ Design │ │ │ Software │ Design │ Unit Test ├────────┘ (No STR for │ for Build 1)└──┤ Software │ │ Req'ts │ ├─┼────────────┤ Req'ts │ ├───────────┘(No STD for Build 1) │ │ Transition)│ │ Def'n ├────────┘ │ │ Def'n ├──────────┘ Build 1) │ └────────────┘ └──────────┘ SSDD/IDD*│ └──────────┘ Partial SDD/IDD/DBDD │ OCD* SSS/IRS* │ Partial SRS/IRS │ (All activities may be more │ │ ongoing, overlapping, and iterative *Preliminary/ │ ┌──────────────────────────────────────────────────┐ │ than the figure is able to show) partial └──────────┤ Hardware item(s) (Not covered by this standard) ├─────────┘ └──────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ─────────────────────┐ │ SW devel environment, SW configuration management, SW product evaluation, SW quality assurance, corrective action, joint reviews, other activities │ └─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ─────────────────────┘ BUILD 2: Refine and complete the requirements; install the completed software at user sites; transition the software to the SW maintenance organization ┌─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ─────────────────────┐ │ Project planning and oversight │ └─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ─────────────────────┘ SDP updated STP for Build 2 ┌──────────┐ SIP for Build 2; completed STrP ┌──────────┐ for Build 2 ┌────────┴─┐SW Item │ │ Prepare │ ┌───────────┴─┐ Unit │ Qual ├─────────────────┐ ┌──┤ for SW │ ┌───────────┴─┐ Software │ Integ/ │ Test │ │ │ │ Use │ Software Item 1:┌───────┴──┐ Software │ Implemen/ │ Test ├────────┘ │ │ └──────────┘ │ Software │ Design │ Unit Test ├────────┘ STR for Build 2 │ │ Executable SW ┌─┤ Req'ts │ ├───────────┘ STD for Build 2 │ ┌───────────┐ │ SVDs │ │ Def'n ├──────────┘ ┌───────────┐ │ ┌────────┴──┐ System │ │ User/op manuals for │ └──────────┘ SDD/IDD/DBDD* ┌───────┴──┐SW Item │ │ │ SW/HW │ Qual ├──┤ Build 2 │ SRS/IRS* ┌───────────┴─┐ Unit │ Qual ├──────┼────┤ Item │ Test │ │ ┌──────────┐ │ ┌──────────┴─┐ Software │ Integ/ │ Test │ │ │ Integ/Test├────────┘ │ ┌───────────┐ ┌────────┴─┐ System │ │ SW Item 2:┌────────┴─┐ Software │ Implemen/ │ Test ├────────┘ │ └───────────┘STD STR │ │ Prepare │ │ System │ Design │ │ │ Software │ Design │ Unit Test ├────────┘ STR for │ for Build 2 └──┤ for SW │ │ Req'ts │ ├───┼────────────┤ Req'ts │ ├───────────┘ STD for Build 2 │ │ Transition│ │ Def'n ├────────┘ │ │ Def'n ├──────────┘ Build 2 │ └───────────┘ └──────────┘ SSDD/IDD*│ └──────────┘ SDD/IDD/DBDD* │ Executable SW OCD* SSS/IRS* │ SRS/IRS* │ Source files │ │ SVDs * Refined from Build 1 │ ┌──────────────────────────────────────────────────┐ │ SPSs, updated SSDDs and completed └──────────┤ Hardware item(s) (Not covered by this standard) ├─────────┘ Maintenance manuals └──────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ─────────────────────┐ │ SW devel environment, SW configuration management, SW product evaluation, SW quality assurance, corrective action, joint reviews, other activities │ J-ST D-01 6-19 95 Page 44 └─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ─────────────────────┘ Figure 6--One possible way of applying this standard to the Evolutionary development strategy . SW quality assurance. risk management. derive system │ ┌───────────┴──┐Software │ Integ/ │ Test │ reeng'd SW design/req'ts. improvement of project │ │ process │ └─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ─────────────────────┘ J-ST D-01 6-19 95 Page 46 .────────────────────────────────────────────────────────────REENGINEERING──────────────────────────────────────────────────────── ───────────────── ───────────────────────────FORWARD ENGINEERING─────────────────────────────────────────────────────────────────── ┌─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ────────────────────┐ │ Project planning and oversight │ └─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ────────────────────┘ SDP STP SIP/STrP REDOCUMENTATION ──TRANSLATION── ┌──────────┐ Software Item 1: Translate ┌────────┴─┐SW Item │ to Ada ┌───────────┴─┐ Unit │ Qual ├─────────┐ ┌───────────┴──┐Software │ Integ/ │ Test │ │ ┌───────┴──┐Software │Implemen/ │ Test ├────────┘ │ │SW Req'ts │Design: │Unit Test:├────────┘ STR │ ┌┤Def'n: │revise and │translate │ STD │ ││redocument│redocument │software │ │ ┌──────────┐ ││derived │derived des├──────────┘ │ │ Prepare │ ││req'ts ├───────────┘ │ │ for SW │ │└──────────┘ SDD/IDD/DBDD │ ┌─┤ Use │ │ SRS/IRS │ │ └──────────┘ │ │ │ Executable SW │ REDOCUMENTATION ──RESTRUCTURING── │ ┌───────────┐ │ SVDs │ ┌─────────┐ │ ┌───────┴───┐System │ │ User/op manuals │ SW Item 2: Restructure ┌───────┴─┐SW Item│ │ │ SW/HW │Qual ├─┤ REVERSE ENGINEERING │ to object-oriented ┌────────────┴─┐ Unit │ Qual ├─┼─┤ Item │Test │ │ │ ┌───────────┴──┐Software │ Integ/│ Test │ │ │ Integ/Test├───────┘ │ ┌─────────┐ ┌──────────┐ ┌────────┐ │ ┌────────┴─┐Software │Implemen/ │ Test ├───────┘ │ └───────────┘STD STR │ ┌───────────┐ │ System │ ┌──────┴─┐SW │ │ System │ │ │SW Req'ts │Design: │Unit Test: ├───────┘ STR │ │ │ Prepare │ │ Req'ts ├─┤Software│Req'ts ├──┤ Design ├─┼────────┤Def'n: │restructure/│restructure│ STD │ └─┤ for SW │ │ Def'n │ │Design │Def'n │ │ ││ │redocument│redocument │software │ │ │ Transition│ └─────────┘ │ ├────────┘ └────────┘ │ │derived │derived des ├───────────┘ │ └───────────┘ OCD SSS/IRS└────────┘ Derived SSDD/IDD│ │req'ts ├────────────┘ │ Executable SW │ Derived │ req'ts │ │ └──────────┘ SDD/IDD/DBDD │ Source files │ design │ of legacy │ │ SRS/IRS │ SVDs │ of legacy│ software │ │ │ SPSs │ software │ │ │ REDOCUMENTATION ──RETARGETING── │ Updated SSDDs │ ┌──────────┐ │ Maintenance manuals Determine Collect existing Design │ SW Item 3: Retarget to ┌────────┴─┐SW Item │ │ req'ts software products. coordination with associate developers. overlapping. and SRS/IRS iterative than the figure is able to show) ┌─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ─────────────────────┐ │ SW devel environment. joint reviews. SW product evaluation. │ │ software management indicators. SW configuration management. reeng'd │ new computer ┌───────────┴─┐ Unit │ Qual ├────┘ for analyze them. corrective action. based on │ ┌────────┴──┐Software │Implemen/ │ Test ├────────┘ system derive system findings │ │SW Req'ts │Design: │Unit Test:├────────┘ STR design/req'ts for └────┤Def'n: │revise and │retarget │ STD a software system │revise and │redocument │software │ │redocument │derived des├──────────┘ │derived req├───────────┘ (All activities may be more └───────────┘ SDD/IDD/DBDD ongoing. interface with IV&V. security/privacy protection. Figure 7--One possible way of applying this standard to a reengineering project . the acquirer may set forth general milestones and have the developer provide specifics or may provide specific schedules. Some activities will not apply at all in a given build. . Those involving contractual changes are handled accordingly. completion of the worksheet may itself be incremental.4 Scheduling the selected activities in each buildB. Flexibility in the scheduling of software units can also be effective. B. Refinements to the tailoring decisions may be ongoing as the project proceeds. For example. Tailoring proposed by the developer may be communicated via feedback on draft requests for proposal. The activities in each build are to be laid out in the manner that best suits the work to be done.5. As with tailoring. such formalities may be appropriate from the start. The following guidelines apply: a) Different decisions will apply to different types of software on a project.5. developing "throw-away" software to arrive at a system concept or system requirements. the figure shows that each build will include software development planning (5. Several may be taking place at one time. The following guidelines apply: a) A common mistake is to treat all software items as though they are required to be developed in "lock-step. and some will apply differently in different builds. proposals.1. such as number and type of software items. If the early software will be used later.2 Identifying the activities to be performed in each build The next step in build planning is identifying which activities apply in each build and determining the extent to which they apply. b) If early builds are devoted to experimentation. These decisions are project-dependent. that will be imposed later on the "real" software.5.2 Identifying the activities to be performed in each buildB.5. joint reviews during the project." all designed by a certain date.J-STD-016-1998 Page 48 B.1). b) A similar mistake is to treat software units as though they are required to be developed in "lock-step. the Software Development Plan.5. may not have been identified at the time the worksheet is being filled out.5. The activities of figure 8 show the start of this tailoring.3 Recording tailoring decisionsB.3 Recording tailoring decisions Tailoring decisions made by the acquirer before the project begins are specified in the contract. c) The activities in this standard need not be performed sequentially. Listed on the left are the subclauses of this standard. These differences can be shown within the entries of one worksheet or by using different worksheets for different types of software on a project. implemented by a certain date. and an activity may be performed continually or intermittently throughout a build or over multiple builds. it may be appropriate to forgo certain formalities. some will apply identically in all builds. The worksheet entries indicate in which builds each activity is to be performed and include any notes regarding the nature of each activity in each build." reaching key milestones at the same time. Allowing software items to be on different schedules can result in more optimum development. or by other means of communication. Since some aspects of the project.4 Scheduling the selected activities in each build Another important step in build planning is scheduling the activities in each build. B. etc. such as coding standards. but that the nature of that planning changes in each build. . Indicate below which activities are to be accomplished during the development of each build.1 5.BUILD PLANNING WORKSHEET 1 1.1. SSS-1250 2 Deliver to selected users an operational prototype that meets the requirements of Build 1 plus: SSS-2.2 Yes: For those plans that are in effect Yes: Update as needed for Build 3 Yes: Set up fully for Build 3 qual testing Yes: Update as needed for Build 4 Yes: Update as needed for Build 4 qual testing Figure 8--Example of build planning . SSS-3.1 Activity PROJECT PLANNING AND OVERSIGHT Plan the software development effort Plan for software item qualification testing Plan for system qualification testing Plan for installing software at user sites Plan for transitioning software to the maintenance organization Follow plans. ...1.2 Yes: Update for software item qual testing in this build Yes: Update for system qual testing in this build Yes: Update as needed for installation of Bld 4 Yes: Finalize transition planning Yes: For those plans that are in effect 5.2.5 5...1. SSS-10.1 5.1.1.6 5. SSS-7. Para 5. Builds 3-4 in general No: No software item qual testing in this build No: No system qual testing in this build No: Let users install on their own Yes: Update preliminary plans Deliver to selected users an operational prototype that meets the following system-level requirements: SSS-1.2.1. SSS-15.2 5..4 5. SSS-1249 Build 3 Deliver to all users a tested system that meets the requirements of Builds 1 and 2 plus: SSS-4. Identify at right the objectives of each build 2.. Builds 2-4 in general No: No software item qual testing in this build No: No system qual testing in this build No: Let users install on their own Yes: Very preliminary planning only Yes: For those plans that are in effect Yes: Plan Build 2 in detail.3 5. SSS-5. . . SSS-1248 4 Deliver to all users a tested system that meets all system-level requirements.. Build 4 in general Yes: Plan for software item qual testing in this build Yes: Plan for system qual testing in this build Yes: Plan to install at user sites Yes: Update preliminary plans Yes: For those plans that are in effect Yes: Plan Build 4 in detail 5. Add clarifying notes as needed.. transition to designated maintenance organization J-ST D-01 6-19 95 Page 49 Yes: Plan Build 3 in detail. perform management review ESTABLISHING A SOFTWARE DEVEL ENVIRONMENT Establish a software engineering environment Establish a software test environment Yes: As needed for Build 1 Yes: As needed for Build 1 testing Yes: Update as needed for Build 2 Yes: As needed for Build 2 testing Yes: Plan Build 1 in detail. and other variations to optimize the software development effort. It is informative only. staggered development of software items. If the contract lays out a strict "waterfall" sequence of deliverables.5 Tailoring the content . In addition.1 Scope This annex provides guidance to the acquirer on the deliverables to be required on a software development project. to the maximum extent possible. Final agreement on scheduling can take place at that time. provided to aid in using this standard. While this form works well for some deliverables. the door is left open for incremental delivery of software products.5 Tailoring the content requirements for deliverablesC. A key objective of this wording is to eliminate the notion that the acquirer is required to order a given deliverable in order to have planning or engineering work take place.2 Ordering deliverables This standard has been worded to differentiate between the planning/engineering activities that make up a software development project and the generation of deliverables. the planning and engineering work takes place regardless of which deliverables are ordered. Another variation is specifying that a paper or word processor document is to include required contents but may be in the developer's format and structure. the contract avoids such pre-determination. Figure 10 in annex K provides information helpful in deciding whether the corresponding deliverable is to be ordered. Yet another variation is allowing deliverables to take forms that are not traditional documents at all.3 Scheduling deliverablesC. C. and alternatives are to be considered. and change. This saves paper. C. little room is left to develop the software items in an optimum order. One variation from paper documents is word processing files containing those documents. The developer's Software Development Plan will lay out a proposed schedule that meets the constraints in the contract. joint technical reviews have been included to review the results of that work in its natural form. but still requires the developer to format and structure the information in a particular way. If. All of this flexibility can be canceled by rigid scheduling of deliverables in the contract. These variations can be specified in the contract.J-STD-016-1998 Page 50 Annex CAnnex C Guidance on ordering deliverablesGuidance on ordering deliverables (informative) C. C. If the contract forces all software items into lock-step with each other. recognizing that this transformation requires time and effort that would otherwise be spent on the engineering effort.3 Scheduling deliverables This standard has been structured to support a variety of development strategies and to provide the developer flexibility in laying out a software development process that will best suit the work to be done.4 Format of deliverablesC. is less expensive to duplicate. Under this standard. unless a given activity is tailored out of the standard.2 Ordering deliverablesC. without the generation of deliverables. little room is left to propose innovative development processes.1 ScopeC.4 Format of deliverables Traditional deliverables take the form of paper documents exactly following required formats and structures. such as data in computer-aided software engineering (CASE) tools. Deliverables are to be ordered only when there is a genuine need to have planning or engineering information transformed into a deliverable (such as deliverables needed for use or maintenance of the software). it is not the only form. transport. C. . or adding requirements as needed.J-STD-016-1998 Page 51 requirements for deliverables Tailoring the content requirements for deliverables consists of deleting from the software product contents clauses of annexes E through J any requirements for unneeded information. It can also consist of changes such as combining two or more documents under one cover. altering requirements to more explicitly reflect the application to a particular effort. 1 Scope This annex interprets this standard when applied to the incorporation of reusable software products. security. D.and long-term cost impacts of using the software product i) Technical. including: 1) Likelihood the software product will need to be changed 2) Feasibility of accomplishing that change 3) Availability and quality of documentation and source files 4) Likelihood that the current version will continue to be maintained by the developer 5) Impact on the system if the current version is not maintained 6) The acquirer's usage and ownership rights to the software product 7) Warranties available h) Short. including: 1) Restrictions on copying/distributing the software or documentation 2) License or other fees applicable to each copy g) Maintainability. For example. cost. as evidenced by established track record Testability Interoperability with other system and system-external elements Distribution issues. specification. a requirement may be met by using an existing plan. and schedule risks and tradeoffs in using the software product D.1 ScopeD.3 Interpreting this standard's activities for reusable software products The following rules can be applied in interpreting this standard: a) Any requirement that calls for development of a software product may be met by a reusable software product that fulfills the requirement and meets the criteria established in the Software Development Plan. provided to aid in using this standard. .3 Interpreting this standard's activities for reusable software productsD. but are not limited to: a) b) c) d) e) f) Ability to provide required capabilities and meet required constraints Ability to provide required safety. or design. The reusable software product may be used as-is or modified and may be used to satisfy part or all of the requirement.2 Evaluating reusable software products The criteria for use in evaluating reusable software products will be described in the developer's SDP. It is informative only. and privacy protection Reliability/maturity. Examples of candidate criteria that may be used include.J-STD-016-1998 Page 52 Annex DAnnex D Interpreting this standard for incorporation of reusable software productsInterpreting this standard for incorporation of reusable software products (informative) D.2 Evaluating reusable software productsD. Key issues are whether the software will be modified. some of the requirements in this standard require special interpretation. The figure is presented in a conditional manner: if an activity in the left column is required for a given type of software. .J-STD-016-1998 Page 53 b) When the reusable software product to be incorporated is the software itself. Figure 9 provides this interpretation. and whether unmodified software has a positive performance record (no firm criteria exist for making this determination). whether unmodified software constitutes an entire software item or only one or more software units. the figure tells how to interpret the activity for reusable software of that type. 6.4. allocate system requirements to it Specify the project-specific requirements the software item is required to meet.2 System architectural design 5.6.3 Software item detailed design 5.1 Software implementation 5.2 Software item architectural design 5.7.6. and software development files as appropriate to perform the activities in this figure Apply full requirements Consider software's capabilities in defining the operational concept & system requirements Use test/ performance records to confirm ability to meet needs 5.13) No requirement: the software for the software item's units is already implemented No requirement: the software items's units are already tested Perform selectively if in question and units are accessible Consider the unit's capabilities and characteristics in designating software items and allocating system requirements to them Consider the unit's capabilities and characteristics in specifying the requirements for the software item of which it is a part Consider the unit's capabilities and characteristics in designing software item behavior and making other software item-wide design decisions Include the unit in the software item architecture and allocate software item requirements to it No requirement: the unit is already designed (recording the "as built" design is under 5.2 Establishing software devel environment 5.5 Unit testing Perform this testing Figure 9--Interpreting this standard for incorporation of reusable software . software development library.3 System requirements definition No or poor performance record Positive performance record No or poor performance record Include the activities in this figure in project plans Establish and apply a software test environment.1 Software item-wide design Test to confirm ability to meet needs Use test/ performance records to confirm ability to meet needs Test to confirm ability to meet needs Use tests or records to determine potential to meet needs Consider the software's capabilities and characteristics in designing system behavior and in making other system-wide design decisions Include the software item in the system architecture.J-STD-016-1998 Page 54 Interpret the activity as follows for each type of existing.13) No requirement: the software for the unit is already implemented No requirement: the unit is already tested Modify the unit's design as needed Modify the software for the unit 5.7.1 Systemwide design 5.7.13) No requirement: the detailed design is already defined (recording the "as built" design is under 5.4. verify via records or retest that the software item can meet them No requirement: the software item-wide design decisions have already been made (recording the "as built" design is under 5.1 Project planning and oversight 5.2-5.13) No requirement: the architectural design is already defined (recording the "as built" design is under 5.5 Software requirements definition 5. reusable software: If this activity is required: For software items to be used unmodified For software units to be used unmodified For software units being modified for/ during project Positive performance record 5. reusable software: If this activity is required: For software items to be used unmodified Positive performance record 5. modified. install the software item or unit as part of the overall system. handle any license issues. or used in incorporating this software 5.5. new. prepare or provide "as built" design descriptions for software whose design is known. except where integra-tion is already tested/proven No or poor performance record Perform selectively if in question and units are accessible Perform this testing For software units to be used unmodified Positive performance record Perform except where integra-tion is already tested/proven No or poor performance record Perform this testing For software units being modified for/ during project Include the unit in software item qualification testing Include the software item in SW/HW item integration and testing Include the unit in software/hardware item integration and testing Include the software item in system qualification testing Include the unit in system qualification testing Include the software for the software item or unit in the executable software. cover use of the software item or unit.16 Software quality assurance 5. handle any license issues. via existing. if applicable Figure 9--Interpreting this standard for incorporation of reusable software -.18 Joint reviews 5. include its use. or used in incorporating this software Apply to all activities performed and all software products prepared or modified in incorporating this software Cover the software products prepared or modified in incorporating this software Apply the full requirements of each of these 6 clauses.17 Corrective action 5.J-STD-016-1998 Page 55 Interpret the activity as follows for each type of existing.25 Other activities Apply to all software products prepared or modified in incorporating this software. modified.15 Software product evaluation 5.10 Software/ hardware item integration and testing 5.11 System qualification testing 5. install the software item or unit at the maintenance site. if available. demonstrate regenerability if source is available.13 Preparing for software transition 5. or revised user/operator manuals.(continued) . prepare source files for the software item or unit. include in version descriptions.8 Unit integration and testing 5. in the training offered Include the software for the software item or unit in the executable software. as appropriate.12 Preparing for software use No requirement: the SW items units are already integrated No requirement: software item is already tested & proven Perform. include in the training offered Apply to all software products prepared.9 Software item qualification testing 5.19 . as appropriate.14 Software configuration management 5. for software products used unchanged. apply unless a positive performance record or evidence of past evaluations indicates that such an evaluation would be duplicative Apply to all activities performed and all software products prepared. include in version descriptions. This annex is a normative (that is. E.1 Scope This annex specifies the contents of software products associated with planning in this standard.2 Software products covered This following subclauses describe the contents of the software products covered by this annex. subject to tailoring.2 Software products coveredE.1 ScopeE. It applies regardless of whether the software products are deliverable.J-STD-016-1998 Page 56 Annex EAnnex E Planning software product descriptionsPlanning software product descriptions (normative) E. The products are listed in the order they are referenced in this standard and include the following: a) b) c) d) Software Development Plan (SDP) Software Test Plan (STP) Software Installation Plan (SIP) Software Transition Plan (STrP) . binding) part of this standard. (continued) 5.1 4.2.1 5.2 5.8 Software development methods Standards and practices for software products Traceability Reusable software products Handling of critical requirements Computer hardware resource utilization Recording rationale Access for acquirer review 5.5 Software development planning (covering updates to this plan) Software item test planning System test planning Software installation planning Software transition planning Following and updating plans.4 2.6 5.6 4.1 Contents of the Software Development Plan (SDP) SOFTWARE DEVELOPMENT PLAN (SDP) Contents 1.4 5.2.2.2 1.5 4.4 4.J-STD-016-1998 Page 57 E.2 Software development process General plans for software development 4.2.2 4.1.2.4 5.1.3 5.3 1.2.1 Contents of the Software Development Plan (SDP)E. Plans for performing detailed software development activities 5. Identification System overview Document overview Relationship to other plans Referenced documents Overview of required work Plans for performing general software development activities 4. 4.1 4.3 System requirements definition 5.2 5.1. Scope 1. 3.1 Project planning and oversight 5.2.1 Analysis of user input Establishing a software development environment .1.2.5 5.2. including the intervals for management review Software engineering environment Software test environment Software development library Software development files Non-deliverable software Software Development Plan (SDP) -.1.2 5.3 4.1 5.2.3.7 4.3 5.1.1 1.2.2.2.2.2. 9.1 Independence in software item qualification testing 5.8.2 Preparing for unit testing 5.9.9 Software item qualification testing 5.4.2 System architectural design 5.3 Performing unit testing 5.4 Dry run of software item qualification testing 5.J-STD-016-1998 Page 58 5.9.8.3 Revision and retesting 5.9.9.7 Software implementation and unit testing 5.2 Operational concept 5.5 Performing software item qualification testing 5.1 Preparing for unit integration and testing 5.2 Software item architectural design 5.8.7 Analyzing and recording software item qualification test results .9.7.6 Revision and retesting 5.1 Software item-wide design decisions 5.6.3 Software item detailed design 5.3 System requirements 5.7.1 System-wide design decisions 5.6.6.2 Performing unit integration and testing 5.3.4 System design 5.3 Preparing for software item qualification testing 5.7.1 Software implementation 5.2 Testing on the target computer system 5.6 Software design 5.4 Analyzing and recording unit integration and test results 5.8.4.7.5 Software requirements definition 5.4 Revision and retesting 5.7.8 Unit integration and testing 5.5 Analyzing and recording unit test results 5.9.3. 3 5.11.4 5.12.4 5.13.10.11.13.6 5.8 5.1 5.12Preparing for software use 5.3 5.7 5.3 5.13.5 5.10.7 5.12.13Preparing for software transition .11.10.13.11.9 Preparing for software/hardware item integration and testing Performing software/hardware item integration and testing Revision and retesting Analyzing and recording software/hardware item integration and test results Independence in system qualification testing Testing on the target computer system Preparing for system qualification testing Dry run of system qualification testing Performing system qualification testing Revision and retesting Analyzing and recording system qualification test results Preparing the executable software Preparing version descriptions for user sites Preparing user manuals Installation at user sites Preparing the executable software Preparing source files Preparing version descriptions for the maintenance site Preparing the "as built" software item design and other software maintenance information Updating the system design description Updating the software requirements specification Updating the system/subsystem specification Preparing maintenance manuals Transition to the designated maintenance site 5.2 5.1 5.3 5.6 5.(continued) 5.11.5 5.13.13.11.4 5.J-STD-016-1998 Page 59 Software Development Plan (SDP) -.10Software/hardware item integration and testing 5.10.12.2 5.12.13.11.2 5.2 5.1 5.13.11System qualification testing 5.1 5.4 5.13. including a proposed set of reviews Joint management reviews. handling.20Software management indicators 5.2 5.1 5.14. Annexes .24Coordinating with associate developers 5.1 5. including items to be recorded Independence in software product evaluation Software quality assurance evaluations Software quality assurance records. Schedules and activity network 7.14.14Software configuration management 5. including a proposed set of reviews 5.1 5.2 5.1 Project organization 7.1 5.25Project process improvement 6.4 5.2 5.17Corrective action 5.15.3 5.2 5.18Joint technical and management reviews 5.3 5.5 5.15.19Risk management 5.3 5.1 5.17.18. and delivery In-process and final software product evaluations Software product evaluation records.22Managing subcontractors 5.2 Project resources 8.16.16.(continued) 5.J-STD-016-1998 Page 60 Software Development Plan (SDP) -.17. including items to be recorded Corrective action system Joint technical reviews. including items to be recorded Independence in software quality assurance Problem/change reports.16Software quality assurance 5.2 Configuration identification Configuration control Configuration status accounting Configuration audits Packaging.14. Notes A.15Software product evaluation 5.14. storage.14.16.15.21Administrative security and privacy protection 5.23Interfacing with software IV&V agents 5.18. Project organization and resources 7. 1.2 System overview. This clause should be divided into subclauses as needed to establish the context for the planning described in later clauses. acquirer. methods. 1. including. these differences shall be noted in the subclauses. operation. e. plans for dealing with those risks/uncertainties. and maintenance organizations. interdependencies in hardware and software development. 1.1 Identification. if any. This subclause shall briefly state the purpose of the system and the software to which this document applies. identify the project sponsor. and source of all documents referenced in this manual. 2. Provisions corresponding to non-required activities may be satisfied by the words "Not applicable. of the SDP to other project management plans. abbreviation(s). revision." If different builds or different software on the project require different planning.3 Document overview. each subclause shall identify applicable risks/uncertainties. This clause should be divided into the following subclauses. user. date. d. In addition to the content specified below. such as on project security.4 Relationship to other plans. This subclause shall describe the relationship. privacy protection. This subclause shall summarize the purpose and contents of this document and shall describe any security or privacy protection considerations associated with its use. etc. as applicable. This clause shall list the number. and shall cover all contractual clauses regarding the identified topic. Requirements and constraints on the system and software to be developed Requirements and constraints on project documentation Position of the project in the system life cycle The selected development/acquisition strategy. standards. Overview of required work. any requirements or constraints on it Requirements and constraints on project schedules and resources Other requirements and constraints. title. version number(s).(continued) 1. b. f. and release number(s). . 1.J-STD-016-1998 Page 61 Software Development Plan (SDP) -. identify current and planned operating sites. It shall describe the general nature of the system and software. as applicable. This clause should be divided into the following subclauses. 3. Plans for performing general software development activities. an overview of: a. 4. This subclause shall contain a full identification of the system and the software to which this document applies. and maintenance. developer. Referenced documents. It shall include. c. title(s). identification number(s). and list other relevant documents. summarize the history of system development. Scope. and the software development activities to be performed in each build. This subclause shall describe or reference the software development methods to be used. etc. 4.4 Reusable software products.(continued) 4. limitations.2 Standards and practices for software products.2. packages. They shall include at a minimum: a. f. including the scope of the search for such products and the criteria to be used for their evaluation and incorporation. Standards for format (such as indentation. etc. Reference may be made to other subclauses in this plan if the methods are better described in context with the activities to which they will be applied. Restrictions.2 General plans for software development. e. 4. variables. name/identifier of the code. 4. This subclause shall describe or reference the standards and practices to be followed for representing requirements.1 Software development methods. together with benefits.1 Software development process. d. and restrictions. purpose. modification history. design. for example.2.J-STD-016-1998 Page 62 Software Development Plan (SDP) -. 4. Reference may be made to other subclauses in this plan if the standards are better described in context with the activities to which they will be applied.2. Standards for code shall be provided for each programming language to be used. associated with their use. Included shall be descriptions of the manual and automated tools and procedures to be used in support of these methods. This subclause shall describe the software development process to be used. . This subclause shall describe the approach to be followed for performing upward and downward traceability. test cases. and incorporating reusable software products. files.2. code. evaluating. notes on the processing (such as algorithms used. if any. outputs. test procedures. and test results. capitalization. Candidate or selected reusable software products known at the time this plan is prepared or updated shall be identified and described. their objectives. b. requirements and design decisions implemented. This subclause shall describe the approach to be followed for identifying. version identification. and side effects). data structures. if applicable. if any. on the complexity of code aggregates c. procedures. as applicable. The planning shall identify planned builds. on the use of programming language constructs or features Restrictions. parameters. 4. constraints.) Standards for other comments (such as required number and content expectations) Naming conventions for variables. This subclause should be divided into the following. drawbacks.3 Traceability. and order of information) Standards for header comments (requiring. and notes on the data (inputs. assumptions. spacing. and other critical requirements.7 Recording rationale. Plans for performing detailed software development activities.2.2.2. and shall cover all contractual clauses regarding the identified topic.4 Software development files 5.2. controlling.1. plans for dealing with those risks/uncertainties.1 if applicable methods are described there. including the intervals for management review 5.3 System test planning 5.2 Software item test planning 5.5 Non-deliverable software ." If different builds or different software on the project require different planning. The discussion shall also identify applicable risks/uncertainties.6 Computer hardware resource utilization. 4. privacy protection. if applicable. 2) the recording of results. security. This subclause shall describe the approach to be followed for allocating computer hardware resources and monitoring their utilization.1 Project planning and oversight. these differences shall be noted in the subclauses. This subclause should be divided into the following to describe the approach to be followed for project planning and oversight.1.1.1. 5.3 Software development library 5.8 Access for acquirer review.2 Software test environment 5. 4. 5.(continued) 4.4 Software installation planning 5. This clause should be divided into the following subclauses. and handling safety.2.5 Handling of critical requirements. This subclause shall describe the approach to be followed for recording rationale that will be useful to the maintenance organization for key decisions made on the project.2.1. 5.2. Provisions corresponding to non-required activities may be satisfied by the words "Not applicable.2 Establishing a software development environment.2.1. The discussion of each activity shall include the approach (methods/procedures/tools) to be applied to: 1) the analysis or other technical tasks involved.1 Software engineering environment 5. This subclause shall describe the approach to be followed for providing the acquirer or its authorized representative access to developer and subcontractor facilities for review of software products and activities. and maintaining a software development environment. developing strategies for.6 Following and updating plans. This subclause should be divided into the following to describe the approach to be followed for establishing. This subclause shall describe the approach to be followed for identifying.J-STD-016-1998 Page 63 Software Development Plan (SDP) -. 4. 5. and 3) the preparation of associated deliverables.2. It shall interpret the term "key decisions" for the project and state where the rationale are to be recorded.2.5 Software transition planning 5. Reference may be made to 4.1 Software development planning (covering updates to this plan) 5. 2 Performing unit integration and testing 5. This subclause should be divided into the following to describe the approach to be followed for unit integration and testing.4 Revision and retesting 5.5 Software requirements definition.6.2 System architectural design 5.4 Analyzing and recording unit integration and test results .(continued) 5.8 Unit integration and testing. 5.3.3 System requirements 5.6.3 Performing unit testing 5. This subclause should be divided into the following to describe the approach to be followed for software design.J-STD-016-1998 Page 64 Software Development Plan (SDP) -.1 System-wide design decisions 5.7. 5.8. This subclause should be divided into the following to describe the approach to be followed for participating in system requirements definition. 5.8. This subclause should be divided into the following to describe the approach to be followed for participating in system design. 5. This subclause should be divided into the following to describe the approach to be followed for software implementation and unit testing.3.2 Preparing for unit testing 5.7 Software implementation and unit testing. 5.6 Software design.6.7.5 Analyzing and recording unit test results 5.8.3 System requirements definition.4.8.3 Software item detailed design 5.7.7.7.4 System design. 5.2 Software item architectural design 5.3.2 Operational concept 5.1 Analysis of user input 5. This subclause shall describe the approach to be followed for software requirements definition.1 Preparing for unit integration and testing 5.3 Revision and retesting 5.1 Software item-wide design decisions 5.4.1 Software implementation 5. 2 Testing on the target computer system 5.6 Revision and retesting 5.5 5.1 5.11.12.9 Software item qualification testing.4 Preparing the executable software Preparing version descriptions for user sites Preparing user manuals Installation at user sites .12.12.9.9.2 5. This subclause should be divided into the following to describe the approach to be followed for preparing for software use.3 5.9.11 System qualification testing.10.7 Analyzing and recording software item qualification test results 5.11.J-STD-016-1998 Page 65 Software Development Plan (SDP) -. This subclause should be divided into the following to describe the approach to be followed for participating in software/hardware item integration and testing.4 Dry run of software item qualification testing 5.3 5.1 Independence in software item qualification testing 5.11.1 5. This subclause should be divided into the following to describe the approach to be followed for software item qualification testing.2 5.3 5. 5.9.4 5.2 5.9.1 5.11.(continued) 5.9. 5. 5.11.11.10.3 Preparing for software item qualification testing 5.10.6 5.7 Independence in system qualification testing Testing on the target computer system Preparing for system qualification testing Dry run of system qualification testing Performing system qualification testing Revision and retesting Analyzing and recording system qualification test results 5.10 Software/hardware item integration and testing.9. 5.5 Performing software item qualification testing 5.12 Preparing for software use. This subclause should be divided into the following to describe the approach to be followed for participating in system qualification testing.11.4 Preparing for software/hardware item integration and testing Performing software/hardware item integration and testing Revision and retesting Analyzing and recording software/hardware item integration and test results 5.10.12. 3 5.13.13.13. category and priority.1 5.1 5.4 5. version where corrected.16.14 Software configuration management.15.14.13. recommended solution.2 5.13.17. originator. 5.15 Software product evaluation.1 5.1 Problem/change reports. correction date.2 5. storage.15.17 Corrective action. 5. including items to be recorded (candidate items include project name. This subclause should be divided into the following to describe the approach to be followed for software product evaluation. problem name.(continued) 5.13.8 5. description of solution implemented) Corrective action system 5.13 Preparing for software transition. This subclause should be divided into the following to describe the approach to be followed for corrective action.5 5.13. approval of solution. analysis time. origination date.3 In-process and final software product evaluations Software product evaluation records.13. This subclause should be divided into the following to describe the approach to be followed for software configuration management.16.3 Software quality assurance evaluations Software quality assurance records. date completed. This subclause should be divided into the following to describe the approach to be followed for preparing for software transition.J-STD-016-1998 Page 66 Software Development Plan (SDP) -. 5. software element or document affected. This subclause should be divided into the following to describe the approach to be followed for software quality assurance. problem status.14. including items to be recorded Independence in software quality assurance 5.16 Software quality assurance.17.2 5. impacts.6 5.9 Preparing the executable software Preparing source files Preparing version descriptions for the maintenance site Preparing the "as built" software item design and other software maintenance information Updating the system design description Updating the software requirements specification Updating the system/subsystem specification Preparing maintenance manuals Transition to the designated maintenance site 5.13.14. corrector. description. and delivery 5. date assigned. problem number.4 5.15.5 Configuration identification Configuration control Configuration status accounting Configuration audits Packaging.7 5.3 5. 5.14. correction time. handling.14. follow-up actions. including items to be recorded Independence in software product evaluation 5.2 5. analyst assigned to the problem.1 5.2 .16. 5. 7. Project organization and resources. This subclause shall describe the approach to be followed for risk management. 5. This clause shall present: a.1 Project organization.18 Joint technical and management reviews.2 Joint technical reviews.23 Interfacing with software IV&V agents. 5. 5.19 Risk management. Schedule(s) identifying the activities in each build and showing initiation of each activity. This subclause shall describe the approach to be followed for managing subcontractors.(continued) 5. availability of draft and final deliverables and other milestones.22 Managing subcontractors. This subclause shall describe the approach to be followed for use of software management indicators. Schedules and activity network. 5. This subclause shall describe the approach to be followed for interfacing with IV&V agents or auditors. 7. 5. including a proposed set of reviews 5. This subclause shall describe the approach to be followed for coordinating with associate developers. including a proposed set of reviews Joint management reviews. including the organizations involved. This subclause shall describe the organizational structure to be used on the project. their relationships to one another. and completion of each activity An activity network. and the authority and responsibility of each organization for carrying out required activities. This clause should be divided into the following subclauses to describe the project organization and resources to be applied in each build. 5. This subclause shall describe the approach to be followed for administrative security and privacy protection. .J-STD-016-1998 Page 67 Software Development Plan (SDP) -.18.18. This subclause shall describe the approach to be followed for project process improvement.21 Administrative security and privacy protection.25 Project process improvement.24 Coordinating with associate developers. depicting sequential relationships and dependencies among activities and identifying those activities that impose the greatest time restrictions on the project b.1 5. 6. 5. This subclause should be divided into the following to describe the approach to be followed for joint technical and management reviews.20 Software management indicators. software. and facilities required for the contracted effort. and their meanings as used in this document and a list of any terms and definitions needed to understand this document. . Annexes may be used to provide information published separately for convenience in document maintenance (e. each annex shall be referenced in the main body of the document where the data would normally have been provided. software configuration management. abbreviations. data. This subclause shall describe the resources to be applied to the project.). including geographic locations in which the work will be performed. including a plan for obtaining the resources. software engineering.(continued) 7. dates needed. software product evaluation. as applicable: a. c. software quality assurance) 3) A breakdown of the skill levels. background information. It shall include.. Annexes may be bound as separate documents for ease in handling. software testing. Overview of developer facilities to be used. facilities to be used. geographic locations.g. As applicable. including: 1) The estimated staff-loading for the project (number of personnel over time) 2) The breakdown of the staff-loading numbers by responsibility (for example. B.g.2 Project resources.J-STD-016-1998 Page 68 Software Development Plan (SDP) -. d. A schedule detailing when these items will be needed shall also be included. and availability of each resource item. services. 8.. Annexes. This clause shall contain any general information that aids in understanding this document (e. Other required resources. glossary. Personnel resources. Notes. classified data). Annexes shall be lettered alphabetically (A. management. A. rationale). etc. documentation. Acquirer-furnished equipment. This clause shall include an alphabetical listing of all acronyms. and secure areas and other features of the facilities as applicable to the contracted effort. and security clearances of personnel performing each responsibility b. charts. 2 Contents of the Software Test Plan (STP) SOFTWARE TEST PLAN (STP) Contents 1. reduction.x.6 3. 6. testing.x.2 4.5 3.J-STD-016-1998 Page 69 E. 7. Test identification 4.2 3. Identification System overview Document overview Relationship to other plans Referenced documents Software test environment 3.2. Scope 1.x.1 General information 4.1 1.2.3 1.2 1.x.x.8 3. Test schedules Requirements traceability Notes Annexes .x.4 4.4 3.1 3.1.2 4.5 4.2 Contents of the Software Test Plan (STP)E.1.1.x. 3. A.x (Name of test site(s)) 3.x.1 4.2.x Test levels Test classes General test conditions Test progression Data recording. and licensing Installation. and analysis (Item(s) to be tested) 4.1.9 Software Hardware and firmware Other materials Proprietary nature.7 3.3 3.4 2. and control Participating organizations Personnel Orientation plan Tests to be performed 4.3 4.1.y (Project-unique identifier of a test) Planned tests 5.2.x.x. acquirer's rights. 2. the software (e.. etc. identify current and planned operating sites. preprocessors. and list other relevant documents. databases. 1. This subclause shall contain a full identification of the system and the software to which this document applies. and version. they may be discussed together. and maintenance organizations.g. operation. identification number(s). version number(s). interfacing equipment. as applicable. test data generators. 3.). communications equipment. This subclause shall summarize the purpose and contents of this document and shall describe any security or privacy protection considerations associated with its use.2 System overview. and should be divided into the following to describe the software test environment at the site(s). This clause should be divided into the following subclauses. identify those that are expected to be supplied by the site. number. test data reduction equipment. revision.1 Software.. test event records. title. date. This subclause shall identify by name. related applications software. and version. developer. compilers. printers. This clause should be divided into the following subclauses to describe the software test environment at each intended test site. input files.J-STD-016-1998 Page 70 Software Test Plan (STP) -. abbreviation(s). 1.(continued) 1. this subclause and its subclauses shall be presented only once. of the STP to related project management plans. Reference may be made to the Software Development Plan (SDP) for resources that are described there. and release number(s). and identify any classified processing or other security or privacy protection issues associated with the software. disk. other special test software. plotters). . summarize the history of system development. test drivers.x (Name of test site(s)).x. Duplicative information among test site descriptions may be reduced by referencing earlier descriptions. number.3 Document overview. acquirer. This subclause shall identify by name. describe its media (tape. and maintenance. dynamic path analyzers. 3. title(s). including. This subclause shall describe the purpose of the software. communications software. as applicable. If multiple test sites use the same or similar software test environments. apparatus such as extra peripherals (tape drives.x. post-processors) necessary to perform the planned testing activities at the test site(s).2 Hardware and firmware.4 Relationship to other plans. as applicable. test control software. This clause shall list the number. etc. It shall describe the general nature of the system and software. 3. This subclause shall identify one or more test sites to be used for the testing. test timing devices. This subclause shall describe the relationship. Scope. 1.1 Identification. if any. 3. Referenced documents. identify the project sponsor. and source of all documents referenced in this manual. code auditors. the computer hardware. 1. test message generators. This subclause shall briefly state the purpose of the system and the software to which this document applies. If all tests will be conducted at a single site. operating systems. Software test environment. user. acquirer's rights. by referencing clause 4. This subclause shall identify those items that are to be delivered to the site and those that are expected to be supplied by the site. layout. This clause should be divided into the following subclauses to identify and describe each test to which this STP applies. 4. as applicable. This subclause shall identify and describe any other materials needed for the testing at the test site(s).4 Proprietary nature.x. If extensive training is anticipated. 4.(continued) and firmware that will be used in the software test environment at the test site(s). 3. and orientation briefings to staff personnel. This subclause shall identify the developer's plans for performing each of the following. 3. sample listings of output.x.7. and licensing issues associated with each element of the software test environment.x. 3.x. such as multishift operation and retention of key skills to ensure continuity and consistency in extensive test programs. 3. This subclause shall identify the number. acquirer's rights. maintenance and control group instruction. state the period of usage and the number of each needed. This subclause should be divided into subclauses to present general information applicable to the overall testing to be performed. This training may include user instruction. c.6 Participating organizations. and licensing. 3. identify those that are expected to be supplied by the site. 3. operator instruction. This subclause shall identify the organizations that will participate in the testing at the test sites(s) and the roles and responsibilities of each. and quantity of the materials. type.3 Other materials. software listings.7 Personnel. the dates and times they will be needed. This subclause shall describe the purpose of the hardware or firmware.1 General information. . and skill level of personnel needed during the test period at the test site(s). and control. media containing the software to be tested. possibly in conjunction with personnel at the test site(s): a. These materials may include manuals. a separate plan may be developed and referenced here. and other forms or instructions. This information shall be related to the personnel needs given in 3. This subclause shall identify any classified processing or other security or privacy protection issues associated with the items. media containing data to be used in the tests. This subclause shall identify. and identify any classified processing or other security or privacy protection issues associated with the hardware or firmware. Acquiring or developing each element of the software test environment Installing and testing each item of the software test environment prior to its use Controlling and maintaining each item of the software test environment 3.9 Tests to be performed. This subclause shall identify the proprietary nature.x.x.J-STD-016-1998 Page 71 Software Test Plan (STP) -. This subclause shall describe any orientation and training to be given before and during the testing. and any special needs. testing.8 Orientation plan. The description shall include the type.5 Installation.x.x. Test identification. the tests to be performed at the test site(s). b. h. Also included shall be the approach to be followed for retesting/regression testing.2. simulation." "each test of type x shall use live data. 4.y (Project-unique identifier of a test). For example: "each test shall include nominal. Reference may be made as needed to the general information in 4. use of a special input or database) Type of data to be recorded Type of data recording/reduction/analysis to be employed . and analysis procedures to be used during and after the tests identified in this STP. for example.x (Item(s) to be tested). This subclause should be divided into the following to describe the total scope of the planned testing. timing tests.2 Planned tests. c. e. and semi-automatic techniques for recording test results.5 Data recording. and retaining the results of data reduction and analysis.1.1. if applicable.J-STD-016-1998 Page 72 Software Test Plan (STP) -. 4. manual.1 Test levels. Test objective Test level Test type or class Qualification method(s) as specified in the requirements specification Identifier of the software item requirements and. and analysis. maximum capacity tests). This subclause shall describe conditions that apply to all of the tests or to a group of tests. This subclause shall describe the levels at which testing will be performed." Included shall be a statement of the extent of testing to be performed and rationale for the extent selected. a. and minimum values. or other entity by name and project-unique identifier.3 General test conditions. maximum. There is no intent to describe each test case in this document.1.) Special requirements (for example. erroneous input tests.2 Test classes. 4. The extent of testing shall be expressed as a percentage of some well defined total quantity. b. software system requirements addressed by this test.4 Test progression. reduction. This subclause shall identify a software item.) 4. as applicable. 48 hours of continuous facility time. this subclause shall explain the planned sequence or progression of tests. reduction. subsystem. These procedures shall include. This subclause shall identify and describe the data recording. system. f. such as the number of samples of discrete operating conditions or values.x.1. manipulating the raw results into a form suitable for evaluation. This subclause shall describe the types or classes of tests that will be performed (for example. automatic.(continued) 4. or other sampling approach. In cases of progressive or cumulative tests. and should be divided into the following to describe the testing planned for the item(s). (Note: the "tests" in this plan are collections of test cases. g.1. 4.1. 4. d. 4.2. (Alternatively. extent of test." "execution size and time shall be measured for each software item. This subclause shall identify a test by project-unique identifier and shall provide the information specified below for the test. this information may be provided in clause 6. software item level or system level. As applicable. and familiarization Collection of database/data file values. personnel. database. rationale). A. such as anticipated limitations on the test due to system or test conditions--timing. Requirements traceability. classified data). glossary. and approval of the Software Test Report (STR) 6. abbreviations. in chronological order with supporting narrative as necessary: 1) 2) 3) 4) 5) On-site test period and periods assigned to major portions of the testing Pretest on-site period needed for setting up the software test environment and other equipment.J-STD-016-1998 Page 73 Software Test Plan (STP) -. Annexes may be used to provide information published separately for convenience in document maintenance (e. the system requirements in all applicable System/Subsystem Specifications (SSSs) and associated system-level IRSs. Notes.y and referenced from this subclause.) Traceability from each software item requirement and. if applicable. This subclause shall contain: a. Safety. security. and other operational data needed for the testing Conducting the tests. Traceability from each test identified in this plan to the software item requirements and. system debugging. Annexes. Assumptions and constraints. B. this traceability may be provided in 4. input values. The traceability shall cover the software item requirements in all applicable Software Requirements Specifications (SRSs) and associated Interface Requirements Specifications (IRSs).x. for software systems.g. interfaces. Annexes shall be lettered alphabetically (A.(continued) i. orientation. Annexes may be bound as separate documents for ease in handling. This clause shall contain or reference the schedules for conducting the tests identified in this plan. . b. as applicable. equipment.. This clause shall include an alphabetical listing of all acronyms. Test schedules. j. charts. review. each software system requirement covered by this test plan to the test(s) that address it. A listing or chart depicting the sites at which the testing will be scheduled and the time frames during which the testing will be conducted A schedule for each test site depicting the activities and events listed below. including planned retesting Preparation. and their meanings as used in this document and a list of any terms and definitions needed to understand this document.). and. background information.. etc. 7. and privacy protection considerations associated with the test 5. software system requirements it addresses. if applicable.2. This clause shall contain any general information that aids in understanding this document (e. (Alternatively.g. each annex shall be referenced in the main body of the document where the data would normally have been provided. It shall include: a. etc. b. Notes Annexes .7 Description Contact point Support materials Training Tasks Personnel Security and privacy protection (Site name) 4.2 3.x.6 Schedule Software inventory Facilities Installation team Installation procedures Data update procedures 4.4 4.3 Contents of the Software Installation Plan (SIP) SOFTWARE INSTALLATION PLAN (SIP) Contents 1.x 5.4 2.J-STD-016-1998 Page 74 E.4 3.x.6 3.x (Site name) 5. Site-specific information for software center operations staff 4. Site-specific information for software users 5. Scope 1.3 1.x. A. 3.1 4.x.2.x.3 Schedule Installation procedures Data update procedures 6.1 1.2 5.3 3.1 3.2 1.x.x.5 3.3 4.x.5 4.1 5. Identification System overview Document overview Relationship to other plans Referenced documents Installation overview 3.x.2 4. identify the project sponsor. 2. Installation overview. This subclause shall list the type. and "hands-on" training. This clause shall list the number. This subclause shall describe the developer's plans for training personnel who will operate and/or use the software installed at user sites. operation. identify current and planned operating sites. title. acquirer. A list of sites for software installation. This clause should be divided into the following subclauses to provide an overview of the installation process. computer operations. computer printer paper. Referenced documents.J-STD-016-1998 Page 75 Software Installation Plan (SIP) -. user. The task list shall include such items as: .4 Relationship to other plans. 3.2 Contact point. and release number(s). and list other relevant documents. usually either the user. identification number(s). of the SIP to other project management plans. This subclause shall summarize the purpose and contents of this plan and shall describe any security or privacy protection considerations associated with its use. It shall describe the general nature of the system and software. 1.(continued) 1. 1. and quantity of support materials needed for the installation. Included shall be the delineation between general orientation. including. 3. developer. This subclause shall contain a full identification of the system and the software to which this document applies. This subclause shall briefly state the purpose of the system and the software to which this document applies. or the developer. and source of all documents referenced in this manual. classroom training. and the method of installation shall be included.2 System overview. revision.3 Support materials.4 Training. department/division. date. 1. abbreviation(s). title(s). and maintenance. 3. as applicable. and maintenance organizations. This subclause shall describe the relationship. 3. Each task description shall identify the organization that will accomplish the task. and telephone number of a point of contact for questions relating to this installation. 3.3 Document overview. This clause should be divided into the following subclauses. Included shall be items such as magnetic tapes. summarize the history of system development. disk packs. 3. This subclause shall list and describe in general terms each task involved in the software installation.1 Identification. version number(s). if any. This subclause shall provide the organizational name. Scope. 1. and special forms. source. the schedule dates.5 Tasks.1 Description. This subclause shall provide a general description of the installation process to provide a frame of reference for the remainder of the document. This subclause shall describe the number. and security classification. as applicable. e. release number. i. coordination.x. 3. f. Multiple sites may be discussed together when the information for those sites is generally the same. This subclause shall identify a site or set of sites and should be divided into the following to discuss those sites.6 Personnel. number of days. Site-specific information for software center operations staff. as applicable: a.(continued) a. This subclause shall contain an overview of the security and privacy protection considerations associated with the system. 4. and training aids needed. This description shall include the following. This subclause shall indicate whether the software is expected to be on site or will be delivered for the installation and shall identify any software to be used only to facilitate the installation process. Providing overall planning. d. version number. Classroom. 4. b. and shifts Hardware that is required to be operational and available Transportation and lodging for the installation team .x. configuration.J-STD-016-1998 Page 76 Software Installation Plan (SIP) -. The software shall be identified by name. This clause applies if the software will be installed in computer center(s) or other centralized or networked software installations for users to access via terminals or using batch input/output. c. and preparation for installation Providing personnel for the installation team Arranging lodging. This subclause shall detail the physical facilities and accommodations needed during the installation period. and office facilities for the installation team Ensuring that all manuals applicable to the installation are available when needed Ensuring that all other prerequisites have been fulfilled prior to the installation Planning and conducting training activities Providing students for the training Providing computer support and technical assistance for the installation Providing for conversion from the current system 3. and skill level of the personnel needed during the installation period.x. this clause shall contain the words "Not applicable. etc. specifying hours per day. b. If this type of installation does not apply. transportation. h.2 Software inventory. This subclause shall provide an inventory of the software needed to support the installation. 4. work space. g. clerical support. type.x (Site name). 4.3 Facilities.1 Schedule. c.7 Security and privacy protection. This subclause shall present a schedule of tasks to be accomplished during installation. It shall depict the tasks in chronological order with beginning and ending dates of each task and supporting narrative as necessary. identification number." 4. including the need for multishift operation. possibly involving running in parallel Dry run of procedures in user manuals . performing different functions. d. e. such as operator manuals. a separate clause (clauses 5 through n) may be written for each type of user and the clause titles modified to reflect each user. The procedures shall include the following. This subclause shall provide step-by-step procedures for accomplishing the installation. When more than one type of user is involved. Site-specific information for software users. The procedures shall include the following. b. such as operator manuals.5 Installation procedures. Multiple sites may be discussed together when the information for those sites is generally the same. This subclause shall describe the composition of the installation team. This subclause shall provide step-by-step procedures for accomplishing the installation. d. or in different organizations.x (Site name).4 Installation team. marked by WARNING or CAUTION.J-STD-016-1998 Page 77 Software Installation Plan (SIP) -. as applicable: a. such as user manuals.x. 5.(continued) 4. References may be made to other documents. g. 5. This clause shall provide installation planning pertinent to users of the software.x. Reference may be made to other documents. for example.x. 5. users at different positions.6 Data update procedures. b.2 Installation procedures. as applicable: a. When the data update procedures are the same as normal updating or processing procedures. c.5 if not performed by operations staff Initializing user-specific data Setting up queries and other user inputs Performing sample processing Generating sample reports Conversion from the current system. Safety precautions. This subclause shall present the data update procedures to be followed during the installation period. Safety precautions. reference may be made to other documents. Each team member's tasks shall be defined. It shall depict the tasks in chronological order including beginning and ending dates for each task and supporting narrative as necessary. This subclause shall identify a site or set of sites and should be divided into the following to discuss those sites. This subclause shall present a schedule of tasks to be accomplished by the user during installation. marked by WARNING or CAUTION. f.x. shall be included where applicable. 4.1 Schedule. Performing the tasks under 4. possibly involving running in parallel Dry run of the procedures in operator and user manuals 4.x. shall be included where applicable. c. Installing the software Checking out the software once installed Initializing databases and other software with site-specific data Conversion from the current system.x. 5. e. Annexes. rationale). each annex shall be referenced in the main body of the document where the data would normally have been provided.. reference may be made to other documents. A.. Annexes shall be lettered alphabetically (A.g. Notes.. .g. glossary.3 Data update procedures. Annexes may be used to provide information published separately for convenience in document maintenance (e. classified data). This clause shall include an alphabetical listing of all acronyms. This subclause should be divided into subclauses to present the user's data update procedures to be followed during the installation period.x. abbreviations. such as user manuals.J-STD-016-1998 Page 78 Software Installation Plan (SIP) -. As applicable.. If clause 5 has been expanded into clause(s) 6. This clause shall contain any general information that aids in understanding this document (e.n. When update procedures are the same as normal processing. and their meanings as used in this document and a list of terms and definitions needed to understand this document. this clause shall be numbered as the next clause following clause n. . and to clause 4 of this document 6. charts. etc.(continued) 5. B.). Annexes may be bound as separate documents for ease in handling. background information. 2.5 3.4 Contents of the Software Transition Plan (STrP) SOFTWARE TRANSITION PLAN (STrP) Contents 1.3 1.7 Facilities Hardware Software Other documentation Personnel Other resources Interrelationship of components 4. 6.2. Scope 1.4 Contents of the Software Transition Plan (STrP)E. 3. Recommended procedures Training Anticipated areas of change Transition planning Notes Annexes . 5.2 1.1 1.4 2.1 3. Identification System overview Document overview Relationship to other plans Referenced documents Software maintenance resources 3.2 3.6 3.3 3. 8.4 3. A.J-STD-016-1998 Page 79 E. 7. This subclause shall summarize the purpose and contents of this document and shall describe any security or privacy protection considerations associated with its use. This subclause shall contain a full identification of the system and the software to which this document applies. if any. emulators. and to specify. It shall describe the general nature of the system and software. including. developer. and source of all documents referenced in this manual. This clause shall list the number.3 Document overview. 1. and so on. and distribute the software and its documentation. and configurations b. This clause should be divided into subclauses to identify and describe the resources needed to maintain the deliverable software. building features to support security and privacy protection requirements (electromagnetic shielding. 3. stimulators. or other description of status . rooms. hardware simulators.). This subclause shall identify and describe the hardware and associated documentation needed to maintain the deliverable software. 3. identification number(s). copy. This subclause shall briefly state the purpose of the system and the software to which this document applies.). peripheral equipment. Reference to user/operator manuals or instructions for each item. an item that will be delivered to the maintenance organization.1 Identification. and maintenance organizations. This hardware may include computers. 3. This subclause shall describe the relationship. building features such as raised flooring or cabling. This clause should be divided into the following subclauses. The purpose of each item shall be described. Diagrams may be included as applicable. special power requirements. implement. 2. identify current and planned operating sites. 1. mock-ups.2 Hardware. diagnostic equipment. Scope. These facilities may include special buildings. These resources shall include items needed to control. design. test. Specific models. evaluate. etc. of the STrP to other project management plans. building features to support safety requirements (smoke alarms. an item the maintenance organization is required to acquire. 1. vaults. 1. an item the maintenance organization is known to have. control. Rationale for the selected hardware c. and list other relevant documents. copy. revision. acquirer. The description shall include: a. and release number(s). versions. Referenced documents. title(s). etc. and distribute modifications to the software. as applicable d. Software maintenance resources. operation. version number(s). Identification of each hardware item and document as acquirer-furnished.J-STD-016-1998 Page 80 Software Transition Plan (STrP) -.4 Relationship to other plans. document. summarize the history of system development. safety glass.2 System overview.1 Facilities.(continued) 1. and noncomputer equipment. as applicable. title. abbreviation(s). This subclause shall describe the facilities needed to maintain the deliverable software. and maintenance. user. date. identify the project sponsor. utilities.(continued) e. c. including whether the item is currently supported by the manufacturer. an item the maintenance organization is known to have. design descriptions. studies. an item the maintenance organization is required to acquire. b. data in these tools. compilers. identification numbers. test reports. information about a current source of supply. licensing. 3. an item that will be delivered to the maintenance organization. test tools. whether it is expected to be supported at the time of delivery. The description shall include: a. 3. The list will include.3 Software. and usage and ownership rights. whether licenses will be assigned to the maintenance organization. This subclause shall provide: a. and release numbers. release numbers. g. databases and data files. specifications. Specific names. as applicable Identification of each item of software and document as acquirer-furnished. or other items of interest e. test cases/procedures.4 Other documentation. information about a current source of supply. If items are required to be acquired. Names. version numbers. and usage and ownership rights. limitations. and other software. whether licenses will be assigned to the maintenance organization. plans. This subclause shall identify any other documentation needed to maintain the deliverable software. simulations. as applicable Rationale for the selected software Reference to user/operator manuals or instructions for each item. including whether the item is currently available and whether it is expected to be available at the time of delivery Information about manufacturer support. configuration management tools. an item the maintenance organization is known to have. for example. as applicable Rationale for including each document in the list Identification of each document as acquirer-furnished. including whether the item is currently available and whether it is expected to be available at the time of delivery Information about vendor support. or other items of interest f. user/operator manuals. reports. This subclause shall identify and describe the software and associated documentation needed to maintain the deliverable software. or other description of status If items are required to be acquired. emulations. identification numbers. version numbers. and the terms of such licenses Security and privacy protection considerations. and configurations. f. and the terms of such licenses Security and privacy protection considerations. b. or other description of status .J-STD-016-1998 Page 81 Software Transition Plan (STrP) -. whether it is expected to be supported at the time of delivery. an item that will be delivered to the maintenance organization. licensing. g. and maintenance manuals for the deliverable software. an item the maintenance organization is required to acquire. d. including whether the item is currently supported by the vendor. c. limitations. This software may include computer-aided software engineering (CASE) tools. test data. that the developer may wish to recommend to the maintenance organization for maintaining the deliverable software and associated maintenance environment. including advice and lessons learned. 5. together with an estimate of the type and number that should be acquired. This clause should be divided into subclauses as needed to describe any procedures. preparation of items to be delivered to the maintenance organization. as applicable. or other items of interest 3. 7. These activities may include planning/coordination meetings. Training. This clause should be divided into subclauses as appropriate to describe the developer's plans for training maintenance personnel to maintain the deliverable software. information about where to acquire it Information about licensing and usage and ownership rights Security and privacy protection considerations. This clause should be divided into subclauses as needed to describe the developer's plans for transitioning the deliverable software to the maintenance organization. 4. shipment. If a document is required to be acquired. actual staffing on the development project as a basis for the staffing needs cited. Included may be consumables such as magnetic tapes and diskettes.6 Other resources. Recommended procedures. and checkout of the operational software. packaging. including anticipated number of personnel. c. 3. Anticipated areas of change. installation. This clause shall include: a. .7 Interrelationship of components. 3. duration.(continued) d. All activities to be performed to transition the deliverable software to the maintenance organization. A figure may be used to show the interrelationships.5 Personnel. The schedule. e. and security clearances. and checkout of the software maintenance environment. f.J-STD-016-1998 Page 82 Software Transition Plan (STrP) -. types and levels of skills and expertise. Transition planning. installation. b. This clause shall describe anticipated areas of change to the deliverable software. limitations. and location for the training The delineation between classroom training and "hands-on" training Provision (either directly or by reference) for: 1) 2) Familiarization with the operational software and target computer(s) Familiarization with the maintenance software and host system 6. This subclause shall identify any other resources needed to maintain the deliverable software. This clause shall address the following: a. and training of maintenance personnel. packaging. This subclause shall describe the personnel needed to maintain the deliverable software. shipment. This subclause shall identify the interrelationships of the components identified in the preceding subclauses. This subclause shall cite. ). e..g. background information. d. abbreviations.J-STD-016-1998 Page 83 Software Transition Plan (STrP) -. Roles and responsibilities for each activity The resources needed to carry out the transition activities and the source from which each resource will be provided Schedules and milestones for conducting the transition activities. etc. each annex shall be referenced in the main body of the document where the data would normally have been provided. Annexes may be used to provide information published separately for convenience in document maintenance (e. This clause shall include an alphabetical listing of all acronyms. A. These schedules and milestones shall be compatible with the contract master schedule. rationale). c. and their meanings as used in this document and a list of any terms and definitions needed to understand this document. Annexes shall be lettered alphabetically (A.. . classified data). Annexes.g. B. Procedures for installation and checkout of deliverable items in the maintenance environment 8. This clause shall contain any general information that aids in understanding this document (e. As applicable. glossary.(continued) b. Notes. charts. Annexes may be bound as separate documents for ease in handling. 2 Software products coveredF. This annex is a normative (that is.2 Software products covered This following subclauses describe the contents of the software products covered by this annex. binding) part of this standard.1 Scope This annex specifies the contents of software products associated with concept description and requirements specification in this standard. subject to tailoring. It applies regardless of whether the software products are deliverable. The products are listed in the order they are referenced in this standard and include the following: a) b) c) d) Operational Concept Description (OCD) System/Subsystem Specification (SSS) Interface Requirements Specification (IRS) Software Requirements Specification (SRS) .J-STD-016-1998 Page 84 Annex FAnnex F Concept and requirements software product descriptionsConcept and requirements software product descriptions (normative) F.1 ScopeF. F. 1 Justification for change 4.4 Changes considered but not included 4. and scope 3.5 Support strategy Operational scenarios Summary of impacts 7.2 Organizational impacts 7. 6. 2.3 Description of current system or situation 3.2 System overview 1. 3.1 Operational impacts 7.1 Background.2 Operational policies and constraints 5. A. Scope.5 Support strategy Justification for and nature of changes 4. 4. 8.3 Priorities among the changes 4. 7. 9.1 Contents of the Operational Concept Description (OCD)F. objectives.4 Users/affected personnel 5.3 Document overview Referenced documents Current system or situation 3.4 Users or involved personnel 3.1 Summary of advantages 8. This clause should be divided into the following subclauses.2 Operational policies and constraints 3.2 Description of needed changes 4.3 Description of the new or modified system 5.(continued) 1.3 Impacts during development Analysis of the proposed system 8.5 Assumptions and constraints Concept for a new or modified system 5.1 Background.2 Summary of disadvantages/limitations 8. objectives.J-STD-016-1998 Page 85 F. 5.1 Contents of the Operational Concept Description (OCD) OPERATIONAL CONCEPT DESCRIPTION (OCD) Contents 1.1 Identification 1.2.3 Alternatives and trade-offs considered Notes Annexes Operational Concept Description (OCD) -. and scope 5. Scope 1. .2. . Current system or situation. The distinction between states and modes is arbitrary. this subclause shall so state. A system may be described in terms of states only. b. such as speed. maintenance. identifying differences associated with different states or modes of operation (for example. 1. and source of all documents referenced in this manual. modes within states.1 Background. throughput. summarize the history of system development. acquirer. modes only. d. operation. identification number(s). This subclause shall provide a description of the current system or situation.1 Identification. This subclause shall describe the background. emergency.2 System overview. degraded. wartime. This subclause shall contain a full identification of the system to which this document applies. alternative-site. This clause should be divided into the following subclauses to describe the system or situation as it currently exists. If the system operates without states or modes. 2. version number(s). or any other scheme that is useful. title. revision.J-STD-016-1998 Page 86 1. objectives. and manual and automated processes sufficient to understand the current system or situation from the user's point of view Performance characteristics. and list other relevant documents. and scope. and release number(s). 3.3 Description of current system or situation. This clause shall list the number. states within modes. and scope of the current system or situation. 1. title(s). Referenced documents.2 Operational policies and constraints. and maintenance. The description shall include. identify the project sponsor. and maintenance organizations. abbreviation(s). This subclause shall describe any operational policies and constraints that apply to the current system or situation. date. 3. peacetime). 3. regular. output. e. The operational environment and its characteristics Major system components and the interconnections among these components Interfaces to external systems or procedures Capabilities/functions of the current system Charts and accompanying descriptions depicting input. data flow. identify current and planned operating sites. developer. c. volume.3 Document overview. 3. This subclause shall briefly state the purpose of the system to which this document applies. frequency f. user. mission or objectives. training. This subclause shall summarize the purpose and contents of this document and shall describe any security or privacy protection considerations associated with its use. as applicable. as applicable: a. without the need to create artificial distinctions. including. It shall describe the general nature of the system. personnel or other factors that require a new or modified system Summarize deficiencies or limitations in the current system or situation that make it unable to respond to these factors 4. equipment. Concept for a new or modified system. This subclause shall: a. including. maintenance levels and cycles.(continued) g. 3. facilities. and rationale for not including them. This subclause shall identify priorities among the needed changes. responsibilities. maintenance organization(s). portability. training/skills. interfaces. and prioritize the desirable and optional changes. as applicable. availability. 4. This subclause shall provide an overview of the support strategy for the current system. 4. and continuity of operations in emergencies 3.J-STD-016-1998 Page 87 Operational Concept Description (OCD) -. 5. usability. This subclause shall identify changes considered but not included in 4. 4. such as reliability. efficiency Provisions for safety. objectives. environments. This clause should be divided into the following subclauses. and scope.1 Background. This subclause shall describe the types of users of the system. Justification for and nature of changes. distribution.5 Support strategy. processes. This subclause shall identify any assumptions and constraints applicable to the changes identified in this clause. 4.2. objectives.5 Assumptions and constraints. organizational structures. for example. Quality attributes. It shall. activities. mission or objectives. interfaces. This subclause shall describe any operational policies and constraints that apply to the new or modified system. . b. 4. and supply methods. identify each change as essential.4 Changes considered but not included. h. and scope of the new or modified system. as applicable to this document.4 Users or involved personnel. or other changes needed to respond to the factors identified in 4. desirable.1 Justification for change. repair/replacement criteria.2 Description of needed changes. missions. flexibility. Describe new or modified aspects of user needs. and interactions with one another. 5.2 Operational policies and constraints. This clause should be divided into the following subclauses to describe a new or modified system. maintenance software. 5. maintainability. threats. or personnel involved in the current situation. including.1. or optional. and storage. security.3 Priorities among the changes. This subclause shall summarize new or modified capabilities/functions. privacy protection. This subclause shall describe the background. d. information. This subclause shall describe anticipated operational impacts on the user. and continuity of operations in emergencies f. such as videos. as applicable. modes only. without the need to create artificial distinctions. such as speed. security. training. 5. A system may be described in terms of states only. If the system operates without states or modes. The scenarios shall include events. maintainability. 7.5 Support strategy. equipment. efficiency Provisions for safety. actions. maintenance software. This clause should be divided into the following subclauses. b. peacetime). emergency. g. privacy protection.1 Operational impacts. or any other scheme that is useful. The operational environment and its characteristics Major system components and the interconnections among these components Interfaces to external systems or procedures Capabilities/functions of the new or modified system Charts and accompanying descriptions depicting input. 7. e. changes in quantity. change in procedures. such as reliability.J-STD-016-1998 Page 88 Operational Concept Description (OCD) -. maintenance organization(s). its interaction with users. . as applicable. maintenance. The distinction between states and modes is arbitrary. flexibility. maintenance levels and cycles. h. its interface to other systems. 5. alert. regular. Summary of impacts. wartime. changes in data retention requirements. modes within states. 6. repair/replacement criteria. usability. This subclause shall provide an overview of the support strategy for the new or modified system. and maintenance organizations. including. responsibilities. acquirer. The description shall include. and timing of data to be input to the system. stimuli. This subclause shall describe the types of users of the new or modified system. These impacts may include changes in interfaces with computer operating centers. and supply methods. and interactions with one another. developer. alternative-site. output. use of new data sources. facilities. organizational structures. data flow.4 Users/affected personnel. wartime.(continued) 5. to provide part or all of this information. identifying differences associated with different states or modes of operation (for example. interactions. and all states or modes identified for the system. as applicable. as applicable: a. type. availability.3 Description of the new or modified system. portability. This subclause shall provide a description of the new or modified system. training/skills.. including. and manual and automated processes sufficient to understand the new or modified system or situation from the user's point of view Performance characteristics. states within modes. volume. frequency Quality attributes. and new modes of operation based on peacetime. etc. c. This clause shall describe one or more operational scenarios that illustrate the role of the new or modified system. and storage. throughput. degraded. this subclause shall so state. distribution. Reference may be made to other media. or emergency conditions. Operational scenarios. as applicable. and other activities needed to aid or monitor development.g. degraded or missing capabilities. glossary. degraded or less-than-desired performance. These impacts may include modification of responsibilities. This subclause shall provide a qualitative and quantitative summary of the advantages to be obtained from the new or modified system. Annexes may be bound as separate documents for ease in handling.1 Summary of advantages. acquirer. A.(continued) 7. each annex shall be referenced in the main body of the document where the data would normally have been provided. .3 Impacts during development. enhanced capabilities.. This clause should be divided into the following subclauses. or location of personnel in various modes of operation. This subclause shall describe anticipated organizational impacts on the user. acquirer. training. addition or elimination of responsibilities or positions. 9. impacts during testing of the new system. parallel operation of the new and existing systems. developer. 8. need for training or retraining. Annexes shall be lettered alphabetically (A. as applicable. position identifiers. and improved performance. abbreviations. developer. These disadvantages and limitations shall include. and changes in number. This summary shall include new capabilities. development or modification of databases. 7. Analysis of the proposed system. and their relationship to deficiencies identified in 4. These impacts may include meetings/discussions regarding the new system. and other constraints. and maintenance organizations. This subclause shall identify and describe major alternatives considered to the system or its characteristics. Notes.1. This subclause shall describe anticipated impacts on the user. Annexes.2 Summary of disadvantages/limitations.3 Alternatives and trade-offs considered. This clause shall include an alphabetical listing of all acronyms. classified data). etc.g. and rationale for the decisions reached. and maintenance organizations during the development effort. This subclause shall provide a qualitative and quantitative summary of disadvantages or limitations of the new or modified system. 8. 8. greater-than-desired use of computer hardware resources.. charts.J-STD-016-1998 Page 89 Operational Concept Description (OCD) -. As applicable. conflicts with user assumptions. rationale). and their meanings as used in this document and a list of any terms and definitions needed to understand this document. B. skill levels. This clause shall contain any general information that aids in understanding this document (e. Annexes may be used to provide information published separately for convenience in document maintenance (e. undesirable operational impacts. the trade-offs among them. 8.2 Organizational impacts.). background information. 2.x (System capability) 3.11 System quality factors 3.5 System internal data requirements 3.4 System internal interface requirements 3.9 System environment requirements 3. Scope 1. 4.1 Required states and modes 3.3 Computer software requirements 3.18 Precedence and criticality of requirements Qualification provisions Requirements traceability Notes Annexes 2.2. 5.3.2 System capability requirements 3.4 Computer communications requirements 3.17 Packaging requirements 3.7 Safety requirements 3.10. 6.15 Logistics-related requirements 3.12 Design and construction constraints 3.2 System overview 1.x (Project-unique identifier of interface) 3.10 Computer resource requirements 3.3 System external interface requirements 3.3 Document overview Referenced documents Requirements 3.2 Contents of the System/Subsystem Specification (SSS) SYSTEM/SUBSYSTEM SPECIFICATION (SSS) Contents 1. 3.13 Personnel-related requirements 3.2 Contents of the System/Subsystem Specification (SSS)F.J-STD-016-1998 Page 90 F.2 Computer hardware resource utilization requirements 3.8 Security and privacy protection requirements 3.10.1 Identification 1.3.6 Adaptation requirements 3.2.1 Computer hardware requirements 3.14 Training-related requirements 3.16 Other requirements 3.10.10.1 Interface identification and diagrams 3. A. . identify the project sponsor. If a given requirement fits into more than one subclause. 3. degraded. developer. post-use analysis. peacetime. active. backup. This clause shall list the number. This subclause shall contain a full identification of the system to which this document applies. Each requirement shall be annotated with associated qualification method(s) (see clause 4) and. in an annex referenced from this subclause. date. this subclause shall identify and define each state and mode. including. or by annotation of the requirements in the subclauses where they appear. Requirements. and maintenance. ready. version number(s). and maintenance organizations. This subclause shall summarize the purpose and contents of this document and shall describe any security or privacy protection considerations associated with its use. operation. Conventions needed to understand the requirements shall be presented or referenced. if not provided in those clauses.3 Document overview. or any other scheme that is useful. This clause should be divided into the following subclauses. emergency. A system may be described in terms of states only. Each requirement shall be assigned a project-unique identifier to support testing and traceability and shall be stated in such a way that an objective test can be defined for it. Scope. the subclause shall so state. as applicable.1 Identification. 3. Referenced documents. identification number(s).J-STD-016-1998 Page 91 System/Subsystem Specification (SSS) -. revision. If there are no requirements in a given subclause. it may be stated once and referenced from the other subclauses. It shall describe the general nature of the system. 2. If states and/or modes are required. abbreviation(s).a). identify current and planned operating sites.(continued) 1.2 System overview. If the system is required to operate in more than one state or mode having requirements distinct from other states or modes. This clause should be divided into the following subclauses to specify the system requirements. The correlation may be indicated by a table or other method in this subclause. traceability to system requirements (see 5. each requirement or group of requirements in this specification shall be correlated to the states and modes. The degree of detail to be provided shall be guided by the following rule: include those characteristics of the system that are conditions for system acceptance. title. and list other relevant documents. wartime. This subclause shall briefly state the purpose of the system to which this document applies. this subclause shall so state.1 Required states and modes. states within modes. modes within states. without the need to create artificial distinctions. modes only. The distinction between states and modes is arbitrary. summarize the history of system development. title(s). defer to design descriptions those characteristics that the acquirer is willing to leave up to the developer. those characteristics of the system that are conditions for its acceptance. user. that is. 1. If no states or modes are required. acquirer. 1. training. and source of all documents referenced in this manual. for subsystems. Examples of states and modes include: idle. 1. . and release number(s). This subclause may reference other documents (such as data dictionaries. sequencing. capacities (how much/how many). frequency... and any provisions to be incorporated into the system to provide continuity of operations in the event of emergencies. and shall note any differences in these characteristics from the point of view of the interfacing entities (such as different expectations about the size. This subclause should be divided into sub-clauses to specify the requirements.1 Interface identification and diagrams.3 System external interface requirements. The requirements shall specify required behavior of the system and shall include applicable parameters. standards for communication protocols. continuous operation requirements. or "out of bounds" conditions.x (System capability).2. Subclause 3. priorities.3. for the system's external interfaces. The requirements shall include the following. This subclause shall identify the required external interfaces of the system.2 System capability requirements. as applicable. version. 3. as applicable. A "capability" is defined as a group of related requirements. other timing constraints. The word "capability" may be replaced with "function." "object.. The identification shall state which entities have fixed interface characteristics (and therefore impose interface requirements on interfacing entities) and which are being developed or modified (thus having interface requirements imposed on them).x (Project-unique identifier of interface). This subclause should be divided into subclauses to itemize the requirements associated with each capability of the system.3.x of the SSS provides a list of topics to be considered when specifying requirements regarding input the system is required to accept and output it is required to produce. such as response times. number. if any. presented in any order suited to the requirements. and should be divided into subclauses as needed to state the requirements imposed on the system to achieve the interface. unallowed. Interface characteristics of the other entities involved in the interface shall be stated as assumptions or as "When [the entity not covered] does this. 3. The requirements shall include. This subclause (beginning with 3.3. One or more interface diagrams shall be provided to depict the interfaces. 3. etc. the constituent capabilities shall be specified in subclauses." "subject. and allowable deviations based on operating conditions.) by name. required behavior under unexpected.(continued) 3. users. and standards for user interfaces) in place of stating the information here. This subclause shall identify a required system capability and shall itemize the requirements associated with the capability. hardware items. software items. and documentation references. shall briefly identify the interfacing entities. throughput times. This subclause may reference one or more Interface Requirements Specifications (IRSs) or other documents containing these requirements. requirements for error handling.2) shall identify a system external interface by project-unique identifier." not as requirements on the other entities. or other characteristics of data elements): .J-STD-016-1998 Page 92 System/Subsystem Specification (SSS) -. accuracy." or other term useful for presenting the requirements. as applicable. If the capability can be more clearly specified by dividing it into constituent capabilities.3. 3. the system shall . The identification of each interface shall include a project-unique identifier and shall designate the interfacing entities (systems. etc. b. icons and other display elements. receive. dollars. record or data structure name in code or database) d) Abbreviations or synonymous names 2) Data elements in the assembly and their structure (number.) that the system is required to provide. beeps. store. and other constraints. etc. order. reports.g. arrays. access.J-STD-016-1998 Page 93 System/Subsystem Specification (SSS) -.) to be implemented Required characteristics of individual data elements that the system is required to provide. grouping) 3) Medium (such as disk) and structure of data elements/assemblies on the medium 4) Visual and auditory characteristics of displays and other outputs (such as colors. such as: 1) Names/identifiers a) Project-unique identifier b) Non-technical (natural language) name c) Standard data element name d) Technical name (e. displays. access.g. volume. such as whether the data element may be updated and whether business rules apply 8) Security and privacy protection constraints 9) Sources (setting/sending entities) and recipients (using/receiving entities) Required characteristics of data element assemblies (records. . timing. sequencing.) 3) Size and format (such as length and punctuation of a character string) 4) Units of measurement (such as meters. layouts. Required characteristics of communication methods that the system is required to use for the d. volume. frequency. fonts.(continued) a. integer. store.. variable or field name in code or database) e) Abbreviation or synonymous names 2) Data type (alphanumeric. and other constraints..(continued) e. etc. timing. send. etc. such as whether the assembly may be updated and whether business rules apply 7) Security and privacy protection constraints 8) Sources (setting/sending entities) and recipients (using/receiving entities) System/Subsystem Specification (SSS) -. etc. such as: 1) Names/identifiers a) Project-unique identifier b) Non-technical (natural language) name c) Technical name (e. files. frequency. lights) 5) Relationships among assemblies. send. receive. such as sorting/access characteristics 6) Priority. nanoseconds) 5) Range or enumeration of possible values (such as 0-99) 6) Accuracy (how correct) and precision (number of significant digits) 7) Priority.. sequencing. storage-and-retrieval of data.. Priority that the system is required to assign the interface Requirements on the type of interface (such as real-time data transfer. messages. c. if any. such as: 1) Project-unique identifier(s) 2) Communication links/bands/frequencies/media and their characteristics 3) Message formatting 4) Flow control (such as sequence numbering and buffer allocation) 5) Data transfer rate. and naming conventions 7) Transmission services. including connection establishment. user authentication. including fragmentation and reassembly. loads. and recovery procedures 5) Synchronization.3 of the SSS provides a list of topics to be considered. on databases and data files to be included in the system. Required characteristics of protocols the system is required to use for the interface. and auditing f. etc. identification.x. If such requirements are to be imposed.6 Adaptation requirements. plug compatibility. If all internal interfaces are left to the design or to requirement specifications for system components. and interval between transfers 6) Routing. If all decisions about internal data are left to the design or to requirements specifications for system components. compartmentalization. error control. if any. 3.3.5 System internal data requirements.x. this fact shall be so stated. If such requirements are to be imposed. routing. this fact shall be so stated.4 System internal interface requirements. if any. and addressing 4) Legality checks. tolerances. Included shall be requirements. .c and 3. addressing. subclause 3.d of the SSS provide a list of topics to be considered. 3. imposed on data internal to the system. if any.3. termination 6) Status. imposed on interfaces internal to the system. concerning installation-dependent data that the system is required to provide (such as site-dependent latitude and longitude or site-dependent state tax codes) and parameters that the system is required to use that may vary according to operational needs (such as operation-dependent targeting constants or site-dependent month-end dates). such as physical compatibility of the interfacing entity(ies) (dimensions. subclauses 3.) g. and any other reporting features Other required characteristics. such as: 1) Project-unique identifier(s) 2) Priority/layer of the protocol 3) Packeting. such as encryption. This subclause shall specify the requirements. maintenance. whether periodic/aperiodic. This subclause shall specify the requirements.J-STD-016-1998 Page 94 interface. 3. This subclause shall specify the requirements. voltages. including priority and grade 8) Safety/security/privacy protection considerations. shock. 3. prevention of inadvertent detonation.1 Computer hardware requirements. auxiliary storage device capacity. if any. temperature. the security/privacy protection environment in which the system is required to operate. concerned with maintaining security and privacy protection.9 System environment requirements. 3. type. under which the resource utilization is to be measured. the type and degree of security or privacy protection to be provided. such as conditions in the natural environment (wind. handling. such as maximum allowable use of processor capacity. regarding the environment in which the system is required to operate. grounding of electrical systems. This subclause shall specify the requirements. radiation). or incorporated into. capacity. for example.10. Examples include restricting the use of dangerous materials. if any. memory. This subclause shall specify the requirements. This subclause shall include the system requirements. if any. as applicable. as applicable. rain. . auxiliary storage. The requirements shall include. and the physical environment. the security/privacy protection policy that is required to be met. if any. as applicable. on the system's computer hardware resource utilization. the security/privacy protection accountability the system is required to provide. geographic location). and compliance with nuclear safety rules. The requirements (stated. gas detection and warning devices. abort/escape provisions from enclosures. size. if any.2 Computer hardware resource utilization requirements.10 Computer resource requirements.(continued) 3.8 Security and privacy protection requirements. concerned with preventing or minimizing unintended hazards to personnel. and the criteria that are required to be met for security/privacy protection certification/accreditation. and storing. This subclause should be divided into the following. (Additional requirements concerning computer resources are given in the next subclause). Examples for a hardware-software system include the environmental conditions that the system is required to withstand during transportation. noise. The requirements shall include. the computer resources covered in these subclauses may constitute the environment of the system (as for a software system) or components of the system (as for a hardware-software system). This subclause shall specify the system requirements. the induced environment (motion. and other required characteristics of processors. Examples for a software system are the computer hardware and operating system on which the software is required to run.10. required safeguards to reduce those risks. This subclause shall specify the requirements. 3. and operation. as percentages of the capacity of each computer hardware resource) shall include the conditions. number of each type of equipment. This subclause shall specify the system requirements. for nuclear components. decontamination.J-STD-016-1998 Page 95 System/Subsystem Specification (SSS) -. electromagnetic radiation). classifying explosives for purposes of shipping. and environments due to hostile action (explosions. and explosion proofing. and other required equipment. memory capacity. including. 3. 3. input/output device capacity. property. storage. and communications/network equipment capacity. Depending upon the nature of the system. the system. the security/privacy protection risks the system is required to withstand.7 Safety requirements. if any. input/output devices. regarding computer hardware that is required to be used by. communications/network equipment. if any. requirements for component design. 10. Examples include requirements concerning: a. regarding computer software that is required to be used by. military. if any. if any. such as required subsystems. or incorporated into. Examples include quantitative requirements concerning system functionality (the ability to perform all required functions).12 Design and construction constraints. the system. Use of a particular system architecture or requirements on the architecture. maintainability (the ability to be easily serviced. database management systems. reliability (the ability to perform with correct. requirements on the handling of toxic materials. The correct nomenclature. or a given number of. This subclause shall specify the requirements. or software) Use of particular design or construction standards. and other attributes. Examples include operating systems. concerning the computer communications that are required to be used by.4 Computer communications requirements. interchangeability of parts. or incorporated into. communications/ network software. that constrain the design and construction of the system. workmanship requirements and production techniques Physical characteristics of the system (such as weight limits. usability (the ability to be easily learned and used). transmission techniques. 3. . persons Materials that can and cannot be used.10. This subclause shall specify the additional requirements. 3. input and equipment simulators. ability to be transported from one location to another. pertaining to system quality factors. if any.3 Computer software requirements. This subclause shall specify the requirements. peak volumes of data. color. data transfer rates. or existing components. consistent results -. repaired.such as mean time between failure for equipment). configuration and network topology. availability (the ability to be accessed and operated when needed). version. flexibility (the ability to be easily adapted to changing requirements). Examples include geographic locations to be linked. the system. or corrected). protective coatings). portability of software (the ability to be easily modified for a new environment). if any. or use of acquirer-furnished property (equipment. dimensional limits. use of particular data standards. type and volume of data to be transmitted/received. testability (the ability to be easily and thoroughly tested). 3. limits on the electromagnetic radiation that the system is permitted to generate b.J-STD-016-1998 Page 96 System/Subsystem Specification (SSS) -. ability to be carried or set up by one. utility software. reusability (the ability to be used in multiple applications). test software. information. use of a particular programming language.11 System quality factors. These requirements may be specified by reference to appropriate commercial or government standards and specifications. and diagnostic features. gateways. and manufacturing software. This subclause shall specify the requirements. For hardware-software systems. and documentation references of each such item of software shall be provided. c. required system use times. time boundaries for transmission/reception/response.(continued) 3. use of standard. this subclause shall include the physical requirements imposed on the system. d. J-STD-016-1998 Page 97 System/Subsystem Specification (SSS) -. considerations for the capabilities and limitations of humans. or mission 3.16 Other requirements. or to privacy protection for purposes of singling them out for special treatment. 3. if any. and use of auditory signals. technical manuals. 3. Examples include training devices and training materials to be included in the system. Applicable commercial or government specifications and standards may be referenced if appropriate. part marking.(continued) e. test plans and procedures. These considerations may include: system maintenance.15 Logistics-related requirements. Examples include requirements for adjustable-height work stations.13 Personnel-related requirements. criticality. Qualification methods may include: . threat. and other identifying markings Flexibility and expandability that are required to be provided to support anticipated areas of growth or changes in technology. if any. serial and lot number marking. supply-system requirements. foreseeable human errors under both normal and extreme conditions. or assigned weights indicating the relative importance of the requirements in this specification. as applicable. concerned with logistics considerations. imposed on the system. to security. if any. 3. and impact on existing equipment. 3. If all requirements have equal weight. labeling. This subclause shall specify the system requirements. This subclause shall specify additional system requirements. included to accommodate the number. 3. Examples include requirements for the number of work stations to be provided and for built-in help and training features. not covered in the previous subclauses. f. This subclause shall specify the system requirements. This subclause shall specify the system requirements.14 Training-related requirements. training needs.18 Precedence and criticality of requirements. if applicable. physical placement of critical indicators or buttons. A table may be used to present this information. This subclause shall specify. pertaining to training. and installation instruction data.17 Packaging requirements. or each requirement in clause 3 may be annotated with the method(s) to be used. 4. system transportation modes. for packaging. the order of precedence. This clause shall specify the requirements. or other information about the personnel who will use or support the system. and handling the system and its components for delivery. Examples include identifying those requirements deemed critical to safety. Use of nameplates. if not covered in other contractual documents. Also included shall be the human factors engineering requirements. impact on existing facilities. if any. if any. software maintenance. This clause shall define a set of qualification methods and shall specify for each requirement in clause 3 the method(s) to be used to ensure that the requirement has been met. These requirements shall include. Qualification provisions. color and duration of error messages. Examples include requirements for system documentation. and specific areas where the effects of human error would be particularly serious. such as specifications. duty cycles. skill levels. drawings. if any. this subclause shall so state. etc.) Note: Each level of system refinement may result in requirements not directly traceable to higher-level requirements. pilot models. this subclause does not apply. All system requirements allocated to the subsystem shall be accounted for. charts.g. or pilot lots. procedures. Traceability from each subsystem requirement in this specification to the system requirements it addresses.. Those that trace to subsystem requirements contained in IRSs shall reference those IRSs. Special qualification methods: Any special qualification methods for the system. For subsystem-level specifications.). (Alternatively. Annexes may be used to provide information published separately for convenience in document maintenance (e. For system-level specifications.(continued) a. . documentation..J-STD-016-1998 Page 98 System/Subsystem Specification (SSS) -. Examples are reduction. such as special tools. abbreviations. Demonstration: The operation of the system. glossary. or extrapolation of test results. Traceability from each system requirement that has been allocated to the subsystem covered by this specification to the subsystem requirements that address it. b. Annexes. using instrumentation or other special test equipment to collect data for later analysis. e. Test: The operation of the system. facilities. b. Such requirements may be traced to a general requirement such as "system implementation" or to the system design decisions that resulted in their generation. A. This clause shall contain any general information that aids in understanding this document (e. each annex shall be referenced in the main body of the document where the data would normally have been provided. special test equipment. and their meanings as used in this document and a list of any terms and definitions needed to understand this document. Requirements traceability. 6. For example. or a part of the system. etc. background information. this subclause shall contain: a. preproduction or periodic production samples. use of standard samples. As applicable. 5. that relies on observable functional operation not requiring the use of instrumentation. This clause shall contain an alphabetical listing of all acronyms. d. acceptance limits. B. Notes. even though these interfaces are not covered in system requirements. this traceability may be provided by annotating each requirement in clause 3. a system architectural design that creates two subsystems may result in requirements about how the subsystems will interface. classified data). Annexes may be bound as separate documents for ease in handling.g. Inspection: The visual examination of system components. c. or subsequent analysis. interpolation. Annexes shall be lettered alphabetically (A. or a part of the system. techniques. rationale). Analysis: The processing of accumulated data obtained from other qualification methods. J-STD-016-1998 Page 99 F. Qualification provisions Requirements traceability Notes Annexes .3 2.2 1. Scope 1. Identification System overview Document overview Referenced documents Requirements 3.3 Contents of the Interface Requirements Specification (IRS) INTERFACE REQUIREMENTS SPECIFICATION (IRS) Contents 1. A. 3.2.x 3.2.3 Contents of the Interface Requirements Specification (IRS)F.y Interface identification and diagrams (Project-unique identifier of interface) Precedence and criticality of requirements 4. 6.1 3.1 1. 5. or other system components) and the interfaces to which this document applies. 1. date. Conventions needed to understand the requirements shall be presented or referenced. Each requirement shall be assigned a project-unique identifier to support testing and traceability and shall be stated in such a way that an objective test can be defined for it. version. If an interfacing entity included in this specification will operate in states and/or modes having interface requirements different from other states and modes.1 Interface identification and diagrams. user.a) if not provided in those clauses. This clause should be divided into the following subclauses. This clause should be divided into the following subclauses to specify the requirements imposed on one or more systems. identify the project sponsor. hardware items. software items.) by name. identify current and planned operating sites.1. This clause shall list the number. it may be stated once and referenced from the other subclauses. etc. The degree of detail to be provided shall be guided by the following rule: include those characteristics of the interfacing entities that are conditions for their acceptance. The identification shall state which entities have fixed interface characteristics (and therefore impose interface requirements on interfacing entities) and which are being developed or modified (thus having interface requirements imposed on them). number. revision. hardware items. in an annex referenced from this subclause. manual operations. It shall describe the general nature of the system and software. title. 1.3 Document overview. This subclause shall contain a full identification of the interfacing entities (systems. software items. This subclause shall summarize the purpose and contents of this document and shall describe any security or privacy protection considerations associated with its use. each requirement or group of requirements for that entity shall be correlated to the states and modes. Scope. acquirer. operation. defer to design descriptions those characteristics that the acquirer is willing to leave up to the developer. 3. subsystems. manual operations.1 Identification.(continued) 1. and source of all documents referenced in this manual. 2. including. version number(s). or other system components to achieve one or more interfaces among these entities. abbreviation(s). and documentation references. Requirements. and list other relevant documents. identification number(s). users. 1. and maintenance organizations. and maintenance. This subclause shall briefly state the purpose of the system(s) and software to which this document applies. subsystems. software items. or by annotation of the requirements in the subclauses where they appear. Referenced documents.2 System overview.J-STD-016-1998 Page 100 Interface Requirements Specification (IRS) -. hardware items. 3. summarize the history of system development. as applicable. if applicable) requirements (see 5. . For each interface identified in 1. developer. One or more interface diagrams shall be provided to depict the interfaces. as applicable. Each requirement shall be annotated with associated qualification method(s) (see clause 4) and traceability to system (or subsystem. and release number(s). The correlation may be indicated by a table or other method in this subclause. this subclause shall include a project-unique identifier and shall designate the interfacing entities (systems. title(s). If a given requirement fits into more than one subclause. such as: 1) Names/identifiers a) Project-unique identifier b) Non-technical (natural language) name d.) that the interfacing entity(ies) is required to provide. files. and standards for user interfaces) in place of stating the information here. volume. and shall note any differences in these characteristics from the point of view of the interfacing entities (such as different expectations about the size..J-STD-016-1998 Page 101 Interface Requirements Specification (IRS) -. etc. This subclause may reference other documents (such as data dictionaries..x (Project-unique identifier of interface). dollars. or other characteristics of data elements): a. etc. send. nanoseconds) 5) Range or enumeration of possible values (such as 0-99) 6) Accuracy (how correct) and precision (number of significant digits) 7) Priority. store. shall briefly identify the interfacing entities. c.. The requirements shall include the following. as applicable. If the interface characteristics of an entity are not covered by this IRS but need to be mentioned to specify the requirements for entities that are. messages. frequency. send. timing. access. This subclause (beginning with 3. arrays. store. such as: 1) Names/identifiers a) Project-unique identifier b) Non-technical (natural language) name c) Standard data element name d) Technical name (e. frequency.(continued) 3.g.. storage-and-retrieval of data. etc. etc. sequencing. access. displays. such as whether the data element may be updated and whether business rules apply 8) Security and privacy protection constraints 9) Sources (setting/sending entities) and recipients (using/receiving entities) Required characteristics of data element assemblies (records. variable or field name in code or database) e) Abbreviation or synonymous names 2) Data type (alphanumeric. presented in any order suited to the requirements. reports. receive..) to be implemented Required characteristics of individual data elements that the interfacing entity(ies) is required to provide. standards for communication protocols. receive. b. the [entity being specified] shall .2) shall identify an interface by project-unique identifier. those characteristics shall be stated as assumptions or as "When [the entity not covered] does this. etc." rather than as requirements on the entities not covered by this IRS. integer. and should be divided as needed to state the requirements imposed on one or more of the interfacing entities to achieve the interface. Priority that the interfacing entity(ies) is required to assign the interface Requirements on the type of interface (such as real-time data transfer. and other constraints.) 3) Size and format (such as length and punctuation of a character string) 4) Units of measurement (such as meters. .. lights) Relationships among assemblies.g. record or data structure name in code or database) d) Abbreviations or synonymous names Data elements in the assembly and their structure (number. order. such as sorting/access characteristics Priority. and recovery procedures 5) Synchronization.. criticality. If all requirements have equal weight. Required characteristics of communication methods that the interfacing entity(ies) is required to use for the interface.) f.J-STD-016-1998 Page 102 Interface Requirements Specification (IRS) -. 3. addressing. such as physical compatibility of the interfacing entity(ies) (dimensions. This subclause shall be numbered as the last subclause in clause 3 and shall specify. identification. . such as: 1) Project-unique identifier(s) 2) Priority/layer of the protocol 3) Packeting. timing. icons and other display elements. including connection establishment. voltages. sequencing. termination 6) Status. routing. such as: 1) Project-unique identifier(s) 2) Communication links/bands/frequencies/media and their characteristics 3) Message formatting 4) Flow control (such as sequence numbering and buffer allocation) 5) Data transfer rate. and interval between transfers 6) Routing. frequency. Examples include identifying those requirements deemed critical to safety. layouts. such as encryption. including priority and grade 8) Safety/security/privacy protection considerations.y Precedence and criticality of requirements. and addressing 4) Legality checks. the order of precedence. etc. this subclause shall so state.(continued) c) Technical name (e. user authentication. maintenance. g. and any other reporting features Other required characteristics. grouping) Medium (such as disk) and structure of data elements/assemblies on the medium Visual and auditory characteristics of displays and other outputs (such as colors. such as whether the assembly may be updated and whether business rules apply Security and privacy protection constraints Sources (setting/sending entities) and recipients (using/receiving entities) 2) 3) 4) 5) 6) 7) 8) e. error control. fonts. plug compatibility. compartmentalization. to security. including fragmentation and reassembly. loads. or assigned weights indicating the relative importance of the requirements in this specification. and other constraints. beeps. and naming conventions 7) Transmission services. whether periodic/aperiodic. tolerances. or to privacy protection for purposes of singling them out for special treatment. if applicable. and auditing Required characteristics of protocols the interfacing entity(ies) is required to use for the interface. volume. procedures. 6. Traceability from each requirement imposed on the entity in this specification to the system (or subsystem.J-STD-016-1998 Page 103 Interface Requirements Specification (IRS) -. Examples are reduction. Special qualification methods: Any special qualification methods for the interfacing entities. and acceptance limits.(continued) 4. each annex shall be referenced in the main body of the document where the data would normally have been provided. This clause shall contain any general information that aids in understanding this document (e. the qualification method(s) to be used to ensure that the requirement has been met. Inspection: The visual examination of interfacing entities. As applicable.. for each requirement in clause 3. d. etc. 5. B. if applicable) requirements it addresses. this subclause does not apply. e. For each subsystem. c. Requirements traceability. Demonstration: The operation of interfacing entities that relies on observable functional operation not requiring the use of instrumentation. Test: The operation of interfacing entities using instrumentation or special test equipment to collect data for later analysis..g. documentation. a system architectural design that creates multiple software items may result in requirements about how the software items will interface. Qualification methods may include: a.). charts. or each requirement in clause 3 may be annotated with the method(s) to be used. or subsequent analysis. Analysis: The processing of accumulated data obtained from other qualification methods. etc. and their meanings as used in this document and a list of any terms and definitions needed to understand this document. techniques. rationale). b. Annexes may be used to provide information published separately for convenience in document maintenance (e. Qualification provisions. Such requirements may be traced to a general requirement such as "system implementation" or to the system design decisions that resulted in their generation. facilities. This clause shall define a set of qualification methods and shall specify. classified data). A table may be used to present this information. background information. Traceability from each system (or subsystem. This clause shall include an alphabetical listing of all acronyms. abbreviations. interpretation. if applicable) requirement that has been allocated to the interfacing entity and that affects an interface covered in this specification to the requirements in this specification that address it. b. or extrapolation of test results. Notes. such as special tools. this traceability may be provided by annotating each requirement in clause 3. . this subclause shall contain: a. Annexes may be bound as separate documents for ease in handling. even though these interfaces are not covered in system requirements. glossary.or lower-level interfacing entity covered by this IRS. special test equipment.) Note: Each level of system refinement may result in requirements not directly traceable to higher-level requirements. For system-level interfacing entities. Annexes shall be lettered alphabetically (A. For example. (Alternatively. Annexes. A.g. 18 Precedence and criticality of requirements 4.1 Identification 1.10.3.2 System overview 1.15 Logistics-related requirements 3.x (Software item capability) 3.2.J-STD-016-1998 Page 104 F.10 Computer resource requirements 3.3 Software item external interface requirements 3.4 Computer communications requirements 3.1 Computer hardware requirements 3.1 Required states and modes 3. Requirements 3. Notes A.2 Software item capability requirements 3.2.13 Personnel-related requirements 3.17 Packaging requirements 3.8 Security and privacy protection requirements 3.10.3 Computer software requirements 3.6 Adaptation requirements 3.2.4 Contents of the Software Requirements Specification (SRS)F.10.5 Software item internal data requirements 3. Annexes .14 Training-related requirements 3.2 Computer hardware resource utilization requirements 3.10.9 Software item environment requirements 3.x (Project-unique identifier of interface) 3. Referenced documents 3.7 Safety requirements 3.11 Software quality factors 3.4 Contents of the Software Requirements Specification (SRS) SOFTWARE REQUIREMENTS SPECIFICATION (SRS) Contents 1.3. Qualification provisions 5. Requirements traceability 6.12 Design and implementation constraints 3.4 Software item internal interface requirements 3.3 Document overview 2.1 Interface identification and diagrams 3. Scope 1.16 Other requirements 3. 1. those characteristics of the software item that are conditions for its acceptance. If states and/or modes are required. If there are no requirements in a given subclause. The degree of detail to be provided shall be guided by the following rule: include those characteristics of the software item that are conditions for software item acceptance. Scope. The distinction between states and modes is arbitrary. identify current and planned operating sites. modes only. . and list other relevant documents. Software item requirements are software requirements generated to satisfy the system requirements allocated to this software item. identification number(s). modes within states. developer. If a given requirement fits into more than one subclause. Requirements.2 System overview. abbreviation(s). Conventions needed to understand the requirements shall be presented or referenced. Each requirement shall be annotated with associated qualification method(s) (see clause 4) and traceability to system (or subsystem. 1. ready. Referenced documents.(continued) 1. post-use analysis. version number(s). degraded. title. 3. that is.1 Required states and modes. If the software item is required to operate in more than one state or mode having requirements distinct from other states or modes. if applicable) requirements (see 5. including. wartime. This clause shall list the number. without the need to create artificial distinctions. If no states or modes are required. This subclause shall contain a full identification of the system and the software to which this document applies. the subclause shall so state. user. backup. emergency. This clause should be divided into the following subclauses. 2. and release number(s). and maintenance organizations. in an annex referenced from this subclause. Each requirement shall be assigned a projectunique identifier to support testing and traceability and shall be stated in such a way that an objective test can be defined for it. A software item may be described in terms of states only. This subclause shall briefly state the purpose of the system and the software to which this document applies. it may be stated once and referenced from the other subclauses. 3.J-STD-016-1998 Page 105 Software Requirements Specification (SRS) -. as applicable. operation. defer to design descriptions those characteristics that the acquirer is willing to leave up to the developer. This subclause shall summarize the purpose and contents of this document and shall describe any security or privacy protection considerations associated with its use. active. date. title(s). This clause should be divided into the following subclauses to specify the software item requirements.3 Document overview. Examples of states and modes include: idle. and maintenance. this subclause shall identify and define each state and mode. each requirement or group of requirements in this specification shall be correlated to the states and modes. The correlation may be indicated by a table or other method in this subclause. this subclause shall so state.a) if not provided in those clauses. revision. acquirer. peacetime. It shall describe the general nature of the system and software. or by annotation of the requirements in the subclauses where they appear. 1. and source of all documents referenced in this manual. training. or any other scheme that is useful. summarize the history of system development.1 Identification. states within modes. identify the project sponsor. One or more interface diagrams shall be provided to depict the interfaces. software items. sequencing.J-STD-016-1998 Page 106 Software Requirements Specification (SRS) -. This subclause shall identify a required software item capability and shall itemize the requirements associated with the capability. This subclause (beginning with 3. as applicable.. capacities (how much/how many). priorities. users. or other characteristics of data elements): . unallowed.x of the SRS provides a list of topics to be considered when specifying requirements regarding input the software item is required to accept and output it is required to produce. as applicable. continuous operation requirements." or other term useful for presenting the requirements. other timing constraints. the constituent capabilities shall be specified in subclauses.. providing or exchanging data). 3. The requirements shall specify required behavior of the software item and shall include applicable parameters. The requirements shall include. and standards for user interfaces) in place of stating the information here. The identification shall state which entities have fixed interface characteristics (and therefore impose interface requirements on interfacing entities) and which are being developed or modified (thus having interface requirements imposed on them). or "out of bounds" conditions.2. Subclause 3. hardware items.x (Project-unique identifier of interface). presented in any order suited to the requirements.2 Software item capability requirements. shall briefly identify the interfacing entities. and allowable deviations based on operating conditions. If the capability can be more clearly specified by dividing it into constituent capabilities. if any. This subclause should be divided into subclauses to itemize the requirements associated with each capability of the software item. standards for communication protocols. The requirements shall include the following. 3.. and documentation references. The word "capability" may be replaced with "function." "object. relationships with other entities that involve sharing." not as requirements on the other entities." "subject.3. and any provisions to be incorporated into the software item to provide continuity of operations in the event of emergencies. number. This subclause may reference other documents (such as data dictionaries. This subclause shall identify the required external interfaces of the software item (that is. This subclause may reference one or more Interface Requirements Specifications (IRSs) or other documents containing these requirements. Interface characteristics of the other entities involved in the interface shall be stated as assumptions or as "When [the entity not covered] does this.2) shall identify a software item external interface by project-unique identifier.3 Software item external interface requirements. This subclause should be divided into subclauses to specify the requirements. for the software item's external interfaces. etc.3.3. The identification of each interface shall include a project-unique identifier and shall designate the interfacing entities (systems. as applicable. 3. and shall note any differences in these characteristics from the point of view of the interfacing entities (such as different expectations about the size. throughput times. such as response times. requirements for error handling. A "capability" is defined as a group of related requirements.) by name. accuracy. 3. and should be divided into subclauses as needed to state the requirements imposed on the software item to achieve the interface. frequency. required behavior under unexpected.x (Software item capability).3. the software item shall .(continued) 3. version.1 Interface identification and diagrams. record or data structure name in code or database) d) Abbreviations or synonymous names 2) Data elements in the assembly and their structure (number. such as sorting/access characteristics 6) Priority. and other constraints. Required characteristics of communication methods that the software item is required to use d. displays. sequencing. nanoseconds) 5) Range or enumeration of possible values (such as 0-99) 6) Accuracy (how correct) and precision (number of significant digits) 7) Priority. etc. store. fonts.. . send.J-STD-016-1998 Page 107 Software Requirements Specification (SRS) -.(continued) e. etc. storage-and-retrieval of data. integer. and other constraints. access. store. such as: 1) Names/identifiers a) Project-unique identifier b) Non-technical (natural language) name c) Technical name (e. such as whether the assembly may be updated and whether business rules apply 7) Security and privacy protection constraints 8) Sources (setting/sending entities) and recipients (using/receiving entities) Software Requirements Specification (SRS) -.. access. b. reports. messages. such as whether the data element may be updated and whether business rules apply 8) Security and privacy protection constraints 9) Sources (setting/sending entities) and recipients (using/receiving entities) Required characteristics of data element assemblies (records.g. timing. frequency. etc. send.) 3) Size and format (such as length and punctuation of a character string) 4) Units of measurement (such as meters.. lights) 5) Relationships among assemblies. Priority that the software item is required to assign the interface Requirements on the type of interface (such as real-time data transfer. variable or field name in code or database) e) Abbreviation or synonymous names 2) Data type (alphanumeric. volume. receive. icons and other display elements.) to be implemented Required characteristics of individual data elements that the software item is required to provide. timing. grouping) 3) Medium (such as disk) and structure of data elements/assemblies on the medium 4) Visual and auditory characteristics of displays and other outputs (such as colors. receive. sequencing.) that the software item is required to provide. c. etc. order.g. arrays. beeps. etc. frequency. files. dollars.(continued) a.. layouts. such as: 1) Names/identifiers a) Project-unique identifier b) Non-technical (natural language) name c) Standard data element name d) Technical name (e. volume. and interval between transfers 6) Routing. If all decisions about internal data are left to the design.c and 3. if any. compartmentalization. if any. 3. If all internal interfaces are left to the design. maintenance.3 of the SRS provides a list of topics to be considered. tolerances. error control.J-STD-016-1998 Page 108 for the interface. This subclause shall specify the requirements.d of the SRS provide a list of topics to be considered. and auditing f. subclause 3. If such requirements are to be imposed. concerning installation-dependent data to be provided by the software item (such as site-dependent latitude and longitude or site-dependent state tax codes) and parameters that the software item is required to use that may vary according to operational needs (such as operation-dependent targeting constants or site-dependent month-end dates). loads. This subclause shall specify the requirements. including connection establishment.6 Adaptation requirements. identification.3. such as encryption.4 Software item internal interface requirements. termination 6) Status. such as: 1) Project-unique identifier(s) 2) Communication links/bands/frequencies/media and their characteristics 3) Message formatting 4) Flow control (such as sequence numbering and buffer allocation) 5) Data transfer rate. including priority and grade 8) Safety/security/privacy protection considerations. addressing. plug compatibility.5 Software item internal data requirements. this fact shall be so stated. and naming conventions 7) Transmission services. 3.3. imposed on interfaces internal to the software item. and any other reporting features Other required characteristics. this fact shall be so stated. and recovery procedures 5) Synchronization. subclauses 3.x. Included shall be requirements.) g. 3. such as physical compatibility of the interfacing entity(ies) (dimensions. etc. Required characteristics of protocols the software item is required to use for the interface. and addressing 4) Legality checks. imposed on data internal to the software item. This subclause shall specify the requirements. whether periodic/aperiodic. such as: 1) Project-unique identifier(s) 2) Priority/layer of the protocol 3) Packeting. . including fragmentation and reassembly. on databases and data files to be included in the software item.x. voltages. if any. routing. if any. user authentication. If such requirements are to be imposed. under which the resource utilization is to be measured. Examples include safeguards the software item is required to provide to prevent inadvertent actions (such as accidentally issuing an "auto pilot off" command) and non-actions (such as failure to issue an intended "auto pilot off" command). as applicable. This subclause shall specify the requirements. communications/network equipment. the software item. number of each type of equipment.J-STD-016-1998 Page 109 Software Requirements Specification (SRS) -. and other required equipment. and other required characteristics of processors. database management systems. input/output device capacity. auxiliary storage. and manufacturing software. The requirements (stated.3 Computer software requirements. This subclause shall include the software item requirements. the security/privacy protection environment in which the software item is required to operate. on the software item's computer hardware resource utilization. This subclause shall specify the software item requirements. Examples include the computer hardware and operating system on which the software item is required to run. regarding computer hardware that is required to be used by the software item. input/output devices. prevention of inadvertent detonation and compliance with nuclear safety rules. The correct nomenclature. or incorporated into. This subclause shall specify the software item requirements. size.10. if any. This subclause shall specify the requirements.10. and the criteria that are required to be met for security/privacy protection certification/accreditation. the security/privacy protection risks the software item is required to withstand. the type and degree of security or privacy protection to be provided. type.(continued) 3. required safeguards to reduce those risks. if any.9 Software item environment requirements. as percentages of the capacity of each computer hardware resource) shall include the conditions. input and equipment simulators. This subclause should be divided into the following. and documentation references of each such item of software shall be provided. regarding computer software that is required to be used by.10 Computer resource requirements. if any. concerned with preventing or minimizing unintended hazards to personnel. version. 3. if any. and the physical environment. capacity. regarding the environment in which the software item is required to operate. Examples include operating systems. 3. as applicable. memory capacity. (Additional requirements concerning computer resources are given in the next subclause.1 Computer hardware requirements. These requirements shall include.) 3. and communications/ network equipment capacity.8 Security and privacy protection requirements. The requirements shall include. if any. test software. regarding nuclear components of the system. . 3. 3. the security/privacy protection accountability the software item is required to provide. auxiliary storage device capacity. utility software. memory.7 Safety requirements.10. if any. as applicable. concerned with maintaining security and privacy protection. the security/privacy protection policy that is required to be met. communications/ network software. for example. This subclause shall specify the requirements. property. 3. such as maximum allowable use of processor capacity. This subclause shall specify the requirements. if any.2 Computer hardware resource utilization requirements. including. if any. pertaining to training. threat. type and volume of data to be transmitted/received. These requirements shall include. peak volumes of data. Examples include requirements for color and duration of error messages. and use of auditory signals. if any. Examples include requirements for number of simultaneous users and for built-in help or training features. data transfer rates. This subclause shall specify the additional requirements. flexibility (the ability to be easily adapted to changing requirements). testability (the ability to be easily and thoroughly tested). 3. such as required databases or other software units. Also included shall be the human factors engineering requirements.10. usability (the ability to be easily learned and used). 3. 3. time boundaries for transmission/reception/response. consistent results). concerned with software quality factors identified in the contract or derived from a higher level specification. if any. This subclause shall specify the software item requirements. that constrain the design and implementation of the software item. and other attributes. if any. These requirements may be specified by reference to appropriate commercial or government standards and specifications. Examples include requirements concerning: a. required system use times.13 Personnel-related requirements. reusability (the ability to be used in multiple applications). This subclause shall specify the software item requirements. imposed on the software item.J-STD-016-1998 Page 110 Software Requirements Specification (SRS) -. duty cycles. use of standard. as applicable. military. and diagnostic features. Use of a particular software item architecture or requirements on the architecture. c. or software) Use of particular design or implementation standards. maintainability (the ability to be easily corrected).11 Software quality factors. This subclause shall specify the software item requirements. Examples include quantitative requirements regarding software item functionality (the ability to perform all required functions). physical placement of critical indicators or keys. or other information about the personnel who will use or maintain the software item. gateways. or mission b. portability (the ability to be easily modified for a new environment). or use of acquirer-furnished property (equipment. concerning the computer communications that are required to be used by the software item. if any. transmission techniques. or existing components. use of a particular programming language Flexibility and expandability that are required to be provided to support anticipated areas of growth or changes in technology. use of particular data standards.4 Computer communications requirements. foreseeable human errors under both normal and extreme conditions. considerations for the capabilities and limitations of humans.14 Training-related requirements. if any. training needs. if any. configuration and network topology. . reliability (the ability to perform with correct. 3. included to accommodate the number. availability (the ability to be accessed and operated when needed). information. skill levels. This subclause shall specify the requirements. Examples include training software to be included in the software item. and specific areas where the effects of human error would be particularly serious.12 Design and implementation constraints. Examples include geographic locations to be linked.(continued) 3. concerned with logistics considerations.J-STD-016-1998 Page 111 Software Requirements Specification (SRS) -. or extrapolation of test results. and impact on existing equipment. or to privacy protection for purposes of singling them out for special treatment. such as special tools. and handling the software item for delivery (for example. this subclause shall so state. if any. Examples include identifying those requirements deemed critical to safety. or assigned weights indicating the relative importance of the requirements in this specification. to security. These considerations may include: system maintenance. labeling. facilities. criticality. documentation. supply-system requirements. special test equipment.16 Other requirements. impact on existing facilities. for packaging. or subsequent analysis. 3. Analysis: The processing of accumulated data obtained from other qualification methods. software maintenance. Inspection: The visual examination of software item code. if applicable) requirements it addresses. e. 4. if any. techniques. the order of precedence.17 Packaging requirements. Qualification methods may include: a. system transportation modes. if any. 5. or each requirement in clause 3 may be annotated with the method(s) to be used.15 Logistics-related requirements. delivery on 8 track magnetic tape labelled and packaged in a certain way). This clause shall define a set of qualification methods and shall specify for each requirement in clause 3 the method(s) to be used to ensure that the requirement has been met. Demonstration: The operation of the software item. using instrumentation or other special test equipment to collect data for later analysis. If all requirements have equal weight. (Alternatively. Qualification provisions. or a part of the software item. d. c. This subclause shall contain: a. b.18 Precedence and criticality of requirements. procedures. and acceptance limits. Examples are reduction. This clause shall specify the requirements. if applicable. or a part of the software item. interpolation. that relies on observable functional operation not requiring the use of instrumentation. Traceability from each software item requirement in this specification to the system (or subsystem. This subclause shall specify. 3. etc. not covered in the previous subclauses. Applicable commercial or government specifications and standards may be referenced if appropriate. this traceability may be provided by annotating each requirement in clause 3. Requirements traceability. A table may be used to present this information.) . Special qualification methods: Any special qualification methods for the software item. This subclause shall specify the software item requirements. This subclause shall specify additional software item requirements. Test: The operation of the software item.(continued) 3. 3. abbreviations. All system (subsystem) requirements allocated to this software item shall be accounted for. A. b. This clause shall contain any general information that aids in understanding this specification (e. if applicable) requirement allocated to this software item to the software item requirements that address it.. Annexes. charts.. Traceability from each system (or subsystem. Those that trace to software item requirements contained in IRSs shall reference those IRSs. even though these interfaces are not covered in system requirements. Annexes may be used to provide information published separately for convenience in document maintenance (e. and their meanings as used in this document and a list of any terms and definitions needed to understand this document.g. . For example. Annexes may be bound as separate documents for ease in handling.). 6. This clause shall include an alphabetical listing of all acronyms. background information. Notes. rationale). each annex shall be referenced in the main body of the document where the data would normally have been provided.g. Annexes shall be lettered alphabetically (A. a system architectural design that creates multiple software items may result in requirements about how the software items will interface. As applicable. classified data). etc. B.(continued) Note: Each level of system refinement may result in requirements not directly traceable to higher-level requirements. glossary. Such requirements may be traced to a general requirement such as "system implementation" or to the system design decisions that resulted in their generation.J-STD-016-1998 Page 112 Software Requirements Specification (SRS) -. subject to tailoring.J-STD-016-1998 Page 113 Annex GAnnex G Design software product descriptionsDesign software product descriptions (normative) G.2 Software products coveredG.2 Software products covered This following subclauses describe the contents of the software products covered by this annex. The products are listed in the order they are referenced in this standard and include the following: a) b) c) d) System/Subsystem Design Description (SSDD) Interface Design Description (IDD) Database Design Description (DBDD) Software Design Description (SDD) . G. It applies regardless of whether the software products are deliverable.1 Scope This annex specifies the contents of software products associated with design in this standard. binding) part of this standard.1 ScopeG. This annex is a normative (that is. 3 System components Concept of execution Interface design 4. 4. A. Scope 1. Requirements traceability Notes Annexes .1 1.1 4.3.2. 6.2.2 1. Identification System overview Document overview Referenced documents System-wide design decisions System architectural design 4.x Interface identification and diagrams (Project-unique identifier of interface) 5.1 Contents of the System/Subsystem Design Description (SSDD) SYSTEM/SUBSYSTEM DESIGN DESCRIPTION (SSDD) Contents 1. 3.1 4.1 Contents of the System/Subsystem Design Description (SSDD)G.2 4.J-STD-016-1998 Page 114 G.3.3 2. ignoring internal implementation) and other decisions affecting the selection and design of system components. such as those for safety. security. revision. Design decisions that respond to requirements designated critical.3. This subclause shall briefly state the purpose of the system to which this document applies. developer. description of physical systems modeled. including. and list other relevant documents. and maintenance organizations. and users (4.1 Identification.3.(continued) 1. d. This clause should be divided into subclauses as needed to present system-wide design decisions. decisions about the system's behavioral design (how it will behave. 1. . user. hardware items.J-STD-016-1998 Page 115 System/Subsystem Design Description (SSDD) -. title. 2. This clause should be divided into the following subclauses. This subclause shall summarize the purpose and contents of this document and shall describe any security or privacy protection considerations associated with its use.x of the SSDD identifies topics to be considered in this description). This subclause shall contain a full identification of the system to which this document applies. in meeting its requirements. this clause shall so state. they may be referenced. that is. 1. If part or all of this information is given in Interface Design Descriptions (IDDs). and handling of unallowed inputs or conditions. including interfaces with other systems. summarize the history of system development.3 Document overview. software items. security. including actions the system will perform. from a user's point of view. 3. or privacy protection. identify current and planned operating sites. Design decisions on how system databases/data files will appear to the user (4. title(s). and source of all documents referenced in this manual. selected equations/ algorithms/rules. This clause shall list the number.x of the SSDD identifies topics to be considered in this description). Design conventions needed to understand the design shall be presented or referenced. 1. shall be placed in separate subclauses. Design decisions regarding input the system will accept and output it will produce. and privacy protection requirements. Scope. Selected approach to meeting safety. operation. If all such decisions are explicit in the requirements or are deferred to the design of the system components. Referenced documents. Design decisions on system behavior in response to each input or condition.2 System overview. this dependency shall be indicated. date. Examples of system-wide design decisions are the following: a. they may be referenced. response times and other performance characteristics. identify the project sponsor. and maintenance. and release number(s). version number(s). If a design decision depends upon system states or modes. abbreviation(s). System-wide design decisions. b. If part or all of this information is given in Database Design Descriptions (DBDDs). It shall describe the general nature of the system. acquirer. identification number(s). as applicable. c. version. (Alternatively. This clause should be divided into the following subclauses to describe the system architectural design. This subclause shall: a. depending on the selected design methodology. it may be presented once and referenced from the other subclauses. software items. . System architectural design. organizing a subsystem into hardware items. materials. color. If design information falls into more than one subclause. etc. If part or all of the design depends upon system states or modes. shape. such as name. software items. the allocation of requirements may be provided in 5. Other system-wide design decisions made in response to requirements. memory.a. such as selected approach to providing required flexibility. existing design or component to be reengineered. if known (such as new development. such as physical size. and manual operations. c. the description shall provide identifying information. but is interpreted to cover organizing a system into subsystems. Note: For brevity. Each description shall. d. describe the allocation of resource utilization to each software item that will use the resource (for example.1 System components. existing component to be reused as is.J-STD-016-1998 Page 116 System/Subsystem Design Description (SSDD) -. and manual operations). component to be developed for reuse. etc. and maintainability. Multiple relationships may be presented. and markings. 30% to software item 2). availability. 4. or other variations as appropriate. Each component shall be assigned a project-unique identifier. and describe the characteristics of the resource: b. documentation references. as applicable. Identify the components of the system (hardware items. this clause is written in terms of organizing a system directly into hardware items. and communications/ network equipment).) For existing design or components. identify the hardware and software items that will use the resource. For each computer system or other aggregate of computer hardware resources identified for use in the system. this dependency shall be indicated. auxiliary storage. weight. input/output devices. Note: A database may be treated as a software item or as part of a software item. describe the conditions under which utilization will be measured. f. component planned for Build N. Design conventions needed to understand the design shall be presented or referenced.(continued) e. 4. location. State the purpose of each component and identify the system requirements and system-wide design decisions allocated to it.) Identify each component's development type. and manual operations. describe its computer hardware resources (such as processors. Design and construction choices for hardware or hardware-software systems. Show the static (such as "consists of") relationship(s) of the components. software items. e. 20% of the resource's capacity allocated to software item 1. existing design to be reused as is. Descriptions of communications/network equipment. cabling. Each description shall also include. that is. and configuration (such as 256K cache memory. amount of installed storage. hubs. hardware items. high speed data lines. 2) 3) 4) 5) 6) f. data transfer rates/capacities. dynamic creation/deletion of objects. character set standard (such as ASCII. manufacturer name and model number. timing diagrams. Descriptions of auxiliary storage shall include. as applicable.J-STD-016-1998 Page 117 System/Subsystem Design Description (SSDD) -. type. word size (number of bits in each computer word). and any additional hardware capabilities relevant to the description.(continued) 1) Descriptions of computer processors shall include. manufacturer name and model number. It shall include both interfaces among the components and their interfaces with external entities such as other systems. tasks. manufacturer name and model number. a diagram that identifies and shows the relationships among the planned specifications for the system components. dynamically controlled sequencing. and device speed/capacity. as applicable. data flow. this subclause is provided to allow the recording of interface design decisions made as part of system architectural design. type of device. identification of instruction set architecture. network interface cards. transmission techniques. exception handling. 16MB RAM (4MB x 4)). as applicable. and other aspects of dynamic behavior. and users. and protocols used. If part or all of this information is contained in Interface Design Descriptions (IDDs) or elsewhere. processes. 4. such as modems. This subclause shall describe the concept of execution among the system components. and interrupt capabilities. speed. EBCDIC). type of storage. concurrent execution.2 Concept of execution. network topologies. timing/sequencing relationships. software items. that is. applicable compiler(s). shall include. Note: There is no requirement for these interfaces to be completely designed at this level. Descriptions of input/output devices shall include. priorities among components. gateways. and storage speed. handling of interrupts. This subclause should be divided into the following to describe the interface characteristics of the system components.3 Interface design. 4. Present a specification tree for the system. diagnostic capabilities. as applicable. processor speed/capacity. It shall include diagrams and descriptions showing the dynamic relationship of the components. how they will interact during system operation. as applicable. these sources may be referenced. growth capabilities. manufacturer name and model number. flow of execution control. dynamic allocation/deallocation. manufacturer name and model number and memory size. including. as applicable. state transition diagrams. or aggregates of these or other components. . as applicable. Descriptions of memory shall include. ) 3) Size and format (such as length and punctuation of a character string) 4) Units of measurement (such as meters. integer. presented in any order suited to the information to be provided.1 Interface identification and diagrams. number. and shall note any differences in these characteristics from the point of view of the interfacing entities (such as different expectations about the size. The design description shall include the following. and documentation references. 4. as appropriate. storage-and-retrieval of data. such as whether the data element may be updated and whether business rules apply 8) Security and privacy protection constraints 9) Sources (setting/sending entities) and recipients (using/receiving entities) . timing.3. access. as applicable. [the entity that is covered] will . sequencing.) to be implemented Characteristics of individual data elements that the interfacing entity(ies) will provide. dollars. software items. shall briefly identify the interfacing entities. receive. send... frequency. store..) by name. c. such as: 1) Names/identifiers a) Project-unique identifier b) Non-technical (natural language) name c) Standard data element name d) Technical name (e.3. to depict the interfaces. nanoseconds) 5) Range or enumeration of possible values (such as 0-99) 6) Accuracy (how correct) and precision (number of significant digits) 7) Priority.3.. an external system) but its interface characteristics need to be mentioned to describe interfacing entities that are. standards for protocols.2) shall identify an interface by project-unique identifier. One or more interface diagrams shall be provided.(continued) 4. or other characteristics of data elements): a. etc. version. users. This subclause (beginning with 4. The identification shall state which entities have fixed interface characteristics (and therefore impose interface requirements on interfacing entities) and which are being developed or modified (thus having interface requirements imposed on them). etc. etc. and standards for user interfaces) in place of stating the information here.J-STD-016-1998 Page 118 System/Subsystem Design Description (SSDD) -. b. frequency. and other constraints.x (Project-unique identifier of interface). Priority assigned to the interface by the interfacing entity(ies) Type of interface (such as real-time data transfer. If a given interfacing entity is not covered by this SSDD (for example.g.. This subclause shall state the project-unique identifier assigned to each interface and shall identify the interfacing entities (systems. these characteristics shall be stated as assumptions or as "When [the entity not covered] does this. volume. and should be divided into subclauses as needed to describe the interface characteristics of one or both of the interfacing entities. variable or field name in code or database) e) Abbreviation or synonymous names 2) Data type (alphanumeric. as applicable." This subclause may reference other documents (such as data dictionaries. hardware items. etc. loads. timing. compartmentalization. displays. arrays. icons and other display elements. Characteristics of communication methods that the interfacing entity(ies) will use for the interface. store. record or data structure name in code or database) d) Abbreviations or synonymous names Data elements in the assembly and their structure (number. sequencing. including fragmentation and reassembly. voltages. send. maintenance. Characteristics of data element assemblies (records. g. receive. termination 6) Status. reports. and any other reporting features Other characteristics. and interval between transfers 6) Routing. layouts. and recovery procedures 5) Synchronization.. files.) System/Subsystem Design Description (SSDD) -.g. volume. routing. and auditing Characteristics of protocols that the interfacing entity(ies) will use for the interface. and other constraints.(continued) f. etc. fonts. grouping) Medium (such as disk) and structure of data elements/assemblies on the medium Visual and auditory characteristics of displays and other outputs (such as colors. Requirements traceability. including priority and grade 8) Safety/security/privacy protection considerations. including connection establishment.) that the interfacing entity(ies) will provide. such as sorting/access characteristics Priority.(continued) d. such as physical compatibility of the interfacing entity(ies) (dimensions. plug compatibility. etc. etc. such as: 1) Names/identifiers a) Project-unique identifier to be used for traceability b) Non-technical (natural language) name c) Technical name (e. lights) Relationships among assemblies. such as encryption. beeps. such as: 1) Project-unique identifier(s) 2) Communication links/bands/frequencies/media and their characteristics 3) Message formatting 4) Flow control (such as sequence numbering and buffer allocation) 5) Data transfer rate. and addressing 4) Legality checks. frequency. identification. whether periodic/aperiodic. and naming conventions 7) Transmission services. This subclause shall contain: . error control. 5. tolerances.J-STD-016-1998 Page 119 System/Subsystem Design Description (SSDD) -. addressing. access. user authentication.. such as whether the assembly may be updated and whether business rules apply Security and privacy protection constraints Sources (setting/sending entities) and recipients (using/receiving entities) 2) 3) 4) 5) 6) 7) 8) e. order. messages. such as: 1) Project-unique identifier(s) 2) Priority/layer of the protocol 3) Packeting. and their meanings as used in this document and a list of any terms and definitions needed to understand this document. b.) Note: Each level of system refinement may result in requirements not directly traceable to higher-level requirements. Annexes shall be lettered alphabetically (A.g.. even though these interfaces are not covered in system requirements. each annex shall be referenced in the main body of the document where the data would normally have been provided.). Annexes. a system architectural design that creates two subsystems may result in requirements about how the subsystems will interface. . background information. charts. B. abbreviations. etc. (Alternatively. As applicable. For example.J-STD-016-1998 Page 120 a. This clause shall contain an alphabetical listing of all acronyms. Traceability from each system component identified in this SSDD to the system requirements allocated to it. glossary. Annexes may be used to provide information published separately for convenience in document maintenance (e. this traceability may be provided in 4.. rationale). classified data). Such requirements may be traced to a general requirement such as "system implementation" or to the system design decisions that resulted in their generation.g. Notes. Annexes may be bound as separate documents for ease in handling. This clause shall contain any general information that aids in understanding this document (e. Traceability from each system requirement to the system components to which it is allocated.1. A. 6. 1 1. 3.2 Contents of the Interface Design Description (IDD)G.2. Identification System overview Document overview Referenced documents Interface design 3.2 Contents of the Interface Design Description (IDD) INTERFACE DESIGN DESCRIPTION (IDD) Contents 1. Scope 1.2 1. A.2.3 2.J-STD-016-1998 Page 121 G.1 3. Requirements traceability Notes Annexes .x Interface identification and diagrams (Project-unique identifier of interface) 4. 5. Interface design. and maintenance. . it may be referenced. software items.1 Identification. subsystems. This subclause shall briefly state the purpose of the system(s) and software to which this document applies. version. The identification shall state which entities have fixed interface characteristics (and therefore impose interface requirements on interfacing entities) and which are being developed or modified (thus having interface requirements imposed on them). software items. This clause should be divided into the following subclauses to describe the interface characteristics of one or more systems. This subclause shall summarize the purpose and contents of this document and shall describe any security or privacy protection considerations associated with its use. 2.1. as applicable. acquirer. title. this dependency shall be indicated. manual operations. 3. 3. It shall describe the general nature of the system and software. date. 1. 1. users. it may be presented once and referenced from the other subclauses. hardware items. identification number(s). If design information falls into more than one subclause. If part or all of this information is documented elsewhere. and list other relevant documents. This clause should be divided into the following subclauses. This clause shall list the number. One or more interface diagrams shall be provided.J-STD-016-1998 Page 122 Interface Design Description (IDD) -. If part or all of the design depends upon system states or modes. For each interface identified in 1. and release number(s). and documentation references. manual operations. or other system components.(continued) 1. hardware items. abbreviation(s).1 Interface identification and diagrams. identify the project sponsor. Referenced documents. user. Scope. operation. etc. Design conventions needed to understand the design shall be presented or referenced. This subclause shall contain a full identification of the interfacing entities (systems. as appropriate. and source of all documents referenced in this manual.) by name.3 Document overview. as applicable. hardware items. or other system components) and interfaces to which this document applies. to depict the interfaces. including. subsystems. identify current and planned operating sites. developer.2 System overview. revision. 1. and maintenance organizations. version number(s). title(s). this subclause shall state the project-unique identifier assigned to the interface and shall identify the interfacing entities (systems. number. software items. summarize the history of system development. shall briefly identify the interfacing entities. receive. or other characteristics of data elements): a. send.. The design description shall include the following. etc. If a given interfacing entity is not covered by this IDD (for example.) to be implemented Characteristics of individual data elements that the interfacing entity(ies) will provide. and shall note any differences in these characteristics from the point of view of the interfacing entities (such as different expectations about the size. This subclause (beginning with 3.J-STD-016-1998 Page 123 Interface Design Description (IDD) -. sequencing.x (Project-unique identifier of interface). volume. these characteristics shall be stated as assumptions or as "When [the entity not covered] does this. as applicable. variable or field name in code or database) e) Abbreviation or synonymous names 2) Data type (alphanumeric. nanoseconds) 5) Range or enumeration of possible values (such as 0-99) 6) Accuracy (how correct) and precision (number of significant digits) 7) Priority. such as whether the data element may be updated and whether business rules apply 8) Security and privacy protection constraints 9) Sources (setting/sending entities) and recipients (using/receiving entities) . timing. such as: 1) Names/identifiers a) Project-unique identifier b) Non-technical (natural language) name c) Standard data element name d) Technical name (e... [the entity that is covered] will . access.. frequency.(continued) 3.g. storage-and-retrieval of data. integer. store.. and should be divided as needed to describe the interface characteristics of one or both of the interfacing entities.2) shall identify an interface by project-unique identifier. standards for protocols. frequency. presented in any order suited to the information to be provided. b. and other constraints. an external system) but its interface characteristics need to be mentioned to describe interfacing entities that are. c. etc.) 3) Size and format (such as length and punctuation of a character string) 4) Units of measurement (such as meters." This subclause may reference other documents (such as data dictionaries. Priority assigned to the interface by the interfacing entity(ies) Type of interface (such as real-time data transfer. dollars. etc. and standards for user interfaces) in place of stating the information here. arrays. files. including fragmentation and reassembly. displays. such as encryption. beeps. compartmentalization. messages. routing. such as: 1) Project-unique identifier(s) 2) Priority/layer of the protocol 3) Packeting.J-STD-016-1998 Page 124 Interface Design Description (IDD) -. layouts. termination 6) Status. and recovery procedures 5) Synchronization. Characteristics of data element assemblies (records. and any other reporting features e. including priority and grade 8) Safety/security/privacy protection considerations.) that the interfacing entity(ies) will provide.(continued) d. send. maintenance. addressing. and interval between transfers 6) Routing. including connection establishment. frequency. such as: 1) Project-unique identifier(s) 2) Communication links/bands/frequencies/media and their characteristics 3) Message formatting 4) Flow control (such as sequence numbering and buffer allocation) 5) Data transfer rate. timing. and auditing Characteristics of protocols the interfacing entity(ies) will use for the interface.. fonts. and naming conventions 7) Transmission services. icons and other display elements. access. error control. whether periodic/aperiodic. grouping) 3) Medium (such as disk) and structure of data elements/assemblies on the medium 4) Visual and auditory characteristics of displays and other outputs (such as colors. user authentication. reports. lights) 5) Relationships among assemblies. such as whether the assembly may be updated and whether business rules apply 7) Security and privacy protection constraints 8) Sources (setting/sending entities) and recipients (using/receiving entities) Characteristics of communication methods that the interfacing entity(ies) will use for the interface. and other constraints.. record or data structure name in code or database) d) Abbreviations or synonymous names 2) Data elements in the assembly and their structure (number.g. and addressing 4) Legality checks. such as: 1) Names/identifiers a) Project-unique identifier b) Non-technical (natural language) name c) Technical name (e. f. order. etc. etc. identification. store. . volume. sequencing. such as sorting/access characteristics 6) Priority. receive. Annexes may be used to provide information published separately for convenience in document maintenance (e. A. each annex shall be referenced in the main body of the document where the data would normally have been provided. abbreviations.. glossary. and their meanings as used in this document and a list of any terms and definitions needed to understand this document. loads. rationale).J-STD-016-1998 Page 125 Interface Design Description (IDD) -. 5. etc. plug compatibility. Such requirements may be traced to a general requirement such as "system implementation" or "software item" or to the system or software design decisions (e. .. b. Annexes. voltages.g. etc. B. tolerances. classified data). For example. even though these interfaces are not covered in system or software item requirements.) 4. Annexes may be bound as separate documents for ease in handling. Requirements traceability. Notes. This clause shall include an alphabetical listing of all acronyms. Traceability from each system or software item requirement that affects an interface covered in this IDD to the interfacing entities that address it. such as physical compatibility of the interfacing entity(ies) (dimensions. This subclause shall contain: a. a system or software architectural design that creates two subsystems or two software units may result in requirements about how the subsystems or software units will interface. charts.g. Traceability from each interfacing entity covered by this IDD to the system or software item requirements addressed by the entity's interface design. This clause shall contain any general information that aids in understanding this document (e.. in the SDD) that resulted in their generation. As applicable. Annexes shall be lettered alphabetically (A. Note: Each level of system or software item refinement may result in requirements not directly traceable to higher-level requirements.g.(continued) g. Other characteristics. background information.). 2 1. 7.1 1. A.2.3 Contents of the Database Design Description (DBDD) DATABASE DESIGN DESCRIPTION (DBDD) Contents 1.x (Project-unique identifier of a software unit.3 Contents of the Database Design Description (DBDD)G. 4. Requirements traceability Notes Annexes .2. 3. Identification Database overview Document overview Referenced documents Database-wide design decisions Design of the database 4.x (Name of database design level) 5. Detailed design of software units used for database access or manipulation 5. or designator of a group of software units) 6.3 2.J-STD-016-1998 Page 126 G. Scope 1. This subclause shall summarize the purpose and contents of this document and shall describe any security or privacy protection considerations associated with its use. reports. hardware items. security. they may be referenced. they may be referenced from this clause. messages. from a user's point of view. version/release) and the type of flexibility to be built into the database for adapting to changing requirements b. If a design decision depends upon system states or modes. or privacy protection. This clause should be divided into subclauses as needed to present database-wide design decisions. identification number(s). 3. including actions. revision. ignoring internal implementation) and other decisions affecting further design of the database. in meeting its requirements. identify the project sponsor. It shall describe the general nature of the database.J-STD-016-1998 Page 127 Database Design Description (DBDD) -. Design decisions regarding queries or other input the database will accept and output (displays. including interfaces with other systems. This subclause shall contain a full identification of the database to which this document applies. identify current and planned operating sites. If some or all of the design decisions are described in the documentation of a custom or commercial database management system (DBMS). Design decisions that respond to requirements designated critical. title(s). date. and users (5. this clause shall so state. Design conventions needed to understand the design shall be presented or referenced. Referenced documents. this dependency shall be indicated.2 Database overview. such as those for safety. . d. and release number(s). developer. as applicable. summarize the history of its development. decisions about the database's behavioral design (how it will behave. 2. including.(continued) 1.3 Document overview. Scope. Database-wide design decisions. This clause shall list the number.d of the DBDD identifies topics to be considered in this description). abbreviation(s). use. Design decisions on database behavior in response to each input or query. If part or all of this information is given in Interface Design Descriptions (IDDs).x. c. and list other relevant documents. selected equations/algorithms/rules.) it will produce. and source of all documents referenced in this manual. 1.x of the DBDD identifies topics to be considered in this description) Design decisions on the database management system to be used (including name. acquirer. and maintenance. This subclause shall briefly state the purpose of the database to which this document applies. etc. disposition. Examples of database-wide design decisions are the following: a. that is. 1. If all such decisions are explicit in the system or software item requirements. title. shall be placed in separate subclauses. version number(s). This clause should be divided into the following subclauses. and maintenance organizations.1 Identification. software items. response times and other performance characteristics. user. responses. 1. and handling of unallowed inputs Design decisions on how databases/data files will appear to the user (4. that has structure (number/order/grouping of data elements) at a given design level (e. The number of levels of design and the names of those levels shall be based on the design methodology used. logical. data element. and continuity of operations to be offered by the database Design decisions on database distribution (such as client/server). If part or all of the design depends upon system states or modes.J-STD-016-1998 Page 128 Database Design Description (DBDD) -. field name in the database) e) Abbreviation or synonymous names 2) Data type (alphanumeric. cell. as applicable. field. Design of the database. h. schema. table. security. relation. 4.. Note: The term "data element assembly" is used to mean any entity. etc. presented in any order suited to the information to be provided: a. The information shall include the following. synchronization. that does not have structure at that level. array.. etc. internal. attribute. and consistency including automated disk management and space reclamation considerations. enforcing integrity and business rules Design decisions on backup and restoration including data and process distribution strategies. permissible actions during backup and restoration. privacy protection. including maintaining consistency.) 3) Size and format (such as length and punctuation of a character string) 4) Units of measurement (such as meters. sorting. this dependency shall be indicated. indexing. physical) and the term "data element" to mean any relation. conceptual. integer.x (Name of database design level). master database file updates and maintenance. nanoseconds) 5) Range or enumeration of possible values (such as 0-99) 6) Accuracy (how correct) and precision (number of significant digits) . optimizing strategies and considerations. storage and size considerations. dollars. Design conventions needed to understand the design shall be presented or referenced. Characteristics of individual data elements in the database design. internal. Design decisions on the levels and types of availability.g. etc. Examples of database design levels include conceptual. 4. f. and population of the database and capture of legacy data g. field.g. This subclause shall identify a database design level and shall describe the data elements and data element assemblies of the database in the terminology of the selected design method. This clause should be divided into subclauses as needed to describe the design of the database.. and physical. establishing/ reestablishing and maintaining synchronization.(continued) e. such as: 1) Names/identifiers a) Project-unique identifier b) Non-technical (natural language) name c) Standard data element name d) Technical name (e. and special considerations for new or non-standard technologies such as video and sound Design decisions on repacking. logical. Any constraints. such as whether the data element may be updated and whether business rules apply Security and privacy protection constraints Sources (setting/sending entities) and recipients (using/receiving entities) Characteristics of data element assemblies (records. record or data structure name in code or database) d) Abbreviations or synonymous names 2) Data elements in the assembly and their structure (number. if any. input to a graphical user interface (GUI) builder for automated code generation. beeps. lights) 5) Relationships among assemblies. frequency. layouts. and other constraints. a list of the procedural commands and a . messages. sequencing. or shell scripts). such as: 1) Names/identifiers a) Project-unique identifier b) Non-technical (natural language) name c) Technical name (e. Unit design decisions. and other constraints. sequencing. on-line DBMS queries for database access and manipulation. If design information falls into more than one subclause. if not previously selected. it may be presented once and referenced from the other subclauses. as applicable. If part or all of the design depends upon system states or modes. If part or all of this information is provided elsewhere. b. such as sorting/access characteristics 6) Priority. grouping) 3) Medium (such as disk) and structure of data elements/assemblies on the medium 4) Visual and auditory characteristics of displays and other outputs (such as colors. Software units that contain other software units may reference the descriptions of those units rather than repeating information. etc. the SDD for a customized DBMS. timing. fonts. that information may be referenced rather than repeated here. or designator of a group of software units). volume. reports.. a. This subclause shall identify a software unit by project-unique identifier and shall describe the unit. displays. The programming language to be used and rationale for its use if other than the specified language for the software item Database Design Description (DBDD) -. 5.) in the database design. Priority. files. This clause should be divided into the following subclauses to describe each software unit used for database access or manipulation. volume. arrays. limitations. such as whether the assembly may be updated and whether business rules apply 7) Security and privacy protection constraints 8) Sources (setting/sending entities) and recipients (using/receiving entities) 5. or unusual features in the design of the software unit c. this dependency shall be indicated. Detailed design of software units used for database access or manipulation. such as in a Software Design Description (SDD).x (Project-unique identifier of a software unit. commands to the operating system. Alternatively.(continued) d. icons and other display elements. or the user manual of a commercial DBMS. Design conventions needed to understand the design shall be presented or referenced. timing.J-STD-016-1998 Page 129 Database Design Description (DBDD) -. such as algorithms to be used. The description shall include the following information.(continued) 7) 8) 9) b.g. If the software unit consists of or contains procedural commands (such as menu selections in a DBMS for defining forms and reports. order. frequency. this subclause may designate a group of software units and identify and describe the software units in subordinate subclauses. etc. Characteristics of data element assemblies (records. access. and standards for user interfaces) in place of stating the information here.J-STD-016-1998 Page 130 reference to user manuals or other documents that explain them e.) that the interfacing entity(ies) will provide. version. such as: a) Project-unique identifier(s) b) Communication links/bands/frequencies/media and their characteristics 6) 7) ." This subclause may reference other documents (such as data dictionaries. presented in any order suited to the information to be provided.x.. a description of its inputs. Characteristics of communication methods that the interfacing entity(ies) will use for the interface. an external system) but its interface characteristics need to be mentioned to describe software units that are. users. The design description shall include the following. files. as applicable.a of the DBDD identifies topics to be covered in this description. displays. etc. as applicable. receives. If a given interfacing entity is not covered by this DBDD (for example. store. Interface characteristics may be provided here or by referencing Interface Design Description(s). etc.x. hardware items.) by name. Subclause 4. software items. and other data elements and data element assemblies. If the software unit contains. standards for protocols.b of the DBDD identifies topics to be covered in this description. these characteristics shall be stated as assumptions or as "When [the entity not covered] does this.. frequency. and shall note any differences in these characteristics from the point of view of the interfacing entities (such as different expectations about the size. storage-and-retrieval of data. number. arrays. etc. etc. and documentation references. or outputs data. receive. reports. store.. send. Data local to the software unit shall be described separately from data input to or output from the software unit. Subclause 4. as applicable Priority assigned to the interface by the interfacing entity(ies) Type of interface (such as real-time data transfer. receive. messages. outputs. or other characteristics of data elements): 1) 2) 3) 4) 5) Project-unique identifier for the interface Identification of the interfacing entities (software units.) to be implemented Characteristics of individual data elements that the interfacing entity(ies) will provide. access. send. [the software unit] will . (continued) c) d) e) f) g) h) 8) Message formatting Flow control (such as sequence numbering and buffer allocation) Data transfer rate. and recovery procedures e) Synchronization. and naming conventions Transmission services. priority assignments c) Data transfer in and out of memory d) The sensing of discrete input signals. routing. addressing. compartmentalization. and any other reporting features Other characteristics. If the software unit contains logic. including priority and grade Safety/security/privacy protection considerations. and addressing d) Legality checks. etc. termination f) Status. the logic to be used by the software unit. including fragmentation and reassembly. This clause shall contain: a. such as physical compatibility of the interfacing entity(ies) (dimensions. user authentication.) 9) f. including data conversion. tolerances. such as timing variations. as applicable: 1) Conditions in effect within the software unit when its execution is initiated 2) Conditions under which control is passed to other software units 3) Response and response time to each input. and data transfer operations 4) Sequence of operations and dynamically controlled sequencing during the software unit's operation. and auditing Characteristics of protocols that the interfacing entity(ies) will use for the interface. including: a) The method for sequence control b) The logic and input conditions of that method. renaming. including. such as: a) Project-unique identifier(s) b) Priority/layer of the protocol c) Packeting. voltages. whether periodic/aperiodic. loads. Requirements traceability. Traceability from each database or other software unit covered by this DBDD to the system or software item requirements it addresses. such as encryption. . identification. and timing relationships between interrupt operations within the software unit 5) Exception and error handling 6. plug compatibility. including connection establishment. maintenance. error control.J-STD-016-1998 Page 131 Database Design Description (DBDD) -. and interval between transfers Routing. A. Annexes. This clause shall contain any general information that aids in understanding this document (e. For example. etc.g. Annexes shall be lettered alphabetically (A. and their meanings as used in this document and a list of any terms and definitions needed to understand this document.). glossary. charts. background information.g. b. 7. As applicable. abbreviations.J-STD-016-1998 Page 132 Database Design Description (DBDD) -. each annex shall be referenced in the main body of the document where the data would normally have been provided. Traceability from each system or software item requirement that has been allocated to a database or other software unit covered in this DBDD to the database or other software units that address it.. .(continued) Note: Each level of system refinement may result in requirements not directly traceable to higher-level requirements. even though these interfaces are not covered in system requirements. Such requirements may be traced to a general requirement such as "system implementation" or to the system design decisions that resulted in their generation. Annexes may be used to provide information published separately for convenience in document maintenance (e. rationale). a system architectural design that creates two subsystems may result in requirements about how the subsystems will interface. Notes. B. classified data). This clause shall include an alphabetical listing of all acronyms. Annexes may be bound as separate documents for ease in handling.. Identification System overview Document overview Referenced documents System item-wide design decisions Software item architectural design 4. Software item detailed design 5. Requirements traceability Notes Annexes .4 Contents of the Software Design Description (SDD) SOFTWARE DESIGN DESCRIPTION (SDD) Contents 1. or designator of a group of software units) 6.3 2. A.2.x Interface identification and diagrams (Project-unique identifier of interface) 5.J-STD-016-1998 Page 133 G.1 4.2 4. 3.3 Software item components Concept of execution Interface design 4.1 4.3.3.1 1. 7.2 1.x (Project-unique identifier of a software unit.2.4 Contents of the Software Design Description (SDD)G. 4. Scope 1. If part or all of this information is given in Interface Design Descriptions (IDDs). This clause should be divided into subclauses as needed to present software item-wide design decisions. summarize the history of system development. 3. version number(s). Software item-wide design decisions.1 Identification. operation. 2. This subclause shall contain a full identification of the system and the software to which this document applies. ignoring internal implementation) and other decisions affecting the selection and design of the software units that make up the software item. Examples of software item-wide design decisions are the following: a.x of the SDD identifies topics to be considered in this description).3. response times and other performance characteristics. this clause shall so state. or privacy protection. 1. and source of all documents referenced in this manual. Design decisions regarding input the software item will accept and output it will produce. this dependency shall be indicated. If all such decisions are explicit in the software item requirements or are deferred to the design of the software item's software units. and users (4. abbreviation(s).3. identify current and planned operating sites.3 Document overview. and maintenance. developer. It shall describe the general nature of the system and software. identification number(s). This clause shall list the number. 1. If part or all of this information is given in Database Design Descriptions (DBDDs). such as those for safety. acquirer. date.J-STD-016-1998 Page 134 Software Design Description (SDD) -. title. and handling of unallowed inputs or conditions. This subclause shall briefly state the purpose of the system and the software to which this document applies. software items. and release number(s). Design decisions that respond to requirements designated critical. as applicable. in meeting its requirements. Referenced documents. This subclause shall summarize the purpose and contents of this document and shall describe any security or privacy protection considerations associated with its use.2 System overview. If a design decision depends upon system states or modes.x of the SDD identifies topics to be considered in this description). that is. and maintenance organizations. b. Scope. including interfaces with other systems. Design decisions on how databases/data files will appear to the user (4. description of physical systems modeled. user. revision.(continued) 1. Design decisions on software item behavior in response to each input or condition. c. Design conventions needed to understand the design shall be presented or referenced. shall be placed in separate subclauses. from a user's point of view. selected equations/algorithms/rules. decisions about the software item's behavioral design (how it will behave. 1. including. hardware items. . security. including actions the software item will perform. they may be referenced. identify the project sponsor. they may be referenced. title(s). This clause should be divided into the following subclauses. and list other relevant documents. depending on the selected software design methodology (for example. b. in system-level resource allocations affecting the software c. software to be developed for reuse. module. a class. A database may be treated as a software item or as a software unit. Show the static (such as "consists of") relationship(s) of the software units. function. Software units in the design may or may not have a oneto-one relationship with the code and data entities (routines. or database. it may be presented once and referenced from the other subclauses. routine. Each software unit shall be assigned a project-unique identifier. Other software item-wide design decisions made in response to requirements. this subclause may present the class and object structures as well as the module and process architectures of the software item). library. a major subdivision of a software item. e. Design conventions needed to understand the design shall be presented or referenced. etc.) Identify each software unit's development type (such as new development. Identify the software units that make up the software item. etc. procedures. object. the description shall provide identifying information. Describe the software item's (and as applicable. for example. software planned for Build N. such as name.1 Software item components.) For existing design or software.a. Software item architectural design. version. each software unit's) planned utilization of computer hardware resources (such as processor capacity. etc. and communications/network equipment capacity). and maintainability. Multiple relationships may be presented. . this dependency shall be indicated. e. d. databases. memory capacity. Software units may occur at different levels of a hierarchy and may consist of other software units. This subclause shall: a. State the purpose of each software unit and identify the software item requirements and software item-wide design decisions allocated to it. The description shall cover all computer hardware resources included in resource utilization requirements for the software item. 4. and privacy protection requirements. Selected approach to meeting safety. If part or all of the design depends upon system states or modes. availability. in an object-oriented design. Note: A software unit is an element in the design of a software item.) that implement them or with the computer files containing those entities. security. The SDD may refer to software units by any name(s) consistent with the design methodology being used.J-STD-016-1998 Page 135 Software Design Description (SDD) -. 4. This clause should be divided into the following subclauses to describe the software item architectural design. existing design or software to be reused as is. documentation references. such as selected approach to providing required flexibility. (Alternatively.(continued) d. If design information falls into more than one subclause. input/output device capacity. the allocation of requirements may be provided in 6. data files. existing design or software to be reengineered. auxiliary storage capacity. a component of that subdivision. J-STD-016-1998 Page 136 Software Design Description (SDD) -. including. . It shall include both interfaces among the software units and their interfaces with external entities such as systems. or elsewhere. 4. cycles per second. concurrent execution. typical usage. as appropriate. One or more interface diagrams shall be provided. bytes of memory.) by name. This subclause shall state the project-unique identifier assigned to each interface and shall identify the interfacing entities (software units. software item. This subclause shall describe the concept of execution among the software units. etc. If part or all of this information is contained in Interface Design Descriptions (IDDs).3 Interface design. This subclause should be divided as follows to describe the interface characteristics of the software units. timing diagrams. or multiprocessors or the impacts of operating system overhead. that is. these sources may be referenced. and users. users. in clause 5 of the SDD. It shall include diagrams and descriptions showing the dynamic relationship of the software units. hardware items. overlays. as applicable. processes. 4. version. Identify the program library in which the software that implements each software unit is to be placed 4. handling of interrupts. library software. timing/sequencing relationships.(continued) item. data flow.1 Interface identification and diagrams. Included for each computer hardware resource shall be: 1) 2) 3) The software item requirements or system-level resource allocations being satisfied The assumptions and conditions on which the utilization data are based (for example. assumption of certain events) Any special considerations affecting the utilization (such as use of virtual memory. hardware items. software items. systems. The identification shall state which entities have fixed interface characteristics (and therefore impose interface requirements on interfacing entities) and which are being developed or modified (thus having interface requirements imposed on them). software items. flow of execution control. state transition diagrams. as applicable. If all utilization data for a given computer hardware resource are presented in a single location. this subclause may reference that source. worst-case usage. or other implementation overhead) The units of measure used (such as percentage of processor capacity. dynamic allocation/deallocation. dynamic creation/deletion of objects. and documentation references. such as in one SDD. number. priorities among units. or executable program) 4) 5) f. dynamically controlled sequencing.2 Concept of execution. and in resource utilization measurement planning in the Software Development Plan. and other aspects of dynamic behavior. kilobytes per second) The level(s) at which the estimates or measures will be made (such as software unit. tasks.3. how they will interact during software item operation. to depict the interfaces. exception handling. " This subclause may reference other documents (such as data dictionaries. and should be divided as needed to describe the interface characteristics of one or both of the interfacing entities. these characteristics shall be stated as assumptions or as "When [the entity not covered] does this. nanoseconds) 5) Range or enumeration of possible values (such as 0-99) 6) Accuracy (how correct) and precision (number of significant digits) 7) Priority.J-STD-016-1998 Page 137 Software Design Description (SDD) -. receive. dollars. etc. This subclause (beginning with 4.. or other characteristics of data elements): a. such as: 1) Names/identifiers a) Project-unique identifier b) Non-technical (natural language) name c) Standard data element name d) Technical name (e.) to be implemented Characteristics of individual data elements that the interfacing entity(ies) will provide. and shall note any differences in these characteristics from the point of view of the interfacing entities (such as different expectations about the size. and standards for user interfaces) in place of stating the information here.3. messages. store.. arrays. If a given interfacing entity is not covered by this SDD (for example. access. etc. timing. and other constraints.. integer. as applicable. such as: d.) that the interfacing entity(ies) will provide. etc. sequencing.(continued) 4. frequency.) 3) Size and format (such as length and punctuation of a character string) 4) Units of measurement (such as meters. displays. standards for protocols. shall briefly identify the interfacing entities. Priority assigned to the interface by the interfacing entity(ies) Type of interface (such as real-time data transfer. access. files.. storage-and-retrieval of data. presented in any order suited to the information to be provided. such as whether the data element may be updated and whether business rules apply 8) Security and privacy protection constraints 9) Sources (setting/sending entities) and recipients (using/receiving entities) Characteristics of data element assemblies (records. . variable or field name in code or database) e) Abbreviation or synonymous names 2) Data type (alphanumeric.. [the entity that is covered] will . receive.3. send. send.. an external system) but its interface characteristics need to be mentioned to describe interfacing entities that are. b. etc.g. store. etc.2) shall identify an interface by project-unique identifier. reports. volume. frequency. The design description shall include the following. c.x (Project-unique identifier of interface). error control. including priority and grade 8) Safety/security/privacy protection considerations. such as physical compatibility of the interfacing entity(ies) (dimensions. such as: 1) Project-unique identifier(s) 2) Priority/layer of the protocol 3) Packeting. including connection establishment. such as: 1) Project-unique identifier(s) 2) Communication links/bands/frequencies/media and their characteristics 3) Message formatting 4) Flow control (such as sequence numbering and buffer allocation) 5) Data transfer rate. and interval between transfers 6) Routing. such as encryption. and naming conventions 7) Transmission services. fonts. and other constraints. identification.. routing. . volume. addressing. loads. such as sorting/access characteristics Priority. etc. whether periodic/aperiodic. voltages.(continued) 1) Names/identifiers a) Project-unique identifier b) Non-technical (natural language) name c) Technical name (e. order.g. maintenance. sequencing. frequency. grouping) Medium (such as disk) and structure of data elements/assemblies on the medium Visual and auditory characteristics of displays and other outputs (such as colors. plug compatibility.J-STD-016-1998 Page 138 Software Design Description (SDD) -. record or data structure name in code or database) d) Abbreviations or synonymous names Data elements in the assembly and their structure (number. and recovery procedures 5) Synchronization. user authentication. layouts. g. timing. and auditing Characteristics of protocols that the interfacing entity(ies) will use for the interface. beeps. termination 6) Status.) f. compartmentalization. and addressing 4) Legality checks. Characteristics of communication methods that the interfacing entity(ies) will use for the interface. lights) Relationships among assemblies. including fragmentation and reassembly. such as whether the assembly may be updated and whether business rules apply Security and privacy protection constraints Sources (setting/sending entities) and recipients (using/receiving entities) 2) 3) 4) 5) 6) 7) 8) e. tolerances. icons and other display elements. and any other reporting features Other characteristics. or that are used to access or manipulate databases. if any. Unit design decisions. or unusual features in the design of the software unit The programming language to be used and rationale for its use if other than the specified software item language If the software unit consists of or contains procedural commands (such as menu selections in a database management system (DBMS) for defining forms and reports. f. input to a graphical user interface (GUI) builder for automated code generation. this subclause may designate a group of software units and identify and describe the software units in subordinate subclauses. Interface characteristics of software units may be described here. or outputs data. as applicable. commands to the operating system. or in Interface Design Descriptions (IDDs). If the software unit contains logic. If part or all of the design depends upon system states or modes. This subclause shall identify a software unit by project-unique identifier and shall describe the unit.(continued) 5. . Alternatively. Software item detailed design. Data local to the software unit may be described separately from data input to or output from the software unit. a description of its inputs. outputs. or shell scripts). a corresponding Database Design Description (DBDD) may be referenced. renaming. b. Design conventions needed to understand the design shall be presented or referenced.J-STD-016-1998 Page 139 Software Design Description (SDD) -.x of the SDD provides a list of topics to be covered. limitations. a list of the procedural commands and reference to user manuals or other documents that explain them If the software unit contains. as applicable. including. as applicable: 1) 2) 3) Conditions in effect within the software unit when its execution is initiated Conditions under which control is passed to other software units Response and response time to each input. Software units that are databases. Software units that contain other software units may reference the descriptions of those units rather than repeating information.3. priority e. if not previously selected Any constraints. and other data elements and data element assemblies. Subclause 4. If design information falls into more than one subclause. a.(continued) 4) Sequence of operations and dynamically controlled sequencing during the software unit's operation. including: a) b) The method for sequence control The logic and input conditions of that method. c. 5. The description shall include the following information. and data transfer operations Software Design Description (SDD) -. it may be presented once and referenced from the other subclauses. such as algorithms to be used. receives. the logic to be used by the software unit. may be described here or in Database Design Descriptions (DBDDs). d. interface characteristics may be provided here or by referencing clause 4 or the corresponding Interface Design Description(s).x (Project-unique identifier of a software unit. This clause should be divided into the following subclauses to describe each software unit of the software item. on-line DBMS queries for database access and manipulation. as applicable. including data conversion. If the software unit is a database. this dependency shall be indicated. in clause 4. such as timing variations. or designator of a group of software units). rationale).. charts. . This clause shall include an alphabetical listing of all acronyms.) Note: Each level of software item refinement may result in requirements not directly traceable to higher-level requirements. For example. classified data).). a software architectural design that creates two software units may result in requirements about how the software units will interface. background information. and their meanings as used in this document and a list of any terms and definitions needed to understand this document. even though these interfaces are not covered in software item requirements. Annexes may be bound as separate documents for ease in handling. B. This clause shall contain any general information that aids in understanding this document (e. This clause shall contain: a. Annexes shall be lettered alphabetically (A. Requirements traceability.g. Such requirements may be traced to a general requirement such as "software item" or to the software design decisions that resulted in their generation. b.J-STD-016-1998 Page 140 assignments c) d) 5) Data transfer in and out of memory The sensing of discrete input signals. Traceability from each software item requirement to the software units to which it is allocated. (Alternatively. Notes. Annexes. and timing relationships between interrupt operations within the software unit Exception and error handling 6.. this traceability may be provided in 4.g. Traceability from each software unit identified in this SDD to the software item requirements allocated to it. abbreviations. glossary. 7. etc. each annex shall be referenced in the main body of the document where the data would normally have been provided.1. As applicable. A. Annexes may be used to provide information published separately for convenience in document maintenance (e. binding) part of this standard.1 Scope This annex specifies the contents of software products associated with qualification testing in this standard (the Software Test Plan is found together with other plans in annex E).2 Software products covered This following subclauses describe the contents of the software products covered by this annex. subject to tailoring.1 ScopeH. It applies regardless of whether the software products are deliverable. The products are listed in the order they are referenced in this standard and include the following: a) Software Test Description (STD) b) Software Test Report (STR) .J-STD-016-1998 Page 141 Annex HAnnex H Qualification testing software product descriptionsQualification testing software product descriptions (normative) H. H. This annex is a normative (that is.2 Software products coveredH. 2 1.y (Project-unique identifier of a test case) 4.x.y.5 4.x (project-unique identifier of a test) 3.1 3.4 4.y.7 Requirements addressed Prerequisite conditions Test input Expected test results Criteria for evaluating results Test procedure Assumptions and constraints 5.3 Hardware preparation Software preparation Other pre-test preparations 4.x (Project-unique identifier of a test) 4.y.y. Scope 1.J-STD-016-1998 Page 142 H.1 4. Test descriptions 4.x.x.3 2.x. 3.x.2 4.2.x.x.y.3 4.6 4.1 1. Requirements traceability Notes Annexes .1 Contents of the Software Test Description (STD)H.1 Contents of the Software Test Description (STD) SOFTWARE TEST DESCRIPTION (STD) Contents 1.x.y. Identification System overview Document overview Referenced documents Test preparations 3.y. A.x.2 3.2. 6.x.x. Reference may be made to published operating manuals for these procedures. and maintenance. c. abbreviation(s). The specific hardware to be used. Referenced documents. This subclause shall describe the procedures necessary to prepare the hardware for the test.3 Document overview. identified by name and. as applicable: a. 1. This clause should be divided into the following subclauses. diskette) .2 System overview. This subclause shall summarize the purpose and contents of this document and shall describe any security or privacy protection considerations associated with its use. b. The following shall be provided. 2. acquirer.1 Hardware preparation. 3. identify the project sponsor. Scope.J-STD-016-1998 Page 143 Software Test Description (STD) -. and release number(s). b. and data paths Step-by-step instructions for placing the hardware in a state of readiness 3. 3. 1. shall provide a brief description. user. operation. title(s). This clause shall list the number.x. number Any switch settings and cabling necessary to connect the hardware One or more diagrams to show hardware. if applicable. d.x. title. This subclause shall contain a full identification of the system and the software to which this document applies. This subclause shall describe the procedures necessary to prepare the item(s) under test and any related software. that information may be referenced rather than repeated. magnetic tape. marked by WARNING or CAUTION. and maintenance organizations. identify current and planned operating sites. and security and privacy protection considerations shall be included as applicable. The following information shall be provided. revision. This clause should be divided into the following subclauses.(continued) 1. This subclause shall briefly state the purpose of the system and the software to which this document applies. and list other relevant documents. It shall describe the general nature of the system and software. version number(s). The specific software to be used in the test The storage medium of the item(s) under test (e. developer.. as applicable: a. including.2 Software preparation. for the test. date. 1. and source of all documents referenced in this manual.1 Identification. Safety precautions. This subclause shall identify a test by project-unique identifier.x (Project-unique identifier of a test). identification number(s). as applicable. When the information required duplicates information previously specified for another test. Test preparations. Reference may be made to published software manuals for these procedures. 3. and should be divided into the following.g. summarize the history of system development. interconnecting control. including data. J-STD-016-1998 Page 144 Software Test Description (STD) -.. or initial data to be set/reset prior to test commencement Preset hardware conditions or electrical states necessary to run the test case Initial conditions to be used in making timing measurements Conditioning of the simulated environment Other special conditions peculiar to the test case 4. The storage medium of any related software (e. accuracy) of each test input Source of the test input and the method to be used for selecting the test input Whether the test input is real or simulated Time or event sequence of test input . Test descriptions.y (Project-unique identifier of a test case). This subclause shall describe any other pre-test personnel actions.2 Prerequisite conditions. and security and privacy protection considerations shall be included as applicable.(continued) c.) 4. databases) Instructions for loading the software. d.. The following shall provide a detailed description of the test case.x. d. This subclause shall describe the test input necessary for the test case. Hardware and software configuration Flags. e.y. that information may be referenced rather than repeated. The following considerations shall be discussed.3 Other pre-test preparations. initial breakpoints. and description (e. This clause should be divided into the following subclauses.x (Project-unique identifier of a test). 4. Name.x. The following shall be provided. This subclause shall identify any prerequisite conditions that are required to be established prior to performing the test case. c. This subclause shall identify the software item or system requirements addressed by the test case.g.x. 4. simulators.x. as applicable: a.y. (Alternatively. purpose. 4. This subclause shall identify a test by project-unique identifier and should be divided into the following.1 Requirements addressed. b.x. or procedures necessary to perform the test. d. and provide a brief description. as applicable: a. including required sequence Instructions for software initialization common to more than one test case 3. this information may be provided in 5. Safety precautions. preparations. marked by WARNING or CAUTION. e. b. control parameters.3 Test input. This subclause shall identify a test case by project-unique identifier. f. state its purpose. 4.a.g. c. range of values. pointers. test drivers. When the required information duplicates information previously provided.y. Test operator actions and equipment operation required for each step. e. each keystroke may be a separate test procedure step. for most software. if necessary 4. or other system breaks that may occur Allowable severity of processing errors Conditions under which the result is inconclusive and re-testing is to be performed Conditions under which the output is to be interpreted as indicating irregularities in input test data. including commands. as applicable: a.y.4 Expected test results.y. The test procedure shall be defined as a series of individually numbered steps listed sequentially in the order in which the steps are to be performed. d. as applicable. to: . The manner in which the input data will be controlled to: 1) Test the item(s) with a minimum/reasonable number of data types and values 2) Exercise the item(s) with a range of valid data types and values that test for overload. in terms of time or number of events Maximum number of interrupts. This subclause shall define the test procedure for the test case. each step may include a logically related series of keystrokes or other actions. as applicable.y. This subclause shall identify all expected test results for the test case. f. h. For convenience in document maintenance.(continued) e. For each test result.x. c. and other "worst case" effects 3) Exercise the item(s) with invalid data types and values to test for appropriate handling of irregular inputs 4) Permit retesting. The appropriate level of detail is the level at which it is useful to specify expected results and compare them to actual results. or in test procedures Allowable indications of the control. Both intermediate and final test results shall be provided. status. halts.5 Criteria for evaluating results. The following shall be provided for each test procedure. i. and results of the test and the readiness for the next test case (may be output of auxiliary test software) Additional criteria not mentioned above. The appropriate level of detail in each test procedure depends on the type of software being tested. 4.x.J-STD-016-1998 Page 145 Software Test Description (STD) -. as applicable: a.x. the following information shall be provided. in the test database/data files. the test procedures may be included as an annex and referenced in this subclause. For some software. g. This subclause shall identify the criteria to be used for evaluating the intermediate and final results of the test case. The range or accuracy over which an output can vary and still be acceptable Minimum number of combinations or alternatives of input and output conditions that constitute an acceptable test result Maximum/minimum allowable test duration. b. saturation. 4.6 Test procedure. 5. as applicable: 1) Detect whether an output has been produced 2) Identify media and location of data produced by the test case 3) Evaluate output as a basis for continuation of test sequence 4) Evaluate test output against required output 4.) . if needed Modify the database/data files Repeat the test case if unsuccessful Apply alternate modes as required by the test case Terminate the test case b. this information may be provided in 5. identification of which test procedure step(s) address which requirements. Traceability from each test case in this STD to the system or software item requirements it addresses. Actions to follow in the event of a program stop or indicated error. If the test case addresses multiple requirements.) d. If a test case addresses multiple requirements. such as limitations on timing. Procedures to be used to reduce and analyze test results to accomplish the following. Requirements traceability. this traceability may be provided in 4. Expected result and evaluation criteria for each step c.1.x.(continued) 1) 2) 3) 4) 5) 6) 7) 8) 9) 10) Initiate the test case and apply test input Inspect test conditions Perform interim evaluations of test results Record data Halt or interrupt the test case Request data dumps or other aids.y.J-STD-016-1998 Page 146 Software Test Description (STD) -. (Alternatively. equipment. If waivers or exceptions to specified limits and parameters are approved. traceability from each set of test procedure steps to the requirement(s) addressed. they shall be identified and this subclause shall address their effects and impacts upon the test case. and database/data files. interfaces.y.x. (Alternatively. This subclause shall contain: a.7 Assumptions and constraints. such as: 1) Recording of critical data from indicators for reference purposes 2) Halting or pausing time-sensitive test-support software and test apparatus 3) Collection of system and operator records of test results e. personnel. This subclause shall identify any assumptions made and constraints or limitations imposed in the description of the test case due to system or test conditions. Annexes. Traceability from each system or software item requirement covered by this STD to the test case(s) that address it. For software item testing. If a test case addresses multiple requirements. B.g. etc. glossary. classified data). Annexes may be bound as separate documents for ease in handling. traceability from each system requirement in the system's System/Subsystem Specification (SSS) and associated IRSs. This clause shall include an alphabetical listing of all acronyms...J-STD-016-1998 Page 147 Software Test Description (STD) -. and their meanings as used in this document and a list of any terms and definitions needed to understand this document. Notes. abbreviations. the traceability shall indicate the particular test procedure steps that address each requirement. 6. A. charts. As applicable.(continued) b. each annex shall be referenced in the main body of the document where the data would normally have been provided.g. Annexes may be used to provide information published separately for convenience in document maintenance (e. For system testing. Annexes shall be lettered alphabetically (A. .). rationale). background information. This clause shall contain any general information that aids in understanding this document (e. traceability from each software item requirement in the software item's Software Requirements Specification (SRS) and associated Interface Requirements Specifications (IRSs). y 4.3 2.y (Project-unique identifier of a test case) 5.2 Contents of the Software Test Report (STR)H.3 (Project-unique identifier of a test case) Deviations from test cases/procedures 4.2 3.2 Summary of test results Problems encountered 4. Detailed test results 4.x.x. 6.3 Overall assessment of the software tested Impact of test environment Recommended improvements 4.x (Project-unique identifier of a test) 4.2.2 1.x. A.x.3. Scope 1. Test log Notes Annexes .2.J-STD-016-1998 Page 148 H.1 1.2 Contents of the Software Test Report (STR) SOFTWARE TEST REPORT (STR) Contents 1. Identification System overview Document overview Referenced documents Overview of test results 3. 3.x.1 3.1 4.2. 2. This subclause shall provide an assessment of the manner in which the test environment may be different from the operational environment and the effect of this difference on the test results. Referenced documents. abbreviation(s). title(s). c. title. describe: 1) Its impact on software and system performance. It shall describe the general nature of the system and software.1 Overall assessment of the software tested. or constraints that were detected by the testing performed.1 Identification. operation. 1. date. 1. and release number(s). 3. as applicable. acquirer. This subclause shall contain a full identification of the system and the software to which this document applies. This subclause shall briefly state the purpose of the system and the software to which this document applies.3 Recommended improvements. Scope. or testing of the software tested. developer.J-STD-016-1998 Page 149 Software Test Report (STR) -. This clause should be divided into the following subclauses. version number(s). b. 3. identification number(s). revision. identify current and planned operating sites. 1. and maintenance. this subclause shall state "None. including identification of requirements not met 2) The impact on software and system design to correct it 3) A recommended solution/approach for correcting it 3. This subclause shall provide any recommended improvements in the design. limitation. including. user. This clause shall list the number. identify the project sponsor. limitations.2 System overview. and maintenance organizations. Problem/change reports may be used to provide deficiency information. operation. summarize the history of system development. or constraint. For each remaining deficiency. and list other relevant documents.2 Impact of test environment. Overview of test results.(continued) 1. This subclause shall: a. 3. Provide an overall assessment of the software as demonstrated by the test results in this report Identify any remaining deficiencies. If no recommended improvements are provided." . This clause should be divided into the following subclauses to provide an overview of test results. and source of all documents referenced in this manual. This subclause shall summarize the purpose and contents of this document and shall describe any security or privacy protection considerations associated with its use. A discussion of each recommendation and its impact on the software may be provided.3 Document overview. x. 4. Note: The word "test" means a related collection of test cases. e. Detailed test results. 4. This subclause shall identify by project-unique identifier a test case in which one or more problems occurred. b.x. test case run in which the deviation occurred and nature of the deviation." this subclause shall reference the following subclauses for details. A description of the deviation(s) (for example. This subclause shall identify a test by project-unique identifier and should be divided into the following to describe the test results. A brief description of the problem(s) that occurred Identification of the test procedure step(s) in which they occurred Reference(s) to the associated problem/change report(s) and backup data. 4. and shall provide: a. c. c. This clause should be divided into the following subclauses to describe the detailed results for each test. This subclause should be divided into subclauses that identify each test case in which one or more problems occurred.x (Project-unique identifier of a test).y (Project-unique identifier of a test case).2 Problems encountered. possibly in a table.J-STD-016-1998 Page 150 Software Test Report (STR) -. When the completion status is not "as expected. and shall provide: a. d. (Red-lined test procedures may be used to show the deviations) The rationale for the deviation(s) An assessment of the deviations' impact on the validity of the test case b. 4. The summary shall include.x." "deviations required"). procedural steps not followed. "all results as expected.(continued) 4. as applicable The number of times the procedure or step was repeated in attempting to correct the problem(s) and the outcome of each attempt Back-up points or test steps where tests were resumed for retesting 4.2. . 4." "problems encountered.y (Project-unique identifier of a test case).3 Deviations from test cases/procedures. such as substitution of required equipment.3. This subclause shall identify by project-unique identifier a test case in which one or more deviations occurred.x. schedule deviations). This subclause shall summarize the results of the test. the completion status of each test case associated with the test (for example.x. This subclause should be divided into sub-clauses that identify each test case in which deviations from test case/test procedures occurred.1 Summary of test results. B. as applicable. abbreviations.). A. Annexes. This clause shall include an alphabetical listing of all acronyms. Annexes may be used to provide information published separately for convenience in document maintenance (e. background information. and version number and name for the software components used The date and time of each test-related activity.. As applicable. and calibration date of all hardware. glossary. a chronological record of the test events covered by this report. This clause shall present. Notes. manufacturer.. and location(s) of the tests performed The hardware and software configurations used for each test including. This test log shall include: a. . classified data). charts. Annexes shall be lettered alphabetically (A. the identity of the individual(s) who performed the activity. b.g. The date(s).J-STD-016-1998 Page 151 Software Test Report (STR) -. time(s). This clause shall contain any general information that aids in understanding this document (e. 6. Test log. rationale).g. Annexes may be bound as separate documents for ease in handling. part/model/serial number. and their meanings as used in this document and a list of any terms and definitions needed to understand this document. etc. each annex shall be referenced in the main body of the document where the data would normally have been provided. as applicable c.(continued) 5. possibly in a figure or annex. revision level. and the identities of witnesses. 1 ScopeI. It applies regardless of whether the software products are deliverable. subject to tailoring. The products are listed in the order they are referenced in this standard and include the following: a) b) c) d) Software Product Specification (SPS) Software Version Description (SVD) Computer Programming Manual (CPM) Firmware Support Manual (FSM) . This annex is a normative (that is. I.1 Scope This annex specifies the contents of software products associated with maintenance in this standard.2 Software products covered This following subclauses describe the contents of the software products covered by this annex.2 Software products coveredI.J-STD-016-1998 Page 152 Annex IAnnex I Maintenance software product descriptionsMaintenance software product descriptions (normative) I. binding) part of this standard. J-STD-016-1998 Page 153 I.2. 7. Identification System overview Document overview Referenced documents Requirements 3.4 "As built" software design Compilation/build procedures Modification procedures Computer hardware resource utilization 6. Qualification provisions Software maintenance information 5. Requirements traceability Notes Annexes .3 5. Scope 1.1 3.2 5.2 3.1 1.3 Executable software Source files Packaging requirements 4.1 Contents of the Software Product Specification (SPS) SOFTWARE PRODUCT SPECIFICATION (SPS) Contents 1.2 1. A.1 Contents of the Software Product Specification (SPS)I. 5.3 2.2.1 5. 3. That approach was modeled on hardware development. summarize the history of system development. as applicable. For software. This clause therefore establishes the software itself as the criterion that is required to be matched for a body of software to be considered a valid copy of the software item. This subclause shall summarize the purpose and contents of this document and shall describe any security or privacy protection considerations associated with its use. data files. 1. the source files for the software item.J-STD-016-1998 Page 154 Software Product Specification (SPS) -.1 Executable software. This subclause shall contain a full identification of the system and the software to which this document applies. date. and maintenance. 2. and maintenance organizations. and the validity of a "manufactured" copy is determined by comparison to the software itself. the executable software for the software item. and list other relevant documents. user. This clause should be divided into the following subclauses to achieve delivery of the software and to establish the requirements that another body of software is required to meet to be considered a valid copy of the software item. This subclause shall provide. acquirer. operation.2 System overview. developer. or other software files needed to install and operate the software on its target computer(s). title(s). The updated software design has been placed in clause 5 below. including any batch files. This clause shall list the number. identification number(s). or otherwise maintain the software. Referenced documents. Requirements. not to a design description. command files. It is the software itself that establishes the product baseline. 1. this approach does not apply. This clause should be divided into the following subclauses. identify current and planned operating sites. This subclause shall provide. Software "manufacturing" consists of electronic duplication of the software itself. 3. including any batch files. and release number(s). command files. version number(s). in which the final product is a design to which hardware items are required to be manufactured. identify the project sponsor. or other files needed to regenerate the executable software for . not a description of the software's design. abbreviation(s). data files. enhance. title.(continued) 1.3 Document overview. 1. Scope. Note: In past versions of the SPS. but as information to be used to modify. This subclause shall briefly state the purpose of the system and the software to which this document applies. by reference to enclosed or otherwise provided electronic media. not recreation from design. revision.1 Identification. and source of all documents referenced in this manual. it is required to be shown to match these files exactly. It shall describe the general nature of the system and software. 3. In order for a body of software to be considered a valid copy of the software item's executable software.2 Source files. by reference to enclosed or otherwise provided electronic media. however. including. not as a requirement. clause 3 required a presentation of the software design describing the "as built" software. Clause 3 is the only portion of this specification to be placed under acquirer configuration control. 3. configurations. The method for source files might be comparable. and procedures for compiling/assembling. equipment. etc. including variations for different sites. via bit-for-bit comparison.2. to be identical to the corresponding executable file. 5.(continued) the software item.3 Modification procedures. If not. Qualification provisions. if any. This subclause shall state the requirements. For example. and software. the compilation/build process to be used to create the executable files from the source files and to prepare the executable files to be loaded into firmware or other distribution media. Interface Design Description (IDD). comments. check sum. or reference an annex or other deliverable document that contains. c. using the source files referenced in 3. Build procedures above the software item level may be presented in one SPS and referenced from the others. the method for executable files might be to establish that each executable file referenced in 3. or conventions to be used. b. any settings. options. e.1 "As built" software design. If the SDD.3 Packaging requirements. The information shall be the same as that required in a Software Design Description (SDD). and procedures for their use Databases/data files used by the software item and procedures for using and modifying them Design.2 Compilation/build procedures. the subclause numbers and page numbers need not be changed. Software maintenance information. 5. This subclause shall state the method(s) to be used to demonstrate that a given body of software is a valid copy of the software item. d. it is required to be shown to match these files exactly. 4. including version numbers. It shall specify the compiler(s)/assembler(s) to be used. versions. or DBDD is included in an annex. and other conventions to be followed Compilation/build procedures if different from those above Integration and testing procedures to be followed . This clause should be divided into the following subclauses to provide information needed to maintain the software item. 5. and code of the source code listings may be referenced and need not be repeated in this clause. This subclause shall contain. this subclause shall reference them. or reference an annex that describes. information describing the design of the "as built" software item. including version numbers. other hardware and software needed. and building the software item and the software system/subsystem containing the software item. linking. In order for a body of software to be considered a valid copy of the software item's source files.1 has an identically-named counterpart in the software in question and that each such counterpart can be shown. It shall include or reference information on the following. IDD. as applicable: a. coding. Information provided in the headers. 3. or other method. as applicable.J-STD-016-1998 Page 155 Software Product Specification (SPS) -. 5. for packaging and marking copies of the software item. This subclause shall describe procedures that are required to be followed to modify the software item. If these documents or their equivalents are to be delivered for the "as built" software item. Maintenance facilities. This subclause shall describe. and Database Design Description (DBDD). the information shall be provided in this document. (continued) 5. library software. Notes.4 Computer hardware resource utilization. Annexes may be used to provide information published separately for convenience in document maintenance (e. b.g. input/output device capacity. worst-case usage. Traceability from each software item source file to the software unit(s) that it implements. background information. Traceability from each computer hardware resource utilization measurement given in 5. glossary. this subclause may reference that source.g. e. overlays. As applicable. kilobytes per second) The level(s) at which the estimates or measures have been made (such as software unit. d. 6. in system-level resource allocations affecting the software item.) The assumptions and conditions on which the utilization data are based (for example. the traceability to software item requirements may be provided in 6.4. Included for each computer hardware resource shall be: a. assumption of certain events) Any special considerations affecting the utilization (such as use of virtual memory. (Alternatively.4 to the software item requirements it addresses.). such as in one SPS. cycles per second. or in the Software Development Plan. This subclause shall describe the "as built" software item's measured utilization of computer hardware resources (such as processor capacity. The software item requirements or system-level resource allocations being satisfied. classified data). Requirements traceability. It shall cover all computer hardware resources included in utilization requirements for the software item. Annexes shall be lettered alphabetically (A.) Traceability from each software item requirement regarding computer hardware resource utilization to the utilization measurements given in 5. charts. . memory capacity. This clause shall contain any general information that aids in understanding this specification (e. 7. rationale). etc. This clause shall include an alphabetical listing of all acronyms. software item. b. bytes of memory. If all utilization data for a given computer hardware resource is presented in a single location. and communications/network equipment capacity). A. or multiprocessors or the impacts of operating system overhead. each annex shall be referenced in the main body of the document where the data would normally have been provided.. Annexes. c. or executable program) d..c.J-STD-016-1998 Page 156 Software Product Specification (SPS) -. or other implementation overhead) The units of measure used (such as percentage of processor capacity. This clause shall provide: a. B.4. this traceability may be provided in 5. and their meanings as used in this document and a list of any terms and definitions needed to understand this document. abbreviations. Annexes may be bound as separate documents for ease in handling. auxiliary storage capacity. c. Traceability from each software unit to the source files that implement it. (Alternatively. typical usage. Identification System overview Document overview Referenced documents Version description 3. Notes Annexes . Scope 1. A.7 Inventory of materials released Inventory of software contents Changes installed Adaptation data Related documents Installation instructions Possible problems and known errors 4.5 3.3 2.2 1.1 3.4 3.2.2 3.2 Contents of the Software Version Description (SVD) SOFTWARE VERSION DESCRIPTION (SVD) Contents 1.1 1.3 3.6 3.2 Contents of the Software Version Description (SVD)I.2.J-STD-016-1998 Page 157 I. 3. acquirer. If classes or categories of changes have been used. change proposals. title. Any applicable security and privacy protection considerations shall be included. This subclause shall summarize the purpose and contents of this document and shall describe any security or privacy protection considerations associated with its use. Version description. and source of all documents referenced in this manual. This clause should be divided into the following subclauses. identify the project sponsor. version numbers.) 1. This subclause shall briefly state the purpose of the system and the software to which this document applies. source code may not be released to all recipients. Scope. It shall include applicable security and privacy protection considerations for these items. This clause should be divided into the following subclauses. as applicable. summarize the history of system development. This subclause shall identify or reference all unique-to-site data contained in the software version. . operation. dates. and maintenance organizations. the changes shall be separated into these classes or categories. if any. abbreviation(s). developer. abbreviations. safeguards for handling them. This subclause shall list by identifying numbers. all physical media (for example.2 Inventory of software contents. This subclause shall identify. revision. 3. all computer files that make up the software version being released. and list other relevant documents. the problem reports. This clause shall list the number.3 Changes installed. and instructions and restrictions regarding duplication and license provisions. This subclause shall contain a list of all changes incorporated into the software version since the previous version.(continued) 1. version number(s). and change notices associated with each change and the effects. identification number(s). 3. 2. and release numbers. disks) and associated documentation that make up the software version being released. 3. Referenced documents.1 Inventory of materials released. 3. of each change on system operation and on interfaces with other hardware and software. This subclause shall contain a full identification of the system and the software to which this document applies.4 Adaptation data. and release numbers. For software versions after the first. It shall describe the general nature of the system and software. as applicable. identify current and planned operating sites.2 System overview. including. this subclause shall describe changes made to the adaptation data. This subclause shall list by identifying numbers. abbreviations. title(s). It shall also identify the intended recipients of the SVD to the extent that this identification affects the contents of the software released (for example. and maintenance. 1. 3. dates. and release number(s). as applicable. titles. user. as applicable. such as concerns for static and magnetic fields.3 Document overview. This subclause does not apply to the initial software version. version numbers. 1. listings.J-STD-016-1998 Page 158 Software Version Description (SVD) -.1 Identification. date. tapes. titles. or otherwise handling each one. e.7 Possible problems and known errors. Annexes. 4. any steps being taken to resolve the problems or errors.5 Related documents. This clause shall include an alphabetical listing of all acronyms. or safety precautions relevant to the installation Procedures for determining whether the version has been installed properly A point of contact to be consulted if there are problems or questions with the installation 3. This clause shall contain any general information that aids in understanding this document (e. d. as applicable: a. b. version numbers. abbreviations. a user organization may need advice on avoiding errors. rationale). as applicable. Annexes shall be lettered alphabetically (A. This subclause shall provide or reference the following information. A. correcting.). . Notes. B. This subclause shall identify any possible problems or known errors with the software version at the time of release.(continued) 3. Annexes may be bound as separate documents for ease in handling.. c.. The information presented shall be appropriate to the intended recipient of the SVD (for example. each annex shall be referenced in the main body of the document where the data would normally have been provided. avoiding. etc. glossary. As applicable. and their meanings as used in this document and a list of any terms and definitions needed to understand this document. background information. Instructions for installing the software version Identification of other changes that have to be installed for this version to be used. and instructions (either directly or by reference) for recognizing. a maintenance organization on correcting them).g. classified data). abbreviations.J-STD-016-1998 Page 159 Software Version Description (SVD) -.g. including site-unique adaptation data not included in the software version Security. all documents pertinent to the software version being released but not included in the release. This subclause shall list by identifying numbers. and release numbers. charts. 3. privacy protection.6 Installation instructions. dates. titles. Annexes may be used to provide information published separately for convenience in document maintenance (e. 5. 4.3 2. 3.2.2 1. A.3 Contents of the Computer Programming Manual (CPM) COMPUTER PROGRAMMING MANUAL (CPM) Contents 1.2.J-STD-016-1998 Page 160 I.1 1.3 Contents of the Computer Programming Manual (CPM)I. Identification Computer system overview Document overview Referenced documents Programming environment Programming information Notes Annexes . Scope 1. disks. word. Highlight any special flags or instructions necessary for loading. as applicable: 1)Machine cycle time 2)Word length 3)Memory capacity and characteristics 4)Instruction set characteristics 5)Interrupt capabilities 6)Modes of operation (e. This clause shall list the number. model number. title. revision. linker. batch. non-privileged) 7)Operational registers 8)Error indicators 9)Input/output characteristics 10) Special features c.2 Computer system overview. floating-point. This clause should be divided into the following subclauses. Description of the programming features of the computer's instruction set architecture. and any other identifying information for the computer system to which this document applies.g. 1. link-editor. 1. compiler. Scope. b.g. Programming information. including. Programming environment. Identify (as applicable) by name and version number the editor. or recording the results. privileged. stack pointer.g. This subclause shall contain the manufacturer's name. 2.J-STD-016-1998 Page 161 Computer Programming Manual (CPM) -. 4. byte.. This subclause shall briefly state the purpose of the computer system to which this document applies. interactive. other peripheral equipment) necessary to perform compilations and assemblies on the computer system.(continued) 1. executing. a.. This subclause shall summarize the purpose and contents of this manual and shall describe any security or privacy protection considerations associated with its use. This clause should be divided into subclauses as appropriate to provide the following information. Description of the equipment (e. and other utilities used. program counter) . capabilities. including. and limitations. as applicable: 1)Data representation (e. a.1 Identification.3 Document overview. date. double precision) 2)Instruction formats and addressing modes 3)Special registers and words (e.g. integer. This clause should be divided into subclauses as appropriate to provide the following information. The components and configuration of the computer system Operating characteristics. and reference appropriate manuals describing their use. Referenced documents.. cross-compilers. assembler. 3. cross-assemblers.. and source of all documents referenced in this manual. 1. tapes. charts. or special programming techniques associated with the computer system (e. as applicable: 1) Initial loading and verification of computer memory 2) Serial and parallel data channels 3) Discrete input and output 4) Interface components 5) Device numbers. This clause shall include an alphabetical listing of all acronyms. jump. B. Examples that demonstrate the programming features described above. including condition codes. A. classified data). macrocode routines. as applicable: 1) Use 2) Syntax 3) Condition codes set 4) Execution time 5) Machine-code format 6) Mnemonic conventions 7) Other characteristics c. Error detection and diagnostic features associated with the computer system. Description of input and output control programming.g.g. such as instruction or data cache architecture b. Annexes may be bound as separate documents for ease in handling. including examples of the proper use of all categories of instructions on the computer system f.g. and the modes they operate in) 5) Subroutines and procedures (e. overflow and addressing exception interrupts. Annexes shall be lettered alphabetically (A... As applicable. etc. rationale).). This clause shall contain any general information that aids in understanding this document (e. and their meanings as used in this document and a list of terms and definitions needed to understand this document. background information. including. privileged instructions. Notes. non-reentrant. argument lists. parameter passing conventions) 6) Interrupt processing 7) Timers and clocks 8) Memory protection features (e..g.g.(continued) 4) Control instructions (e... glossary.. Description of each instruction. read-only memory) 9) Additional features. Additional. a concise description of the microprogram control clause) e. each annex shall be referenced in the main body of the document where the data would normally have been provided. reentrant.g. and input and output error status indicators 5. subroutine and procedure call instructions. restricted. . including. branch. operational codes.J-STD-016-1998 Page 162 Computer Programming Manual (CPM) -. Annexes. Annexes may be used to provide information published separately for convenience in document maintenance (e. abbreviations. and memory locations for peripheral equipment d. 7 Description of pre-programmed device Software to be programmed into the device Programming equipment Programming software Programming procedures Installation and repair procedures Vendor information 4. 3.x. A.4 3.2 3.4 Contents of the Firmware Support Manual (FSM)I.2.x.J-STD-016-1998 Page 163 I.2 1.x.x.1 1.1 3.3 3.x (identifier of programmed firmware device) 3. Scope 1.4 Contents of the Firmware Support Manual (FSM) FIRMWARE SUPPORT MANUAL (FSM) Contents 1.5 3.3 2. Identification System overview Document overview Referenced documents Firmware programming instructions 3. Notes Annexes .6 3.x.2.x.x. including. and list other relevant documents. title(s). user.2 System overview. 3. 8Kx8) Operating characteristics (such as access time. logic levels) Pin functional descriptions Logical interfaces (such as addressing scheme. and firmware devices to which this document applies. acquirer. This subclause shall contain a full identification of the system. This subclause shall briefly state the purpose of the system and the software to which this document applies. This clause should be divided into the following subclauses. including the following. summarize the history of system development.x (Identifier of programmed firmware device). version number(s). as applicable. This clause should be divided into the following subclauses. and source of all documents referenced in this manual. This subclause shall state the project-unique identifier of a programmed firmware device to be used in the system and should be divided into the following.x. and maintenance. This subclause shall summarize the purpose and contents of this manual and shall describe any security or privacy protection considerations associated with its use. Scope.(continued) 1. Firmware programming instructions.3 Document overview. revision. identify the project sponsor. 1.J-STD-016-1998 Page 164 Firmware Support Manual (FSM) -. developer.1 Identification. chip selection) Internal and external identification scheme used Timing diagrams Describe the operational and environmental limits to which the firmware device may be subjected and still maintain satisfactory operation . operation. Description of pre-programmed device. title. abbreviation(s). b. speed. software. type. Referenced documents. identify current and planned operating sites. and maintenance organizations. This subclause shall: Identify by manufacturer's name and model number the firmware device to be programmed Provide a complete physical description of the firmware device. and configuration (such as 64Kx1. 2. 3. and release number(s) of the system and software and manufacturer's name and model number for each firmware device. identification number(s). 1. Memory size. as applicable: 1) 2) 3) 4) 5) 6) c. This clause shall list the number. power requirements. It shall describe the general nature of the system and software.1 a. 1. 3. date. ). version/release. 3.x. Annexes may be bound as separate documents for ease in handling. This subclause shall identify by project-unique identifier(s) the software to be programmed into the firmware device. 3. together with any security and privacy protection measures to be applied. B.6 Installation and repair procedures.J-STD-016-1998 Page 165 Firmware Support Manual (FSM) -. Annexes shall be lettered alphabetically (A.4 Programming software.(continued) 3.5 Programming procedures. loading. verification. and major capabilities. Annexes may be used to provide information published separately for convenience in document maintenance (e. and marking. It shall include computer equipment.g. This subclause shall describe the software to be used for programming and reprogramming the firmware device. It shall include software to be used for device erasure. as applicable. This subclause shall also include remove-and-replace procedures. device addressing scheme and implementation. programming equipment. loading. Each item of software shall be identified by vendor's name. 3. This subclause shall describe the procedures to be used for programming and reprogramming the firmware device. As applicable.2 Software to be programmed into the device. usage. including its purpose. usage. and special equipment to be used for device erasure..7 Vendor information. replacement. and any other information that is necessary to uniquely identify that piece of equipment. A description of each piece of equipment shall be provided. 4. as applicable. This subclause shall describe the equipment to be used for programming and reprogramming the firmware device. Notes. 3. model number.x.. including its purpose. This clause shall include or reference any relevant information supplied by the vendor(s) of the firmware device.x. 3. etc. software name. verification. or programming software.g. A description of each item of software shall be provided. A. . description of the host board layout. This clause shall include an alphabetical listing of all acronyms. and marking. marked by WARNING or CAUTION. shall be included where applicable. Each piece of equipment shall be identified by manufacturer's name.x. Annexes. and their meanings as used in this document and a list of terms and definitions needed to understand this document. This clause shall contain any general information that aids in understanding this document (e.3 Programming equipment. general purpose equipment.x. verification.x. charts. and any other information necessary to uniquely identify the item of software. and marking. abbreviations. and repair procedures for the firmware device. classified data). glossary. as applicable. Safety precautions. All equipment and software necessary for each procedure shall be identified. It shall include procedures to be used for device erasure. each annex shall be referenced in the main body of the document where the data would normally have been provided. rationale). loading. and major capabilities. number. and any procedures for ensuring continuity of operations in the event of emergencies. This subclause shall contain the installation. background information. J-STD-016-1998 Page 166 Annex JAnnex J User/operator software product descriptionsUser/operator software product descriptions (normative) J. This annex is a normative (that is. It applies regardless of whether the software products are deliverable.2 Software products coveredJ.1 ScopeJ. binding) part of this standard. The products are listed in order they are referenced in this standard and include the following: a) b) c) d) Software User Manual (SUM) Software Input/Output Manual (SIOM) Software Center Operator Manual (SCOM) Computer Operation Manual (COM) .2 Software products covered This following subclauses describe the contents of the software products covered by this annex. subject to tailoring. J.1 Scope This annex specifies the contents of software products associated with user and operator manuals in this standard. Scope 1.2 Conventions 5.2.2 Access control 4.3 Document overview 2.1.1 Contents of the Software User Manual (SUM) SOFTWARE USER MANUAL (SUM) Contents 1. and emergencies 5. Processing reference guide 5.1 Software application 3.3 Software environment 3. Notes A.2.3 Installation and setup 4.3. Annexes .7 Messages 5. malfunctions.1 Contents of the Software User Manual (SUM)J.3 Stopping and suspending work 5.5 Contingencies and alternate states and modes of operation 3.3 Processing procedures 5.1.1 Identification 1.6 Recovery from errors.2 Software inventory 3. Referenced documents 3.5 Data backup 5.2 Initiating a session 4.1 First-time user of the software 4.1.4 Related processing 5.2 System overview 1.7 Assistance and problem reporting 4. Software summary 3.1 Capabilities 5.6 Security and privacy protection 3.4 Software organization and overview of operation 3.J-STD-016-1998 Page 167 J.x (Aspect of software use) 5. Access to the software 4.1 Equipment familiarization 4.8 Quick-reference guide 6. 3 Software environment. identification number(s). and benefits expected from its use shall be described. as applicable: . amount of auxiliary storage needed. as applicable. including amount of memory needed. manual operations. as applicable. 3. revision.2 System overview. It shall describe the general nature of the system and software. 1. or resources that are required to be present b. version number(s). 3. 3. Software summary. abbreviation(s). e. user. This subclause shall provide a brief description of the intended uses of the software. Computer equipment that is required to be present. acquirer. title. software. identify the project sponsor. 1. and release number(s). and source of all documents referenced in this manual. c. and maintenance. such as operating systems. This clause should be divided into the following subclauses. d. identify current and planned operating sites. utilities. shall be identification of: a. databases. 3. Included.1 Identification. The description shall include. equipment. developer. including databases and data files.3 Document overview. This subclause shall briefly state the purpose of the system and the software to which this document applies.1 Software application.4 Software organization and overview of operation. date. operating improvements. This clause shall list the number. and other resources needed for a user to install and run the software. 3. This subclause shall summarize the purpose and contents of this manual and shall describe any security or privacy protection considerations associated with its use. and list other relevant documents.(continued) 1. that are required to be installed for the software to operate. The identification shall include security and privacy protection considerations for each file and identification of the software necessary to continue or resume operation in case of an emergency. This clause should be divided into the following subclauses. or other manual operations that are required to be present Other facilities.J-STD-016-1998 Page 168 Software User Manual (SUM) -. Capabilities. data files. Scope. This subclause shall provide a brief description of the organization and operation of the software from the user's point of view. procedures. This subclause shall identify all software files. This subclause shall identify the hardware. operation. This subclause shall contain a full identification of the system and the software to which this document applies. title(s). summarize the history of system development. Referenced documents. 2.2 Software inventory. and maintenance organizations. 1. and other supporting systems Forms. and peripheral equipment such as printers and other input/output devices Communications equipment that is required to be present Other software that is required to be present. including. d.5 Contingencies and alternate states and modes of operation. organizations. marked by WARNING or CAUTION. from the user's point of view. This subclause should be divided into the following. A warning shall be included regarding making unauthorized copies of software or documents. b. d. 3. c.6 Security and privacy protection. This subclause shall explain differences in what the user will be able to do with the software at times of emergency and in various states and modes of operation. and an overview of the purpose/operation of each component Performance characteristics that can be expected by the user. shall be included where applicable. This subclause shall identify points of contact and procedures to be followed to obtain assistance and report problems encountered in using the software.J-STD-016-1998 Page 169 Software User Manual (SUM) -. accuracy. 4. rate of input accepted 2) Type. such as number of events that can be tracked 6) Error rate that can be expected 7) Reliability that can be expected c.(continued) a.7 Assistance and problem reporting. Equipment familiarization. Access to the software. how to identify an active cursor if more than one cursor can appear.1 a.1 First-time user of the software. volume. rate of output the software can produce 3) Typical response time and factors that affect it 4) Typical processing time and factors that affect it 5) Limitations.1. 4. Logical components of the software. or positions Supervisory controls that can be implemented (such as passwords) to manage the software 3. b. e. 4. volume. and how to use a cursor Keyboard layout and role of different types of keys and pointing devices Procedures for turning power off if special sequencing of operations is needed . This clause shall contain step-by-step procedures oriented to the first time/occasional user. Relationship of the functions performed by the software with interfacing systems. Safety precautions. 3. if applicable. how to position a cursor. if applicable. Enough detail shall be presented so that the user can reliably access the software before learning the details of its functional capabilities. such as: 1) Type. This subclause shall contain an overview of the security and privacy protection considerations associated with the software. This subclause shall describe the following as appropriate: Procedures for turning on power and making adjustments Dimensions and capabilities of the visual display screen Appearance of the cursor. functions. e. their assigned positions. c. by screen.3 Installation and setup. For other software. 7.1. This subclause shall present an overview of the access and security features of the software that are visible to the user. b.1. 4. transaction-by-transaction.2 Access control. This subclause shall provide step-by-step procedures for beginning work.. additional clauses 6. 5. . or other processes in order to provide an overview of the use of the software. to perform the installation. The organization of the document will depend on the characteristics of the software being documented. How and from whom to obtain a password How to add. 5. A checklist for problem determination shall be included in case difficulties are encountered.3 Stopping and suspending work.. it may be more appropriate to have clause 5 be a guide to menus. If procedures are complicated or extensive. This subclause shall describe any procedures that the user is required to perform to be identified or authorized to access or install software on the equipment.(continued) 4.g.2 Initiating a session. by function. Safety precautions.1 Capabilities. or other basis. to configure the software.. to delete or overwrite former files or data. the use of abbreviated vocabulary. . 5. Processing reference guide. delete. by menu. or the tasks they are required to perform. marked by WARNING or CAUTION. menu-by-menu. Depending on the design of the software. the use of audible alarms. one approach is to base the clauses on the organizations in which users work.J-STD-016-1998 Page 170 Software User Manual (SUM) -.3 Processing procedures. This subclause shall explain the organization of subsequent subclauses. the subclauses might be organized on a function-by-function. including any options available. Any necessary order in which procedures are required to be accomplished shall be described. or change passwords under user control Security and privacy protection considerations pertaining to the storage and marking of output reports and other media that the user will generate 4. The following items shall be included. such as the use of colors in displays. clause 6 be a guide to the command language used. menus. This clause shall provide the user with procedures for using the software. may be added in the same subclause structure as this clause and with titles meaningful to the clauses selected. This subclause shall describe any conventions used by the software. shall be included where applicable. For example. as applicable: a.2 Conventions. Detailed procedures are intended to be presented in subclauses of subclause 5. and to enter parameters for software operation.3. This subclause shall describe how the user can cease or interrupt use of the software and how to determine whether normal termination or cessation has occurred. 5. This subclause shall briefly describe the interrelationships of the transactions. their work sites. and clause 7 be a guide to functions. 4. and the use of rules for assigning names or codes. Notes. formats. outputs. but a consistent style of presentation shall be used. or refer to an annex that lists. As applicable. 5. this subclause shall provide or reference a quick-reference card or page for using the software. offline. or other process being described. 5. etc.8 Quick-reference guide. The format for presenting this information can be adapted to the particular characteristics of the software. . as applicable. 5.. Annexes shall be lettered alphabetically (A.5 Data backup.g. This subclause shall present detailed procedures for restart or recovery from errors or malfunctions occurring during processing and for ensuring continuity of operations in the event of emergencies. This subclause shall list. 5. This clause shall contain any general information that aids in understanding this document (e. background information. or other aspects of software use.g. This quick-reference guide shall summarize. diagnostic or error messages or alarms. malfunctions. 5.3. graphical icons. defects. the descriptions of menus shall be consistent. If clause 5 has been expanded into clause(s) 6. The meaning of each message and the action that should be taken after each such message shall be identified and described. . malfunctions. data entry forms.x (Aspect of software use). this clause shall be numbered as the next clause following clause n. This subclause shall describe and give options and examples. This clause shall include an alphabetical listing of all acronyms. charts. the descriptions of transactions shall be consistent among themselves. 6. Annexes may be bound as separate documents for ease in handling.3.e.7 Messages. and information messages that can occur while accomplishing any of the user's functions. glossary. i. and their meanings as used in this document and a list of terms and definitions needed to understand this document. abbreviations. classified data). A. B.6 Recovery from errors. This subclause shall describe procedures for creating and retaining backup data that can be used to replace primary copies of data in event of errors. and help facilities that can provide on-line descriptive or tutorial information. rationale). If appropriate to the software. user inputs. frequently-used function keys. diagnostic messages.4 Related processing.J-STD-016-1998 Page 171 Software User Manual (SUM) -. control sequences. all error messages. as applicable. menu.. Any user responsibilities to support this processing shall be specified.)... or accidents.(continued) 5. inputs from other software or hardware that may affect the software's interface with the user. or background processing performed by the software that is not invoked directly by the user and is not described in subclause 5. This subclause shall identify and describe any related batch. Annexes. transaction.. and emergencies. Annexes may be used to provide information published separately for convenience in document maintenance (e. each annex shall be referenced in the main body of the document where the data would normally have been provided.. commands. of menus. The title of this subclause shall identify the function. 3.2 4.3 4.3 3.2.3.2 Description of output Use of output Recovery and error correction procedures Communications diagnostics .4 4.4 4.5 4.2 4.6 Input conditions Input formats Composition rules Input vocabulary Sample input General description Output formats Sample output Output vocabulary 4.2.3 2.3. Using the software 4.2.2.4 3.3 4.1 4.2. Scope 1.1 4.2 Contents of the Software Input/Output Manual (SIOM) SOFTWARE INPUT/OUTPUT MANUAL (SIOM) Contents 1.3.1 1.1 3.3 4.5 4.1 4.2 1.7 Software application Software inventory Software environment Software organization and overview of operation Contingencies and alternate states and modes of operation Security and privacy protection Assistance and problem reporting Initiation procedures Description of input 4.2 Contents of the Software Input/Output Manual (SIOM)J.5 3.3.2.4 4.6 3.J-STD-016-1998 Page 172 J.2. Identification System overview Document overview Referenced documents Software summary 3.2 3. 2 Access procedures 6.1 Available capabilities 6.2 Query capabilities 5.5 Termination procedures 7.(continued) 5.4 Recovery and error correction procedures 6. and retrieval procedures 6.4 Control instructions 6. Query procedures 5. Annexes . Notes A. updates.J-STD-016-1998 Page 173 Software Input/Output Manual (SIOM) -.3 Display. User terminal processing procedures 6.3 Query preparation 5.1 Database/data file format 5. and maintenance organizations. developer. such as terminals. if any.(continued) 1. This subclause shall identify the software files. and other resources needed to access and use the software.3 Software environment. and list other relevant documents. operating improvements. including. This subclause shall summarize the purpose and contents of this manual and shall describe any security or privacy protection considerations associated with its use. This subclause shall briefly state the purpose of the system and the software to which this document applies. This subclause shall provide a brief description of the intended uses of the software. This clause should be divided into the following subclauses. e. It shall describe the general nature of the system and software. printers. 1.J-STD-016-1998 Page 174 Software Input/Output Manual (SIOM) -. This subclause shall identify the hardware. operation. shall be identification of: a. identify the project sponsor. Computer equipment that is required to be present. 3. abbreviation(s).2 Software inventory. Capabilities. identification number(s). b. 1. acquirer. summarize the history of system development. user. manual operations. This clause shall list the number. and source of all documents referenced in this manual. date. The identification shall include security and privacy protection considerations for each file and identification of the software necessary to continue or resume operation in case of an emergency. 2. title(s). This subclause shall be based on the assumption that the software is installed in a computer center or other centralized or networked environment and shall focus on the resources that a user is required to have to access and use the software in that environment. Referenced documents. and benefits expected from its use shall be described. Included. identify current and planned operating sites. that the user is responsible for requesting in order to access the software described in this manual. including databases and data files. such as networking software Forms. This clause should be divided into the following subclauses. equipment. This subclause shall contain a full identification of the system and the software to which this document applies.3 Document overview. 3. d.1 Software application. software. or resources that are required to be present . c. as applicable. version number(s). or other manual operations that are required to be present Other facilities. Scope. or other input/output devices Communications equipment that is required to be present Other software that is required to be present. Software summary.2 System overview. and release number(s). 3.1 Identification. title. 3. procedures. revision. 1. as applicable. and maintenance. 4. d. If the software has a query capability. Software Input/Output Manual (SIOM) -. restrictions on what data may be queried and from what location 6) Error rate that can be expected 7) Reliability that can be expected Relationships of the functions performed by the software with interfacing systems and with the organizations or stations that are sources of input or recipients of output Supervisory controls that can be implemented (such as passwords) to manage the software b. and an overview of the purpose/operation of each component Performance characteristics that can be expected by the user. This subclause should be divided into the following.J-STD-016-1998 Page 175 Software Input/Output Manual (SIOM) -. The conditions shall include the following.(continued) 4. need to update data . Logical components of the software. 4. This subclause shall describe the conditions to be observed in preparing each type or class of input to the software. e. this subclause shall reference clauses 6 through n to describe terminal processing procedures. c. This clause should be divided into the following subclauses to describe how to prepare input to. rate of input accepted 2) Type. This subclause shall identify points of contact and procedures to be followed to obtain assistance and report problems encountered in using the software.2 Description of input. 4. marked by WARNING or CAUTION. volume.1 Input conditions.7 Assistance and problem reporting. Included may be information such as sample job request forms or sample control statements. Safety precautions. Reason for input.1 Initiation procedures. volume. Database Management Systems (DBMSs). from the user's point of view. 3. this subclause shall reference clause 5 for a description of this capability. rate of output the software can produce 3) Typical response time and factors that affect it 4) Typical processing time and factors that affect it 5) Limitations.(continued) 3. Using the software. as applicable: a. and communications paths. such as: 1) Type. and interpret output from.5 Contingencies and alternate states and modes of operation. If the software can be accessed via terminal. if applicable.6 Security and privacy protection. 3. if applicable.2. shall be included where applicable. The description shall include. A warning shall be included regarding making unauthorized copies of software or documents. accuracy. the software. This subclause shall explain the differences in what the user will be able to do with the software at times of emergency and in various states and modes of operation. This subclause shall provide a brief description of the organization and operation of the software from the user's point of view. including databases and data files the user can access. This subclause shall contain an overview of the security and privacy protection considerations associated with the software. such as normal status report. as applicable: a. This subclause shall contain the procedures that are required to be followed to initiate use of the software.g.4 Software organization and overview of operation. 3. ) to denote start and end of input. Headers denoting the start of input Text or body of the input Trailers denoting the end of input Portions of the input that may be omitted Portions of the input that may be repeated . Frequency of input. Included shall be information on the following types of input. d. This subclause shall describe any rules and conventions that are required to be observed to prepare input. such as the organization or station authorized to generate the input Medium of input.2. e. such as magnetic tape Related input that is required to be entered at the same time as this input Other applicable information. d. on demand Origin of input. This subclause shall provide examples that illustrate and explain each type or class of input acceptable by the software. character combinations. such as monthly. such as spacing and use of symbols (virgule. f. such as priority. such as order and placement of items in the input Punctuation. The rules shall include the following. 4. c. f. d.3 Composition rules.. and of fields Restrictions. asterisk. such as 100 characters maximum Format conventions.J-STD-016-1998 Page 176 b. shall be explained. This subclause shall illustrate the layout formats to be used in the preparation of input to the software and shall explain the information that may be entered in the various clauses and lines of each format.2. This subclause shall explain the legal character combinations or codes that are required to be used to prepare input. c. security and privacy protection considerations 4. Input transaction length.2 Input formats.4 Input vocabulary.2. etc.5 Sample input. 4. as applicable: a. b. of data groups. as applicable: a.2. b. such as usage of identifiers to denote major data sets to the software Sequencing. e. c. such as all input items are required to be left-justified Labeling. such as rules forbidding use of particular characters or parameter sets 4. etc. e. An annex may be provided containing an ordered listing of these codes. usage of punctuation. The rules of syntax. display screen. 4. f. b. This subclause shall describe the diagnostic procedures available to the user for validating communications and for identifying and classifying problems. Meaning and use of each column.3 Sample output.6 Communications diagnostics. . Also included shall be the procedures to be followed by the user with respect to restart. on demand Any modifications or variations of the basic output that are available Media. This subclause shall describe any codes or abbreviations that appear in the output that differ from those used in the input described in subclause 4. including column headings and subsets or clauses in the output format Data that may appear in trailers Additional characteristics. as applicable: a. such as extracted from database. as applicable. 4. such as when omitted. c.3. as applicable: a. d. This subclause shall list the error codes generated by the software. such as priority. Source.1 General description. Security and privacy protection markings Data that may appear in headers Information that may appear in the body or text of the output. b. d.3. entry. b. e.4 Use of output. security and privacy protection considerations. 4.4. and continuity of operations in the event of emergencies.3. including. This subclause shall provide the following information. for each type or class of output: a. e. and describe the corrective actions to be taken by the user. c. Reasons why the output is generated Frequency of the output. This subclause shall provide illustrations of each type or class of output from the software.3.J-STD-016-1998 Page 177 Software Input/Output Manual (SIOM) -. such as the meaning of special symbols 4.2 Output formats. This subclause should be divided into the following. recovery. associated output that complements the information in this output 4. etc. give their meanings. The following aspects shall be explained. c. range of values.(continued) 4. such as monthly.4 Output vocabulary. This subclause shall explain the use of the output by the operational area or activity that receives it. calculated Characteristics.3 Description of output. such as in the computer area or remotely Any additional characteristics.5 Recovery and error correction procedures. 4.2. unit of measure 4. A description of each sample shall be provided. This subclause shall illustrate and explain the layout of each type or class of output from the software. tape Location where the output will appear. such as printout. This subclause shall provide instructions for preparing queries. Information such as the following shall be provided for each data element.2 through 6.2 Access procedures. These instructions shall include control statements that may be required by the computer system or software. or other basis. or the tasks they are required to perform.J-STD-016-1998 Page 178 Software Input/Output Manual (SIOM) -. If the procedures are complicated or extensive.5. This subclause shall present the sequence of steps and any applicable rules pertaining to accessing the software to initiate software operations. 5. User terminal processing procedures. . It should be divided into the following subclauses. abbreviations.3 Query preparation. clauses might be based on the organizations in which users work. g. Data element name Synonymous names Definition Format Range and enumeration of values Unit of measurement Data item names. Depending on the design of the software. their assigned positions. work sites.(continued) 5. For other software. This subclause shall provide a user's view of the format and content of each database and data file that can be queried. Safety precautions. marked by WARNING or CAUTION. Query procedures. e. and update of data through terminal operations. and clause 8 be a guide to functions. 5. For example. display. This subclause shall provide instructions for the sequencing of runs and other actions necessary to extract responses to query requests. b. menu-by-menu. clauses 7 through n may be added in the same subclause structure as this clause and with titles meaningful to the clauses selected. d. 6. as applicable: a. transaction-by-transaction.1 Database/data file format. 6. This clause shall be prepared for software with a query capability.4 Control instructions. This subclause shall identify and describe the preprogrammed and ad hoc query capabilities provided by the software. it may be more appropriate to have clause 6 be a guide to menus. This subclause shall describe in general terms the capabilities for retrieval. 6. c.1 Available capabilities. f. The organization of the document will depend on the characteristics of the software being documented. the subclauses might be organized on a function-by-function. Detailed procedures are intended to be presented in subclauses 6. shall be included where applicable.2 Query capabilities. clause 7 be a guide to the command language. 5. and codes 5. This clause should be divided into the following subclauses to provide the user with information on the use of terminals to accomplish processing. updates. input formats.J-STD-016-1998 Page 179 Software Input/Output Manual (SIOM) -. background information.4 Recovery and error correction procedures.g. charts. and retrieval procedures. A.. Annexes may be used to provide information published separately for convenience in document maintenance (e. glossary.5 Termination procedures. this clause shall be numbered as the next clause following clause n..(continued) 6. and sample responses.. etc. 6. and their meanings as used in this document and a list of terms and definitions needed to understand this document. classified data). Also included shall be any procedures to be followed by the user with respect to restart. This subclause shall present the sequence of steps necessary to terminate the processing. B. As applicable. abbreviations.. This clause shall contain any general information that aids in understanding this document (e.g. If clause 6 has been expanded into clause(s) 7. rationale). and retrievals that are available through the use of a terminal. Notes. Annexes may be bound as separate documents for ease in handling. 7. Annexes shall be lettered alphabetically (A. Each procedure shall include the name of the operation. This subclause should be divided into subclauses to provide the step-by-step procedures necessary to produce the displays.3 Display. Annexes. and continuity of operations in the event of emergencies. as applicable.. recovery. This subclause shall identify error messages that may be displayed and shall indicate their meanings and any corrective actions that should be taken. updates. . . each annex shall be referenced in the main body of the document where the data would normally have been provided. This clause shall include an alphabetical listing of all acronyms.). 6. 5.x.6 3.1 5.5 5.2 1. Installation and setup Description of runs 5. Identification System overview Document overview Referenced documents Software summary 3.2.x.x Run description for (run name or identifier) 5.7 Software application Software inventory Software environment Software organization and overview of operation Contingencies and alternate states and modes of operation Security and privacy protection Assistance and problem reporting 4.x. Notes Annexes .2 3.5. Scope 1.3 3.3 Contents of the Software Center Operator Manual (SCOM)J.x.3 2.1 3.5.5.2.3 5. 5.5 3.5.5 Run inventory Phasing Diagnostic procedures Error messages Description of each run 5.3 5.4 5.1 5.3 Contents of the Software Center Operator Manual (SCOM) SOFTWARE CENTER OPERATOR MANUAL (SCOM) Contents 1. 3.x.4 5.J-STD-016-1998 Page 180 J. A.4 3.x.2 5.1 1.6 Control input Run management information Input-Output files Output reports Reproduced output reports Procedures for restart/recovery and continuity of operations 6.5.5.2 5. acquirer. that are required to be installed for the software to operate. and release number(s). 3. and benefits expected from its use shall be described. and peripheral equipment such as terminals. e. 1. developer. Scope. equipment.3 Software environment. . and other input/output devices Communications equipment that is required to be present Other software that is required to be present. or updated by the software. The identification shall include security and privacy protection considerations for each file and identification of the software necessary to continue or resume operation in case of an emergency. This clause should be divided into the following subclauses. version number(s). permanent files that are referenced. printers.1 Software application. including. identification number(s). This clause should be divided into the following subclauses. including amount of memory needed.2 System overview.2 Software inventory. as applicable. procedures. or other manual operations that are required to be present Other facilities. 1. c. 3. or resources that are required to be present b. Software summary. data files. utilities. It shall describe the general nature of the system and software. date. and source of all documents referenced in this manual. Referenced documents. including databases and data files. shall be identification of: a. summarize the history of system development. d. 3. 3. This subclause shall provide a brief description of the intended uses of the software. This subclause shall contain a full identification of the system and software to which this document applies.(continued) 1. and maintenance organizations. identify current and planned operating sites. and list other relevant documents. amount of auxiliary storage needed. abbreviation(s). created. such as networking software. and maintenance. software. operation. This subclause shall identify all software files. 2.3 Document overview. identify the project sponsor. as applicable. title. This subclause shall briefly state the purpose of the system and the software to which this document applies. This subclause shall summarize the purpose and contents of this manual and shall describe any security or privacy protection considerations associated with its use.1 Identification. Computer equipment that is required to be present. Capabilities. Included. and databases/data files necessary to resume operation in the event of emergencies Forms. user.J-STD-016-1998 Page 181 Software Center Operator Manual (SCOM) -. databases. operating systems. 1. operating improvements. This clause shall list the number. This subclause shall identify the hardware. and other resources needed to install and operate the software. revision. manual operations. title(s). c. d. marked by WARNING or CAUTION.5 Contingencies and alternate states and modes of operation. library. or other special aspects of processing General description of the communications functions and processes of the software. The description shall include. shall be presented. the groups of runs that can be performed by each organizational level such as headquarters or central office processing. Installation and setup. interfaces with other systems). field office processing. e. If sets of runs are grouped by time periods or cycles. if applicable. A warning shall be included regarding making unauthorized copies of software or documents.(continued) 3. g. and to enter parameters for software operation. This subclause shall provide a brief description of the organization and operation of the software from the operator's point of view. each set of integrated operations required on a daily. If runs may be grouped logically by organizational level. basis shall be presented.7 Assistance and problem reporting. small computer and teleprocessing support. This subclause shall describe any procedures that the operator is required to perform to install the software on the equipment. etc. to configure the software.4 Software organization and overview of operation. if applicable. 3. 3. This subclause shall contain an overview of the security and privacy protection considerations associated with the software.J-STD-016-1998 Page 182 Software Center Operator Manual (SCOM) -. This subclause shall explain the differences in software operation at times of emergency and in various states and modes of operation. including. 4. b. information oriented toward specific support areas (for example. as applicable: a. from the operator's point of view. etc. as applicable. 3. This description shall use a chart. a diagram of the communications network used in the system f. waivers of operational standards. Safety precautions. showing how the different operations are interrelated. and an overview of the purpose/operation of each component Types of input/access that can be made to the software and the software's response to each type The reports and other output that are produced by the software. to delete or overwrite former files or data. Any system restrictions. . shall be included where applicable. including security and privacy protection considerations for each Typical run times and factors that affect them Organization of software operation into runs. Logical components of the software.6 Security and privacy protection.. weekly.. if applicable. This subclause shall identify points of contact and procedures to be followed to obtain assistance and report problems encountered in operating the software. An example of the minimum division for most systems would be edit.x Run description for (run name or identifier). This subclause shall provide the information needed to manage the run including. A run may be phased to permit manual or semiautomatic checking of intermediate results. 5. after another run. and range values for diagnostic software shall be explained. This subclause shall provide the setup and execution procedures for any software diagnostics. This clause should be divided into the following subclauses to provide a description of the runs to be performed. 5. This subclause shall list all error messages output by the software. marked by WARNING or CAUTION.5. shall be included where applicable. This subclause shall describe acceptable phasing of the software into a logical series of operations.5 Description of each run. 5.5.1 Control input. Included shall be procedures for validation and trouble shooting. or at a predetermined time Estimated run time Required turnaround time Messages and responses Procedures for taking check points Waivers from operational standards . and report preparation.2 Run management information. c. 5.4 Error messages. This subclause shall provide a listing of the run stream of job control statements needed to initiate the run. codes. such as on request.2 Phasing.(continued) 5. b.x. 5. This subclause shall provide a list of the runs to be performed.1 Run inventory. to provide the user with intermediate results for other purposes.x.5. Peripheral and resource requirements Security and privacy protection considerations Method of initiation. file update.J-STD-016-1998 Page 183 Software Center Operator Manual (SCOM) -. 5. This subclause shall identify a run and should be divided into the following to describe the run. identifying the software and the jobs that make up each run. This subclause should be divided into the following. 5. Description of runs. 5. d. All parameters (both input and output). g. along with the meaning and corresponding correction procedure for each message. Safety precautions. e. h.3 Diagnostic procedures. as applicable: a. or to permit a logical break if higher priority jobs are submitted. f. It shall include a brief summary of the purpose of each run and shall relate the list to the run descriptions included in the remainder of this clause. 5. reproduction technique. Annexes shall be lettered alphabetically (A..g.x.4 Output reports. report control symbol. This subclause shall provide procedures to be followed by operator personnel concerning restart/recovery in the event of a system failure and for continuity of operations in the event of emergencies. and disposition.(continued) 5. each annex shall be referenced in the main body of the document where the data would normally have been provided. rationale).x. retention schedule. number of copies. and distribution of copies. glossary.x. security and privacy protection. Included for each shall be information such as name. binding method. Included for each report shall be information such as report identification. Notes. security and privacy protection. etc. This clause shall contain any general information that aids in understanding this document (e. title. This subclause shall provide information about the reports that are produced during the run.5. volume of report.). number of copies.5. This subclause shall provide information about the files and databases that serve as input to or that are created or updated by the run. Annexes may be bound as separate documents for ease in handling. This clause shall include an alphabetical listing of all acronyms. background information.x. B.g. Annexes. . 5.5 Reproduced output reports.g. 5. A. 6. charts. and distribution of copies. classified data). and their meanings as used in this document and a list of terms and definitions needed to understand this document. product control number.3 Input-output files.. Annexes may be used to provide information published separately for convenience in document maintenance (e. As applicable. Included for each report shall be the following information. as applicable: report identifier. abbreviations. recording medium. security and privacy protection. media (e..J-STD-016-1998 Page 184 Software Center Operator Manual (SCOM) -. magnetic tape). hard copy. paper size.6 Procedures for restart/recovery and continuity of operations. This subclause shall provide information about computergenerated reports that are subsequently reproduced by other means.5.5. 2 3.4 Contents of the Computer Operation Manual (COM)J.4 Input and output procedures Monitoring procedures Off-line procedures Other procedures 3. Identification Computer system overview Document overview Referenced documents Computer system operation 3.1. 3.3 Diagnostic features summary Diagnostic procedures Diagnostic tools 5. Notes Annexes .1 1.3 3.3 3.4 Contents of the Computer Operation Manual (COM) COMPUTER OPERATION MANUAL (COM) Contents 1.1.1 3.3 4.1 4.2.2.2 1.2.1 3. Problem-handling procedures Diagnostic features 4. Scope 1. A.2.2.2 Power on and off Initiation Shutdown Operating procedures 3.2 3.2 4.3 2.1.2.J-STD-016-1998 Page 185 J.1 Computer system preparation and shutdown 3. 3. Safety precautions. It shall describe available indicators. 3. This clause shall list the number. and any other identifying information for the computer system to which this COM applies. as applicable. tape) relevant to the computer system. This subclause shall summarize the purpose and contents of this manual and shall describe any security or privacy protection considerations associated with its use.(continued) 1. and commands typically used during computer system initiation. 1.1. This subclause should be divided into the following.2 Operating procedures. Referenced documents. revision. equipment setup.2 Initiation. marked by WARNING or CAUTION. and list procedures for interactive messages and replies (e. terminals to use. This subclause shall contain the procedures necessary to terminate computer system operation.2 Computer system overview. This subclause shall describe the input and output media (e. and source of all documents referenced in this manual. instructions for each mode shall be provided. keys). This subclause shall contain the procedures necessary to power-on and power-off the computer system.1. This subclause shall contain the manufacturer's name. If more than one mode of operation is available. This subclause shall briefly state the purpose of the computer system to which this COM applies. 1. 3.2.J-STD-016-1998 Page 186 Computer Operation Manual (COM) -.g. bootstrapping. and routine and special monitoring procedures to be followed. Scope. 3.1. 2.2. briefly describe the operating system control language.1 Computer system preparation and shutdown. . 3.3 Document overview. 1. 3. 3. passwords. title. Computer system operation. This subclause shall contain the procedures necessary to initiate operation of the computer system. state the procedures to read and write on these media. interpretation of those indicators. including. shall be included where applicable. model number.1 Input and output procedures.2 Monitoring procedures. date. This clause should be divided into the following subclauses.1 Identification.1 Power on and off.g. This clause should be divided into the following subclauses.. magnetic disk. pre-operation. This subclause shall contain the procedures to be followed for monitoring the computer system in operation. This subclause should be divided into the following. 3.3 Shutdown. 1 Diagnostic features summary. as applicable. This subclause shall identify each tool by name and number and shall describe the tool and its application.3 Diagnostic tools.4 Other procedures. It shall state the error messages or other indications accompanying those problems and shall describe the automatic and manual procedures to be followed for each occurrence. glossary. computer system alarms.2 Diagnostic procedures. or other measures to ensure continuity of operations in the event of emergencies).(continued) 3. Diagnostic features.. and their meanings as used in this document and a list of terms and definitions needed to understand this document. background information.3 Off-line procedures. Identification of hardware. classified data). abbreviations. This subclause should be divided as needed to describe the diagnostic tools available for the computer system. 5. These tools may be hardware. This subclause shall contain any additional procedures to be followed by the operator (e. A. rationale). c. or firmware necessary for executing each procedure Step-by-step instructions for executing each procedure Diagnostic messages and the corresponding required action 4. or firmware. This subclause shall describe the purpose of each diagnostic feature. Notes. switch over to a redundant computer system. software.2.3 Problem-handling procedures. steps to be taken to restart computer system operation after an abort or interruption of operation. This subclause shall identify problems that may occur in any step of operation described in the preceding subclauses in clause 3. etc. b. and procedures for recording information concerning a malfunction. This clause shall contain any general information that aids in understanding this document (e.g. This subclause shall summarize the diagnostic features of the computer system.g. each annex shall be referenced in the main body of the document where the data would normally have been provided. This subclause shall contain the procedures necessary to operate all relevant off-line equipment of the computer system. conditions requiring computer system shutdown. .). Annexes. including. including error message syntax and hierarchy for fault isolation. 4. 4.2. evaluation techniques. B. including: a. This subclause should be divided as needed to describe the diagnostic procedures to be followed for the computer system. This clause should be divided into the following subclauses to describe diagnostics that may be performed to identify and troubleshoot malfunctions in the computer system. computer system security or privacy protection considerations.J-STD-016-1998 Page 187 Computer Operation Manual (COM) -. 3. charts. Annexes may be bound as separate documents for ease in handling. procedures for on-line intervention or abort. Annexes shall be lettered alphabetically (A.g.. software. 3.. This clause shall include an alphabetical listing of all acronyms. 4. Annexes may be used to provide information published separately for convenience in document maintenance (e. As applicable. 2) whether electronic deliverables are required to be compatible with a specified standard. When other forms of presenting information are allowed and where the intent is that a traditional document need not be produced.3.2 Software products covered Figure 10 identifies the software products covered by this standard and provides guidance on the use of each product. In all cases. such as information in CASE tools or "in contractor format".3 Format and structure for all software products The following guidelines apply to all of the software products in annexes E through J. provided to aid in using this standard. K. . It is informative only.2 Software products coveredK.3. K.J-STD-016-1998 Page 188 Annex KAnnex K Software product description format and structureSoftware product description format and structure (informative) K.3.1 StructureK. as described in annex H.3.3 Format and structure for all software productsK. The format for delivery of software products is project dependent. When two or more software products are to be combined into a single deliverable. as applicable to the project.1 Structure Annexes E through J describe software products in terms of clauses and subclauses for use in developing traditional documents.2 FormatK. the acquirer should decide which one document should be the "parent" and which should be an annex(es) allowing the annexed document(s) to be attached without renumbering paragraphs or pages.1 Scope This annex provides guidance on the format and structure of deliverable software products. Examples of format choices are: 1) whether the information is to be delivered on paper or electronic media.2 Format The term "document" is to be interpreted to mean a collection of information regardless of the medium in which it is stored. or other maintenance software. word processor. the content requirements do apply. this structure does not apply. and 3) whether the information may reside in a CASE or other automated tool rather than in the form of a traditional document.1 ScopeK. K. Content requirements for software products associated with this standard are found in annexes E through J. K. or other system components. or other computers for which commercial or other programming manuals are not readily available. Describes the interface characteristics of one or more systems. and Database Design Description (DBDD). special-purpose computers. manual operations. Programmable ROMs (PROMs). Provides the acquirer visibility into the design and provides information needed for software maintenance. special-purpose computers.2. a collection of related data stored in one or more computerized files in a manner that can be accessed by users or computer programs via a database management system (DBMS). Specifies the requirements imposed on one or more systems. software.Software Product Computer Operation Manual (COM) Computer Programming Manual (CPM) Database Design Description (DBDD) Annex J. and user organizations on the operational concept of a proposed system. subsystems. and procedures needed to erase firmware devices. Can be used to supplement the System/Subsystem Design Description (SSDD). Used to obtain consensus among the acquirer. serves to communicate and control interface design decisions. and mark the loaded firmware devices. Erasable PROMs (EPROMs). manual operations. Intended for newly developed computers. Focuses on the computer itself. an OCD may focus on communicating the user's needs to the developer or the developer's ideas to the user and other interested parties. I.2. With its companion Interface Requirements Specification (IRS). Describes a proposed system in terms of the user needs it will fulfill. Software Design Description (SDD).3 JSTD0161995 Page 189 G. Provides information needed by a programmer to understand how to program a given computer. and the ways it will be used. verify the load process.2. Depending on its use. Describes the firmware devices and the equipment. and other firmware devices. Describes the design of a database. Intended for newly developed computers. load software into the firmware devices.3 Operational Concept Description (OCD) F. Applies to read only memories (ROMs). Focuses on the computer itself. subsystems. hardware items.2.4 Interface Design Description (IDD) G. software items. Can cover any number of interfaces. or other system components to achieve one or more interfaces among these entities. or other computers for which commercial or other operation manuals are not readily available. not on particular software that will run on the computer. maintenance. Can also describe the software units used to access or manipulate the data. software items. its relationship to existing systems or procedures.2 Interface Requirements Specification (IRS) F. Provides the information needed to program and reprogram the firmware devices of a system. not on particular software that will run on the computer.4 Overview Provides information needed to operate a given computer and its peripheral equipment.1 Figure 10--Overview of software products .2. Can be used to supplement the System/Subsystem Specification (SSS) and Software Requirements Specification (SRS) as the basis for design and qualification testing of systems and software items. developer.3 Firmware Support Manual (FSM) I. hardware items.2. May describe any number of interfaces. Used as the basis for implementing the database and related software units. that is.2. Can be used to order the executable software and/or source files for a software item and is the primary software maintenance document for the software item. and all other activities resulting in software products.3 Overview Provides personnel in a computer center or other centralized or networked software installation information on how to install and operate a software system.2.2. user training. A plan for installing software at user sites.2. Covers new development. Often used with the Software Center Operator Manual (SCOM). and resources. Describes a developer's plans for conducting a software development effort. This pair of manuals is an alternative to the Software User Manual (SUM). maintenance. is used as the basis for implementing the software. The SDD may be supplemented by Interface Design Descriptions (IDDs) and Database Design Descriptions (DBDDs). and conversion from existing systems. Examples include plans for software configuration management and software quality assurance. Often used with the Software Input/Output Manual (SIOM). Provides the acquirer insight into. Provides the acquirer visibility into the design and provides information needed for software maintenance. for a software item.1 Software Requirements Specification (SRS) F. and project schedules. This pair of manuals is an alternative to the Software User Manual (SUM). Prepared when the developer will be involved in the installation of software at user sites and when the installation process will be sufficiently complex to require a documented plan. and a tool for monitoring. and the detailed design needed to implement the software.2. For software embedded in a hardware-software system. possibly supplemented by IRSs.2. with users accessing the system via terminals or personal computers or submitting and receiving input and output in batch mode. including preparations. Portions of the plan may be bound separately if this approach enhances their usability. Tells a user how to access. Describes the design of a software item.Software Product Software Center Operator Manual (SCOM) Annex J. with users accessing the system via terminals or personal computers or submitting and receiving input and output in batch or interactive mode. reengineering. J-ST JSTDD-01 0166-19 1995 95 Page Page 190 Software Design Description (SDD) G. the processes to be followed for software development. Describes the software item-wide design decisions. and interpret output from. the software item architectural design. an installation plan for the hardware-software system may make a separate SIP unnecessary. build. With its associated IDDs and DBDDs.2 Software Installation Plan (SIP) E.1 Overview Describes the system.4 Figure 10--Overview of software products -. May be . a batch or interactive software system that is run by personnel in a computer center or other centralized or networked software installation.2. and modification procedures.(continued) Software Product System/Subsystem Design Annex G. modification. Developed for software systems that will be installed in a computer center or other centralized or networked software installation. Developed for software systems that will be installed in a computer center or other centralized or networked software installation. is used as the basis for design and qualification testing of a software item. the approach to be followed for each activity. Specifies the requirements for a software item and the methods to be used to ensure that each requirement has been met.or subsystem-wide design and the architectural design of a system or subsystem.2.4 Software Development Plan (SDP) E. The SRS.1 Software Input/Output Manual (SIOM) J. and software maintenance information. Requirements pertaining to the software item's external interfaces may be presented in the SRS or in one or more Interface Requirements Specifications (IRSs) referenced from the SRS. submit input to.2. reuse.3 Software Product Specification (SPS) I. including "as built" design information and compilation. organization. Contains or references the executable software. the methods to be used. source files. or to one of multiple forms of the software released at approximately the same time (for example. or a software system or subsystem. The term "version" may be applied to the initial release of the software. Requirements pertaining to the system or subsystem external interfaces may be presented in the SSS or in one or more Interface Requirements Specifications (IRSs) referenced from the SSS. identifies the tests to be performed. and other resources needed for life cycle support of deliverable software and describes the developer's plans for transitioning deliverable items to the maintenance organization. An alternative to the Software Center Operator Manual (SCOM) and Software Input/Output Manual (SIOM).2 Figure 10--Overview of software products -. Provides a record of the qualification testing performed on a software item. and control software versions. Identifies the hardware. System/Subsystem Specification (SSS) F. to a subsequent release of that software. Describes the software test environment to be used for the testing. a group of related software items. There is usually a single STP for a project. May also cover a particular aspect of software operation. test cases.1 E. software system qualification testing.2.2. If the software is embedded in a hardware-software system. Describes plans for qualification testing of software items and software systems.2 E.2 Software Test Report (STR) Software Transition Plan (STrP) Software User Manual (SUM) H.2. May be prepared as a System Design Description or Subsystem Design Description (each using the acronym SSDD). user manuals or operating procedures for that system may make separate SUMs unnecessary.1 Software Version Description (SVD) I.4 J. Enables the acquirer to assess the testing and its results.Software Product Description (SSDD) Annex Overview supplemented by Interface Design Descriptions (IDDs) and Database Design Descriptions (DBDDs). May be prepared as a System Specification or Subsystem Specification (each using the acronym SSS). Developed if the software support strategy calls for transition of responsibility from the developer to a separate maintenance organization.2 Specifies the requirements for a system or subsystem and the methods to be used to ensure that each requirement has been met. Identifies and describes a software version consisting of one or more software items. Enables the acquirer to assess the adequacy of the qualification testing to be performed. a software system or subsystem. With its associated IDDs and DBDDs. The SSS. track. possibly supplemented by IRSs. is used as the basis for design and qualification testing of a system or subsystem. if applicable. JSTD0161995 Page 191 Software Test Description (STD) Software Test Plan (STP) H. Developed for software that is run by the user and has a user interface requiring on-line user input or interpretation of displayed output. to different sites).2. Enables the acquirer to assess the adequacy of planning for software item and. and provides schedules for test activities.2. such as instructions for a particular position or task. or other software-related item.(continued) .2. Used to release.2. is used as the basis for further system development. software. Describes the test preparations. Tells a hands-on software user how to install and use a software item. and test procedures to be used to perform qualification testing of a software item or a software system or subsystem. or instructions for accessing. and date. as applicable.3. If the software product is in an alternative form. K. and page number of each titled subclause. and any other identifier for the system.4 Table of contents and index If a software product is in the form of a traditional document. such as a database.6 Response to tailoring instructions If a software product is in the form of a traditional document and a subclause has been tailored out of the corresponding software product description in an annex. or item to which the document applies. and. figure. followed by "This subclause has been tailored out. this information is to be included on external and internal labels or by equivalent identification methods.9 Substitution of existing documents Commercial or other existing documents may be substituted for all or part of a software product if they contain the required data. document title. table.3. matrices. K. and other presentation styles are acceptable substitutes for text when required information can be made more readable using these styles.3. such as a database. If the software product is in an alternative form. or instructions for accessing. or other entities are to be assigned names or numbers in such a way that desired data can be indexed and accessed. screens. K. such as a database. for manuals. security markings or other restrictions on the handling of the document. there is to be an internal or external table of contents containing pointers to." If the software product is in an alternative form. the resulting document is to contain the corresponding subclause number and title.3.3. figure.3 Title page or identifierK. name and address of the preparing organization. abbreviation. K. tables. K.3.9 Substitution of existing documentsK. information corresponding to each subclause. including version. If the software product is in an alternative form. and annex.8 Alternative presentation styles Diagrams. version/revision indicator. table. this representation need occur only in the table of contents or equivalent.3. organization for which the document has been prepared.3.8 Alternative presentation stylesK.7 Multiple clauses and their subordinates Any clause or subclause may be written as multiple clauses or subclauses to enhance readability. K. subsystem. contract number. and annex.4 Table of contents and indexK. as applicable: document number. then files.3. volume.3.3. date. the software product's identification number in the contract. name.5 Page numbering/labeling If a software product is in the form of a traditional document.6 Response to tailoring instructionsK. and distribution restrictions.3. . such as a database.3.J-STD-016-1998 Page 192 K. each page is to contain a unique page number and display the document number. information relevant to key terms or concepts. it is to include a title page containing. it is to contain a table of contents providing the number. title.7 Multiple clauses and their subordinatesK.5 Page numbering/labelingK.3. volume number. an external or internal index containing pointers to. Manuals are to also contain an index providing an alphabetic listing of key terms and concepts covered and the pages or subclauses in which they are covered.3 Title page or identifier If a software product is in the form of a traditional document. the developer may satisfy that subclause (or a portion thereof) with "Not applicable.3.10 Standard data descriptionsK.3.3. reference to an entry in that dictionary is preferred over including the description itself." If there is a possibility of disagreement with the acquirer regarding which content requirements are applicable." If the contents of a given subclause do not apply to a particular project. it is advised that the developer use the Software Development Plan and joint technical and management reviews as avenues to propose and reach agreement on the applicability of required content.11 Applicability of required contentsK.J-STD-016-1998 Page 193 K.11 Applicability of required contents All content requirements in annexes E through J are "as applicable.3. K.10 Standard data descriptions If a data description required by this annex has been published in a standard data element dictionary specified in the contract. . 3 Criteria definitions The following subclauses provide definitions for the criteria in figure 11 that may not be selfexplanatory.3.1.2. if applicable (see L.2 (STP) (see L. L.1-L. .3.11).10). h) covers all requirements for the items under test (see L. The software products are expressed in lower case letters to emphasize that they are generic products. they may be treated as subordinate clauses of this subclause (referring to the first criterion.3. This annex is normative (that is. Evaluations of system-level products are to be interpreted as participation in these evaluations.3. applied to user/operator/programmer instructions and to the "as built" design and version descriptions. g) covers all software-related qualification activities in the SOW (see L. not necessarily in the form of hard-copy documents. The criteria are listed in alphabetical order.8). as L. For example.4). the requirement is to perform the evaluations using these criteria and to identify possible problems for discussion and resolution.3.7).1 Accurately describes (an item)L. subject to the following conditions: 1) these requirements may be tailored.3).3. the criteria to be used for evaluation of a software test plan (item 2) are as follows: a) contains all applicable information in E. d) understandable (see L.3. For convenience.1 Scope This annex identifies the software products that are to undergo software product evaluations.5). Each software product and criterion is labelled for purposes of identification and tailoring. there is no requirement to prove that the criteria have been met.3. b) meets SOW. e) internally consistent (see L. for example.3.1 Accurately describes (an item) This criterion. and j) presents a sound approach to the testing (see L. By substituting the appropriate evaluation criteria for the verb phrases in figure 11 a full set of evaluation criteria may be determined. c) meets delivery requirements. and contains a default set of definitions for the evaluation criteria.3 Criteria definitionsL.2.9). Because of this. i) consistent with other project plans (see L. NOTE--The evaluation criteria for each software product has been presented in tabular form in figure 11 using the applicable criteria definitions in L.a). f) follows Software Development Plan (see L.5). identifies the criteria to be used for each evaluation.2 Required evaluations Figure 11 identifies the software products that are to undergo software product evaluations and states the criteria to be applied to each one.1 ScopeL.14). if applicable (see L. and 3) if the development of a given software product has been tailored out of the standard. the requirement to evaluate that product does not apply. L.3. Some of the criteria are subjective.3. 2) the developer may use alternate criteria or definitions if approved by the acquirer. L. matching as closely as possible the wording used in figure 11.3.14. Note that the lower case letters in the figure are for criterion identification and tailoring purposes only.3.3.2 Required evaluationsL. means that the instructions or descriptions are correct depictions of the software or other item described. binding).J-STD-016-1998 Page 194 Annex L Software product evaluationsSoftware product evaluations (normative) L. g. d.2. f. IDD) b. i. Follows SW dev plan f. b. e. g. h. c.1.2. Intern. f. e. h. c.2 (STP) Meets SOW. 6.3.3 (SSS. IRS) G.2 (SSDD. G.Evaluation Criteria Software Product 1. b.3) Contains all applic. if applic.1. i. DBDD) G. b. g. F. (Updates) f.3 (SSDD. h. G. 7. Covers the system requirements Consistent with the system-wide design decisions Feasible Figure 11--Software products and associated evaluation criteria .2. i. c.2. E. b. b. f. 8.2.2.2.5) Operational concept (5.2. d. Software transition plan a. f. a.4) a. 4. System-wide design decisions (5. i.3) a. d. 3. g. h. c. h. i.1.1 (OCD) F. Software development plan (5. Understandable d.2. d. g.2. e. System architectural design (5.4 (STrP) F. e. i. g. (5. d.2.3. g. if applic.2. b. c. f.2.1) a.1) Software test plan (5.1 (SDP) E. g.2) a. IDD. G. d. e. Software installation plan (5.4. j.1. 5. f.3 (SIP) E.2) System requirements (5. c.1.2. e. h. 5. consistent e. Additional Criteria Covers all activities/deliverables required by the contract Consistent with other project plans Presents a sound approach to the development Covers all software-related qualification activities in the SOW Covers all requirements for the items under test Consistent with other project plans Presents a sound approach to the testing Covers all user site installation activities in the SOW Consistent with other project plans Presents a sound approach to the installation Covers all transition-related activities in the SOW Consistent with other project plans Presents a sound approach to the transition Feasible Covers the operational concept Feasible Testable Consistent with system requirements Feasible JSTD0161995 Page 195 2.1.1. c. b. E. info in: a. h.2. c. a. Meets deliv reqts. e.4. d. Covers the software item detailed design g.7. Consistent with software item-wide design decisions a. g. d.2. e. e.2 (STR) b. Feasible i. Shows evidence that the software item meets its requirements Figure 11--Software products and associated evaluation criteria -.2. Implemented software (5.9. b.3) a. d.2. d.1 (STD) Meets SOW.6. Additional Criteria g. e. b.2. c. Follows SW dev plan f. f.6. g. g. c. c.Evaluation Criteria Software Product 9. IRS) G. c. consistent e. Testable g. Software item requirements (5.2. d. Software item qualification test descriptions (5. b. Covers all planned software item qualification test cases h. Software item architectural design (5. e. Feasible J-ST D-01 6-19 95 Page 196 10. if applic.1) 14.2) 12. c. Covers software item requirements h. IDD. 13. f.2. e. e. f. Consistent with software item-wide design decisions i. b. Covers software item requirements allocated to each unit h. d. qualification test results (5. DBDD) G.1) a.2.2. G.2. Intern.4. H. IDD) G.6. d. f. c. G. DBDD) N/A a.2. if applic. b.2 (SDD. G.2.(continued) .4.3) b. F. c.3 (SRS. Software item-wide design decisions (5. Software item a. G. Meets deliv reqts. Feasible g. info in: a. F. G.5) Contains all applic.4.7) H. Covers all software item requirements 15. f.2.9.2.3 (SDD.2. 11. Covers system requirements allocated to the software item h. f.3 (SDD. Software item detailed design (5. Consistent with software item requirements h.4. Understandable d. IDD. if in: applic. Executable software (5.2.1) Contains Meets all applic. a. Understandable d. e. e. 5. f.13. f. c. I.2 (SIOM) J.1 (STD) H.1 (SUM) J.11. Covers all system requirements JSTD0161995 Page 197 a. f.2) 22. c.13. d.2.(continued) . if applic. a.2.12. f. info SOW. b. Accurately describes software input/output to the intended audience of this manual g. j. e. h. b.12. a.2. d.2. c.3. e.3. Intern. c. f.2 (SVD) J. 19.2. System qualification test descriptions (5. d. Covers all planned system qualification test cases h. Additional Criteria g. unit. Software center operator manuals (5. Computer operation manuals (5.3) 20. Software user manuals (5. c. d. Accurately describes software installation and use to the intended audience of this manual g. c. e.11. d. Accurately identifies the version of each software component (file.2) a. etc.2 (STR) N/A b.3 (SCOM) J. Follows SW dev plan f.12. c.4) 24.1) 21.2. j. e.2. b. f. b. H.Evaluation Criteria Software Product 16.1. e. Source files (5. Meets deliv reqts.12. d.) delivered h. Accurately describes the operational characteristics of the computer g. Software input/ output manuals (5.3) 23. b. a. g.3.3. c. i. 5. e.12. a. Software version descriptions (5. Accurately describes software installation and operation to the intended audience of this manual g. b.7) 18.13. Figure 11--Software products and associated evaluation criteria -. System qualification test results (5. consistent e. d.1 (SPS) b. Shows evidence the system meets its requirements g.12.4 (COM) I. Meets delivery requirements All required software is present Version exactly matches version that passed testing Deliverable media accurately labelled a. f.2. h. f. Meets delivery requirements All software necessary for execution is present Version exactly matches version that passed testing Deliverable media accurately labelled b. c. d. g. software item.3) 17. i. Accurately identifies the changes incorporated g. c. l. f. g.13. f. f.2) 29. i.4 (FSM) N/A b. c.4. g. b.Evaluation Criteria Software Product 25.1. 5. g. h. I. "As built" system design (5. b.6.3.10.(continued) . j.8.9. Accurately describes the programming features of the computer Accurately describes firmware programming features b. Follows SW dev plan f. d. G.1.1 (SPS) Meets SOW. manuals (5. d. b.2. Computer programming a. 5. a. k.11.4) Contains all applic. e.13. 5.3 (CPM) I. e. d. j. 5.13.5) 27. 5.2. 5. Firmware support manuals (5.10.7.2. "As built" software item design and related information (5. consistent e. f.13.2. k.6. N/A d. Understandable d. Sampling of software development files (5.2. c. info in: a. Additional Criteria Accurately describes the "as built" design of the software item Accurately describes compilation/build procedures Accurately describes modification procedures Source files cover all units in the software item design Measured resource utilization meets software item requirements Accurately describes the "as built" system design J-ST D-01 6-19 95 Page 198 26.7. e.1) 28.1 (SSDD) I. if applic. i. Intern.4. e. h. g. 5. Meets deliv reqts.8. Contents are current with the ongoing effort Adequate unit test cases/procedures/data/results Adequate unit integration test cases/procedures/ data/results Adequate software item qualification dry run results Adequate software/hardware item integration test cases/ procedures/data/results Adequate system qualification dry run results Figure 11--Software products and associated evaluation criteria -. c.4) a. g. if applic.4. design. For the Software Development Plan itself. or abbreviation means the same thing in all of the software products.6 Feasible This criterion means that. procedures.3. Allowances are to be made for the applicability of each topic in the annex.5 Covers (a given set of items) A software product "covers" a given set of items if every item in the set has been dealt with in the software product.3.J-STD-016-1998 Page 199 L. data. Examples include following design and coding standards described in the plan.3. possibly after revision and retesting.3 Consistent with indicated product(s)L.4 Contains all applicable information in (a specified annex)L. "Covers" corresponds to the downward traceability (for example. results Test cases are adequate if they cover all applicable requirements or design decisions and specify the input to be used. (2) a given term.3. L.3.4 Contains all applicable information in (a specified annex) This criterion uses annexes E through J to specify the required content of software products. a test plan covers a set of requirements if every requirement is the subject of one or more tests. set of requirements.7 Follows Software Development PlanL. L. etc. violates no known principles or lessons learned that would render it impossible to carry out.2 Adequate test cases. based on the knowledge and experience of the evaluator.3. L.2 Adequate test cases. Test data are adequate if they enable the execution of the planned test cases and test procedures. resultsL. data.6 FeasibleL. Test or dry run results are adequate if they describe the results of all test cases and show that all criteria have been met.3.3. a design covers a set of requirements if every requirement has been dealt with in the design. regardless of whether a deliverable document has been ordered. and (3) a given item or concept is referred to by the same name or description in all of the software products. and the criteria to be used for evaluating those results. acronym. .3. this criterion applies to updates to the initial plan. For example. design. and test planning/descriptions in annexes E through J. the expected results. test. L. from requirements to design) in the requirements.5 Covers (a given set of items)L. Test procedures are adequate if they specify the steps to be followed in carrying out each test case. a plan covers the SOW if every provision in the SOW is dealt with in the plan. procedures.3. The formatting specified in the annex (required subclause structure and numbering) are not relevant to this evaluation.3 Consistent with indicated product(s) This criterion means that: (1) no statement or representation in one software product contradicts a statement or representation in the other software products.7 Follows Software Development Plan This criterion means that the software product shows evidence of having been developed in accordance with the approach described in the Software Development Plan.3. L.3. a given concept. 11 Presents a sound approach This criterion means that.3. if applicable This criterion applies if the software product being evaluated is deliverable and has been formatted for delivery at the time of evaluation. markings.3.3. if applicableL. L. if applicable This criterion means that the software product fulfills any Statement of Work provisions regarding it.8 Internally consistent This criterion means that: (1) no two statements or representations in a software product contradict one another.3.J-STD-016-1998 Page 200 L. or abbreviation means the same thing throughout the software product.10 Meets SOW.3.9 Meets delivery requirements.3.3. (2) a given term.8 Internally consistentL. if applicableL.12 Shows evidence that (an item under test) meets its requirements This criterion means that recorded test results show that the item under test either passed all tests the first time or was revised and retested until the tests were passed.14 Understandable This criterion means "understandable by the intended audience.3.3. a given plan represents a reasonable way to carry out the required activities. and (3) a given item or concept is referred to by the same name or description throughout the software product. For example.3.3. L. software products intended for programmer-to-programmer communication need not be understandable by nonprogrammers.3. based on the knowledge and experience of the evaluator.9 Meets delivery requirements.11 Presents a sound approachL. L. . L. rather than on content.12 Shows evidence that (an item under test) meets its requirementsL. acronym. L. the Statement of Work may place constraints on the operational concept or the design.13 TestableL.3.14 UnderstandableL.13 Testable A requirement or set of requirements is considered to be testable if an objective and feasible test can be designed to determine whether each requirement has been met. and other provisions specified in the contract. A product that correctly identifies its audience (based on information in figure 10 in annex K) and is considered understandable to that audience meets this criterion. L.3." For example. It focuses on the format. covered by other criteria.10 Meets SOW. M.3 Classification by priority The developer shall assign each problem in software products or activities to one of the priorities in figure 13. b) Assign each problem in activities to one or more of the activities in figure 1 (shown at the start of clause 5). .3 Classification by priorityM.2 Classification by category The developer shall: a) Assign each problem in software products to one or more of the categories in figure 12. This annex is normative (that is.2 Classification by categoryM.J-STD-016-1998 Page 201 Annex MAnnex M Category and priority classifications for problem reportingCategory and priority classifications for problem reporting (normative) M. binding). and 2) the developer may use alternate category and priority schemes if approved by the acquirer. M. subject to the following conditions: 1) these requirements may be tailored.1 Scope This annex contains requirements for a category and priority classification scheme to be applied to each problem submitted to the corrective action system.1 ScopeM. test descriptions. operator. or other requirement designated "critical" a) Adversely affect the accomplishment of an essential capability and no work-around solution is known b) Adversely affect technical. security. Manuals i. Concept c. or maintenance manuals Other software products Figure 12--Categories to be used for classifying problems in software products Priority 1 2 Applies if a problem could: a) Prevent the accomplishment of an essential capability b) Jeopardize safety. Test information h. and no work-around solution is known a) Adversely affect the accomplishment of an essential capability but a work-around solution is known b) Adversely affect technical. Code f. Database/data file g. or test reports The user. but does not prevent the accomplishment of those responsibilities Any other effect 3 4 5 Figure 13--Priorities to be used for classifying problems . or schedule risks to the project or to life cycle support of the system. cost. Other Applies to problems in: One of the plans developed for the project The operational concept The system or software requirements The design of the system or software The software code A database or data file Test plans. or schedule risks to the project or to life cycle support of the system. Requirements d. but a work-around solution is known a) Result in user/operator inconvenience or annoyance but does not affect a required operational or mission essential capability b) Result in inconvenience or annoyance for development or maintenance personnel. Plans b.J-STD-016-1998 Page 202 Category a. cost. Design e. b) Any of the reviews may be conducted incrementally.J-STD-016-1998 Page 203 Annex NAnnex N Candidate joint management reviewsCandidate joint management reviews (informative) N.3 System/subsystem requirements reviewsN.3.1 ScopeN. leaving the joint management review as a forum to resolve open issues and reach agreement as to the acceptability of each product.3.2 Operational concept reviewsN. There is no intent to require these reviews or to preclude alternatives or combinations of these reviews.2 Assumptions This annex makes the following assumptions: a) The acquirer has reviewed the subject products in advance.3 Candidate reviews Given below is a set of candidate joint management reviews that might be held during a software development project. . N.3. N.2.3.18. The objectives supplement those given in 5. provided to aid in using this standard. N.3.1 Software plan reviews These reviews are held to resolve open issues regarding one or more of the following: a) b) c) d) The software development plan The software test plan The software installation plan The software transition plan N.1 Software plan reviewsN.2 AssumptionsN.1 Scope This annex describes a candidate set of joint management reviews that might be held during a software development project.3 Candidate reviewsN. and one or more joint technical reviews have been held to resolve issues. not necessarily in the form of hard-copy documents.3 System/subsystem requirements reviews These reviews are held to resolve open issues regarding the specified requirements for a software system or subsystem. It is informative only.2 Operational concept reviews These reviews are held to resolve open issues regarding the operational concept for a software system. Software products are expressed in lower case letters to emphasize that they are generic products. N.3. dealing at each review with a subset of the listed items or a subset of the system or software items being reviewed. J-STD-016-1998 Page 204 N.3.4 System/subsystem design reviewsN.3.4 System/subsystem design reviews These reviews are held to resolve open issues regarding one or more of the following: a) The system- or subsystem-wide design decisions b) The architectural design of a software system or subsystem N.3.5 Software requirements reviewsN.3.5 Software requirements reviews These reviews are held to resolve open issues regarding the specified requirements for a software item. N.3.6 Software design reviewsN.3.6 Software design reviews These reviews are held to resolve open issues regarding one or more of the following: a) The software item-wide design decisions b) The architectural design of a software item c) The detailed design of a software item or portion thereof (such as a database) N.3.7 Test readiness reviewsN.3.7 Test readiness reviews These reviews are held to resolve open issues regarding one or more of the following: a) The status of the software test environment b) The test cases and test procedures to be used for software item qualification testing or system qualification testing c) The status of the software to be tested N.3.8 Test results reviewsN.3.8 Test results reviews These reviews are held to resolve open issues regarding the results of software item qualification testing or system qualification testing. N.3.9 Software usability reviewsN.3.9 Software usability reviews These reviews are held to resolve open issues regarding one or more of the following: a) b) c) d) The readiness of the software for installation at user sites The user and operator manuals The software version descriptions The status of installation preparations and activities J-STD-016-1998 Page 205 N.3.10 Software maintenance reviewsN.3.10 Software maintenance reviews These reviews are held to resolve open issues regarding one or more of the following: a) b) c) d) e) The readiness of the software for transition to the maintenance organization The software product specifications The software maintenance manuals The software version descriptions The status of transition preparations and activities, including transition of the software development environment, if applicable N.3.11 Critical requirement reviewsN.3.11 Critical requirement reviews These reviews are held to resolve open issues regarding the handling of critical requirements, such as those for safety, security, and privacy protection. J-STD-016-1998 Page 206 Annex OAnnex O Candidate management indicatorsCandidate management indicators (informative) O.1 ScopeO.1 Scope This annex identifies a set of management indicators that might be used on a software development project. It is informative only, provided to aid in using this standard. O.2 Candidate indicatorsO.2 Candidate indicators Given below is a set of candidate management indicators that might be used on a software development project. There is no intent to impose these indicators or to preclude others. a) Requirements volatility: total number of requirements and requirement changes over time. b) Software size: planned and actual number of units, lines of code, or other size measurement over time. c) Software staffing: planned and actual staffing levels over time. d) Software complexity: complexity of each software unit. e) Software progress: planned and actual number of software units designed, implemented, unit tested, and integrated over time. f) Problem/change report status: total number, number closed, number opened in the current reporting period, age, priority. g) Build release content: planned and actual number of software units released in each build. h) Computer hardware resource utilization: planned and actual use of computer hardware resources (such as processor capacity, memory capacity, input/output device capacity, auxiliary storage device capacity, and communications/network equipment capacity) over time. i) Milestone performance: planned and actual dates of key project milestones. j) Scrap/rework: amount of resources expended to replace or revise software products after they are placed under project-level or higher configuration control. k) Effect of reuse: a breakout of each of the indicators above for reused versus new software products. J-STD-016-1998 Page 207 Annex PAnnex P Questionnaire on use of this standardQuestionnaire on use of this standard (informative) This publication of J-STD-016-1998 is as a standard for Trial Use during the period of September 1995 through September 1996. During this period reactions and comments regarding this standard are solicited. Below is a questionnaire that can help the joint IEEE/EIA working group assess the usefulness and applicability of the standard. Please feel free to copy this questionnaire for others to use. Send responses by 30 June 1996 to: Perry DeWeese Lockheed-Martin Aeronautical Systems D/73-F9 MZ0685 86 South Cobb Drive Marietta, GA 30063 FAX 404/494-1661 email:
[email protected] (Circle as many as apply) Question What are the characteristics of your project? Small Safety-critical Weapons system DoD / Federal Agency Did you plan to apply the standard on international projects? If you used the standard to develop non-government commercial products, what type of software do you develop? Yes Financial Database Medical Development tools Yes Yes Yes Yes Improve Yes Incremental Yes Is the concept of joint reviews useful? How are you using the software product descriptions? Yes Checklist of information Yes No Response Medium Security / Privacy-critical Information system Multi-national No Client-server Artificial Intel Operating sys Word processor No No No No Delay No Evolutionary Yes No Information in tools or database No No Yes Large Communications system State / county / city In-house Already apply Games Other (list): If you have used the standard on client-server project applications, did the standard meet your needs? Was the standard helpful in supporting business process re-engineering activities? Was the standard useful in facilitating the acquirer-supplier agreement/negotiation process? Does the standard conflict with established company organizationallevel software standards/procedures? How does the standard affect your software time-to-market? Have you found the standard to be supportive of innovative procedures in your company? Was the standard useful for non-traditional life-cycle models? Somewhat Somewhat N/A Somewhat None/don't know Somewhat Other No Don't know Traditional document Somewhat Has the standard helped improve the quality of your software products? Does this support your development process? Yes Yes Yes Yes Yes Software QA Yes The standard does not include activities sometimes used in software development. Contact information (optional): Name: Address: Phone: e-mail: .J-STD-016-1998 Page 208 Question Were you able to draw a meaningful distinction between requirements and design? Were you able to draw a meaningful distinction between software architecture design and detailed design? Should the standard provide requirements on the interface between developer and the acquirer's CM control of requirements? Should the standard require that specific products be baselined at predetermined points in the development? Should the standard provide requirements on the interface between the developer and the acquirer's configuration audits? The standard has incorporated activities sometimes treated as nonsoftware activities. Attach additional sheets if necessary. Should this standard include requirements on: No Response No No No No No Sys Rqmt Def Yes No Don't know Don't know Don't care Don't care Don't care Sys Test Yes No Domain analysis Yes No Business Process Improvement Yes No Data Standardization Yes No Which Military standards for software development and documentation do you currently use? Which commercial standards for software development and documentation do you currently use? DOD-STD2167A/2167 IEEE Standards DOD-STD7935A/7935 EIA Standards DOD-STD-1703 In-house standards Please provide any comments that you feel will help improve this document. 2 . Other annex entries are listed with the annex letter and clause number (annexes A .1 J.2.3 F.2.2.2.2.2. Annexes E through J.3 SPS SRS SSDD SSS I.2 H.P).4 IDD IRS OCD SCOM G.2.4 SUM SVD J.3 SDD SIP SIOM SIP G. are indicated by the acronym of the software product. The entry "et al" indicates that a topic (such as "software") appears too frequently to cite all references.2.1 E.2 E.4 I.2. COM CPM DBDD FSM J. K .2.4 G.2.2 STD STP STR STrP H.3 G.1 I.2.1 F.2.2.2.1 F.2.2 F. The correlation between annex subclause and software product are listed here for quick cross-reference.2.D.J-STD-016-1998 Page 209 Index Entries in bold indicate primary sources of information about a topic. which specify contents of software products.2.2.2 E.3 I.2.2.1 J.4 E.2. 4.4. 12.2.1. should be changed to read as follows: The tailoring requirements of this standard are informative (that is. Clause 4. Delete clause 1.5 should be changed to read as follows: . 1. sentence 9. which is then tailored to the specific requirements of a particular project. Delete clause 4.8.5.6.6.2. Clause 1. non-binding).2.4 sentence 5.a should be changed to read as follows: Performing the activities resulting from tailoring the organization’s defined software development process.2.” 7.a. 2. 6. Clause 1. 13.2. and 8. Delete clause 5. based on the business-case considerations for the project. sentence 3.5. Delete clause 5.5. Clause 5. Clause 5.1.2.1. Delete clause 1. Clause 1. Clause 1. sentence 3. should be changed to read as follows: Tailoring guidance can be found in annexes A and B. sentence 2 should be changed to read as follows: The developer shall record information about the development of the software in appropriate SDFs. 5. 3.2. 9.2. and are the responsibility of the developer.3. sentences 6. 11. 10. 8. 7.2. for a specific project.2. sentences 1 and 2 should be changed to read as follows: This standard is meant to be used to define the organization’s software development process. Clause 1.1. sentence 1 should be changed to read as follows: The developer shall establish a software development process consistent with organization requirements.2. should be changed to read as follows: Compliance with this standard means “compliance with the standard as tailored for the organization and adopted as part of the organization’s software development process definition.J-STD-016-1998 Page 210 Annex Q Changes to the EIA/IEEE J-STD-016-1995 Version of the Standard This annex identifies changes and clarifications to those clauses in EIA/IEEE J-STD-016-1995 that are required to shift the application of the standard from two-party contractual agreements to voluntary adoption as part of an organization’s software life cycle process strategy.6. the developer may deliver: 1) a repository or database containing the information specified in the standard. 2) a means of accessing that repository or database.5. clause A. 26. 21. clause A. sentence 3. Clause 5. Delete clause 5. Annex A. and 3) a hard-copy or electronically-stored table of contents.4. delete “depending on contract provisions”. should be changed to read: Depending upon the requirements of the developer’s operations and maintenance concept for the delivered software.c. Clause 5. Annex A. sentence 3. Clause 5.7. sentence 3. 27. delete “depending on contract provisions”.1. specifying how and where to access the information required in each subclause. 15. if not already available to the designated recipients. 22. clause A. Clause 5. sentence 3.b. based on the project environment characteristics. sentence 3 should be changed to read as follows: Requirements concerning system interfaces may be included in the SSS or in Interface Requirements Specifications (IRSs). sentence 3. should be changed to read as follows: Evaluate the requirements of the organization’s software development process to determine whether each requirement is applicable. should be changed to read as follows: Decide which requirements in the organization’s software development process are applicable and cost effective over the life of the project. 14. sentence 3. 19. Clause 6. delete “depending on contract provisions”. Annex A should be changed from normative to informative. clause A.2.6. Annex A. 24.2.5. 16.1.2. 25.J-STD-016-1998 Page 211 The developer may use non-deliverable software in the development of deliverable software provided that such use is consistent with the developer’s life cycle operation and maintenance concept for the deliverable software.5. Clause 5. Clause 5.5. sentence 3.6. delete “depending on contract provisions”. 18. 20. Annex A. should be changed to read as follows: .4. Annex B provides additional guidance on tailoring the organization’s software development process for a specific project.1 should be changed to read as follows: This annex contains guidance for the developer in tailoring the developer’s J-STD-016-1998compliant organizational software development processes for a specific project.6. delete “depending on contract provisions”.a. delete “depending on contract provisions”.3.1.3. 17. such as a CASE tool. Clause 5.3. 23. J-STD-016-1998 Page 212 Modify.2. 30. 3.2. clause A.13.6. 5.2. SDD 4.4. L. 6. sentence 2. Tailoring accomplished by the developer should be recorded in the Software Development Plan (SDP). should be changed to read as follows: Tailoring decisions for the project should be specified in the Software Development Plan (SDP). Fig 9. binding) subject to the following conditions: 1) these requirements may be tailored. SPS 3.1.5. should be changed to read as follows: This annex is normative (that is.1 architecture 3. SDP 4.2 acquirer (use of term "acquirer" in this standard) 1. 35. Annex L.17. system architectural design) "as built" design descriptions 5.4 (see also: software item architectural design.9. Fig 11 associate developer 3. clause B.9. clause B. Annex A. Annex B.1. SRS 3. SSS 5. Annex A. 34.2. 31. should be changed to read as follows: Decide which additional requirements not described in the organization’s software development process.3. Delete Annex B. and 2) if the development of a given software product has been tailored out of the project’s software development process. 4. SSS 3.5 application of this standard 1. SDP 4. SDP 4. requirements in the organization’s software development process to reflect unique or special needs of the project.7.2. SSDD 4.2.18. clause L.5.2 allocation allocation of computer hardware resources 4. 5. SDP 5. sentence 1 should be changed to read as follows: The development strategy is the responsibility of the developer.2.2.3.2. 5.25.2.18. 5. should be changed to read as follows: Tailoring decisions are the responsibility of the developer. Fig 11 applicable (interpretation of "applicable" in this standard) 1. N.1.1.13. IRS 3.2.4. SDP 5. SRS 5. Annex B.5.2. 37.3. 5. if necessary.6. subject to the following conditions: 1) these requirements may be tailored.8 access to information in a repository 6. 5. acceptance 3. clause B.13.5 .24 assurance 4.5.2. clause A.1.5.1.2. 5. 33. SDD 4. L.30.5. sentence 2.2. 5.1 sentence 2 should be changed to read as follows: This annex is normative (that is.2 access access for acquirer review 4.5.8. and 2) the developer may use alternate category and priority schemes.1.1. should be specified. Delete Annex P.1. Fig 4-7. Delete Annex C. clause M.2 acquisition strategies (see: development strategies) acronyms 3.24. 32. M. Annex M. the requirement to evaluate the product does not apply. 5.1.d.1. 1.1 allocation of requirements Fig 9. Fig 1. binding). SSDD 4. if any.5. 3. and the SDP should be updated accordingly. SDP 4. 5. Delete Annex B. 28. 36. 29.11. clause B.1.5 (see also: software quality assurance) privacy protection assurance 4. 5.6.2 approval (by the acquirer) 3. sentences 2 and 3.1.6. 5.5.13.4.1.1.3.2.13.1. Refinements to tailoring decisions may be ongoing as the project proceeds.1. 5.1. 2. SPS 5. 4. 6.12. 4. 3.2.13.4.39. 5.2.17.14.1.12. Introduction. D.6.x.1.2. 5.1.14. 3.5.6. K. 3. Fig 13 critical requirements reviews N. Fig 11.37.4.1. compilation/build procedures 5.4.1. SDP 4.1.x.3 definitions abbreviations and acronyms 3.1.12.4.2 Computer Operation Manual (COM) 5.1. 1.18 5. 5.4 (see also: joint technical and management reviews) corrective action system 5.3 compliance with the "as tailored" standard 1.1.3.5.12. 5.3.x.x.2. DBDD 3.3. 6.10. 3.32.2.5.1.3.11 privacy protection assurance 4.3. 5.3 activity completion criteria 1. Fig 1.2.3.15.8.1. SPS 5. reusable software products) compilers.2.y. 4.2.11. 4.x. Fig 10. A.x.1.1.16.2. Foreword-4. SDD 4. Fig 12.1.1.5.1. 5.SDP 5.1 category classifications for problem reporting 5.2. 4. 5. Fig 10. SSS 3.14.12. K. Fig 9.2.2.17.2.2. 3.1. STP 3. 4.3.17.2.3.2. O.6. SDD 3.2. SRS 3. software center 5.1. SSDD 4.2. 3.3. SDP 4.1. Annex M problem/change reports 5.2. 5.3.10. 5. 5. 5. B.3.15.3.2. 3.3.7 Note Computer Programming Manual (CPM) 5.30.17.10. SDP 5.4.1 Note.2.2.11 security assurance 4. K.2.3. 3.1.5.1. 5.2. IDD 3. standard data descriptions SSS 3. 3.4. 5.1. 4. 1.11 safety assurance 4.3.3.2. OCD 3.2. SPS 5. SCOM.5.5. 3.1. contractual use of term "contract" in this standard 1.17.3. 5. D.25.1.2. 5.10.1.13.3. 5.2 computer center.2.2. STrP 3. 5. SPS 5.x.5. 5. 5.18.5.3.4. 3. A. IRS 3.9. DBDD 3.2.16.18.6. STrP 7.3.13. SIOM 5. 3.2.9 contractor (see: developer) corrective action 4.2.6. 5. IRS 3. SCOM 3.2. SPS 5. Fig 1.1.3. 5.2 compliance stipulation 1.2.2. D.x.x.2.1. OCD 7. SDP 5.1.3.18.3.2. N. STrP 3.1. 6. 3.2.1.6.22. B. 5. Fig 13 critical requirements 3.1.3.7.10 database 3.1-5.2.2.3. 7..2.5.1.1.4 behavioral design 3. B.2.2.11 data elements/data element assemblies SSS 3. 5.4. SDP 4. L. 6.3.1. J. 5.6.7 coding (see: software implementation and unit testing) commercial off-the-shelf (COTS) (see: reuse.3. 4. 5. 1.4.6. DBDD 3.6. 5.6 define (interpretation of "define" in this standard) 1.12.16.4.2 cost/schedule risks 5. 3.2.1.x. 3. DBDD. 5. 5.3.2. SUM.2. 5.6. 3. SSDD 4.2.1. 1.3.21.4. SSS 3.6.2 contract-specific application Foreword-2. 1. SDD 3.2.5 security assurance 4.1-5. 6. Annex M costs cost benefit.2.14. 5. Fig 12 (see also: corrective action) code standards 4.2.7.2. OCD 8.1.10. 6.1 Note 1. 5. Fig 4-7.1. 3. SDP 5.4. 5.3. Fig 4-7.2.3.24.8.5.3.5.3. 4. C. Introduction.2. 5.17. 5. 5.3.4. Fig 10.2.4.y.x. N. SIOM. SCOM 3.5. 4.13. COM. 5. C.6.9 computer program 3. Fig 8 notes on interpreting activities for multiple builds 5. SIOM 3. 5.4. O. Database Design Description (DBDD) 4. CPM 3. 5.x.3. SDP 5.12.4.1.14.2. 1.x. 5. Fig 11. Fig 12 configuration management (see: software configuration management) contract. 5.4. Fig 13.3. SSDD 3.x.2. 5.2. STP 3. SRS 3. 4.12.17.7. 1.3 computer hardware resource utilization 4. SSS 3.2. M. SRS 3.x.1.6.3.1.1. 5. SIP 4. OCD 7.5.5. 1.9. Fig 5-6. K. SDD 3 builds Introduction.5.3. 3.1.3.3.x.19.1.3. Fig 10. SIOM 4.6. 4. 3.3. N.5.7.12.6.8.1. A.2.2. Fig 12 database design.1 data standardization.16. 4.4. 5. A.2 build planning guidance B. 1.5.3. IDD 3.21. CPM.3. SSDD 4. Fig 4-7.1.12. Fig 11.37. SIOM 3.x.3. I.3.2. 3.1. SSDD 3. 6. SSDD 3. SDP 4. 4 Note.1. 5.2.3.5.5.39. K.1.3. SSS 3. Fig 10.6. 5.2.1. SDP 4. 3.3. 5. 1.2.2. SDD 3.2.7.2.5. 5.6. 5.1.x. 3. SIP 4. 5. STD 4.6. 5.2. 4. B. B.13. Fig 4-7.3. 5.4. Fig 9. 6.3. 4.5. 5. L. SRS 3.2.3. 3. K. CPM 3.3.10. 5.x. 3 Note. D. M. SUM 3.2. 5.5 audits (configuration audits) 5. SRS 3.3.2.1. SSS 3.6. N. Fig 11 compliance 1.3 definitions of terms 3. SRS 3.43.7. SDP 4.1. D. K. 3. Fig 10 computer hardware characteristics STrP 3.2. 5. 5. 5.23.2.16.1.3. cost-effectiveness Foreword-4.1. 5. 3.18.x. 5.1.3.16. 5. 5.3.3. Fig 13. 4. 5.10.x.2. 1. SRS 3.1.4. N.21.3.6. K. SDP 5. SDP 4.16.5. 6. 6.5.1.32.2.3. G. 4.6.14.6.4. .1.10. 5. 3.2.1.1. 5.3.1.1. STrP 3.3.1 computer-aided software engineering (CASE) Foreword-6.2. FSM 3.3 references to the contract Foreword-2. Fig 11.2. 5.1.J-STD-016-1998 Page 213 safety assurance 4. K.5.2.13. 5.1. SRS 3.x.3.1.2 definitions of software product evaluation criteria L. C.17.2. 7.4. SSDD 3. SUM 3.x.7 Note.3. 5.1.1. 3.2 Note. SDD 3.1.1.9.4.2. Fig 2.12. 5.2. 3.9.2.4 in-process in-process and final software product evaluations 5. 5. 1.1.23.6.13.15.1. Notes clause of software product contents (Annexes E-J) key word listing Title page licenses.3.2.11 (see also: corrective action. Fig 4-7. STD 5. Fig 2.1.12.1.23 Independent Verification and Validation (IV&V) 3.x. SSDD 3. 5. system design. 5.3. Fig 11.17.13. 1.2.16. software item architectural design. 4.5. software engineering environment) error reporting (see: problem reporting) evaluation 3.12.37 development strategies Annex B. N. Fig 7 IDD 1.2.1. IRS.3. Fig 10.2 engineering (see: forward engineering. 5.4.16. 3. SDP 4. Fig 4-8.10.1 preparing the executable software for software use 5.3. Fig 2.1. IDD 3.2.1.1. L. 3. Fig 3.2.2. SDP 5. Fig 9. 4 Note.5. 3. Interface Design Description (IDD) 4.x.J-STD-016-1998 Page 214 deliverables deliverable software products 1. Fig 10.3. B.1. Fig 9. STrP 3. 5. software product evaluations. 6.2.18. 5. 3.1. L. Fig 4-7.9.1. STrP 7 installation at user sites 5.4. SRS 3.4. 4.1.13.3. 5.2.7. 5.x.2.4. 4.10. 4.3 developer (use of term "developer" in this standard) Foreword-3.3.1. 5. 1. 4. Fig 2.8. 5. Fig 11. SIP. SDP 5. Fig 11 interface requirements.1.2.5. 6 Note. 4.6. 3. system architectural design.2. problem reporting. C. IDD. Fig 4-7. 3. G. SPS 5.2 version descriptions (see: Software Version Description) firmware Introduction. SDP 5. 5.3 independence in software quality assurance 5.3. 1.2. SUM 4.x.1.1.2.3. 1. SDP 3 documentation 3. SSS 3.2.1.1.2. L.x.3 independent auditor 5.4.13.1.1. F. Fig 4-7.13. IRS 1.1.3.12.4. C. software item detailed design.1 dry run of qualification tests 5. STP 3.9 software installation planning 5.11.1. 5.1. reusable software products. 5.3. SSS 3. 5.3.2.8. Fig 4-6.4.18.7.x. Database Design Description. reverse engineering.5. Fig 11 delivery of executable software SPS 3. Fig 3. DBDD 3. Fig 4-7.2.1 regenerating executable software 5. 5.12. SSDD 3. Fig 1.3.1 joint reviews of in-process and final software products 5.1.2.22.2. system-wide design decisions) design standards 4.4. 4. 5 Note. SCOM 4.1 independence in software product evaluation 5.13.1.4. 5.21. 3. Fig 10. 5.6. SSDD 3. 4. I. 5.1. SSS 3.1 incorporating reusable software into the executable software Fig 9 installing executable software 5.7. 4. N.1. Fig 11 hardware-software systems Introduction.1. SIP.1. Interface Requirements Specification (IRS) 4. 5. 3.3. SDP 5. Annex C design 3. STrP 3.4. Fig 5 independence independence in qualification testing 5.3.2. SDP 5. Fig 10 Firmware Support Manual (FSM) 5.3.4.10. System/Subsystem Design Description.1. 5. 5.3.3. problem/change reports) candidate joint management reviews Annex N key decisions (recording rationale for key decisions) Introduction.5. 3.3. 5. Software Design Description.29.1.9. .2.1. SDP 3. 5.2. 3.1.1. SDP 5. A. 5. SDP 5. 5.13.9 guidance on ordering deliverables 6.1.7.2. 6.2. Fig 10 implementation (see: software implementation and unit testing) in-house application of the standard 1.1. software item-wide design decisions.3.3. 5. Introduction.2. 5.14. SSS 3.14.13. 5.2. Interface Design Description. behavioral design.3. 3. SSDD 3. STP 6.2. 3. Fig 11 ISO/IEC 12207 Foreword-3 joint technical and management reviews 3. 5. 5.4 in-house organizations (as developers) 1.3.13.2.4. DBDD 3.6.11. 6. FSM. SDP 5.1.1. K. SDP 5. STrP 3.2. SDP 5.19. SRS 3. general requirements 4 hardware item 3.7.2. 5.3. SDP 5.2.2. 5. 6.x.9.2 (see also: usage and ownership rights) life cycle Foreword-3.11. SDP 5.1.4.7. 4.4. SPS 5.14.9. unit integration and testing) interface 3.11.4.1 integral software development processes 4. licensing D. SVD 3.2. 5.4 Note.2. COM 4.2. 5.3. STP 3. software design. 3.1 Incremental development strategy Introduction.2. STP 3.20. software quality assurance) Evolutionary development strategy B. SDP 4. 3. Fig 3.2.13.1. reengineering.4 preparing the executable software for software transition 5.13. Fig 10.3. Fig 1.1.2.1.7.3. K.9. SDP 5.16.2.2.1. SVD 3. 4.5. 4. Fig 11. STP 3.3.15.12. 5.16. 1. DBDD 3. Fig 11 forward engineering 3. 1.22 interface design. Fig 6 executable software Fig 11 compilation/build procedures SPS 5. SPS 5. SDD 3. SDD 3.1.11 Note.15.9 Note.9.1 integration (see: software/hardware item integration and testing.15.3.15. 6 Note.1. 4.7 detailed requirements 5 develop (interpretation of "develop" in this standard) 1. 5. 5. A. SPS 3.2.23.2. Fig 9. B.6.3.18 (see also: Independent Verification and Validation.34. K.2.23 installation installation at the maintenance site 5.10. 5. Fig 4-7.10.3.15 (see also: "as built" design descriptions.2. 1. 5.18.11 Note. STR 4.11 (see also: assurance) problem reporting. problem/change reports 5.5. IRS 3.1. 3.7.3.x.x. STP 4.5 Notes 6. 4.1.y.5.x.6.2. Operational Concept Description (OCD) 5.1.11.y. SIOM 3. SSDD 3.3. 3.7.12.3. 5.1 reverse engineering 3. 7.2.32.1. Fig 8.x. SRS 1.2. SUM 1.3. Fig 12. 5. 3. etc.2.1.2.14. Fig 9.6. 5.y.x. 4.3.3. 5.2. 3.2. 3.2 planning (see: build planning. 3. software transition planning.18.3.4. OCD. D. 3.18. Fig 9.4.2.3. 3. 5.5.3.1. Fig 6. 5. 5. STrP 5. 5. IRS 1.2.3.3.y.1. 5. Fig 13.3. software development planning.x (see also: Computer Programming Manual) project planning 4.3. Notes clause of software product contents (Annexes E-J) record (interpretation of "record" in this standard) 1.15 maintenance (see: software maintenance) management indicators (see: software management indicators) management review 5.2.7. N.1.9. SSS 3.2.2. STP 1.4.5. Fig 8.28.14. SRS 3. 1.8.16.19. SDP 4. 3.1. Fig 13 safety 4. SCOM 1.10. SIP 4.4. SRS 3. 5.1. Fig 4-7.4. 5.5. SSDD 4. 4.3.x.7.x.3.1. 4. 3.3.x. IDD 1.2 qualification methods STP 4. SSS 3. B.3.10.5. 3.x.29. SUM 4. 5.1. OCD 1. 6.11. Fig 12. SDP 5.3. SDP 1. cost/schedule risks 5. SDP 5. 5.3.6.2 packaging. Fig 10 request for proposal (RFP) B. SSS 3. SCOM 3. SRS 3. 3. 3. STD 3.25. SPS 3.1.x. SIOM 4. 3. 3. 5.1.y.3. 3. DBDD 3.7.17. SCOM 4.2 operational concept reviews N. Annex M. SUM 3.1.2 process improvement 5.3 priority classifications for problem reporting 5. A. 4.3. 5. Fig 7.6.25. 5.5.3.x. STR 4.2.x. 3. SPS 1. Fig 7 reviews (see: joint technical and management reviews) revision and retesting 5. SVD 3. SDP 5.x.8.2.x. 4.11 (see also: assurance) schedules 3.1.34.37. 4. 5.6. 4.3.y. Fig 7 reuse.5. Fig 9.x. Fig 1. SDP 1. D. 3. STrP 1.1. STR 1. 3.1.x.3.8.1.2. Fig 4-7.x. 4.x. Fig 10.3.2. 5.1. Fig 13.18. 3.3. COM 3.y.5.x. 5.1.2.5.1.3. 6. STP 1.3. Fig 1.2.x.5.x. B.1. 5. SSDD 4.1.6. D.4.19. 5.2. SDP 5. L.y.4.2.18.3. 5. 5. SDP 4. L. SDD 4.x.4. 4.x.21. DBDD 1. 4. 4. STP 4. 3.1.11. Fig 1.5.2.x.5. 5.2.2. O. 3.17.25.31. 4.3. 3. Fig 9.1.2.29. M.6.3.8.17.3. Fig 3-7. N.3.3. FSM 3. maintainability. M. SSS 1. OCD 3.3. FSM 1. 3.2.5.13.2.x.2.5.1.4. reusable software products Introduction. 6.3. SRS 3. SRS 3. 3.1.2. 3.J-STD-016-1998 Page 215 Fig 10. SIP 3. 3. SSS 3. SDP 5.15. 3. N.3.3 participate (interpretation of "participate" in this standard) 1. 4.3.10. 5. SDD 4.1.3.3. 5. 5.x.4.2 participation in system-level activities 5. Fig 7 reengineering 1. 5. SIOM 1. D.3. 4.37 programming languages 3. CPM 1. B. 4.2. 5.1.37.x. 5.2. L.7.y. Annex D.14. 4.29.6 metrics (see: software management indicators) non-deliverable software products 1.11. 3.2.25 program (computer program) 3.3. SSDD 4.2.2. 3.x. IRS 3. Fig 13 guidance on scheduling activities B. SVD 3.x. 3. 5.5.7. D. SSS 3.x.3. SRS 3.1.x.1.3.6. IDD 3.3. 3.3 requirement 3. SDP 4. B. Fig 4-8. 4.3.2. SSDD 1.1. 5.2.2.4.x.2. Fig 3. OCD 3. 3.x.2 (see also: corrective action) privacy protection 3.1.2. STR 3. 3.3.2. software installation planning. SIP 1.x. 5. 3.14. STrP 7. 4. SDP 5.1. 3.) Introduction.x.x. 5. 5.1.3. 4. Fig 11 project-unique identifiers 5.3.18.18. 3. SIP 1.3.2. 5.4 .1.2. 5.2. project planning.2.x. 7.2.1. Fig 4 operational concept. IRS 3.3. 5.2. SSS 3.2.2.2.1.3. 3.x. COM 1.2. 5.2. 5. 3.1. Fig 11. 5.y. 3.11. 4.8. 3.29.x. software test planning) policy A.4 incorporating reusable software products 3. 5.11.1.3. SDD 3 rationale (recording rationale) 3.x. 4. 5.1.1. D. Fig 4-7.1. 5.x. O.y. 3.1.4. SRS 3. 4.34.3.6.3.30 requirements definition (see: software requirements definition.1. SDP 5.x.7.18.8.18.33.2.x.x.10.1.7.4. 5. 3.2.3.3. SDD 4. 3.3. Fig 13. SDP 5.3.3. 1.x.y.x. 5.3.1. 4.1.3.7. SVD 1.33.1. SDD 4.4 redocumentation 3.21.3.3. 4.17.2.29. 4.X. 5.4. SSDD 3. STP 5.x. system requirements definition. 3. 5. SPS 4 qualification testing 3.y.27.2.2. IDD 3.x. 5.7. STD 3.7.1.9.2. 5.1.3.x. SSS 3. 4. Fig 1.14.1. STP 4.17.x. Fig 13 logistics SSS 3. DBDD 5.1.2.2. SDD 5.2. F.4. 3.2. SDD 3.3. 4.1. SRS 3.12 risk management 4. FSM 3. 3.7.1.2. system qualification testing) quality assurance (see: software quality assurance) quality factors (reliability. 4.5. 5.x. 3. Fig 2. 3. 3. SSDD 4.17. 5.4.1. SDP 5.3.3. 4. 5. packaging requirements 5.7. SDP 4. 4. 3.2.4. 3. 4. Fig 9.1.3. DBDD 4.1. SDD 1.3.9.y.7. Fig 10 cost/schedule reporting. 4.x. Notes clause of software product contents (Annexes E-J) Once-Through development strategy B.3.11 (see also: software item qualification testing.2 prototypes 5.2. Fig 7 retargeting 3.7. 5.19. SDP 4.4 developing reusable software products 4. STrP 3.13. STrP 1. 3.10. STD 4.26. 3.5.7.1. 3. 5.6.4.4.1.1.2.3. traceability) resource utilization (see: computer hardware resource utilization) restructuring 3.1.6.1. SDP 4.15.1-3. D.5.3. SDP 3. 3. DBDD 3.x.1.1.17.12.4.1.1 evaluating reusable software products 4.5. 5. 4. 4. SDP 4.4.3. 5. SDP 4. STD 1. 4.3. 5. SIOM. 5.4. 4.1. SCOM 1. 3.7.4.8.x. N. SRS 1.1.4.1. System/Subsystem Design Description.2.2. SDD 5.7.14.2. 4.3.y.x. system-wide design decisions) software design reviews N.10. Fig 10.15. SDP 4.y.1. J.1. SVD 1.5. 5. 4. SDP 5.2. N. 5.1.2. Fig 1.13.2. 4.4.3. 5. SPS 1.6. 3.2. C.2. Fig 1.14. G.3.2. SRS 3. SIOM 3. 4.14.2. SPS 5.3.3 scope of this standard 1 security 4. 4.3. SIP.14.6.1.6 software item detailed design 3. Fig 10. 5.2.7.x.14.3.3.3 packaging.1.2.25. SDP 5.4.5. SDP 5.3.3. 5.4.2.3. 5.x.4.3.1.1. Software User Manual) software configuration management 3. 3.12. E. SDP 5.2. SPS 5.9.3. 5. 4.1. 5.2. Software Design Description (SDD) 3. D. Fig 11.2.3. SIOM 1. SDD 4.43.6.4.6.9.11.1. SPS 5. Fig 4-8. K. 1. handling. SDP 5.3. 4.34. 5. author control. 5.4.5. Fig 1. Fig 9. SDP 5. Fig 11.1.2.2.4. 5. Fig 12. Fig 9.1.6.2. 6. 5. project-level control.19. 4. O.21. 3.2. 4.3.3.25.1.3. Fig 10. DBDD 5.6 (see also: Database Design Description. 5.7. Fig 11 (see also: Software Center Operator Manual. SDP 5.3. 3. 5. Fig 9.1.3.2.2.14. 3.3. SCOM.2 configuration identification 5. 3. N. 4. 1.2.18.x.1.2. Fig 12.2.4. 5.1. Fig 11.1.1.14. 4.11 (see also: assurance) software 3.32.2 SDP 1. Fig 1.1. system design.2. B. Annex B. 1. 4.3. O.1. SDP 5. Fig 4-7. 5. 3. 3.12.3.2.1.1.2. COM 1. STR 1.x.2. D.3.1.1. SUM 1.1.7.2.13.2. 5.4.2. 5. 6. SDP 5.x.x. 5. Fig 11 software development library (SDL) 3.2.3. Fig 11. 3. Fig 9. 5. 3. 3.16. 5.2.1. Fig 9.17. Software User Manual) software installation planning. SPS 5. J.8.J-STD-016-1998 Page 216 guidance on scheduling deliverables C. 3. et al Software Center Operator Manual (SCOM) 5.4.1.1. Fig 1. software item detailed design.11. 4. system architectural design. SDD 3. E.9.3. Software Development Plan (SDP) 1. 5. .3. 5.6. 6. 3.3. Fig 4-8.5.1.3. Fig 4-7. 5. Fig 4-7.3 software development methods Foreword-4.39.3. 3.35.6. 3.4.1.14. Fig 11. 4. IDD 1.7 software development (meaning of term "software development" in this standard) Foreword-1.3.x.2.3. 5. 3. 5.43. behavioral design.11 Note. 4.16.3.2.9.3. Fig 9.5. 5. Fig 4-7.14. SDD. Fig 4-7.1-3.1.4. 5. 4.5.3. 5.2.5. 3.2 Note.3. Interface Design Description) software item qualification testing 3.2. L.17. 5. DBDD 3.1.5.1. DBDD 1. 5.2. 5.2. 4. 1. acquirer control 5. 5.3. SDP 5.10. STrP 3. B.3. 1.2.5.20.1.1.2.12.37.17. Fig 1. 3. 5.1.4. FSM 3. FSM 1.2.3.1 configuration status accounting 5. Fig 4-7.1 software item 3.20.1. Fig 11 (see also: Software Input/Output Manual.7. Fig 2.x. Interface Design Description. 7.2. 3. 4.3. 6.1. 4. 3.1 software development process Foreword-1. 6. 5.7. 3. 1.2. 3.17.11. 4. Fig 4-7.3.2.6.14. 3.1.8. 5.1.2. 5. Fig 13.33 software development environment 1. CPM 3 software implementation and unit testing 4. SDP 5. SDP 5. Fig 10.18. 4. 1. SDP 4.4.10 software development files (SDF) 3.3 software engineering environment Foreword-1. 5.3. CPM 1.11.4. STP 3.1 Note 3. Fig 9.10.1. 5.3.22. IRS 1. Fig 9. 3.14.2. SDP 5.3. software item-wide design decisions.9.8.3. SDD 4. SDP 5.x.1. Fig 8.8. storage. Fig 11 software item architectural design 3.1.36. Software Installation Plan (SIP) 5. 4. 4.1.1.19.1. D. OCD 1. 3. Fig 9. 5. Fig 1.2.14. 5.2. 3.3. 3.x.1.2.3.1. 5.6. SDP 4. Fig 4-8.7.1.2. 5. 5.2. Fig 10 configuration audits 5. SSDD 1. 5.11. Database Design Description. N. et al software/hardware item integration and testing 4. SPS 5.3.7.x. 3.1.5 software design. 4.4. 5.7.21.1.1. 5. Foreword-5. 5.3. N. Fig 4-7. 5. 5.2.3.2. Fig 10.2. Fig 10. SDP 5.1.2.3.16.10. 5. Fig 11 Software Input/Output Manual (SIOM) 5.15. Fig 10.1. L.1. 3.9.4. 3.1. 5.10. 4. 5. (see also: "as built" design descriptions.14.14.1. 5.6. 3. SIP 1.2.4.x.4 configuration control.2. 5. 7. 5. 3.3.5.x. Fig 8.5.4. 5. 5. 5. and delivery (of deliverable software products) 5.7.1. STD 1.6.3.2.1.x. 5.3.6.14.1.2. 4. 3.x.2.8.2.8. Fig 12. STP 1. SDD 1.2.3.2. SSS 1. SDP.2.1. C.1 software development planning.4. Introduction.1.6. STrP 1. SSDD 3. 5. 3.11.2. IDD 3. Introduction.6. 4. 3. N.7.3. 3. 5.2. 3.3.25.3.14.1. 5.37.3. software item architectural design.1. 5.1. 3. 5.2.26.6 software design standards 4.3. SDP 5.3. Fig 1. 5. 1. 1. Fig 10. Fig 10.5.16.6.5.9 Note.2. Fig 9.1 software quality assurance records 5. 5. Fig 11 software product evaluation records 5.1.2 software requirements.12.x.x.2 standards for software products 4.12. 5.J-STD-016-1998 Page 217 SDP 5. IRS 3.14. SDP 5.1.13. 4.3. Fig 9. 3.13.1.13.5.1. 3. 5.1 software transition (preparing for) 4. Fig 11.2.1 software product evaluation criteria 5.7.2.13.15.7. Fig 11. SDP 5. 6.4.1. Annex L. 4.2.2. 5. 1.2. 5. D.2.1. IDD 3.1.15. SDP 5. SRS 3.y.3. 3.2 (see also: testing) software use (preparing for) 4.6.18.4. 6.15. 5.3. 5.x. 1.4. 5. 5.7. Fig 11. N.y. SDP 5.1.1.5. DBDD 5. L. 3.5. O.1 software product Foreword-1.1 Note 3.2.3.2.4.4. Fig 9. 5. Fig 4-7.10 maintenance organization Introduction. Fig 12. Software Transition Plan (STrP) Fig 1. 7.7.38.6. SDP 5.7.1. Fig 10.2.1.16. SDP 5. N. SSDD 3. 3.1. Fig 4-7. 3.3. Fig 12 (see also: software item requirements) software requirements definition 4. software transition planning) support strategy 3.9 Software User Manual (SUM) 5.2. Fig 4-7.9.x.25. 5. Fig 4-7.2.3. 7. 5. SCOM 3. Fig 10. 1. Software Requirements Specification.1. SDP 5. 3.12. 6.4.10. IDD 4.2.2.10 maintenance reviews N. F. SDP 5.10. OCD 3. 3.16. Fig 1. IDD 3. SDD 3.2. 5.1.1.4. Fig 11. C. 3. Fig 1. Fig 11. 4. Fig 8.4.3.37.3 Note. SDD 3. A.1.7.5.2. Fig 9.4.3. SPS 3.13. Fig 9.3. Fig 4-7. Fig 9. 5.3. Fig 12. Fig 10 independence in software quality assurance 5.5. SIOM 3. 4. SSDD.2.2.7. 5.22.3.14. 1. SSS 3. Fig 1. SDD 3.1.40 software quality assurance 4. Fig 1. 3. Fig 9.2. 1.3. 6.15.1. Fig 11. Interface Requirements Specification) software item-wide design decisions 3.1. 3.2. 5. 1. Software Requirements Specification (SRS) 4. Fig 4-7. C.5.2. D. 5. OCD 3. 5.x. Fig 4-7.2.2. STP. Fig 4-7. SIP 3. Fig 4-7.3. 5. 6. SDP 5. 5.2.1.16.1.13.5. 1. STP 4.3 (see also: code standards.3. COM 3.37.2. Fig 10.20. 5. STrP. 5. SRS 3. SRS 3.16.5. 1. 5. CPM 3. Fig 9. 5.1. STP 6. 5. 3.31. 5. SDP 5. et al (see also: standards for software products) software product descriptions 1. SRS.5.2. STD.2.7.2. Fig 10. 5.22 subsystem 1.42 software transition planning. SDP 4.2.10 software quality 3.13.13.2. L.7.4.3.3.4. SDP 5. N.3. IRS 3. Software Input/Output Manual) Software Version Description (SVD) 5. STrP 3. 5.13. DBDD 3.3.2.10 maintenance site 5.3.1. SRS 4. 5. 4. 1.1.1 Note. 3.6. Fig 10.2. 7.9. 5. 5.13. 5.41.3. SVD. N. 7.1.2.x. N.9.1. Fig 1. 5. 5. 5.4.3. Fig 4-7.1 support (of software) (see: software maintenance.2.7 Note.2. 4. Fig 11. SPS 5. N.2.13. 6.13. 5.4.20.15.2. 5. 3.2.3.1. SPS 5. Fig 11 Software Product Specification (SPS) 4. SRS 3. B.1.1. Fig 9 software unit 3. L. B. L.2. SDP 5. 5. SPS 5. 6. 3. 3.4. SUM. 1. SPS 5.9.3 in-process and final software product evaluations 5.12.5.7. IRS 4.15. Fig 10. 5.13. STR. 3. 5. 5.9 (see also: Software Center Operator Manual.4. 5.1.16. 4. 5. 6.5. 5.10.6. I. Fig 10 software testing (see: testing) software transition 3.7. 7. Fig 4-7.9 software management indicators Introduction.29.2. 3.1. N. subclause 1. SDP 5. 3. 3.5.13.1.6.13.43.15. 5.3.3. SDP 4.x.3.7.2 Note. SDP 5.7.39.5.8. OCD 3. N. software design standards) states and modes of operation OCD 3. 6.9. STrP. 6. 3.12. O.1. STD 5.1. N. STrP 3.3.1. SSS.5.1.2.13.5. SSS 3.2.1. 3.1 software systems 1. 5.1. DBDD 3.3.3. 5. Fig 12. Fig 4-7.3. 4. Fig 10 interpretation of "system" in this standard 1.13.13.1. 3.2. SDP 5.1.2. 3.13. SRS 3.1.6 software maintenance Introduction.13. 5. 6.5.13.4.1. SDP 5. 4. N. Fig 11.11. 5.5. Fig 9.1.5. 5.42. 5. SSDD 3.2.2. 5.4. 4.1.7. SSS 3. Fig 11 maintenance manuals 5. SDP 5.3. SVD 3.13 Note.1. Fig 4-7.2.3.1. 5. Fig 10. Annexes E-K.2 Statement of Work (SOW) 1. SIP 3.7.2.3. 5.3.12. 5.22.x. STrP 3.2. Fig 9.8.5.16.3.3. 5.x.13.3.2.15.3.7.9.8.3.4. Fig 11. SDP 7.3 software quality assurance evaluations 5.15.13. 4.2.1.2.1.2.4 (see also: system/subsystem) supplier (use of the term "supplier" in this standard) Foreword-3.2.1.1. 3.5. 4. 4. SDP 5. Fig 9. SPS. 4. SDD 3.1. Fig 1.1.3.2.8.1.10 (see also: version/revision/release) source code.3.16. Fig 10. 7.4.12 software usability reviews N. Fig 9 software requirements review N. 5.6. 3.15.3. 5.2.1. SSS 3.1. 7.15. A.14.7. 5.2 of software product contents (Annexes E-J).1.4. 4. STP 3. .1.1.1.8.2. 3.9 Note. I. 5.1.4 Note. 5.1 Note.15. 5. 6. SPS 5. Fig 12.3. 3.16. 5.2. 6. source files 3.3. Fig 10. SDP 5.1.8.4.6.2.4 software product evaluation 4. 5.2.3. Fig 11 independence in software product evaluation 5.7. Fig 4-7.1. O.6.2.13.3. 7. SDP 5. 3. 5.3.16.3.15.1.3. 5.1.2.3. 4. Fig 9.1.12. SDP 5.1. STP 4.13.1.13. E. Annex O software plan reviews N.6. 6.10 subcontractor. Fig 12 (see also: software requirements definition.1 Note. N. SDP 5.2 delivery of source files SPS 3 staffing Fig 3. Fig 1. B.1. 6.3. Fig 1. 5. 5.4.x. Foreword-5.3.5. 5. 5. 5. Fig 11.2.2. 5. SDP 4.1. Fig 5-6.9.8. SDP 5.2.13. Fig 11.2.3. 5.8. STD 4.1. 4. SUM 3.1.5 software systems Foreword-1. 5.41.1.12. subcontractor management 1.13. 4.5 system (see also: operational concept) hardware-software systems Introduction.2.2 software products subject to evaluation L.12.5. J. L.x. 1. 5.8 software item requirements 5.5. Fig 11. 3. 5.5.13. Fig 11. SSS 3.2. STrP 3. N.1.2.2.2. 5.2 testing STD.4.1.2. STP.11. Fig 11. Fig 11. O. 5.1. N.3. 5.10.1. 5. SUM 1.2.4 tailoring Foreword-5.3.3. Fig 11 software item qualification testing 3.3. 5.4.1. SDP 1. 5. 5.11. 5.1. 1. SDP 5. 1. Fig 8.8.5. B.1.3 System/Subsystem Design Description (SSDD) 4. 5. Fig 9. Fig 12.3. 5.3.8. 5.11.8 target computer system (testing on) 5. N. 3.6 developer-internal testing 3. 5. Fig 4-7. STR.3.1.5.3.1.4. 5. 5. FSM 1.1. 5.1.3. 3. 3. Fig 12.11. SSDD 5.2.7.4. 4. 5.9.1.4. 5.7.2.1. 6.x.1. 5.3.x. Fig 11 .13. E. 3. SRS 3.9.2.2.1.1. 5.2. 5. 5. N.3. Fig 10 system architectural design 3.2.x. SDP 5.3.11.2.3. SIP 3.1. 4.10.1. 6. IDD 4. 5.3. 4. licensing) user (use of term "user" in this standard) 1.2. Fig 11. 5.3. STP.3.y.17.x. SSS 3.x.4 dry run of qualification testing 5.y. STD 4. SIOM 1.9.3. DBDD 1. 6 training 5.2.1. K. 5. 3. SSDD 4. 3.4.2. OCD 7.1.11. erroneous input.7. 5. STP 4.3.5. L. 5. 4.3. STD.11. Fig 9.11.4 system/subsystem requirements reviews N.2. SSS 4. 5.8. 5. STrP 5.7. SDP 5. 6.2.3.26.1.13.3.4.1.2. Fig 4-7. Fig 11. 5. 3. 5. Fig 11.2.2. 5. Fig 9.3.1.4.1.3. Fig 7 (see also: reengineering) unit (see: software unit) unit integration and testing (see: testing) unit testing (see: testing) usage and ownership rights 4. 5.4. maximum capacity) STP 4.4 system qualification testing 3. L. test descriptions.10.5. 6. SSDD 3. SDP 5.11. 5.4 (see also: licenses. 3.3.3.11.2.5.6.1.3.11.4. Fig 11.2. 6.2.1. H.3.3. SDD 6. Fig 9. STP 3.2. 5.6 target computer system (testing on) 5.6.1.2.1 Note. N.1 Note.7. Fig 12.7.4 system design 3.1. test results) 3. 5.14 maintenance organization training 5.x. 5.1. 4. 5. O. SDP 5.3. 5.11.1. STR.8.13. 5. SSS 1.2.12 software/hardware item integration and testing 4.11.9.1. SDP 5. SCOM 1.3. DBDD 6.6.5.11. N. 5. SDP 5.13.2. SDP 5. SSDD. DBDD 3.13. N. D. 5.6. Fig 9.1.13. 3.5.14. STD 4. STP 6. 5. 5.6.13.1. 6.12.9.J-STD-016-1998 Page 218 5.2. 4.3. SDP 5.1.4 version/revision/release 3. STP 6. Fig 4-7.1. Fig 10. N.2.34.4.3.2. Fig 1. STR 1. N.1 Software Test Report (STR) 5. SDP 5.9.11.2.4. 5. Fig 9. SSS. Fig 9. 5. IDD 4.3. 6. 3.4.7 test results reviews N.1.7 software test planning. Fig 11.4.1.x. K.8 unit integration and testing 4. 4.2.1.1.2.9. 5.7.3.10. 5.7.14.2. Fig 11.y. 5. Fig 11.1.4.3.5.3. STrP 1. Fig 4-7.3.9. IRS 3.3. OCD 1. K. Fig 12 (see also: Interface Requirements Specification.1.13. 5.1. 5.2. 5.28.1.3. IRS 4. 3.1.x. 5.11.1. 5.4. SDP 5.1. SRS 3.11.9. L. 3.5. Fig 10.x. STR 5 traceability 4.2.2.3.1.9.7. 5. Fig 9. 5.7. 5.1.5. 5.8.x. IDD 1. Fig 1. C. 5.11.9.2.3.y. STP 4.8 system requirements 5. Fig 10.4.9. STD 5.11.4.4.11.10. 5.2. Fig 4-7. 5. 3.14. 5. System/Subsystem Specification) system requirements definition 4. STrP 5. 5.1. STrP 3. Fig 11.7. 5. 3. STD. 5. B.1.3.8.3. SDP 5.6. Fig 10. 7. STR 4.7.7.1.4.3.3. Fig 10. G.5.2.10. 4.1.14. 5.1.11.2 revision and retesting 5.5.3.8. Fig 1.y. 3. Fig 4-7.1.3.4. N. 3.3. 5. Fig 11 system/subsystem design reviews N.2. 4. 5.29.15. 5.2.5.1.3.9. F. STP. L.39. Fig 1. 3.9.2. SDP 5. Software Test Plan (STP) 4.11 Note.1.6. Fig 12 test readiness reviews N.2. Fig 12.2 user manuals (see: software user manuals) user organization A.1.y.3. 7 user training 5.5.x. L. STP.8.1. 5. N.10. H.1. 5. Fig 4-7.9.2.2.1. 3.1.4.3. 5. Fig 9. 4. 5.x. Fig 7.11.2.2.2.2.2. 5. 4. SDP 5. 5.2. SDP 5.8 Software Test Description (STD) 4. SDP 5. 3.1.6. N. STP 3.13.9.9.34.3 Note. STR 3.3.3. Fig 1. Fig 11.3.2.4. SDD 1.9. L.4.3. 5.1. 5. Fig 4-8.4. 7.2 witnessed testing 5.2.3. 5.3.3.1.14.9. Fig 1.11. Fig 9.1.3. STR.1.1.1.2. 7.2.7 software test environment 1.13 advance notice of qualification testing 5. Fig 12.1.3. 5.2.3.1.2. Fig 10. SRS 4.3. SSDD 1. Fig 10. Fig 10. 5.5. 4. SPS 1. SDP 5. 5. 5. SSDD 3.3. 5. Fig 4-7.3. SSS 3. Fig 10. SIP 1.3.2. Fig 9.10.1. 5. D. Fig 11.3 System/Subsystem Specification (SSS) 4.7.2.4.4. SSS 3.12. STD.2 unit testing Fig 1. Fig 11. STR.2.10. SDP 5.11.3.3.13. 1.2.9.8.2. STP 5.9.2 test classes (timing.3. Fig 9. 4. 4. 5. SRS 1. 4.3. 5. 4.4. 5.4. 5. SDP 4.3.2. SVD.y test information for developer-internal testing (test cases.1.3.1. Fig 10 transition (of software) (see: software transition) translation 3. Fig 9.1.2. 5. 5.10. SPS 5. Fig 9.4. B. Fig 4-7.3. 5.2. N. test procedures. Fig 11 system test planning 5. SSS 4.7. STP 1. 5. IRS 4. A.3. 5. 5. B.29. STP 6. 5. Fig 4-8.5. 5.28.3.x. 4.7. SDP 5. SDP 5.9. IRS 4.11.1. STD 4.3. STR.2.4.3. Fig 1.1.3. STP system-wide design decisions 3.3.3. 3. 5. 5. 4.5.1. 5.1.4. SIP 3. N.1. C.8 system qualification testing 3.2. L.1. Fig 4-8. Annex A. STD.1. Fig 4-7. STP.2. STP 3.1.4.10.2. Fig 10.x. IRS 1.2. SDP 5.1.2.7.3.