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- Tthe 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. complete requirements. • Goals. Fly instruments A and B to = Identify external interfaces. = Who are Thisall the scope stakeholders information of the SOS must be provided communications= Educateto ground all writers facilities.and reviewers on scope. = Share the vision;= Educateprevent misinterpretations.all writers and review obtain information. Analyze informa- across theto entire all stak life-cycle?eholders so they understand and Following chec=kout,Educatewe all willwriters point and re viewersthe on what = Get needed, clear,= Educate concise, all and writers unambiguous and review tion and make predictions. Compare = When mustagree the SOSto the be operscopeational? before venturing for- predictions with and without the new instruments per goodthe redata-gatheringquirements are .plan requirements. good requirements are . and begin taking= Capturedata. Thisrationale data for willeach= How bere quirement.muchw armod,ney or isthe available?= risksCapture will corporate be unmana= Capture knowledgegea rationaleble and. limitationsfor each re technology. Stakeholderimposed buy-in to by the existing SOS scopesystems. is essen- • Objectives. Fly instruments using downlinked dail=y Captureby the verification satellite. method In the for each = Capture verification method requirement. tial for a successful= Think SOSahead and to un forderstand writing how good to verify and existing satellite and launch vehicle analysis phase, weather forecasters will requirement. = Validate requirements as they arerequirements. to ensure verifiable. within 24 months. Obtain data for 24 combine this with other data to makeMore a Questions to Be Answered = Validate requirements as they a submitted. Since one= Reduce of the review characteristics time.submitted. of forecast that will be compared to =a Whofore- knows what about each existing months. Provide comparisons within = Ensure each requirement is responsivesome toSOS =is Avoidthat ofrequirement continual and evolution, scope creep. two weeks of first obtaining data and cast made without the instrument system?data. = Ensure each requirement is responsiv the scope. =What reliablethis documentationimplies= thatEnsure theexists everythingscope for willthe is alsoscope.allocated evolve. and required. biweekly thereafter. Both forecasts will be compared to the actual weather =toAllocate determine each rethequirement accuracyeach to system?the Tnexthis level. .does not mean that we= Allocatecan just each make requirement to t Often we see processes that ask for =Who amongit up the asstakeholders we go along. can provide We need answers to requirements up front. Generally what is of the forecasts. added information about their systems? In this example, we have just= barelyHow can we contact and work with these meant is that the need, goals, and objec- Table 2: Questions To Be Answered started; however, once the above ques-stakeholders? tives should be identified and operational =What are the interfaces that must exist concepts developed. It is premature to tions are answered we have the next betweenlevel existing andQuestions planned systems? to Be Answered write requirements until all stakeholders of questions (see Table 3 on Page 6).=Who controls= eachWhat in isterface? the initial operational concept for have agreed on the operational concepts. As difficult as gathering the =aboveWhat standardsa have nominal been op usederation by of the SOS? existing systems that can enable the information will be for a single system, it = How robust does the system need to be in During the scope discovery process, interfaces? response to off-nominal events? there are a number of questions that must will be magnitudes harder for an SOS.=What In are the standards that may be be answered (see Table 2). It can be bene- order for the SOS to succeed, these ques-available for =newWhat systems is the andhigh-level future functional architecture of the SOS? ficial to try to answer these questions ini- tions must be answered. The boundssystems? for =What are the= regulatoryWhich systems requirements of the SOS that already exist? tially to understand how much is known the SOS must be clearly defined, includingmust be met in order to deploy the SOS? = How might the existing systems evolve operational concepts for each lif=e-cycleWhat changes can we anticipate over the and what is unknown. If there are many during the SOS lifecycle? unknowns, this will be a much more phase and all transitions. lifecycle? = How many new systems will need to be involved and drawn-out process. The list in Table 3 is a starting= point.What evolution in technologies can we expect? developed to meet the need? Significant engineering and analysis As you can see from our example opera- = Who are all the stakeholders of the SOS efforts, involving conceptual studies, trade tional concept, we have many other ques- across the entire life-cycle? studies, modeling, simulation, and proto- tions. Also, this SOS is planned for a four- = When1 must the SOS be operational? typing, may be required to obtain the year period at the least: two years for = How much money is available? answers. The results of this effort may development and two years of operation.

August 2004 www.stsc.hill.af.mil 5 More Questions to Be Answered be oper be oper = How much money is available? = How much money is available? Orchestrating a Systems Approach

