Software Engineering Institute

The challenges of acquiring software-intensive systems continue to grow along with the increasingly critical role software plays in supporting commercial and government enterprise, business, and mission needs. In addition to expanding functionality and complexity, mounting expectations for software systems to be flexible and interoperable add to acquisition challenges, notably in terms of ensuring their security.

Acquisition is, in a sense, outsourcing the development of a system to one or more external providers. This does not relieve the acquirer of responsibility for the outcome. In fact, the activities, products, and behaviors of the acquirer have a significant influence on the success or failure of outsourcing activities. This fact is acknowledged in the appearance of CMMI-based guidelines for outsourcing [Hofmann 06] and the eSourcing Capability Model, a best-practices capability model that has been developed for outsourcing IT-based business functions [Hefley 06]. One purpose of these models is to give client or acquisition organizations guidance on how to improve their own capabilities for participating in outsourcing or acquirer-supplier agreements.
The Acquisition content area of BSI is intended to raise awareness of the acquirer’s role in “building security in” for major software-intensive systems. Assuring Software Systems Security: Life Cycle Considerations for Government Acquisitions discusses the integration of software security activities into the United States government acquisition life cycle. Building Security into the Business Acquisition Process provides an introduction to the standard IEEE 12207, Information Technology – Software life cycle processes, which provides a framework covering the life cycle from conceptualization through retirement [IEEE/EIA 98a, 98b, 98c]. The use of 12207 can help ensure that security considerations are a central part of product selection, monitoring, and acceptance. System-of-Systems Influences on Acquisition Strategy Development presents some recommendations for using an acquisition strategy to address sources of risk in systems of systems.
System complexity and hence acquisition complexity is an aggregate of technology, scale, scope, operational, and organizational issues. For example, consider the initiation phase of the 12207:

1. Prepare a concept or a need to acquire, develop, or enhance a product or service.
   2. Prepare a set of requirements, including relevant design, testing, and compliance standards.
   3. Prepare a risk and cost-benefit analysis for acquisition.
   4. Prepare a set of acceptance criteria and criteria for evaluation.
   5. Prepare an acquisition plan based on requirements, analyses, and criteria.

The dynamics of organizational usage increase the complexity of identifying requirements. While the elicitation of functional requirements is essential, the primary system architectural drivers are increasingly the non-functional system attributes such as performance, flexibility, and security that enable the desired usage. The acquisition process must explicitly address those non-functional system properties.

In addition, the development of an acquisition plan depends on more than the requirements, the risk and cost-benefit analysis, and the acceptance and evaluation criteria. The plan should be guided by an acquisition strategy that reflects decisions made with respect to a number of strategic issues. Such issues might include acquisition approach (e.g., incremental, evolutionary, agile), external interfaces, use of previously developed or commercial software, competition/solicitation approach, contracting approach, information assurance strategy, training, and support. Strategy drivers impact technical and acquisition requirements, risks, costs, acceptance criteria and approach, and all aspects of operations and sustainment.