From Throw Away to Persistent: the Future of Requirements Traceability in the USAF

1. Approved for Public Release; Distribution Unlimited. Case #: 08-1409 From Throw Away to Persistent: the Future of Requirements Traceability in the USAF Cheryl Connors cconnors@mitre.org Deborah Hawley dhawley@mitre.org The MITRE Corporation 3 Oct 2008

2. Disclaimers • The views, opinions and conclusions expressed in this talk are those of the co-authors and should not be construed as an official position of the United States Department of Defense (DoD) nor of the MITRE Corporation. • All information presented here is unclassified, technically accurate, contains no critical military technology and is not subject to export controls.

3. Outline • Background • Information Exchange Requirements (IERs) • DoD Net-Centric Vision • Emergence of SOA • DoD movement away from boxes to services • Sponsor focus on requirements • IER Repository • Benefits • Summary

4. Background • The Air Force is adopting a web-based, Service Oriented Architecture (SOA) methodology for exchanging critical information • The Global Cyberspace Integration Center (GCIC)/RIN is responsible for helping the Air Force manage their Information Exchange Requirements (IERs): • Support changes to military standards • Coordinate with other Armed Services, Government Agencies and international bodies (NATO) • General concepts can be applied to commercial efforts

5. Requirements Focus • Military purchases occur after there is a requirement • Systems include hardware and software that have to be purchased, so requirements are needed to be defined and documented • Our focus is on the IERs that are exchanged between military systems

6. What are IERs? Position Updates Sensor Data Position Updates Sensor Data Mission Update Tasking Sensor Data Mission Update Tasking Sensor Data • Describe the exchange of information between objects Position Updates Sensor Data Joint STARS F-22 B-2 AOC

7. “Simplified” View of Military Data Exchanges

8. Managing IERs • New IERs are constantly being developed • Military management process will review, approve, and incorporate into a message standard like Link 16 • Then original IERs “fade away” - not persisted once “satisfied” • System implementation of requirements documented for some message standards, but not all Name/Parts Order 1/aircraft/F-16/engine 2/aircraft/F-16/pitot-static/left ... Faux message Standard Standard

9. Now for Something Completely Different • So far, we’ve talked about traditional management of military requirements for information exchange • Acquisition processes will continue for IERs • However, the impact of web-based technologies and DoD vision requires new acquisition approach for the military • Next slides discuss the major factors that have forced this change • Then we’ll discuss a proposed way-ahead

10. DoD Net-Centric Vision • Department of Defense (DoD) released Joint Vision 2020 in late 2000: • Goal - Integrate information technology to improve information flows between platforms, weapon systems, sensors, and decision makers via a machine-to-machine mechanism “The evolution of information technology will increasingly permit us to integrate the traditional forms of information operations with sophisticated all-source intelligence, surveillance, and reconnaissance in a fully synchronized information campaign.”

11. Emergence of Service Oriented Architecture (SOA) Right Information to the Right People at the Right Time • SOA describes a methodology for finding and using small pieces of functionality (services) regardless of how that functionality is implemented • Air Force IERs will be satisfied by services provided by • DoD’s Global Information Grid • Air Force Airborne Network • Etc. • Users will define services needed to satisfy Tactical Data Network IERs

12. SOA – Why should the Air Force care? • Right Information • Standard methodology • Registered services • Reusable services • Reduce impact of technology changes • Right Time • Timely capability updates • Right Place • Break down stovepipes • Satisfy individual user requirements

13. From Boxes... • Where each “box” provided a specialized capability (e.g. planning, logistics) – not interoperable • Information integration between “boxes” is a significant effort with associated significant costs Logistics Weather $ $ $ Flight Control Maps

14. ... To Services • Where services are available for any user at any “box” – integration “built-in” Discovery Service Flight Control Service Logistics Service Shows available Services and information Weather Service Maps Service Service Broker High-level, notional view

15. Impact on Requirements • Transition from systems-based (i.e. “boxes”) to service-basedmethodology should include changing the acquisition processes, including how requirements are handled • Persistent “services”will still need money set aside each year to maintain & improve – but systems had a Program Manager (PM) and direct funding source! • No firm methodology established for creation and maintenance of services. Not likely that these will have PMs! What should the Air Force do in this new environment?

16. Persistent Requirements • Based on this way-ahead, our hypothesis is that requirements must be persisted even after implementation • We propose that an IER Repository be developed to register the requirements, including: • Service(s) that satisfy the requirement • Providers and users of the service • Related services and dependencies • Composable capabilities • Architectural views

17. IER Repository Concept Analysis results: Dependencies, Redundancies, Activity models, etc. Developers/Architects IER Repository Requirements & Services Architectural Views Feed simulations Search Engines Provide access to architectural views UDDI Server

18. Repository Benefits • Provides traceability from requirement to implementation • View across multiple communities’ information to determine redundancies, dependencies, etc. • Users include service managers, developers, acquisition agents, other requirement shops • Feeds modeling and simulation efforts • Determine cumulative bandwidth requirements • Enables service orchestration for composable capabilities

19. GCIC/RIN Focus on Requirements • GCIC/RIN develops and gathers requirements for such programs as Tactical Data Link (TDL) Network, Airborne Network, and Objective Gateway • Requirements come from the Combat Air Forces, Mobility Air Forces, and Special Operation Forces • Documents (e.g., Initial Capabilities, Capabilities Design, architectural views) are produced • Processes are followed to generate requirements • Special working groups may be formed • Developed application to manage TDL implementation information

20. IER Repository Way-Ahead • GCIC/RIN has the iSMART tool that tracks IER implementation on military platforms for several message standards • Overall concept similar to IER Repository • Tool tailored to specific message standards - not currently suited as an “IER Repository” • Plan is to update iSMART to add functionality that would allow it to act as an IER Repository • This IER Repository will be used as a prototype and proof of concept for the Air Force

21. iSMART Update Currently tracks TDL platform implementation iSMART Updated GUI Existing functions New functions New IERs TDL Implementation IER Metadata Collection Collection of new IERs used to produce metadata, including architectural products. Provides ability to perform analysis of competing requirements, etc.

22. Summary • The Air Force is implementing the Net-centric Vision • SOA, web-based services - not “systems” • Acquisition process must change to accommodate new strategy • Propose the Air Force develop an IER Repository to persist requirements • Provide additional information to justify costs • Support simulation, analysis, etc. • Recommend that GCIC/RIN modifies iSMART to include IER Repository functionality • Modified iSMART will act as a prototype and proof of concept for Air Force