More Questions to Be Answered the SOS, there isMore really Questions no such to product. Be Answeredcables, or turn on our laptop in airports =Who knows what about each existing Therefore, it =is Whocritical knows that what each about and each every existingand hotels around the world. The Institute system? SOS requirementsystem? be allocated to an exist- of Electrical and Electronic Engineers has =What reliable documentation exists for =What reliable documentation exists for each system? ing or new systemeach system? or to an interface thousands of standards to help engineers =Who among the stakeholders can provide between two= orWho more among systems. the stakeholders The SOS can provideunderstand what other engineers are talk- added information about their systems? manager is responsibleadded information for ensuring about their the systems?ing about [4]. The American National =How can we contact and work with these acceptance of=How allocated can we requirementscontact and work by with theseStandar ds Institute, the International stakeholders? stakeholders? =What are the interfaces that must exist each of the participating=What are the system interfaces managers that must existStandards Organization, and the Inter- between existing and planned systems? (those managersbetween of existing existing andor plannednew sys- systems?national Electrotechnical Commission are =Who controls each interface? tems within the=Who SOS). controls each interface? also providers of large numbers of inter- =What standards have been used by There may= Whatbe situations standards wherehave been we usedwill by existing systems that can enable the existing systems that can enable thenational standards. interfaces? use a system withininterfaces? the SOS but we will Standards are not static and unchang- =What are the standards that may be never work with=What the are manager the standards of that that sys-may be ing; they are updated to account for available for new systems and future tem; we will justavailable use what for newis available systems asand we futurechanges in technology and needs. New systems? do with many commercialsystems? products today. =What are the regulatory requirements that =What are the regulatory requirementsstandards that are in development to fix per- must be met in order to deploy the SOS? The SOS systemmust engineers be met in must order anticipateto deploy the SOS?ceived problems. In many areas, using =What changes can we anticipate over the and incorporate=What possible changes changes can we anticipateto such overstandards the is not a common practice, and lifecycle? lifecycle? systems, e.g., Internet or GPS. the design approaches currently being =What evolution in technologies can we =What evolution in technologies can we expect? Rationale expect? taken will not effectively support an SOS. Thus more emphasis upon standards is For system managers to agree to the allo- Table 3: More Questions To Be Answered essential to successful SOS development. cated requirements, they must completely 1 1 From the requirements arena, a stan- the above questions to begin. We must understand each requirement allocated to dard is a requirement that is agreed upon understand the big picture, including the them and its relationship to the SOS and understood by a wide range of practi- environment and the context in which the scope. By ensuring that rationale is pro- tioners. Hardware and software designed SOS must exist and operate. We need a vided with every requirement, this can be to interface standards allow each side of plan from which to base our efforts – not accomplished. In those cases where a the interface to build toward the middle just a random effort. requirement is allocated to more than one without extensive negotiations and modi- system, the affected managers must work Management fications as the two sides evolve. Using with their counterparts to define the inter- standards also enables us to unplug one It is not immediately clear after reading faces. system and plug in another that also meets many SOS articles who actually manages For example, the rationale might the same standard interface. an SOS effort for different endeavors. explain how the requirement is con- Success depends on someone being in strained by an existing system. The man- Defensive and Self-Healing charge. There must be an SOS manager, ager of that system can concur that the Requirements whether or not that manager has any requirement is correct, or can state that he direct control over the individual systems. or she is planning changes that would One of the biggest examples of SOS Likewise, it seems clear that there must invalidate the requirement. If the manager complexity exists in our world of comput- be SOS architects and system engineers to never sees the rationale, he or she may er hardware and software. There are many facilitate the efforts for scope and require- assume that the requirement is caused by brands of computers, operating systems, ments definition, to manage the interfaces, someone or something else and never peripheral devices, device drivers, and and to provide the sustaining effort essen- acknowledge the planned changes to his applications. These all are expected to tial to an evolving SOS. The organization- or her system. work together, but problems occur in get- al affiliations of these people may be The requirement will also provide ting all of these individual systems work- many, and they may be selected for their information about how it relates to the ing together as a SOS. experience with the systems that comprise scope so that as the scope evolves so will I have had so many problems with my the SOS. the requirement. small personal world of creating a SOS from commercial off-the-shelf products SOS Requirements Standards that I cannot understand how anyone With the scope clearly defined, we can The number of standards is downright keeps large networked systems opera- now look toward writing requirements for intimidating. Yet use of standards may tional. With hundreds of workstations, the SOS. We are doing this with at least a hold the key to making systems work networks, routers, etc., how does anyone conceptual architecture in mind and with effectively together in an SOS. It is impor- dare to ever make any updates? operational concepts that incorporate tant to note the impact of standards on For a robust SOS, if my system and existing, evolving, and new systems. The the development of cost-effective prod- yours communicate or interact in any way, requirements for the SOS will reflect capa- ucts. Having standards has enabled the we need to both protect against what can bilities and performance implied by the hardware developers to grow and expand happen at or across the interface. This scope results as well as the limitations and while reducing the price of goods to con- begins with each of us defining require- restrictions imposed by existing systems, sumers. There are also standards for soft- ments that will protect our integrity standards, and regulations. ware, but fewer since software is a much regardless of the other’s system. We need younger field of engineering. requirements that defend against problems Allocation We rely on these standards when we like those experienced by the car dash- Although requirements will be written to buy a light bulb for our lamp, hook up our board SOS. We need self-healing require- define the capability and performance of new computer to our existing printer ments for each system to enable its recov-

