Source: http://www.htp.gov.in/ParkingZones.html

Tweet This Post Buzz This Post Delicious Digg This Post

eChallan Status

Campaigns

Traffic Police Station of your area

Statistics

Road Rules

Alternate Routes and so on.

Thanks to the entire team of Hyderabad police for this valiant effort that you have put in we are proud of you. Don’t you agree with me friends?

Regards,
Vivekanand Raula

Tweet This Post Buzz This Post Delicious Digg This Post

1. Scope
This section is divided into the following paragraphs.
1.1 Identification
This paragraph shall contain a full identification of the system and the software to which this document applies, including, as applicable, identification number(s), title(s), abbreviation(s), version number(s), and release number(s).
1.2 System overview
This paragraph shall briefly state the purpose of the system and the software to which this document applies. It shall describe the general nature of the system and software; summarize the history of system development, operation, and maintenance; identify the project sponsor, acquirer, user, developer, and support agencies; identify current and planned operating sites; and list other relevant documents.
1.3 Document overview
This paragraph shall summarize the purpose and contents of this manual and shall describe any security or privacy considerations associated with its use.
2. Referenced documents
This section shall list the number, title, revision, and date of all documents referenced in this manual. This section shall also identify the source for all documents not available through normal Government stocking activities.
3. Software summary
This section is divided into the following paragraphs.
3.1 Software application
This paragraph shall provide a brief description of the intended uses of the software. Capabilities, operating improvements, and benefits expected from its use is described.
3.2 Software inventory
This paragraph shall identify the software files, if any, including databases and data files, that the user is responsible for requesting in order to access the software described in this manual. The identification shall include security and privacy considerations for each file and identification of the software necessary to continue or resume operation in case of an emergency.
3.3 Software environment
This paragraph shall identify the hardware, software, manual operations, and other resources needed to access and use the software. This paragraph is 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 must have to access and use the software in that environment. Included, as applicable, is identification of:
a. Computer equipment that must be present, such as terminals, printers, or other input/output devices
b. Communications equipment that must be present
c. Other software that must be present, such as networking software
d. Forms, procedures, or other manual operations that must be present
e. Other facilities, equipment, or resources that must be present
3.4 Software organization and overview of operation
This paragraph shall provide a brief description of the organization and operation of the software from the user’s point of view. The description shall include, as applicable:
a. Logical components of the software, from the user’s point of view, including databases and data files the user can access, Database Management Systems (DBMSs), and communications paths, and an overview of the purpose/operation of each component
b. Performance characteristics that can be expected by the user, such as:
1) Types, volumes, rate of inputs accepted
2) Types, volume, accuracy, rate of outputs that the software can produce
3) Typical response time and factors that affect it
4) Typical processing time and factors that affect it
5) Limitations, e.g, restrictions on what data may be queried and from what location
6) Error rate that can be expected
7) Reliability that can be expected
c. 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
d. Supervisory controls that can be implemented (such as passwords) to manage the software
3.5 Contingencies and alternate states and modes of operation
This paragraph 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, if applicable.
3.6 Security and privacy
This paragraph shall contain an overview of the security and privacy considerations associated with the software. A warning is included regarding making unauthorized copies of software or documents, if applicable.
3.7 Assistance and problem reporting
This paragraph shall identify points of contact and procedures to be followed to obtain assistance and report problems encountered in using the software.
4. Using the software
This section is divided into the following paragraphs to describe how to prepare inputs to, and interpret output from, the software. If the software has a query capability, this paragraph shall reference section 5 for a description of this capability. If the software can be accessed via terminal, this paragraph shall reference Sections 6 through n to describe terminal processing procedures. Safety precautions, marked by WARNING or CAUTION, is included where applicable.
4.1 Initiation procedures
This paragraph shall contain the procedures that must be followed to initiate use of the software. Included may be information such as sample job request forms or sample control statements.
4.2 Description of inputs
This paragraph is divided into the following subparagraphs.
4.2.1 Input conditions
This paragraph shall describe the conditions to be observed in preparing each type or class of input to the software. The conditions shall include the following, as applicable:
a. Reason for input, such as normal status report, need to update data
b. Frequency of input, such as monthly, on demand
c. Origin of input, such as the organization or station authorized to generate the input
d. Medium of input, such as magnetic tape
e. Related inputs that are required to be entered at the same time as this input
f. Other applicable information, such as priority; security and privacy considerations
4.2.2 Input formats
This paragraph shall illustrate the layout formats to be used in the preparation of inputs to the software and shall explain the information that may be entered in the various sections and lines of each format.
4.2.3 Composition rules
This paragraph shall describe any rules and conventions that must be observed to prepare inputs. The rules of syntax, usage of punctuation, and so on., is explained. The rules shall include the following, as applicable:
a. Input transaction length, such as 100 characters maximum
b. Format conventions, such as all input items must be left-justified
c. Labeling, such as usage of identifiers to denote major data sets to the software
d. Sequencing, such as order and placement of items in the input
e. Punctuation, such as spacing and use of symbols (virgule, asterisk, character combina-tions, and so on.) to denote start and end of input, of data groups, and of fields
f. Restrictions, such as rules forbidding use of particular characters or parameter sets
4.2.4 Input vocabulary
This paragraph shall explain the legal character combinations or codes that must be used to prepare inputs. An appendix may be provided containing an ordered listing of these codes.
4.2.5 Sample inputs
This paragraph shall provide examples that illustrate and explain each type or class of input acceptable by the software. Included is information on the following types of inputs, as applicable:
a. Headers denoting the start of input
b. Text or body of the input
c. Trailers denoting the end of input
d. Portions of the input that may be omitted
e. Portions of the input that may be repeated
4.3 Description of outputs
This paragraph is divided into the following subparagraphs.
4.3.1 General description
This paragraph shall provide the following information, as applicable, for each type or class of output:
a. Reasons why the output is generated
b. Frequency of the output, such as monthly, on demand
c. Any modifications or variations of the basic output that are available
d. Media, such as printout, display screen, tape
e. Location where the output will appear, such as in the computer area or remotely
f. Any additional characteristics, such as priority, security and privacy considerations, associated outputs that complement the information in this output
4.3.2 Output formats
This paragraph shall illustrate and explain the layout of each type or class of output from the software. The following aspects are explained, as applicable:
a. Security and privacy markings
b. Data that may appear in headers
c. Information that may appear in the body or text of the output, including column headings and subsets or sections in the output format
d. Data that may appear in trailers
e. Additional characteristics, such as the meaning of special symbols
4.3.3 Sample outputs
This paragraph shall provide illustrations of each type or class of output from the software. A description of each sample is provided, including, as applicable:
a. Meaning and use of each column, entry, and so on.
b. Source, such as extracted from database, calculated
c. Characteristics, such as when omitted, range of values, unit of measure
4.3.4 Output vocabulary
This paragraph shall describe any codes or abbreviations that appear in the output that differ from those used in the input described in paragraph 4.2.4.
4.4 Use of outputs
This paragraph shall explain the use of the output by the operational area or activity that receives it.
4.5 Recovery and error correction procedures
This paragraph shall list the error codes generated by the software, give their meanings, and describe the corrective actions to be taken by the user. Also included are the procedures to be followed by the user with respect to restart, recovery, and continuity of operations in the event of emergencies.
4.6 Communications diagnostics
This paragraph shall describe the diagnostic procedures available to the user for validating communications and for identifying and classifying problems.
5. Query procedures
This section is prepared for software with a query capability. It is divided into the following paragraphs.
5.1 Database/data file format
This paragraph shall provide a user’s view of the format and content of each database and data file that can be queried. Information such as the following is provided for each data element, as applicable:
a. Data element name
b. Synonymous names
c. Definition
d. Format
e. Range and enumeration of values
f. Unit of measurement
g. Data item names, abbreviations, and codes
5.2 Query capabilities
This paragraph shall identify and describe the preprogrammed and ad hoc query capabilities provided by the software.
5.3 Query preparation
This paragraph shall provide instructions for preparing queries.
5.4 Control instructions
This paragraph shall provide instructions for the sequencing of runs and other actions necessary to extract responses to query requests. These instructions shall include control statements that may be required by the computer system or software.
6. User terminal processing procedures
This section is divided into the following paragraphs to provide the user with information on the use of terminals to accomplish processing. If the procedures are complicated or extensive, Sections 7 through n may be added in the same paragraph structure as this section and with titles meaningful to the sections selected. The organization of the document will depend on the characteristics of the software being documented. For example, sections might be based on the organizations in which users work, their assigned positions, work sites, or the tasks they must perform. For other software, it may be more appropriate to have Section 6 be a guide to menus, Section 7 be a guide to the command language, and Section 8 be a guide to functions. Detailed procedures are intended to be presented in paragraphs 6.2 through 6.5. Depending on the design of the software, the subparagraphs might be organized on a function by function, menu by menu, transaction-by-transaction, or other basis. Safety precautions, marked by WARNING or CAUTION, is included where applicable.
6.1 Available capabilities
This paragraph shall describe in general terms the capabilities for retrieval, display, and update of data through terminal operations.
6.2 Access procedures
This paragraph shall present the sequence of steps and any applicable rules pertaining to accessing the software to initiate software operations.
6.3 Display, updates, and retrieval procedures
This paragraph is divided into subparagraphs to provide the step-by-step procedures necessary to produce the displays, updates, and retrievals that are available through the use of a terminal. Each procedure shall include the name of the operation, input formats, and sample responses, as applicable.
6.4 Recovery and error correction procedures
This paragraph shall identify error messages that may be displayed and shall indicate their meanings and any corrective actions that should be taken. Also included are any procedures to be followed by the user with respect to restart, recovery, and continuity of operations in the event of emergencies.
6.5 Termination procedures
This paragraph shall present the sequence of steps necessary to terminate the processing.
7. Notes
This section shall contain any general information that aids in understanding this document (for example, background information, glossary, rationale). This section shall include an alphabetical listing of all acronyms, abbreviations, and their meanings as used in this document and a list of terms and definitions needed to understand this document. If section 6 has been expanded into section(s) 7,…, this section is numbered as the next section following section n.
8. Appendixes
Appendixes may be used to provide information published separately for convenience in document maintenance (for example, charts, classified data). As applicable, each appendix is referenced in the main body of the document where the data would normally have been provided. Appendixes may be bound as separate documents for ease in handling. Appendixes are lettered alphabetically (A, B, and so on.).

