|
(1 Data Item) |
Forms Approved
OMB No. 0704-0188 |
||||||||||||||||||||||
|
Public reporting burden for this collection of information is estimated to average 110 hours per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden to Department of Defense, Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188), Washington DC 20503. Please DO NOT RETURN your form to either of these addresses. Send completed form to the government Issuing Contracting Officer for the Contract/PR No. in Block E.
|
|||||||||||||||||||||||
|
A. CONTRACT LINE ITEM NO.
0002 |
B. EXHIBIT
A |
C: CATEGORY:
TDP __X___ TM OTHER |
|
17. PRICE GROUP | |||||||||||||||||||
|
D. SYSTEM/ITEM
Airborne Laser |
E. CONTRACT/PR NO.
F29601-96-R-0001 |
F. CONTRACTOR |
|
|
|||||||||||||||||||
|
1. DATA ITEM NO.
A009 |
2. TITLE OF DATA ITEM
SYSTEM/SUBSYSTEM SPECIFICATION (SSS) |
3. SUBTITLE
|
|
18. EST TOTAL
PRICE |
|||||||||||||||||||
|
4. AUTHORITY (Data Acquisition Document No.)
DI-IPSC-81431/t and IEEE 1498/EIA640 Figure 29 |
5. CONTRACT REFERENCE
ITAMP Reference to be provided by offeror |
6. REQUIRING OFFICE
SMC/TM |
|
|
|||||||||||||||||||
|
7. DD 250 REQ
LT |
9. DIST STATEMENT
REQUIRED |
10. FREQUENCY
ONCE |
12. DATE OF FIRST SUBMISSION
SEE 16 |
14. DISTRIBUTION | |||||||||||||||||||
| 8. APP CODE A | F | 11. AS OF DATE NONE | 13. DATE OF SUBSEQUENT SUBM. SEE 16 | a. ADDRESSEE |
b. COPIES
final draft reg repr |
||||||||||||||||||
|
16. REMARKS
BLOCK 4:
Para 3.4: Replace the first sentence with "The paragraph shall specify the requirements, if any, imposed on interfaces internal to the system, including both subsystem-to-subsystem interface and interfaces between components within subsystems."
Replace the second sentence with "If all internal interfaces are left to the design or to requirement specifications for system components and/or interfaces, this fact shall be so stated."
Para 3.11 System quality factors. This paragraph shall be divided into the following subparagraphs which specify the applicable requirements pertaining to system quality factors.
Para 3.11.1 Reliability: This paragraph shall specify reliability requirements in quantitative terms and shall define the conditions under which the reliability requirements are to be met. This paragraph may include a reliability apportionment model to support apportionment of reliability values assigned to system capabilities for their share in achieving required system reliability.
Para 3.11.2 Maintainability: This paragraph shall specify quantitative maintainability requirements for the system. The requirements shall apply to maintenance in the planned maintenance and support environments, which shall include at least the organizational environment and the depot environment, and shall be stated in quantitative terms. Examples are:
a. Mean and maximum down time, reaction time, turnaround time, mean and maximum times to repair, mean time between maintenance actions; b. Maximum effort required to locate and remedy an error; c. Maintenance man-hours per specific maintenance action, operational ready rate, maintenance hours per operating hour, frequency of preventive maintenance; d. Number of people, skills levels, and support equipment; and e. Maintenance cost per operating hour. Para 3.11.3 Availability. This paragraph shall specify the degree to which the system shall be in an operable and committable state at the start of the mission(s), where the mission(s) is/are called for at an unknown (random) point in time. Para 3.11.4 Failure/recovery/restoral/degraded operations requirements. This paragraph shall identify possible failures of the system, the consequences of such failures in terms of the system, the consequences of such failures in terms of system performance, and alternative courses of action to be provided to satisfy system requirements. For example, these may include back-up/redundant provisions, fallback on other systems, retention/restoration priorities in the event of degraded operation, restart/recovery provisions, and other measures such as pre-establishment of alternate sites and capability of communications re-routing. Para 3.11.5 Additional quality factors. This paragraph shall specify any other system quality requirements not defined in the above paragraphs, for example, integrity, efficiency, correctness, flexibility (the ability to be easily modify software for a new environment), reusability (the ability to be used in multiple applications), testability (the ability to be easily and thoroughly tested), and usability (the ability to be easily learned and used.) Para 3.12: Replace item (c) with "Physical characteristics of the system (such as weight limits, dimensional limits, color protective coating), interchangeability of parts; ability to be transported from one location to another, and identification of all system elements that, due to operational or functional considerations, will be unsuitable for normal transportation methods; ability to be carried or set up by one, or a given number, of persons." |
|||||||||||||||||||||||
|
G. PREPARED BY
Lt Erik Lund |
H. DATE 01 May 96 | I. APPROVED BY Del R. Patten // Signed // | |||||||||||||||||||||
|
|
SMC/TMS |
|
01 |
|
|||||||||||||||||||
|
|
SMC/TMC |
|
01 |
|
|||||||||||||||||||
|
|
ACO |
|
LT |
|
|||||||||||||||||||
|
|
|
|
|
|
|||||||||||||||||||
|
|
|
|
|
|
|||||||||||||||||||
|
|
|
|
|
|
|||||||||||||||||||
|
|
|
|
|
|
|||||||||||||||||||
|
|
|
|
|
|
|||||||||||||||||||
|
|
|
|
|
|
|||||||||||||||||||
|
|
|
|
|
|
|||||||||||||||||||
|
|
|
|
|
|
|||||||||||||||||||
|
|
|
|
|
|
|||||||||||||||||||
|
|
|
|
|
|
|||||||||||||||||||
|
|
|
|
|
|
|||||||||||||||||||
|
|
|
|
|
|
|||||||||||||||||||
|
|
|
|
|
|
|||||||||||||||||||
|
|
|
|
|
|
|||||||||||||||||||
|
|
|
|
|
|
|||||||||||||||||||
|
|
|
|
|
|
|||||||||||||||||||
|
|
|
|
|
|
|||||||||||||||||||
|
|
15. TOTAL -----> |
0 |
2 |
0 |
|||||||||||||||||||
|
|
|
J. DATE 04 Apr 96 |
|||||||||||||||||||||
BLOCK 4 (Cont.):
Replace item (f) with "Flexibility and expandability that must be provided to support areas of growth or changes in technology, threat, or mission, and identification of system elements that require spare capacity to support flexibility and expansion."
Para 4: Replace items (a) through (e) with the following:
a. Demonstration: Demonstration is the verification method used to verify requirements by exercising or operating the system or a part of the system in which instrumentation or special test equipment is not required beyond that inherently provided in the system being verified. In the demonstration method, sufficient data for requirements verification can be obtained by observing functional operation of the system or a part of the system. When this verification method generates data that is recorded by inherent instrumentation, inherent test equipment or operational procedures, any analysis that must be performed using the data collected during the demonstration is analysis methods of verification described below.
Test: Test is the verification method used to verify requirements by exercising or operating the system or a part of the system using instrumentation (hardware and/or software) or special test equipment that is not an integral part of the system being verified. The test method by its nature generates data, which is recorded by the instrumentation, test equipment, or procedures. Analysis or review is performed on the data derived from the testing. This analysis, as described here, is an integral part of this method and should not be confused with the analysis method of verification described below.
c. Analysis: Analysis is the verification method used to verify requirements by determining qualitative and quantitative properties and performance by studying and examining engineering drawings, software, and hardware flow diagrams, software and hardware specifications, and other software and hardware documentation (e.g., COTS vendor documentation), or by performing modeling, simulation, and/or calculations and analyzing the results. Analysis techniques include interpretation or interpolation/extrapolation of analytical or empirical data under defined conditions or reasoning to show compliance with requirements. Similarity analysis is used in lieu of the test or demonstration methods when it can be shown that an item is similar to or identical in design to another item that has been previously certified to equivalent or more stringent criteria.
d. Inspection: Inspection is the verification method used to verify characteristics by inspecting engineering documentation produced during product development/modification (including both hardware and software documentation) or by inspection of the product itself to verify conformance with specified requirements. Inspection is generally nondestructive and consists of visual inspections or simple measurements without the use of precision measurement equipment. Verification by inspection will include assessment of similarities of subsequent elements to the first item generated based on a common design.
e. Special qualification methods: Special qualification methods include techniques that do not belong to the methods defined in (a) through (d) above, for example, formal proofs.
Para 5: Replace this paragraph with the following: For systems-level specifications, this paragraph shall contain:
a. Traceability from each system requirement in this specification (the SSS) to the requirements(s) in the Technical Requirements Document that it addresses. (Alternatively, this may be provided by annotating each requirement in section 3.)
b. Traceability from each requirement in the TRD to the requirement(s) in the SSS that address it. All TRD requirements shall be accounted for. Those that trace to system requirements contained in interface requirements documents shall reference one or more requirements contained in those documents.
For subsystem-level specifications, this paragraph shall contain:
a. Traceability from each subsystem-level requirement in this specification to the system-level requirements(s) it addresses. (Alternatively, this 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 two subsystems may result in requirements about how the subsystem may result in these interfaces are not covered in system requirements. Such requirement may be traced to a general requirement or to the system design decisions that resulted in their generation.
b. Traceability from each system requirement that has been allocated to the subsystem requirements that address it. All system requirements allocated to the subsystem requirements contained in interface requirements documents shall reference one or more requirements contained in those documents.
BLOCK 9: Distribution Statement F. Further distribution only as directed by ABL SPO or higher DoD authority; 21 Feb 96.
BLOCK 10, 11, 12, & 13: 1st draft is due on DD MMM YY. (To Be Completed By Offeror)
Government will review until DD MMM YY. (To Be Completed By Offeror)
Final report is due on DD MMM YY. (To Be Completed By Offeror)