An interface control document (ICD) in systems engineering [1] and software engineering, provides a record of all interface information (such as drawings, diagrams, tables, and textual information) generated for a project. [2] The underlying interface documents provide the details and describe the interface or interfaces between subsystems or to a system or subsystem.
An ICD is the umbrella document over the system interfaces; examples of what these interface specifications should describe include:
The purpose of the ICD is to control and maintain a record of system interface information for a given project. This includes all possible inputs to and all potential outputs from a system for some potential or actual user of the system. The internal interfaces of a system or subsystem are documented in their respective interface requirements specifications, while human-machine interfaces might be in a system design document (such as a software design document)[ citation needed ].
Interface control documents are a key element of systems engineering as they control the documented interface(s) of a system, as well as specify a set of interface versions that work together, and thereby bound the requirements.
An application programming interface is a form of interface for a software system, in that it describes how to access the functions and services provided by a system via an interface. If a system producer wants others to be able to use the system, an ICD and interface specs (or their equivalent) is a worthwhile investment.
An ICD should only describe the detailed interface documentation itself, and not the characteristics of the systems which use it to connect. The function and logic of those systems should be described in their own requirements and design documents as needed. In this way, independent teams can develop the connecting systems which use the interface specified, without regard to how other systems will react to data and signals which are sent over the interface. For example, the ICD and associated interface documentation must include information about the size, format, and what is measured by the data, but not any ultimate meaning of the data in its intended use by any user.
An adequately defined interface will allow one team to test its implementation of the interface by simulating the opposing side with a simple communications simulator. Not knowing the business logic of the system on the far side of an interface makes it more likely that one will develop a system that does not break when the other system changes its business rules and logic. (Provision for limits or sanity checking should be pointedly avoided in an interface requirements specification.) Thus, good modularity and abstraction leading to easy maintenance and extensibility are achieved.
Software documentation is written text or illustration that accompanies computer software or is embedded in the source code. The documentation either explains how the software operates or how to use it, and may mean different things to people in different roles.
Software testing is the act of checking whether software satisfies expectations.
Software design is the process of conceptualizing how a software system will work before it is implemented or modified. Software design also refers to the direct result of the design process – the concepts of how the software will work which consists of both design documentation and undocumented concepts.
In systems engineering and software engineering, requirements analysis focuses on the tasks that determine the needs or conditions to meet the new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating, and managing software or system requirements.
In engineering, a requirement is a condition that must be satisfied for the output of a work effort to be acceptable. It is an explicit, objective, clear and often quantitative description of a condition to be satisfied by a material, design, product, or service.
In systems engineering, information systems and software engineering, the systems development life cycle (SDLC), also referred to as the application development life cycle, is a process for planning, creating, testing, and deploying an information system. The SDLC concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both. There are usually six stages in this cycle: requirement analysis, design, development and testing, implementation, documentation, and evaluation.
In software project management, software testing, and software engineering, verification and validation is the process of checking that a software engineer system meets specifications and requirements so that it fulfills its intended purpose. It may also be referred to as software quality control. It is normally the responsibility of software testers as part of the software development lifecycle. In simple terms, software verification is: "Assuming we should build X, does our software achieve its goals without any bugs or gaps?" On the other hand, software validation is: "Was X what we should have built? Does X meet the high-level requirements?"
Business process modeling (BPM) is the action of capturing and representing processes of an enterprise, so that the current business processes may be analyzed, applied securely and consistently, improved, and automated.
Technical writing is a specialized form of communication used by many of today's industrial and scientific organizations to clearly and accurately convey complex information to a user. An organization's customers, employees, assembly workers, engineers, and scientists are some of the most common users who reference this form of content to complete a task or research a subject. Most technical writing relies on simplified grammar, supported by easy-to-understand visual communication to clearly and accurately explain complex information.
Reliability engineering is a sub-discipline of systems engineering that emphasizes the ability of equipment to function without failure. Reliability is defined as the probability that a product, system, or service will perform its intended function adequately for a specified period of time, OR will operate in a defined environment without failure. Reliability is closely related to availability, which is typically described as the ability of a component or system to function at a specified moment or interval of time.
MIL-STD-498, Military Standard Software Development and Documentation, was a United States military standard whose purpose was to "establish uniform requirements for software development and documentation." It was released Nov. 8, 1994, and replaced DOD-STD-2167A, DOD-STD-2168, DOD-STD-7935A, and DOD-STD-1703. It was meant as an interim standard, to be in effect for about two years until a commercial standard was developed.
A software design description is a representation of a software design that is to be used for recording design information, addressing various design concerns, and communicating that information to the design’s stakeholders. An SDD usually accompanies an architecture diagram with pointers to detailed feature specifications of smaller pieces of the design. Practically, the description is required to coordinate a large team under a single vision, needs to be a stable reference, and outline all parts of the software and how they will work.
In software engineering, structured analysis (SA) and structured design (SD) are methods for analyzing business requirements and developing specifications for converting practices into computer programs, hardware configurations, and related manual procedures.
A functional specification in systems engineering and software development is a document that specifies the functions that a system or component must perform.
In software development, the V-model represents a development process that may be considered an extension of the waterfall model and is an example of the more general V-model. Instead of moving down linearly, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. The horizontal and vertical axes represent time or project completeness (left-to-right) and level of abstraction, respectively.
A specification often refers to a set of documented requirements to be satisfied by a material, design, product, or service. A specification is often a type of technical standard.
System requirements in spacecraft systems are the specific system requirements needed to design and operate a spacecraft or a spacecraft subsystem.
In systems engineering, software engineering, and computer science, a function model or functional model is a structured representation of the functions within the modeled system or subject area.
The Interaction Flow Modeling Language (IFML) is a standardized modeling language in the field of software engineering. IFML includes a set of graphic notations to create visual models of user interactions and front-end behavior in software systems.
This glossary of computer science is a list of definitions of terms and concepts used in computer science, its sub-disciplines, and related fields, including terms relevant to software, data science, and computer programming.