Tweet This Post Buzz This Post Delicious Digg This Post

Tweet This Post Buzz This Post Delicious Digg This Post

1. Scope
This section is divided into the following paragraphs.
1.1 Identification
This paragraph shall contain a full identification of the system and the software to which this document applies, including, as applicable, identification number(s), title(s), abbreviation(s), version number(s), and release number(s).
1.2 System overview
This paragraph shall briefly state the purpose of the system and the software to which this document applies. It shall describe the general nature of the system and software; summarize the history of system development, operation, and maintenance; identify the project sponsor, acquirer, user, developer, and support agencies; identify current and planned operating sites; and list other relevant documents.
1.3 Document overview
This paragraph shall summarize the purpose and contents of this document and shall describe any security or privacy considerations associated with its use.
2. Referenced documents
This section shall list the number, title, revision, and date of all documents referenced in this document. This section shall also identify the source for all documents not available through normal Government stocking activities.
3. CSCI-wide design decisions
This section is divided into paragraphs as needed to present CSCI-wide design decisions, that is, decisions about the CSCI’s behavioral design (how it will behave, from a user’s point of view, in meeting its requirements, ignoring internal implementation) and other decisions affecting the selection and design of the software units that make up the CSCI. If all such decisions are explicit in the CSCI requirements or are deferred to the design of the CSCI’s software units, this section shall so state. Design decisions that respond to requirements designated critical, such as those for safety, security, or privacy, is placed in separate subparagraphs. If a design decision depends upon system states or modes, this dependency is indicated. Design conventions needed to understand the design is presented or referenced. Examples of CSCI-wide design decisions are the following:
a. Design decisions regarding inputs the CSCI will accept and outputs it will produce, including interfaces with other systems, HWCIs, CSCIs, and users (4.3.x of this DID identifies topics to be considered in this description). If part or all of this information is given in Interface Design Descriptions (IDDs), they may be referenced.
b. Design decisions on CSCI behavior in response to each input or condition, including actions the CSCI will perform, response times and other performance characteristics, description of physical systems modeled, selected equations/algorithms/rules, and handling of unallowed inputs or conditions.
c. Design decisions on how databases/data files will appear to the user (4.3.x of this DID identifies topics to be considered in this description). If part or all of this information is given in Database Design Descriptions (DBDDs), they may be referenced.
d. Selected approach to meeting safety, security, and privacy requirements.
e. Other CSCI-wide design decisions made in response to requirements, such as selected approach to providing required flexibility, availability, and maintainability.
4. CSCI architectural design
This section is divided into the following paragraphs to describe the CSCI architectural design. If part or all of the design depends upon system states or modes, this dependency is indicated. If design information falls into more than one paragraph, it may be presented once and referenced from the other paragraphs. Design conventions needed to understand the design is presented or referenced.
4.1 CSCI components
This paragraph shall:
a. Identify the software units that make up the CSCI. Each software unit is assigned a project-unique identifier.
Note: A software unit is an element in the design of a CSCI; for example, a major subdivision of a CSCI, a component of that subdivision, a class, object, module, function, routine, or database. Software units may occur at different levels of a hierarchy and may consist of other software units. Software units in the design may or may not have a one-to-one relationship with the code and data entities (routines, procedures, databases, data files, and so on) that implement them or with the computer files containing those entities. A database may be treated as a CSCI or as a software unit. The SDD may refer to software units by any name(s) consistent with the design methodology being used.
b. Show the static (such as “consists of”) relationship(s) of the software units. Multiple relationships may be presented, depending on the selected software design methodology (for example, in an object-oriented design, this paragraph may present the class and object structures as well as the module and process architectures of the CSCI).
c. State the purpose of each software unit and identify the CSCI requirements and CSCI-wide design decisions allocated to it. (Alternatively, the allocation of requirements may be provided in 6.a.)
d. Identify each software unit’s development status/type (such as new development, existing design or software to be reused as is, existing design or software to be reengineered, software to be developed for reuse, software planned for Build N, and so on) For existing design or software, the description shall provide identifying information, such as name, version, documentation references, library, and so on.
e. Describe the CSCI’s (and as applicable, each software unit’s) planned utilization of computer hardware resources (such as processor capacity, memory capacity, input/output device capacity, auxiliary storage capacity, and communications/network equipment capacity). The description shall cover all computer hardware resources included in resource utilization requirements for the CSCI, in system-level resource allocations affecting the CSCI, and in resource utilization measurement planning in the Software Development Plan. If all utilization data for a given computer hardware resource are presented in a single location, such as in one SDD, this paragraph may reference that source. Included for each computer hardware resource is:
1) The CSCI requirements or system-level resource allocations being satisfied
2) The assumptions and conditions on which the utilization data are based (for example, typical usage, worst-case usage, assumption of certain events)
3) Any special considerations affecting the utilization (such as use of virtual memory, overlays, or multiprocessors or the impacts of operating system overhead, library software, or other implementation overhead)
4) The units of measure used (such as percentage of processor capacity, cycles per second, bytes of memory, kilobytes per second)
5) The level(s) at which the estimates or measures will be made (such as software unit, CSCI, or executable program)
f. Identify the program library in which the software that implements each software unit is to be placed
4.2 Concept of execution
This paragraph shall describe the concept of execution among the software units. It includes diagrams and descriptions showing the dynamic relationship of the software units, that is, how they will interact during CSCI operation, including, as applicable, flow of execution control, data flow, dynamically controlled sequencing, state transition diagrams, timing diagrams, priorities among units, handling of interrupts, timing/sequencing relationships, exception handling, concurrent execution, dynamic allocation/deallocation, dynamic creation/deletion of objects, processes, tasks, and other aspects of dynamic behavior.
4.3 Interface design
This paragraph is divided into the following subparagraphs to describe the interface characteristics of the software units. It includes both interfaces among the software units and their interfaces with external entities such as systems, configuration items, and users. If part or all of this information is contained in Interface Design Descriptions (IDDs), in section 5 of the SDD, or elsewhere, these sources may be referenced.
4.3.1 Interface identification and diagrams
This paragraph shall state the project-unique identifier assigned to each interface and shall identify the interfacing entities (software units, systems, configuration items, users, and so on) by name, number, version, and documentation references, as applicable. 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). One or more interface diagrams are provided, as appropriate, to depict the interfaces.
4.3.2 (Project unique identifier of interface)
This paragraph (beginning with 4.3.2) shall identify an interface by project unique identifier, shall briefly identify the interfacing entities, and is divided into subparagraphs as needed to describe the interface characteristics of one or both of the interfacing entities. If a given interfacing entity is not covered by this SDD (for example, an external system) but its interface characteristics need to be mentioned to describe interfacing entities that are, these characteristics is stated as assumptions or as “When [the entity not covered] does this, [the entity that is covered] will . . . .” This paragraph may reference other documents (such as data dictionaries, standards for protocols, and standards for user interfaces) in place of stating the information here. The design description includes the following, as applicable, presented in any order suited to the information to be provided, and shall note any differences in these characteristics from the point of view of the interfacing entities (such as different expectations about the size, frequency, or other characteristics of data elements):
a. Priority assigned to the interface by the interfacing entity(ies)
b. Type of interface (such as real-time data transfer, storage-and-retrieval of data, and so on) to be implemented
c. Characteristics of individual data elements that the interfacing entity(ies) will provide, store, send, access, receive, and so on, such as:
1) Names/identifiers
a) Project-unique identifier
b) Non-technical (natural-language) name
c) DoD standard data element name
d) Technical name (for example, variable or field name in code or database)
e) Abbreviation or synonymous names
2) Data type (alphanumeric, integer, and so on)
3) Size and format (such as length and punctuation of a character string)
4) Units of measurement (such as meters, dollars, nanoseconds)
5) Range or enumeration of possible values (such as 0-99)
6) Accuracy (how correct) and precision (number of significant digits)
7) Priority, timing, frequency, volume, sequencing, and other constraints, such as whether the data element may be updated and whether business rules apply
Security and privacy constraints
9) Sources (setting/sending entities) and recipients (using/receiving entities)
d. Characteristics of data element assemblies (records, messages, files, arrays, displays, reports, and so on) that the interfacing entity(ies) will provide, store, send, access, receive, and so on, such as:
1) Names/identifiers
a) Project-unique identifier
b) Non-technical (natural language) name
c) Technical name (for example, record or data structure name in code or database)
d) Abbreviations or synonymous names
2) Data elements in the assembly and their structure (number, order, 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, layouts, fonts, icons and other display elements, beeps, lights)
5) Relationships among assemblies, such as sorting/access characteristics
6) Priority, timing, frequency, volume, sequencing, and other constraints, such as whether the assembly may be updated and whether business rules apply
7) Security and privacy constraints
Sources (setting/sending entities) and recipients (using/receiving entities)
e. Characteristics of communication methods that the interfacing entity(ies) will use for the interface, 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, whether periodic/aperiodic, and interval between transfers
6) Routing, addressing, and naming conventions
7) Transmission services, including priority and grade
Safety/security/privacy considerations, such as encryption, user authentication, compartmentalization, and auditing
f. Characteristics of protocols that the interfacing entity(ies) will use for the interface, such as:
1) Project-unique identifier(s)
2) Priority/layer of the protocol
3) Packeting, including fragmentation and reassembly, routing, and addressing
4) Legality checks, error control, and recovery procedures
5) Synchronization, including connection establishment, maintenance, termination
6) Status, identification, and any other reporting features
g. Other characteristics, such as physical compatibility of the interfacing entity(ies) (dimensions, tolerances, loads, voltages, plug compatibility, and so on)
5. CSCI detailed design
This section is divided into the following paragraphs to describe each software unit of the CSCI. If part of all of the design depends upon system states or modes, this dependency is indicated. If design information falls into more than one paragraph, it may be presented once and referenced from the other paragraphs. Design conventions needed to understand the design is presented or referenced. Interface characteristics of software units may be described here, in Section 4, or in Interface Design Descriptions (IDDs). Software units that are databases, or that are used to access or manipulate databases, may be described here or in Database Design Descriptions (DBDDs).
5.1 (Project-unique identifier of a software unit, or designator of a group of software units)
This paragraph shall identify a software unit by project-unique identifier and shall describe the unit. The description includes the following information, as applicable. Alternatively, this paragraph may designate a group of software units and identify and describe the software units in subparagraphs. Software units that contain other software units may reference the descriptions of those units rather than repeating information.
a. Unit design decisions, if any, such as algorithms to be used, if not previously selected
b. Any constraints, limitations, or unusual features in the design of the software unit
c. The programming language to be used and rationale for its use if other than the specified CSCI language
d. 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, on-line DBMS queries for database access and manipulation, input to a graphical user interface (GUI) builder for automated code generation, commands to the operating system, or shell scripts), a list of the procedural commands and reference to user manuals or other documents that explain them
e. If the software unit contains, receives, or outputs data, a description of its inputs, outputs, and other data elements and data element assemblies, as applicable. Paragraph 4.3.x of this DID provides a list of topics to be covered, as applicable. Data local to the software unit is described separately from data input to or output from the software unit. If the software unit is a database, a corresponding Database Design Description (DBDD) is referenced; interface characteristics may be provided here or by referencing section 4 or the corresponding Interface Design Description(s).
f. If the software unit contains logic, the logic to be used by the software unit, including, 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, including data conversion, renaming, and data transfer operations
4) Sequence of operations and dynamically controlled sequencing during the software unit’s operation, including:
a) The method for sequence control
b) The logic and input conditions of that method, such as timing variations, priority assignments
c) Data transfer in and out of memory
d) The sensing of discrete input signals, and timing relationships between interrupt operations within the software unit
5) Exception and error handling
6. Requirements traceability
This section shall contain:
a. Traceability from each software unit identified in this SDD to the CSCI requirements allocated to it. (Alternatively, this traceability may be provided in 4.1.)
b. Traceability from each CSCI requirement to the software units to which it is allocated.
7. Notes
This section shall contain any general information that aids in understanding this document (for example, background information, glossary, rationale). This section includes an alphabetical listing of all acronyms, abbreviations, and their meanings as used in this document and a list of any terms and definitions needed to understand this document.
8. Appendixes
Appendixes may be used to provide information published separately for convenience in document maintenance (for example, charts, classified data). As applicable, each appendix is referenced in the main body of the document where the data would normally have been provided. Appendixes may be bound as separate documents for ease in handling. Appendixes is lettered alphabetically (A, B, and so on).

