Within  SBI, SBInet is the program for acquiring, developing, integrating, and  deploying an appropriate mix of (1) surveillance technologies, such as  cameras, radars, and sensors, and (2) command, control, communications,  and intelligence (C3I) technologies. Limited Definition of SBInet Deployments, Capabilities, Schedule, and Life Cycle Management Process Increases Program’s Exposure to Risk

Important aspects of SBInet remain ambiguous and in a continued state of  flux, making it unclear and uncertain what technology capabilities will be  delivered, when and where they will be delivered, and how they will be  delivered. For example, the scope and timing of planned SBInet  deployments and capabilities have continued to change since the program  began and, even now, remain unclear. Further, the approach that is being  used to define, develop, acquire, test, and deploy SBInet is similarly  unclear and has continued to change. The absence of clarity and stability in these key aspects of  SBInet introduces considerable program risks, hampers DHS’s ability to  measure program progress, and impairs the ability of the Congress to  oversee the program and hold DHS accountable for program results. However, the program office does not yet have an approved integrated  master schedule to guide the execution of SBInet, and according to  program officials, such a schedule has not been in place since late 2007. For example, the  deployment of the SBInet system to the Tucson Sector will not be  completed in 2009 as planned. However, this guidance was not finalized until  February 2008 and thus was not used in performing a number of key  requirements-related activities. Further, it has not ensured that the  operational requirements were, for example, verifiable, and it has not  made certain that all of the different levels of requirements are aligned to  one another. As a result, the risk of SBInet not meeting mission needs and  performing as intended is increased, as are the chances of expensive and  time-consuming system rework. Our analysis of this plan shows that  it is consistent with leading practices. Baselined Operational Requirements Used to Inform Lower-Level Requirements Are Limited

As stated above, one of the leading practices for developing and managing  requirements—which is reflected in the program office’s own plan—is that  requirements should be sufficiently analyzed to ensure that the  requirements are, among other things, complete, unambiguous, and  verifiable. Specifically, we attempted to trace  requirements in the version of this database that the program office  received in March 2008 and were unable to trace large percentages of  component requirements to either higher-level or lower-level  requirements. Specifically, it has not tested individual system components  prior to integrating these components with other components and the COP  software. However, it still does not have an  approved system integration test plan. Without clearly defined roles and responsibilities for all entities involved  in SBInet testing, the risk of test activities not being effectively and  efficiently performed increases. Appendix I: Objectives, Scope, and Methodology

Our objectives were to determine whether the Department of Homeland  Security (DHS) (1) has defined the scope and timing of planned SBInet  capabilities and how these capabilities will be developed and deployed, (2)  is effectively defining and managing SBInet requirements, and (3) is  effectively managing SBInet testing. To determine if DHS is effectively defining and managing SBInet  requirements, we reviewed relevant documentation, such as the  Requirements Development and Management Plan, the Requirements  Management Plan, the Configuration and Data Management Plan, the  Operational Requirements Document, System of Systems A-Level  Specification, B-2 Specifications, and Vendor Item Control Drawings, and  compared them to industry best practices to determine the extent to  which the program has effectively managed the systems requirements and  maintained traceability backwards to high-level operational requirements  and system requirements, and forward to system design and verification  methods.
Why GAO Did This Study

The Department of Homeland Security's (DHS) Secure Border Initiative (SBI) is a multiyear, multibillion-dollar program to secure the nation's borders through, among other things, new technology, increased staffing, and new fencing and barriers. The technology component of SBI, which is known as SBInet, involves the acquisition, development, integration, and deployment of surveillance systems and command, control, communications, and intelligence technologies. GAO was asked to determine whether DHS (1) has defined the scope and timing of SBInet capabilities and how these capabilities will be developed and deployed, (2) is effectively defining and managing SBInet requirements, and (3) is effectively managing SBInet testing. To do so, GAO reviewed key program documentation and interviewed program officials, analyzed a random sample of requirements, and observed operations of a pilot project.

What GAO Found

Important aspects of SBInet remain ambiguous and in a continued state of flux, making it unclear and uncertain what technology capabilities will be delivered, when and where they will be delivered, and how they will be delivered. For example, the scope and timing of planned SBInet deployments and capabilities have continued to change since the program began and, even now, are unclear. Further, the program office does not have an approved integrated master schedule to guide the execution of the program, and GAO's assimilation of available information indicates that the schedule has continued to change. This schedule-related risk is exacerbated by the continuous change in and the absence of a clear definition of the approach that is being used to define, develop, acquire, test, and deploy SBInet. The absence of clarity and stability in these key aspects of SBInet impairs the ability of the Congress to oversee the program and hold DHS accountable for program results, and it hampers DHS's ability to measure program progress. SBInet requirements have not been effectively defined and managed. While the program office recently issued guidance that defines key practices associated with effectively developing and managing requirements, such as eliciting user needs and ensuring that different levels of requirements and associated verification methods are properly aligned with one another, the guidance was developed after several key activities had been completed. In the absence of this guidance, the program has not effectively performed key requirements definition and management practices. For example, it has not ensured that different levels of requirements are properly aligned, as evidenced by GAO's analysis of a random probability sample of component requirements showing that a large percentage of them could not be traced to higher-level system and operational requirements. Also, some of SBInet's operational requirements, which are the basis for all lower-level requirements, were found by an independent DHS review to be unaffordable and unverifiable, thus casting doubt on the quality of lower-level requirements that are derived from them. As a result, the risk of SBInet not meeting mission needs and performing as intended is increased, as are the chances of expensive and time-consuming system rework. SBInet testing has not been effectively managed. For example, the program office has not tested the individual system components to be deployed to the initial deployment locations, even though the contractor initiated integration testing of these components with other system components and subsystems in June 2008. Further, while a test management strategy was drafted in May 2008, it has not been finalized and approved, and it does not contain, among other things, a clear definition of testing roles and responsibilities; a high-level master schedule of SBInet test activities; or sufficient detail to effectively guide project-specific test planning, such as milestones and metrics for specific project testing. Without a structured and disciplined approach to testing, the risk that SBInet will not satisfy user needs and operational requirements, thus requiring system rework, is increased.