6 CROSSTALK The Journal of Defense Software Engineering August 2004 Managing Requirements for a System of Systems ery from the impact of other systems. systems. It is critical to do the prerequire- There seems to be a desire or maybe ments work of scope definition, docu- COMING EVENTS even a mandate to merge new and existing mentation, dissemination, and stakeholder systems from disparate organizations to buy-in before the SOS requirements are September 11-17 achieve a new capability. This is often a developed. Management of requirements long and tedious process and in many allocation will be a major activity more 20th IEEE International Conference on cases is simply abandoned in frustration. than in single-system activities. Issues Software Maintenance For example, the National Oceanic and related to allocation, interfaces, and infor- Chicago, IL Atmospheric Administration (NOAA), mation transfer must be high on manage- www.cs.iit.edu/~icsm2004 NASA, and the Navy agreed to do a joint ment’s agenda and resolved swiftly. project for developing new weather fore- Extended use of standards and develop- casting capability. NASA has had prob- ment of standards to empower an SOS September 13-16 lems just having multiple NASA centers may be key to successful endeavors. Each Embedded Systems Conference working together on a project, and this individual system must pay more attention program interjected two other govern- to its defensive and self-healing require- Boston, MA ◆ ment agencies. NASA was responsible for ments to participate in future SOS. www.esconline.com/boston developing the weather instrument. The Navy was responsible for a launch vehicle References September 20-23 and a satellite to house the instrument. 1. Sage, A., and C. Cuppan. “On the The NOAA, NASA, and the U.S. Navy all Systems Engineering and Management Software Development Best Practices 2004 had a say in what the instrument was to of Systems of Systems and Boston, MA measure and responsibility for ground sta- Federations of Systems.” Information, www.sdexpo.com tions to receive the data. A requirement Knowledge, and Systems Management that the instrument data had to be able to 2 (2001): 325-345. be processed by both NOAA and U.S. Air 2. Maier, M. Architecting Principles for September 20-24 Force ground facilities only added to the Systems of Systems. Proc. of the Sixth 8th International Enterprise Distributed program’s complexity. NASA was named Annual International Symposium, the project lead. International Council on Systems Object Computing Conference Attempts were made by the project Engineering, Boston, MA, 1996: 567- Monterey, CA team to develop operational concepts and 574. www.edocconference.org write high-level requirements. While the 3. Hooks, Ivy F., and Kristin A. Farry. team was able to document a lot of infor- Customer Centered Products – mation, they had no formal training in Creating Successful Products Through September 24-26 developing operational concepts or writ- Smart Requirements Management. IPSI-2004 Stockholm ing requirements. This resulted in a system New York: Amacom, 2001. Stockholm, Sweden specification that contained very low-level 4. Vonderheid, E. “Standards Hidden in www.internetconferences.net/ requirements that constrained the instru- Plain Sight.” The Institute Mar. 2004. ment design. As the NASA team struggled industrie/stockholm.html to write requirements for their instrument, About the Author it was clear that they did not know the September 27-30 details for interfacing to the satellite or Ivy Hooks is president launch vehicle. These interfaces and the and chief executive offi- Better Software Conference and Expo environments expected by and imposed cer of Compliance San Jose, CA by the other systems are critical to writing Automation, Inc., a com- www.sqe.com/bettersoftwareconf the instrument requirements; the Navy pany whose focus is was unresponsive to providing the data. requirements. Hooks is With unintentional constraints from October 6-9 an internationally recognized expert, above and lack of information, it was author, and speaker on the subject of Grace Hopper Celebration of Women in impossible to write good instrument Computing requirements. requirements. She brings experience This is not an uncommon situation, it from a 20-year career at the NASA Chicago, IL happens all too often on many govern- Johnson Space Center followed by 20 www.gracehopper.org ment programs. years experience consulting for govern- The end of the saga was that the Navy ment and industry. April 18-21, 2005 bailed out and withdrew its support; NASA continued instrument develop- Compliance Automation, Inc. 2005 Systems and Software ment to interface with an unknown launch 1221 South Main ST Technology Conference vehicle and satellite, and hardware and STE 204 software now exist. Will it ever be Boerne,TX 78006 deployed? That is a good question. Phone: (830) 249-0308 Conclusion Fax: (830) 249-0309 E-mail: ivy@compliance Salt Lake City, UT Requirements management will be an automation.com important aspect of an SOS, as it is to all www.stc-online.org

August 2004 www.stsc.hill.af.mil 7