Tweet This Post Buzz This Post Delicious Digg This Post

1. Scope
This section is divided into the following paragraphs.
1.1 Identification
This paragraph shall contain a full identification of the system and software to which this document applies, including, as applicable, identification number(s), title(s), abbreviation(s), version number(s), and release number(s).
1.2 System overview
This paragraph shall briefly state the purpose of the system and the software to which this document applies. It shall describe the general nature of the system and software; summarize the history of system development, operation, and maintenance; identify the project sponsor, acquirer, user, developer, and support agencies; identify current and planned operating sites; and list other relevant documents.
1.3 Document overview
This paragraph shall summarize the purpose and contents of this manual and shall describe any security or privacy considerations associated with its use.
2. Referenced documents
This section shall list the number, title, revision, and date of all documents referenced in this manual. This section shall also identify the source for all documents not available through normal Government stocking activities.
3. Software summary
This section is divided into the following paragraphs.
3.1 Software application
This paragraph shall provide a brief description of the intended uses of the software. Capabilities, operating improvements, and benefits expected from its use is described.
3.2 Software inventory
This paragraph shall identify all software files, including databases and data files, that must be installed for the software to operate. The identification shall include security and privacy considerations for each file and identification of the software necessary to continue or resume operation in case of an emergency.
3.3 Software environment
This paragraph shall identify the hardware, software, manual operations, and other resources needed to install and operate the software. Included, as applicable, is identification of:
a. Computer equipment that must be present, including amount of memory needed, amount of auxiliary storage needed, and peripheral equipment such as terminals, printers, and other input/output devices
b. Communications equipment that must be present
c. Other software that must be present, such as networking software, operating systems, databases, data files, utilities, permanent files that are referenced, created, or updated by the software; and databases/data files necessary to resume operation in the event of emergencies
d. Forms, procedures, or other manual operations that must be present
e. Other facilities, equipment, or resources that must be present
3.4 Software organization and overview of operation
This paragraph shall provide a brief description of the organization and operation of the software from the operator’s point of view. The description shall include, as applicable:
a. Logical components of the software, from the operator’s point of view, and an overview of the purpose/operation of each component
b. Types of inputs/access that can be made to the software and the software’s response to each type
c. The reports and other outputs that are produced by the software, including security and privacy considerations for each
d. Typical run times and factors that affect it
e. Organization of software operation into runs. This description shall use a chart, if applicable, showing how the different operations are interrelated. If sets of runs are grouped by time periods or cycles, each set of integrated operations required on a daily, weekly, etc., basis is presented. If runs may be grouped logically by organizational level, the groups of runs that can be performed by each organizational level such as headquarters processing, field activity processing, etc., is presented.
f. Any system restrictions, waivers of operational standards, information oriented toward specific support areas (for example, library, small computer and teleprocessing support, interfaces with other systems), or other special aspects of processing
g. General description of the communications functions and processes of the software, including, as applicable, a diagram of the communications network used in the system
3.5 Contingencies and alternate states and modes of operation
This paragraph shall explain the differences in software operation at times of emergency and in various states and modes of operation, if applicable.
3.6 Security and privacy
This paragraph shall contain an overview of the security and privacy considerations associated with the software. A warning is included regarding making unauthorized copies of software or documents, if applicable.
3.7 Assistance and problem reporting
This paragraph shall identify points of contact and procedures to be followed to obtain assistance and report problems encountered in operating the software.
4. Installation and setup
This paragraph shall describe any procedures that the operator must perform to install the software on the equipment, to configure the software, to delete or overwrite former files or data, and to enter parameters for software operation. Safety precautions, marked by WARNING or CAUTION, is included where applicable.
5. Description of runs
This section is divided into the following paragraphs to provide a description of the runs to be performed. Safety precautions, marked by WARNING or CAUTION, is included where applicable.
5.1 Run inventory
This paragraph shall provide a list of the runs to be performed, identifying the software and the jobs that make up each run. 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 section.
5.2 Phasing
This paragraph shall describe acceptable phasing of the software into a logical series of operations. A run may be phased to permit manual or semiautomatic checking of intermediate results, to provide the user with intermediate results for other purposes, or to permit a logical break if higher priority jobs are submitted. An example of the minimum division for most systems would be edit, file update, and report preparation.
5.3 Diagnostic procedures
This paragraph shall provide the setup and execution procedures for any software diagnostics. Included is procedures for validation and trouble shooting. All parameters (both input and output), codes, and range values for diagnostic software is explained.
5.4 Error messages
This paragraph shall list all error messages output by the software, along with the meaning and corresponding correction procedure for each message.
5.5 Description of each run
This paragraph is divided into the following subpara-graphs.
5.5.1 Run description for (run name or identifier)
This paragraph shall identify a run and is divided into the following subparagraphs to describe the run.
5.5.1.1 Control inputs
This paragraph shall provide a listing of the run stream of job control statements needed to initiate the run.
5.5.1.2 Run management information
This paragraph shall provide the information needed to manage the run including, as applicable:
a. Peripheral and resource requirements
b. Security and privacy considerations
c. Method of initiation, such as on request, after another run, or at a predetermined time
d. Estimated run time
e. Required turnaround time
f. Messages and responses
g. Procedures for taking check points
h. Waivers from operational standards
5.5.1.3 Input-output files
This paragraph shall provide information about the files and databases that serve as input to or that are created or updated by the run. Included for each is information such as name, security and privacy, recording medium, retention schedule, and disposition.
5.5.1.4 Output reports
This paragraph shall provide information about the reports that are produced during the run. In-cluded for each report is the following information, as applicable: report identifier, product control number, report control symbol, title, security and privacy, media (for example, hard copy, magnetic tape), volume of report, number of copies, and distribution of copies.
5.5.1.5 Reproduced output reports
This paragraph shall provide information about computer-generated reports that are subse-quently reproduced by other means. Included for each report is information such as report identification, security and privacy, reproduction technique, paper size, binding method, number of copies, and distribution of copies.
5.5.1.6 Procedures for restart/recovery and continuity of operations
This paragraph shall provide procedures to be followed by operator personnel concerning re-start/recovery in the event of a system failure and for continuity of operations in the event of emergencies.
6. Notes
This section shall contain any general information that aids in understanding this document (for example, background information, glossary, rationale). This section shall include an alphabetical listing of all acronyms, abbreviations, and their meanings as used in this document and a list of terms and definitions needed to understand this document.
7. Appendixes
Appendixes may be used to provide information published separately for convenience in document maintenance (for example, charts, classified data). As applicable, each appendix is referenced in the main body of the document where the data would normally have been provided. Appendixes may be bound as separate documents for ease in handling. Appendixes are lettered alphabetically (A, B, and so on).

