The title of this page has been changed. If you are using a bookmark to get here, please updated it.
You should be redirected to https://swehb.nasa.gov/display/SWEHBVC/5.02+-+IDD+-+Interface+Design+Description. If you do not get there in 2 seconds, click the link to go there.
Return to 7.18 - Documentation Guidance Minimum recommended content for the Interface Design Description. The Interface Design Description (IDD) describes the interface characteristics of one or more systems, subsystems, Hardware Configuration Items (HWCIs), Computer Software Configuration Items (CSCIs), manual operations, or other system components. Typical NASA development projects are complex, multi-disciplined activities that consist of systems and systems of systems. These projects usually require integrated product teams working together to achieve the goals and objectives in a timely and cost-efficient manner. The execution of the software development life cycle and its activities by the team requires multiple tasks and work products to be developed and accomplished in parallel. To assure that the assembled systems and integrated systems function as intended, the interfaces for the software work products (components) and systems must be accurately defined, designed, controlled, and communicated. A high-quality IDD document fulfills these needs for the software development team. The software IDD document may be a stand-alone entity or part of the Software Design Description document or part of an electronic data system. Center policies and procedures are expected to be followed when determining which documentation approach is suitable for a particular project. It is important that the interface design information be identified and tracked as the software system is being developed, tested, and operated. Software interface designs and requirements tend to drive software designs and can lead to a potential source of anomalies during the development and operational life cycle. The key to implementing this requirement is to have a good description of all software, hardware, operations, and system interfaces and interactions during the design and operational phases of a development cycle. The content of the IDD is defined by PDR (Preliminary Design Review). The preliminary IDDs are expected to be approximately 30 percent completed at PDR. All interface components are to be defined by PDR. The IDDs are completed by CDR (Critical Design Review) and updated as needed after CDR. The final as-built IDD is documented as a part of the as-built design documentation for operational use, software modification, and potential software reuse applications. The software development team is responsible for preparing an IDD that describes the interface entity characteristics for all defined systems, subsystems, domains, hardware items, software items, manual operations, and other system components. The descriptions contain the interface characteristics for systems or configuration items that participate in the interface (including human-system and human-human interfaces), standards and protocols, responsible parties, interface operational schedules, and any error handling routines. The software team also defines those interface characteristics that are existing or permanent, as well as those that are being developed or modified. The applicability of this requirement is highly dependent on the classification level for the software work product(s). Appendix C, Requirements Mapping Matrix, of NPR 7150.2 shows the requirements for each classification level (see SWE-020 - Software Classification). An excellent way to begin the descriptions of the interfaces is with a context or state diagram. A suitably detailed diagram (showing the relationship of the interface with the overall activity) with legends and callouts will easily show the dependencies that must be controlled and satisfied in the software detailed design. Either a single diagram or an interrelated set of diagrams, depending on the complexity of the software work product(s), may be the most appropriate choice. As shown in the text above, the software IDD document is recommended to contain specific information. NASA-specific interface design description information and resources are available in Software Processes Across NASA (SPAN), accessible to NASA users from the SPAN tab in this Handbook. Below are suggestions for the type of information to consider for the named content. Document content The following paragraphs are based on Department of Defense (DoD) DI-IPSC-81436A, Data Item Description Interface Design Description (IDD) 025, along with supporting material from GRC (Glenn Research Center) GRC-SW-TPLT-IDD, Interface Design Description (IDD) Template. Factors like functionality, performance speed, the time needed to use the program, user satisfaction, and the rate of user errors are some criteria for the software development team to consider when designing an interface. The software interface tests are specified in the Software Test Plan. The two most common ways of expressing interface information are (1) alphabetically by parameter and (2) for data-oriented interfaces, by layers with reference to a level-of-abstraction model such as the Open Systems Interconnection (OSI)-7 Layer model. 303 In the latter case, individual information items (e.g., requirements or characteristics) are framed consistent with the layer definitions and then specified by layer, "physical" up to "application" in that order of the OSI-7 Layer model. Within a layer, control flow sequence is used where applicable to express information; otherwise it is expressed alphabetically by parameter. Additional analysis, testing, or a combination thereof can be performed to verify safety-critical OTS or reused software to the same level required of in-house developed software to the extent possible via black box testing. The Contract Data Requirements List specifies whether deliverable data are to be delivered on paper or electronic media; may be delivered in developer format rather than in the format specified herein; and may reside in a computer-aided software engineering or other automated tool rather than in the form of a traditional document. Best practices The software development team solicits relevant stakeholder involvement to evaluate applicable system interface(s). Whenever possible, the software development team considers using an industry recognized standard for system interfaces. The proper execution of interfaces among entities in software design activities is no less important for small projects than for large projects. Improper interface development, evaluation, and testing will cause any software work product to fail to function, regardless of the size of the project. Smaller projects may benefit by using standard interface designs or Interface Design Description (IDD) templates previously developed and cataloged in software reuse repositories or by using personnel with previous experience on identical or similar interfaces. Where applicable, information may be duplicated from IDDs written for previously developed software interfaces. Extreme care is used whenever deciding to reuse software. (See SWE-027 - Use of Commercial, Government, and Legacy Software for information that may be applicable.) (See the Center's repository of best practices for additional guidance in this area (see SWE-144 - Software Engineering Process Assets.) NASA users find this in the Tools Library in the Software Processes Across NASA (SPAN) site of the Software Engineering Community in NEN. The list is informational only and does not represent an “approved tool list”, nor does it represent an endorsement of any particular tool. The purpose is to provide examples of tools being used across the Agency and to help projects and centers decide what tools to consider. No other Lessons Learned have currently been identified for this requirement.
See edit history of this section
Post feedback on this section
1. Minimum Recommended Content
2. Rationale
3. Guidance
This is the priority assigned to the interface by the interfacing entity(ies).The level of the priority allows the software to service higher priority queues ahead of lower priority queues. Complex priority values may allow timeouts and software interrupts to avoid the starving of lower priority interfaces.
The IDD document includes characteristics about interface types, such as real-time data transfer, storage-and-retrieval of data, remote programming interface, etc., that will be implemented.
The IDD document includes characteristics about the individual data elements that the interfacing entity(ies) will provide, store, send, access, receive, etc., such as:
The IDD document includes characteristics about data element assemblies, such as records, messages, files, arrays, displays, reports, etc., that the interfacing entity(ies) will provide, store, send, access, receive, etc., such as:
The IDD document includes characteristics about communication methods that the interfacing entity(ies) will use for the interface, such as:
The IDD document includes characteristics about digital message formats and the rules for exchanging those messages. A protocol defines the syntax, semantics, and synchronization of communication, and the specified behavior is typically independent of how it is to be implemented. A protocol can therefore be implemented as hardware or software or both. Characteristics of protocols the interfacing entity(ies) will use for the interface include:
Physical compatibility of the interfacing entity(ies) (dimensions, tolerances, loads, voltages, plug compatibility, etc.).
Show the path from each interfacing entity to the system or CSCI (Computer Software Configuration Item) requirement addressed by the design. To complete the bidirectional tracing of the requirements, show from each system or CSCI requirement to the interfacing entity that addresses it.
The IDD document contains information about the intended compatibility between or among the interfaces being developed. Specifically, will there be uniform or optional approaches to developing weak versus strong compatibility? Will the compatibility of the software components' interaction with their environment be characterized as optimistic or pessimistic in nature?
Safety-critical off-the-shelf (OTS) and reused software must undergo safety analysis that considers:4. Small Projects
5. Resources
5.1 References
5.2 Tools
6. Lessons Learned
6.1 NASA Lessons Learned
6.2 Other Lessons Learned