Orchestrating a Systems Approach Managing Requirements for a System of Systems Ivy Hooks Compliance Automation, Inc. As we encounter more system of systems (SOS) and more complex SOS, we must consider the changes that will be required of our existing processes. For example, requirements management has been focused on a system or a product. This article looks at how the SOS has evolved, including what parts of requirements management apply to the SOS and where the process will need revision. It also discusses the need for dynamic scope for the SOS and more use of standards to interface the sys- tems. Challenges definitely exist in SOS, not just in the Department of Defense but also in every aspect of the networked world. Our existing requirements management process is necessary, but not sufficient for the SOS. here is much in literature depicting ent data processing systems – one for each new systems to accomplish their mission system of systems (SOS) [1]. I will use satellite program. The person providing without reinventing the wheel or duplicat- theT characteristics Maier [2] has defined the tour had no idea why things were like ing capabilities. Writing requirements to (in boldface below), followed by my sum- they were, but I later talked to a NASA interface to these existing systems is gen- mary of each. headquarters person who explained it very erally straightforward, involving an under- 1. Operational Independence of the clearly. “Of course fewer systems would standing of what the new system must do Individual Systems. If you decom- be better, but we can’t take the risk. If to interface to the existing system. pose the SOS, each component system Program A and Program B agree to share Interfacing to a developing system can still perform independently of the a ground data system and then one or the where its design is evolving even as your others. other gets cancelled, the remaining pro- design is evolving is much more difficult. 2. Managerial Independence of the In the automotive industry, with many Systems. Each individual system has computers under the hood of every vehi- its own purpose independent of the “The SOS scope cle, interfaces are a nightmare. One story I others and is managed separately for was told involved creating a new dash- that purpose. creates the vision and board – an SOS comprised of entertain- 3. Geographic Distribution. Often ment, car information, temperature con- individual systems are distributed over sets the bounds for what trol, airbags, etc. The designer for the large geographic areas. airbag system noticed that if anyone else 4. Emergent Behavior. The SOS per- is to be accomplished. sent a particular command on the bus, forms functions not possible by any of then the airbag would deploy. “But the individual systems operating alone. Scope includes the need, nobody would ever do that,” he said. The reason for developing the SOS is When the dashboard was assembled and to obtain this unique behavior. goals, and objectives for an unsuspecting person moved the tem- 5. Evolutionary Development. An perature control, the airbag deployed. SOS is never finished; it continually the SOS ...Additionally evolves as needs change and newer the SOS scope will Managing Requirements technologies become available. If you have not already, you will probably Maier defines an SOS as having all or a need to address all the encounter an SOS in the near future. majority of these characteristics. Although I wrote about managing require- system-to-system ments for single systems [3] without Evolution of SOS regard to the SOS, the basic principles The Past interfaces within apply. In fact, the basic activities shown in In the first space systems, we built a sys- Table 1 are even more essential for man- tem to do all of the functions simultane- the SOS. aging an SOS than for a single system. In ously. The responsibility for the system ” a single system, management is by a pro- fell under one organization, although the gram or project manager. Requirements work may have been parceled out to many gram will not have the funds for its data elicitation is the responsibility of system organizations. There was a central point of processing system. To protect against this engineers or analysts who report to the control. For example, when the National highly probable scenario, it’s every man program/project manager. In an SOS, Aeronautics and Space Administration for himself.” This can still happen. these roles will need to be performed, but (NASA) built the Apollo space vehicle 40 will be difficult organizationally. While years ago, NASA built all elements of the The Present using standards can benefit almost every vehicle, its launch pad, and many other Today, we have a number of existing sys- system, standards may be essential for a ground facilities. tems that serve many other systems. These successful SOS. When I toured the NASA Goddard systems, e.g., Telemetry Data Relay Strategic planning is essential for SOS Space Flight Center nearly 20 years ago, I Satellite System and the Global development. The overall vision must be questioned the need for dozens of differ- Positioning System (GPS), enable multiple defined and embraced. Since an SOS does 4 CROSSTALK The Journal of Defense Software Engineering August 2004 Managing Requirements for a System of Systems abcdefghijklmnopqrnot have a limited life cycle but continues Requirement Basics stuvwxyz1234567890with the evolution of the SOS, its strategic Process Benefit =`= plan must also evolve. The SOS capabili- = Define scope before requirements. = Bound the problem/solution space. ties must evolve as needs change and new = Develop operational concepts for the entire = Prevent requirements omissions. technologies become available. lifecycle. = Prevent requirements omissions and = Identify stakeholders and involve them from misunderstandings. SOS Scope the beginning. = Make sure the system works within the larger In product development, it is essential to = Identify external interfaces. SOS. identify the scope of the product before = Educate all writers and reviewers on scope. = Share the vision; prevent misinterpretations. writing requirements. It is even more = Educate all writers and reviewers on what = Get needed, clear, concise, and unambiguous important to define the scope of the SOS good requirements are . requirements. before embarking on any aspect of = Capture rationale for each requirement. = Capture corporate knowledge and limitations requirements writing. The SOS scope cre- = Capture verification method for each imposed by existing systems. requirement. = Think ahead to understand how to verify and ates the vision and sets the bounds for to ensure verifiable. what is to be accomplished. Scope = Validate requirements as they are submitted. = Reduce review time. includes the need, goals, and objectives for the SOS. It also includes operational con- = Ensure each requirement is responsive to = Avoid requirement and scope creep. the scope. = Ensure everything is allocated and required. cepts for all life-cycle phases from the = Allocate each requirement to the next level.. viewpoint of all stakeholders. Scope includes the external drivers, e.g., regula- tions and external interfaces. Additionally Table 1: Requirements Basics the SOS scope will need to address all the culminate in modified goals and objec- We already know about ground data sys- system-to-system interfaces within the tives. Questionstem changes to Be Answered that are going to need to be SOS. In the preceding example, the =opera-What is theaccommodated initial operational over concept this fortime period. If it If we can identify the problem to be tional concept might start with somethinga nominalis op successful,eration of thew SOS?e ma y want to continue solved, then we can determine our need, like the following: We will launch= Howthe robustusing does these the system same needinstruments to be in for a longer goals, and objectives for the SOS. An response toRequirement off-nominal events? Basics abcdefghijklmnopqr instruments abcdefghijklmnopqrusing an xyz class launch period. examplestuvwxyz1234567890 problem might be to obtain more stuvwxyz1234567890Process= What is the high-level functional Benefit Process vehicle out of the Kennedy Space Center.architecture ofIt theis not SOS? possible to overstress the need accur-=`=ate weather data using new technolo- -=`== Define scope before requirements. = Bound the problem/solution= Define scope space. before requirements We will install the instruments in for full stakeholder participation and for gy in the following example: = Develop operational co=nceptsWhich for systems the entire of the =SOSPrevent already requirements exist? omissions. Company A’s satellite using the satellite for full life-cycle coverage of= operationalDevelop operational con- concepts for t • Need. Validate using the new technol- lifecycle. = How might the existing= systemsPrevent evolve requirements lifecycle. omissions and power, pointing, and communications.during We thece SOSpts. lifecycle?Information is needed to feed plan- ogy to increase weather forecast accu- = Identify stakeholders and involve them from misunderstandings.= Identify stakeholders and inv will spend three theweeks beginning. doing instrument ning, cost, and schedule estimating, and racy. = How many new systems= Makewill ne sureed to the be systemthe beginning. works within the larger checkout on-orbit= Identify and this external will inincludeterfaces.developed all for to medevelopinget the need?SOS.