Tweet This Post Buzz This Post Delicious Digg This Post

1. Scope
This section is divided into the following paragraphs.
1.1 Identification
This paragraph shall contain a full identification of the system to which this document applies, including, as applicable, identification number(s), title(s), abbreviation(s), version number(s), and release number(s).
1.2 System overview
This paragraph shall briefly state the purpose of the system to which this document applies. It shall describe the general nature of the system; summarize the history of system development, operation, and maintenance; identify the project sponsor, acquirer, user, developer, and support agencies; identify current and planned operating sites; and list other relevant documents.
1.3 Document overview
This paragraph shall summarize the purpose and contents of this document and shall describe any security or privacy considerations associated with its use.
2. Referenced documents
This section shall list the number, title, revision, and date of all documents referenced in this document. This section shall also identify the source for all documents not available through normal Government stocking activities.
3. Current system or situation
This section is divided into the following paragraphs to describe the system or situation as it currently exists.
3.1 Background, objectives, and scope
This paragraph shall describe the background, mission or objectives, and scope of the current system or situation.
3.2 Operational policies and constraints
This paragraph shall describe any operational policies and constraints that apply to the current system or situation.
3.3 Description of current system or situation
This paragraph shall provide a description of the current system or situation, identifying differences associated with different states or modes of operation (for example, regular, mainte-nance, training, degraded, emergency, alternative-site, wartime, peacetime). The distinction between states and modes is arbitrary. A system may be described in terms of states only, modes only, states within modes, modes within states, or any other scheme that is useful. If the system operates without states or modes, this paragraph shall so state, without the need to create artificial distinctions. The description shall include, as applicable:
a. The operational environment and its characteristics
b. Major system components and the interconnections among these components
c. Interfaces to external systems or procedures
d. Capabilities/functions of the current system
e. Charts and accompanying descriptions depicting inputs, outputs, data flow, and manual and automated processes sufficient to understand the current system or situation from the user’s point of view
f. Performance characteristics, such as speed, throughput, volume, frequency
g. Quality attributes, such as reliability, maintainability, availability, flexibility, portability, usability, efficiency
h. Provisions for safety, security, privacy, and continuity of operations in emergencies
3.4 Users or involved personnel
This paragraph shall describe the types of users of the system, or personnel involved in the current situation, including, as applicable, organizational structures, training/skills, responsibili-ties, activities, and interactions with one another.
3.5 Support concept
This paragraph shall provide an overview of the support concept for the current system, including, as applicable to this document, support agency(ies); facilities; equipment; support software; repair/replacement criteria; maintenance levels and cycles; and storage, distribution, and supply methods.
4. Justification for and nature of changes
This section is divided into the following paragraphs.
4.1 Justification for change
This paragraph shall:
a. Describe new or modified aspects of user needs, threats, missions, objectives, environ-ments, interfaces, personnel or other factors that require a new or modified system
b. Summarize deficiencies or limitations in the current system or situation that make it unable to respond to these factors
4.2 Description of needed changes
This paragraph shall summarize new or modified capabilities/functions, processes, interfaces, or other changes needed to respond to the factors identified in 4.1.
4.3 Priorities among the changes
This paragraph shall identify priorities among the needed changes. It shall, for example, identify each change as essential, desirable, or optional, and prioritize the desirable and optional changes.
4.4 Changes considered but not included
This paragraph shall identify changes considered but not included in 4.2, and rationale for not including them.
4.5 Assumptions and constraints
This paragraph shall identify any assumptions and constraints applicable to the changes identified in this section.
5. Concept for a new or modified system
This section is divided into the following paragraphs to describe a new or modified system.
5.1 Background, objectives, and scope
This paragraph shall describe the background, mission or objectives, and scope of the new or modified system.
5.2 Operational policies and constraints
This paragraph shall describe any operational policies and constraints that apply to the new or modified system.
5.3 Description of the new or modified system
This paragraph shall provide a description of the new or modified system, identifying differences associated with different states or modes of operation (for example, regular, mainte-nance, training, degraded, emergency, alternative-site, wartime, peacetime). The distinction between states and modes is arbitrary. A system may be described in terms of states only, modes only, states within modes, modes within states, or any other scheme that is useful. If the system operates without states or modes, this paragraph shall so state, without the need to create artificial distinctions. The description shall include, as applicable:
a. The operational environment and its characteristics
b. Major system components and the interconnections among these components
c. Interfaces to external systems or procedures
d. Capabilities/functions of the new or modified system
e. Charts and accompanying descriptions depicting inputs, outputs, data flow, and manual and automated processes sufficient to understand the new or modified system or situation from the user’s point of view
f. Performance characteristics, such as speed, throughput, volume, frequency
g. Quality attributes, such as reliability, maintainability, availability, flexibility, portability, usability, efficiency
h. Provisions for safety, security, privacy, and continuity of operations in emergencies
5.4 Users/affected personnel
This paragraph shall describe the types of users of the new or modified system, including, as applicable, organizational structures, training/skills, responsibilities, and interactions with one another.
5.5 Support concept
This paragraph shall provide an overview of the support concept for the new or modified system, including, as applicable, support agencies); facilities; equipment; support software; repair/replacement criteria; maintenance levels and cycles; and storage, distribution, and supply methods.
6. Operational scenarios
This section shall describe one or more operational scenarios that illustrate the role of the new or modified system, its interaction with users, its interface to other systems, and all states or modes identified for the system. The scenarios shall include events, actions, stimuli, information, interactions, etc., as applicable. Reference may be made to other media, such as videos, to provide part or all of this information.
7. Summary of impacts
This section is divided into the following paragraphs.
7.1 Operational impacts
This paragraph shall describe anticipated operational impacts on the user, acquirer, developer, and support agencies. These impacts may include changes in interfaces with computer operating centers; change in procedures; use of new data sources; changes in quantity, type, and timing of data to be input to the system; changes in data retention requirements; and new modes of operation based on peacetime, alert, wartime, or emergency conditions.
7.2 Organizational impacts
This paragraph shall describe anticipated organizational impacts on the user, acquirer, developer, and support agencies. These impacts may include modification of responsibili-ties; addition or elimination of responsibilities or positions; need for training or retraining; and changes in number, skill levels, position identifiers, or location of personnel in various modes of operation.
7.3 Impacts during development
This paragraph shall describe anticipated impacts on the user, acquirer, developer, and support agency(ies) during the development effort. These impacts may include meetings/discussions regarding the new system; development or modification of databases; training; parallel operation of the new and existing systems; impacts during testing of the new system; and other activities needed to aid or monitor development.
8. Analysis of the proposed system

8.1 Summary of advantages
This paragraph shall provide a qualitative and quantitative summary of the advantages to be obtained from the new or modified system. This summary shall include new capabilities, enhanced capabilities, and improved performance, as applicable, and their relationship to deficiencies identified in 4.1.
8.2 Summary of disadvantages/limitations
This paragraph shall provide a qualitative and quantitative summary of disadvantages or limitations of the new or modified system. These disadvantages and limitations shall include, as applicable, degraded or missing capabilities, degraded or less-than-desired performance, greater-than-desired use of computer hardware resources, undesirable operational impacts, conflicts with user assumptions, and other constraints.
8.3 Alternatives and trade-offs considered
This paragraph shall identify and describe major alternatives considered to the system or its characteristics, the trade-offs among them, and rationale for the decisions reached.
9. Notes
This section shall contain any general information that aids in understanding this document (for example, background information, glossary, and rationale). This section shall include an alphabetical listing of all acronyms, abbreviations, and their meanings as used in this document and a list of any terms and definitions needed to understand this document.
10. Appendixes
Appendixes may be used to provide information published separately for convenience in document maintenance (for example, charts, classified data). As applicable, each appendix is referenced in the main body of the document where the data would normally have been provided. Appendixes may be bound as separate documents for ease in handling. Appendixes are lettered alphabetically (A, B, and so on).

Tweet This Post Buzz This Post Delicious Digg This Post

Then go through below link to get online status
http://59.90.212.185:8787/publicview/

Tweet This Post Buzz This Post Delicious Digg This Post

1. Scope
This section shall be divided into the following paragraphs.

1.1 Identification
This paragraph shall contain a full identification of the systems, the interfacing entities, and the interfaces to which this document applies, including, as applicable, identification number(s), title(s), abbreviation(s), version number(s), and release number(s).

1.2 System Overview
This paragraph shall briefly state the purpose of the system(s) and software to which this document applies. It shall describe the general nature of the system and software; summarize the history of system development, operation, and maintenance; identify the project sponsor, acquirer, user, developer, and support agencies; identify current and planned operating sites; and list other relevant documents.

1.3 Document Overview
This paragraph shall summarize the purpose and contents of this document and shall describe any security or privacy considerations associated with its use.

2. Referenced Documents
This section shall list the number, title, revision, and date of all documents referenced in this specification. This section shall also identify the source for all documents not available through normal Government stocking activities.

3. Requirements
This section shall be divided into the following paragraphs to specify the requirements imposed on one or more systems, subsystems, configuration items, manual operations, or other system components to achieve one or more interfaces among these entities. 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. Each requirement shall be annotated with associated qualification method(s) (see section 4) and traceability to system (or subsystem, if applicable) requirements (see section 5.a) if not provided in those sections. 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; defer to design descriptions those characteris¬tics that the acquirer is willing to leave up to the developer. If a given requirement fits into more than one paragraph, it may be stated once and referenced from the other paragraphs. If an interfacing entity included in this specification will operate in states and/or modes having interface requirements different from other states and modes, each requirement or group of requirements for that entity shall be correlated to the states and modes. The correlation may be indicated by a table or other method in this paragraph, in an appendix referenced from this paragraph, or by annotation of the requirements in the paragraphs where they appear.

3.1 Interface Identification and Diagrams
For each interface identified in 1.1, this paragraph shall include a project-unique identifier and shall designate the interfacing entities (systems, configuration items, users, and so on.) by name, number, version, and documentation references, as applicable. 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). One or more interface diagrams shall be provided to depict the interfaces.

3.2 (Project Unique Identifier of Interface)
This paragraph (beginning with 3.2) shall identify an interface by project unique identifier, shall briefly identify the interfacing entities, and shall be divided into subparagraphs as needed to state the requirements imposed on one or more of the interfacing entities to achieve the interface. 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, those characteristics shall be stated as assumptions or as “When [the entity not covered] does this, the [entity being specified] shall…,” rather than as requirements on the entities not covered by this IRS. This paragraph may reference other documents (such as data dictionaries, standards for communication protocols, and standards for user interfaces) in place of stating the information here. The requirements shall include the following, as applicable, presented in any order suited to the requirements, and shall note any differences in these characteristics from the point of view of the interfacing entities (such as different expectations about the size, frequency, or other characteristics of data elements):

a. Priority that the interfacing entity(ies) must assign the interface
b. Requirements on the type of interface (such as real-time data transfer, storage-and-retrieval of data, and so on.) to be implemented
c. Required characteristics of individual data elements that the interfacing entity(ies) must provide, store, send, access, receive, and so on., such as:

1. Names/identifiers

a. Project-unique identifier
b. Non-technical (natural-language) name
c. DoD standard data element name
d. Technical name (for example, variable or field name in code or database)
e. Abbreviation or synonymous names

2. Data type (alphanumeric, integer, and so on.)
3. Size and format (such as length and punctuation of a character string)
4. Units of measurement (such as meters, dollars, nanoseconds)
5. Range or enumeration of possible values (such as 0-99)
6. Accuracy (how correct) and precision (number of significant digits)
7. Priority, timing, frequency, volume, sequencing, and other constraints, such as whether the data element may be updated and whether business rules apply
8. Security and privacy constraints
9. Sources (setting/sending entities) and recipients (using/receiving entities)

d. Required characteristics of data element assemblies (records, messages, files, arrays, displays, reports, and so on.) that the interfacing entity(ies) must provide, store, send, access, receive, and so on., such as:

1. Names/identifiers

a. Project-unique identifier
b. Non-technical (natural language) name
c. Technical name (for example, record or data structure name in code or database)
d. Abbreviations or synonymous names

2. Data elements in the assembly and their structure (number, order, 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, layouts, fonts, icons and other display elements, beeps, lights)
5. Relationships among assemblies, such as sorting/access characteristics
6. Priority, timing, frequency, volume, sequencing, and other constraints, such as whether the assembly may be updated and whether business rules apply
7. Security and privacy constraints
8. Sources (setting/sending entities) and recipients (using/receiving entities)

e. Required characteristics of communication methods that the interfacing entity(ies) must use for the interface, 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, whether periodic/aperiodic, and interval between transfers
6. Routing, addressing, and naming conventions
7. Transmission services, including priority and grade
8. Safety/security/privacy considerations, such as encryption, user authentication, compartmentalization, and auditing

f. Required characteristics of protocols the interfacing entity(ies) must use for the interface, such as:

1. Project-unique identifier(s)
2. Priority/layer of the protocol
3. Packeting, including fragmentation and reassembly, routing, and addressing
4. Legality checks, error control, and recovery procedures
5. Synchronization, including connection establishment, maintenance, termination
6. Status, identification, and any other reporting features

g. Other required characteristics, such as physical compatibility of the interfacing entities (dimensions, tolerances, loads, plug compatibility, and so on.), voltages, and so on.

3.3 Precedence and criticality of requirements
This paragraph shall be numbered as the last paragraph in Section 3 and shall specify, if applicable, the order of precedence, criticality, or assigned weights indicating the relative importance of the requirements in this specification. Examples include identifying those requirements deemed critical to safety, to security, or to privacy for purposes of singling them out for special treatment. If all requirements have equal weight, this paragraph shall so state.

4. Qualification provisions
This section shall define a set of qualification methods and shall specify, for each requirement in Section 3, the qualification method(s) to be used to ensure that the requirement has been met. A table may be used to present this information, or each requirement in Section 3 may be annotated with the method(s) to be used. Qualification methods may include:

a. Demonstration: The operation of interfacing entities that relies on observable functional operation not requiring the use of instrumentation, special test equipment, or subsequent analysis.
b. Test: The operation of interfacing entities using instrumentation or special test equipment to collect data for later analysis.
c. Analysis: The processing of accumulated data obtained from other qualification methods. Examples are reduction, interpretation, or extrapolation of test results.
d. Inspection: The visual examination of interfacing entities, documentation, and so on.
e. Special qualification methods: Any special qualification methods for the interfacing entities, such as special tools, techniques, procedures, facilities, and acceptance limits.

5. Requirements Traceability
For system-level interfacing entities, this paragraph does not apply. For each subsystem- or lower-level interfacing entity covered by this IRS, this paragraph shall contain:

a. Traceability from each requirement imposed on the entity in this specification to the system (or subsystem, if applicable) requirements it addresses. (Alternatively, this traceability may be provided by annotating each requirement in Section 3.)

Note: Each level of system refinement may result in requirements not directly traceable to higher-level requirements. For example, a system architectural design that creates multiple CSCIs may result in requirements about how the CSCIs will interface, 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.

b. Traceability from each system (or subsystem, 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.

6. Notes
This section shall contain any general information that aids in understanding this document (for example, background information, glossary, rationale). This section shall include an alphabetical listing of all acronyms, abbreviations, and their meanings as used in this document and a list of any terms and definitions needed to under¬stand this document.

7. Appendixes
Appendixes may be used to provide information published separately for convenience in document maintenance (for example, charts, classified data). As applicable, each appendix shall be refer¬enced in the main body of the document where the data would normally have been provided. Appendixes may be bound as separate documents for ease in handling. Appendixes shall be lettered alphabeti¬cally (A, B, and so on).

Tweet This Post Buzz This Post Delicious Digg This Post

The IDD is used to supplement the System/Subsystem Design Description (SSDD), Software Design Description (SDD), and Database Design Description (DBDD). The IDD and its companion Interface Requirements Specification (IRS) serve to communicate and control interface design decisions.

1. Scope
This section is divided into the following sub-sections.

1.1 Identification
This sub-section contains a full identification of the system(s), the interfacing entities, and interfaces to which this document applies, including, as applicable, identification number(s), title(s), abbreviation(s), version number(s), and release number(s).

1.2 System Overview
This sub-section briefly states the purpose of the system(s) and software to which this document applies. It describes the general nature of the system and software; summarize the history of system development, operation, and maintenance; identify the project sponsor, acquirer, user, developer, and support agencies; identify current and planned operating sites; and list other relevant documents.

1.3 Document Overview
This sub-section summarizes the purpose and contents of this document and describes any security or privacy considerations associated with its use.

2. Referenced Documents
This section lists the number, title, revision, and date of all documents referenced in this document. This section also identifies the source for all documents not available through normal Government stocking activities.

3. Interface Design
This section is divided into the following sub-sections to describe the interface characteristics of one or more systems, subsystems, configuration items, manual operations, or other system components. If part or all of the design depends upon system states or modes, this dependency is indicated. If design information falls into more than one sub-section, it is presented once and referenced from the other sub-sections. If part or all of this information is documented elsewhere, it is referenced. Design conventions needed to understand the design are presented or referenced.

3.1 Interface Identification and Diagrams
For each interface identified in 1.1, this sub-section states the project-unique identifier assigned to the interface and identifies the interfacing entities (systems, configuration items, users, and so on.) by name, number, version, and documentation references, as applicable. The identification states 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). One or more interface diagrams are provided, as appropriate, to depict the interfaces.

3.2 (Project Unique Identifier of Interface)
This sub-section (beginning with 3.2) identifies an interface by project unique identifier, briefly identifies the interfacing entities, and is divided into sub-sections as needed to describe the interface characteristics of one or both of the interfacing entities. If a given interfacing entity is not covered by this IDD (for example, an external system) but its interface characteristics need to be mentioned to describe interfacing entities that are, these characteristics are stated as assumptions or as “When [the entity not covered] does this, [the entity that is covered] will ….” This sub-section may reference other documents (such as data dictionaries, standards for protocols, and standards for user interfaces) in place of stating the information here. The design description includes the following, as applicable, presented in any order suited to the information to be provided, and shall note any differences in these characteristics from the point of view of the interfacing entities (such as different expectations about the size, frequency, or other characteristics of data elements):

a. Priority assigned to the interface by the interfacing entity(ies)
b. Type of interface (such as real-time data transfer, storage-and-retrieval of data, and so on) to be implemented
c. Characteristics of individual data elements that the interfacing entity(ies) will provide, store, send, access, receive, and so on such as:

1. Names/identifiers

a) Project-unique identifier
b) Non-technical (natural-language) name
c) DoD standard data element name
d) Technical name (for example, variable or field name in code or database)
e) Abbreviation or synonymous names

2. Data type (alphanumeric, integer, and so on)
3. Size and format (such as length and punctuation of a character string)
4. Units of measurement (such as meters, dollars, nanoseconds)
5. Range or enumeration of possible values (such as 0-99)
6. Accuracy (how correct) and precision (number of significant digits)
7. Priority, timing, frequency, volume, sequencing, and other constraints, such as whether the data element may be updated and whether business rules apply
8. Security and privacy constraints
9. Sources (setting/sending entities) and recipients (using/receiving entities)

d. Characteristics of data element assemblies (records, messages, files, arrays, displays, reports, and so on) that the interfacing entities will provide, store, send, access, receive, and so on, such as:

1. Names/identifiers

a) Project-unique identifier
b) Non-technical (natural language) name
c) Technical name (for example, record or data structure name in code or database)
d) Abbreviations or synonymous names

2. Data elements in the assembly and their structure (number, order, 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, layouts, fonts, icons and other display elements, beeps, lights)
5. Relationships among assemblies, such as sorting/access characteristics
6. Priority, timing, frequency, volume, sequencing, and other constraints, such as whether the assembly may be updated and whether business rules apply
7. Security and privacy constraints
8. Sources (setting/sending entities) and recipients (using/receiving entities)

e. Characteristics of communication methods that the interfacing entities will use for the interface, 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, whether periodic/aperiodic, and interval between transfers
6. Routing, addressing, and naming conventions
7. Transmission services, including priority and grade
8. Safety/security/privacy considerations, such as encryption, user authentication, compartmentalization, and auditing

f. Characteristics of protocols the interfacing entity(ies) will use for the interface, such as:

1. Project-unique identifier(s)
2. Priority/layer of the protocol
3. Packeting, including fragmentation and reassembly, routing, and addressing
4. Legality checks, error control, and recovery procedures
5. Synchronization, including connection establishment, maintenance, termination
6. Status, identification, and any other reporting features

g. Other characteristics, such as physical compatibility of the interfacing entity(ies) (dimensions, tolerances, loads, voltages, plug compatibility, etc.)

4. Requirements Traceability
This sub-section contains:

a. Traceability from each interfacing entity covered by this IDD to the system or CSCI requirements addressed by the entity’s interface design.
b. Traceability from each system or CSCI requirement that affects an interface covered in this IDD to the interfacing entities that address it.

5. Notes
This section contains any general information that aids in understanding this document (for example, background information, glossary, rationale). This section includes an alphabetical listing of all acronyms, abbreviations, and their meanings as used in this document and a list of any terms and definitions needed to understand this document.

6. Appendixes
Appendixes may be used to provide information published separately for convenience in document maintenance (for example, charts, classified data). As applicable, each appendix shall be referenced in the main body of the document where the data would normally have been provided. Appendixes may be bound as separate documents for ease in handling. Appendixes are lettered alphabetically (A, B, and so on).

Tweet This Post Buzz This Post Delicious Digg This Post