Armstrong bocast integration_of_systems_engineering_and_software_development_2003-libre

The Integration of Systems
Engineering and Software
Development
Based on the
Object-Oriented Approach to Software Intensive Systems
SPC-2003041-CMC
Version 01.00
April 2003

The Integration of Systems
Engineering and Software
Development
Based on the
Object-Oriented Approach to Software Intensive Systems
SPC-2003041-CMC
Version 01.00
April 2003
Jim Armstrong
Alex Bocast
SOFTWARE PRODUCTIVITY CONSORTIUM
SPC Building
2214 Rock Hill Road
Herndon, Virginia 20170-4227
Copyright © 2003, Software Productivity Consortium NFP, Inc. Permission to use, copy, and distribute this material for any
purpose and without fee is hereby granted consistent with 48 CFR 227 and 252, and provided that the above copyright notice
appears in all copies and that both this copyright notice and this permission notice appear in supporting documentation. This
material is based in part upon work sponsored by the Advanced Research Projects Agency under Grant #MDA972-96-1-0005.
The content does not necessarily reflect the position or the policy of the U.S. Government, and no official endorsement should be
inferred. The name Software Productivity Consortium NFP, Inc. shall not be used in advertising or publicity pertaining to this
material or otherwise without the prior written permission of Software Productivity Consortium, NFP, Inc. SOFTWARE
PRODUCTIVITY CONSORTIUM NFP, INC. MAKE NO REPRESENTATIONS OR WARRANTIES ABOUT THE
SUITABILITY OF THIS MATERIAL FOR ANY PURPOSE OR ABOUT ANY OTHER MATTER, AND THIS MATERIAL
IS PROVIDED WITHOUT EXPRESS OR IMPLIED WARRANTY OF ANY KIND.

CONTENTS
ACKNOWLEDGMENTS..........................................................................................................IX
EXECUTIVE SUMMARY ........................................................................................................XI
1. INTRODUCTION................................................................................................................1
1.1 Scope.............................................................................................................................1
1.2 Audience.......................................................................................................................1
1.3 Organization .................................................................................................................1
1.4 Typographic Conventions.............................................................................................2
2. INTEGRATING SYSTEMS ENGINEERING AND SOFTWARE DEVELOPMENT3
2.1 Introduction ..................................................................................................................3
2.2 Systems Engineering ....................................................................................................3
2.2.1 Technical Activities....................................................................................................... 4
2.2.2 Management Activities.................................................................................................. 5
2.2.3 Distinguishing Attributes............................................................................................... 5
2.3 Software Development .................................................................................................6
2.3.1 Scope of OOASIS.......................................................................................................... 6
2.3.2 OOASIS Inputs and Related Activities External Activities .......................................... 9
2.4 Mapping Systems Engineering to Software Development.........................................10
2.5 Interaction Guidance...................................................................................................14
2.5.1 Top-Level Definition/Define System Requirements ................................................... 14
2.5.2 Lower-Level Interactions/Software Development....................................................... 16
2.5.3 General Interface Issues............................................................................................... 18
2.5.4 SE and UML................................................................................................................ 19
2.6 Summary.....................................................................................................................20
3. APPLYING IDEF METHODS TO DEVELOP OOASIS INFORMATION
REQUIREMENTS.............................................................................................................21
A. RELATING IDEF METHODS TO OOASIS..................................................................23
A.1 Part I. Applying the IDEF0 Method ...........................................................................23
iii

Contents
A.1.1 Overview of Method.................................................................................................... 24
A.2 Results of this Method..............................................................................................111
A.2.1 Stakeholders............................................................................................................... 111
B. SANTA NARIDA BACKSTORY ...................................................................................117
B.1 Santa Narida and the Santa Narida Ocean Observation Region...............................117
C. OOASIS NODE-DEVICE-CONNECTOR DIAGRAM ...............................................123
D. NATIONAL DATA BUOY CENTER............................................................................125
D.1 Standard Meteorological Data..................................................................................125
D.2 Detailed Wave Summary..........................................................................................126
D.3 Acoustic Doppler Current Profiler (ADCP) .............................................................126
D.4 Continuous Winds ....................................................................................................126
D.5 Spectral Wave Data ..................................................................................................127
D.6 Water Level ..............................................................................................................127
D.7 Marsh-McBirney Current Measurements.................................................................127
E. APPLYING SADT ACTIVATION RULES TO IDEF0 ACTIVITY ANALYSIS.....129
E.1 Activation Rules .......................................................................................................129
E.2 Conditional Expressions...........................................................................................129
E.3 Preconditions ............................................................................................................130
E.4 Postconditions...........................................................................................................131
E.5 Writing Rule Sets......................................................................................................132
E.6 Incorporating Activation Rules in a Diagram...........................................................135
E.7 Revisiting Marca and McGowan’s Example............................................................136
LIST OF ABBREVIATIONS AND ACRONYMS .................................................................139
iv

FIGURES AND DIAGRAMS
Figure 1. OOASIS Model of System and Software Interaction.................................................................... 3
Figure 2. OOASIS Software Development Flow.......................................................................................... 6
Table 1. Systems Engineering/Software Interactions ................................................................................. 10
Figure 3. Top-Level Interactions ................................................................................................................ 14
Figure 4. Mid-Level Interactions ................................................................................................................ 17
Diagram 1. SWM/A0 (Present Weather) .................................................................................................... 28
Diagram 2. STW/A0 (Produce Tsunami Warnings)................................................................................... 29
Diagram 3. SIS/A0 (Research Ocean Weather Phenomena) ...................................................................... 29
Diagram 4. SRP/A0 (Plan Ship Itinerary)................................................................................................... 30
Diagram 5. SWF/A0 (Forecast Weather).................................................................................................... 31
Diagram 6. SNW/A0 (Increase Puerta Oveida Market Share).................................................................... 31
Diagram 7. SSP/A0 (Deliver Data)............................................................................................................. 32
Diagram 8. SNM/A0 (Maintain Buoys)...................................................................................................... 32
Diagram 9. RTP/A-1=AKB5.1 for Weather Media Stakeholder................................................................ 37
Diagram 10. RTP/A-1=AKB5.2, Adding Environment Stakeholder ......................................................... 38
Diagram 11. RTP/FEO1: Parallel Decomposition Fragment...................................................................... 39
Diagram 12. RTP/A-1=AKB5.3, Adding GOOS Satellite System............................................................. 40
Diagram 13. RTP/FEO2, Ocean Observation Fragment............................................................................. 40
Diagram 14. RTP/A-1=AKB5.4, Adding Tsunami Warning System......................................................... 41
Diagram 15. RTP/A-1=AKB5.5, Adding National Weather Service ......................................................... 42
Diagram 16. RTP/A-1=AKB5.6, Adding Institute Scientist....................................................................... 43
Diagram 17. RTP/A-1=AKB5.7, Additional Clarification of Behaviors.................................................... 44
Diagram 18. RTP/FEO3, Relating Observing to Forecasting..................................................................... 45
Diagram 19. RTP/FEO5, Environmental Exchange Example.................................................................... 46
Diagram 20. RTO/A-1=AKB5, Operations Stakeholders........................................................................... 47

Figures and Diagrams
Diagram 21. RTO/A1 Measure Ocean Observables.................................................................................. 48
Diagram 22. RTT/A-1, Training Stakeholder............................................................................................. 49
Diagram 23. RTP/A-1 (Stakeholder Context of Meteorological Product Generation)............................... 50
Diagram 24. RTP/A-0 (Context of Meteorological Product Generation)................................................... 51
Diagram 25. RTP/A0 (Generate Meteorological Products)........................................................................ 53
Diagram 26. RTP/A1 (Measure Ocean Weather Characteristics)............................................................... 54
Diagram 27. RTP/A11 (Control Data Collection) ...................................................................................... 55
Diagram 28. RPT/A12 (Measure Observables) .......................................................................................... 55
Diagram 29. RTP/A13 (Transmit Collected Data) ..................................................................................... 56
Diagram 30. RTP/A2 (Provide Datasets).................................................................................................... 57
Diagram 31. RTP/A4 (Forecast Weather)................................................................................................... 58
Diagram 32. ATP/A-1 (Stakeholder Context of Meteorological Product Generation)............................... 59
Diagram 33. ATP/A-1 (Context of Meteorological Product Generation)................................................... 60
Diagram 34. ATP/A0 (Generate Meteorological Products)........................................................................ 61
Diagram 35. ATP/A1 (Measure Ocean Observables)................................................................................. 62
Diagram 36. ATP/A11 (Control Data Collection)...................................................................................... 63
Diagram 37. ATP/A12 (Measure Observables).......................................................................................... 63
Diagram 38. ATP/A13 ( Transmit Collected Data) .................................................................................... 64
Diagram 39. ATP/A2 (Generate Meteorology Products) ........................................................................... 65
Diagram 40. ATP/A21 (Generate Datasets)................................................................................................ 66
Diagram 41. ATP/A211 (Save Observations)............................................................................................. 67
Diagram 42. ATP/A212 (Create Datasets).................................................................................................. 68
Diagram 43. ATP/A213 (Retrieve Datasets) .............................................................................................. 69
Diagram 44. ATP/A23 (Forecast Weather) ................................................................................................ 69
Diagram 45. ATP/A3 (Distribute Products) ............................................................................................... 70
Diagram 46. ATP/A31 (Fulfill Orders)....................................................................................................... 71
Diagram 47. ATP/A32 (Stage Products)..................................................................................................... 72
Diagram 48. ATP/A33 (Post Products)....................................................................................................... 72
Diagram 49. ATP/A34 (Email Products).................................................................................................... 73
Diagram 50. ATP/A0 (Generate Meteorological Products) with System Agents....................................... 74
Diagram 51. ATP/A11 (Control Data Collection) with System Controller................................................ 75
vi

Diagram 52. ATP/A13 (Transmit Collected Data) with System Controller............................................... 76
Diagram 53. ATP/A211 (Save Observations) with Data Engineer............................................................. 76
Diagram 54. ATP/A212 (Create Datasets) with Data Engineer.................................................................. 77
Diagram 55. ATP/A213 (Retrieve Datasets) with Product Engineer.......................................................... 77
Diagram 56. ATP/A3 (Distribute Product) with Fulfillment Technician ................................................... 78
Diagram 57. RTO/A-1 (Stakeholder Context of Routing Product Generation).......................................... 79
Diagram 58. RTO/A-0 (Context of Routing Product Generation).............................................................. 80
Diagram 59. RTO/A0 (Generate Routing Products)................................................................................... 81
Diagram 60. RTO/A2 (Generate Routing Products)................................................................................... 82
Diagram 61. RTO/A23 (Propose Itineraries).............................................................................................. 83
Diagram 62. ATO/A-0 (Context of Routing Product Generation) ............................................................. 83
Diagram 63. ATO/A0 (Generating Routing Products) ............................................................................... 84
Diagram 64. ATO/A2 (Generating Routing Products) ............................................................................... 85
Diagram 65. ATO/A23 (Propose Itineraries).............................................................................................. 85
Diagram 66. ATO/A0=AKB11 (Generate Routing Products).................................................................... 86
Diagram 67. ATO/A2=AKB9 (Generate Routing Products)...................................................................... 87
Figure 5. Conventions for Marking Activities WRT Use Cases................................................................. 88
Diagram 68. ASU/A0 (Generate Meteorological Products) ....................................................................... 89
Figure 6. Use Case Analysis: Measure Ocean Observables........................................................................ 89
Diagram 69. OSU/A0=AKB24 (Generate Meteorological Products)......................................................... 90
Figure 7. Use Case Analysis: Run Weather Models................................................................................... 90
Diagram 70. OSU/A3=AKB26 (Distribute Products) ................................................................................ 91
Diagram 71. OSU/A0=AKB25 (Generate Meteorological Products)......................................................... 92
Figure 8. Use Case Analysis: Stage Products ............................................................................................. 93
Figure 9. Use Cases Analysis: Maintain Meteorological Data ................................................................... 94
Diagram 72. OSC/A2 (Generate Routing Products)................................................................................... 94
Figure 10. Use Case Analysis: Propose Itineraries..................................................................................... 95
Diagram 73. OSC/A0 (Generate Routing Products), Final Markup ........................................................... 96
Figure 11. OOASIS System Use Case Diagram ......................................................................................... 97
Figure 12. First NDC Transform on ONA/A11.......................................................................................... 98
Figure 13. Second NDC Transformation on ONA/A11.............................................................................. 99
vii

Figure 14. First NDC Transformation on ONA/A1.................................................................................... 99
Figure 15. Second NDC Transformation on ONA/A1.............................................................................. 100
Figure 16. Third NDC Transformation on ONA/A1 ................................................................................ 100
Figure 17. First NDC Transformation on ANA/A21................................................................................ 101
Figure 18. Second NDC Transformation on ONA/A21............................................................................ 101
Figure 19. First NDC Transformation of ANO/A23................................................................................. 102
Figure 20. First NDC Transformation of ONA/A2................................................................................... 102
Figure 21. Second NDC Transformation of ONA/A2 .............................................................................. 103
Figure 22. First DNC Transformation of ONA/A3................................................................................... 103
Figure 23. First NDC Transformation for ONA/A0 ................................................................................. 104
Figure 24. Final NDC Transformation for ONA/A0 ................................................................................ 105
Figure 25. First NDC Transformation of ONB/A2................................................................................... 106
Figure 26. Second NDC Transformation for ONB/A2 ............................................................................. 107
Figure 27. Third NDC Transformation for ONB/A2................................................................................ 107
Figure 28. First NDC Transformation for ONB/A0.................................................................................. 108
Figure 29. First NDC Information Integration.......................................................................................... 109
Figure 30. Second NDC Information Integration ..................................................................................... 110
Figure 31. OOASIS NDC Diagram .......................................................................................................... 111
Diagram 74. OCD/A-0 (Context of Meteorological Product Generation)................................................ 113
Figure 32. OOASIS System Use Case Diagram for Buoy Case Study..................................................... 114
Figure 33. OOASIS NDC Diagram for Buoy Case Study........................................................................ 115
viii

ACKNOWLEDGMENTS
The authors wish to thank those who contributed to this report. Many hours have been spent discussing
technical points to reach resolution on several significant areas of issue between the systems engineering
and software development communities.
• Contributors and Internal Reviewers: Sarah Sheard, Rich McCabe, and Mike Polen
• External Reviewers: Dr. Ralph Freeman

Acknowledgments
This page intentionally left blank.
x

EXECUTIVE SUMMARY
Current systems engineering and software development methods have been separately created with little
regard to their interfaces. This report takes an initial look at this interface. It identifies many of the critical
aspects of the interface and proposes ways in which they may be addressed.
The report addresses the systems engineering and software development interface in general terms that
are believed to be applicable to all software development. However, specific examples and discussion
address object-oriented software development that uses Unified Modeling Language (UML). Since UML
does not specify a method, the report is based on the Object-Oriented Approach to Software-Intensive
Systems (OOASIS) method. OOASIS provides practice level guidance for application of UML with
specific steps and decisions identified. The report identifies the systems engineering activities that provide
information to the OOASIS activities or uses information from them. It also identifies guidance for
interaction between the activities on both sides of the interface to avoid some of the most critical
problems.
The report does not fully define all interface issues nor does it define the details of a method for
performing both disciplines across the interface. Also, the treatment covers those requirements that relate
to the behavior of the systems and the software. Not addressed are those systems requirements that affect
other areas of performance such as reliability, safety, survivability, etc. Some examples of systems
engineering studies that are beyond the scope of UML related methods are given but their interface
mechanisms are not fully developed. These areas should be the subject of further study.
Key points of this report are:
• Systems engineering and software development techniques have been developed to address
different specific issues and concerns. However, they do overlap and the overlap increases as the
proportion of software content increases.
• Information that is common to both areas must be identified and properly exchanged.
• Systems engineering and software development should be conducted in parallel and integrated.
Doing them sequentially in an over-the-wall manner generates severe problems.

Executive Summary
xii

1. INTRODUCTION
1.1 SCOPE
This report addresses the need for and nature of the interface between systems engineering and software
development. While providing guidance of a general nature that is applicable to any software
development method, it uses the specific examples of object-oriented development as defined in the
Consortium’s Object-Oriented Approach to Software-Intensive Systems (OOASIS). The treatment covers
those requirements that relate to the behavior of the systems and the software. Not addressed are those
systems requirements that affect other areas of performance such as reliability, safety, survivability, etc.
Some examples of systems engineering studies that are beyond the scope of OOASIS are given but their
interface mechanisms are not fully developed.
It is recognized that many approaches have been documented to use the software-oriented techniques of
the Unified Modeling Language (UML) to accomplish systems engineering. While these methods are
recognized to have benefit in a system that is almost totally software in content, there remain systems
engineering activities that these techniques do not address. The Object Management Group has released a
Request for Proposal to add capabilities to UML to more thoroughly address the needs of systems
engineering and reduce the gap. However, that effort recognizes that the proposed changes will not
completely cover systems engineering and there will remain a need to define the interface between the
two disciplines. This report addresses the overall activities of systems engineering and the information
generated, regardless of the specific notation used.
1.2 AUDIENCE
This report is directed to systems engineering practitioners, software developers and others who address
the interface between the two disciplines. The report focuses on but is not limited to the interface between
systems engineering methods and software methods using Unified Modeling Language (UML) with
specific attention to the methods defined in the OOASIS.
1.3 ORGANIZATION
• Section 1 Introduction. Provides the scope of the report.
• Section 2 Integrating Systems Engineering and Software Development. Provides the
background and approach at the process and method level
− 2.1 Introduction. Defines the overall interface to be addressed
1

1. Introduction
− 2.2 Systems Engineering. Defines the activities of systems engineering and those that will be
included in this report
− 2.3 Software Development. Reviews the OOASIS method for use of UML
− 2.4 Mapping. Defines the interactions between the two disciplines
− 2.5 Guidance. Explains the interactions and provides guidance for both sides in program
development
• Section 3 Case Study. Provides specific guidance for interfacing the OOASIS UML inputs with
systems engineering analysis using IDEF
1.4 TYPOGRAPHIC CONVENTIONS
This report uses the following typographic conventions:
Serif font.....................General presentation of information
Bold Italic...................Bulleted lists and run-in headings.
2

2. INTEGRATING SYSTEMS ENGINEERING AND
SOFTWARE DEVELOPMENT
2.1 INTRODUCTION
The model used in this discussion is an interactive relationship between systems engineering and software
development. Requirements and architecture decisions are arrived at by concurrence rather than by over-
the-wall direction. Also, software development is embedded within the overall requirements analysis
activity and as part of the systems design. While this is not a unique or original approach, neither is it as
commonly practiced as it should be.
System
Requirements
Analysis
System Design
Physical
Architecture
Software
Architecture
time
System
Requirements
Analysis
System Design
Physical
Architecture
Software
Architecture
time
Figure 1. OOASIS Model of System and Software Interaction
The discussions that follow will first define the systems engineering and software development activities
that occur in this model using a general definition of systems engineering and the OOASIS method of
software development. Next, an information map will be presented correlating the outputs of systems
engineering activities with the inputs defined in the OOASIS method. Finally, guidance is provided for
the interactions at different levels of systems definition.
2.2 SYSTEMS ENGINEERING
Systems engineering has been defined in many ways. The definitions include systems engineering as a
process, as a group of people, as a step in the life cycle, as a set of analyses, as coordination functions, as
an approach to be taken by any engineer, and even as a way of life to be adopted by people who aren’t
engineers. In most descriptions of systems engineering there are both technical and management
activities. The activities following were named in at least two of several references, although in a few,
3

2. Integrating Systems Engineering and Software Development
notably ISO 9000-2000, these were not specifically called “systems engineering activities”. References
include (Sheard 1996) (CMMI
) (SE-CMM
)1
(IEEE 1220) (EIA 632) (DSMC SE Handbook) (ISO
9000-2000).
2.2.1 TECHNICAL ACTIVITIES
This report addresses the technical activities of systems engineering in defining and analyzing the
requirements and top-level design or architecture of a system. It is more than just the requirements
development phase of a software project. The technical activities include:
• Problem Definition. Discovering system requirements and derived requirements, stating the
problem, eliciting customer need, analyzing the complexity of the problem space, developing the
concept of operations, determining system scope and boundaries, defining and decomposing
functionality, determining performance measures including Measures of Effectiveness and
Technical Performance Measures, developing subsystem specifications, including software
specifications, validating requirements, tracking requirements and design issues to closure.
• Architecting. Designing the system, exploring alternative system concepts, system or product
integration, defining and designing external and internal interfaces, and system modeling.
• Analysis. Performing analyses including performing trade studies with appropriate sensitivity
analysis, reliability analysis, survivability analysis, failure mode and effects analysis,
electromagnetic compatibility and survivability analysis, and other system analyses that are
specific to the system domain such as orbit analysis, thermal analysis, bandwidth analysis, signal
strength analysis, memory usage, system reaction time analysis, even cosmic particle interference.
• Allocation. Maintaining traceability between requirements, behavior, and systems elements.
• Integration. Integrating the system components as well as integrating the system into the external
environment and transition to use.
• Verification and Validation. Prescribing a verification and validation program that will show the
system has been built correctly and that the correct system was built. Prescribing system and
lower-level tests to prove the system design.
• Integrated Product Development. Including production, support logistics, and operations in all
development activities. Ensuring appropriate requirements and design features are included,
appropriate tests are done, and the additional materials such as users’ manuals and system
training are available
From the early stages of analysis, often referred to in systems engineering as the concept exploration
stage, these multiple activities of systems engineering become intermixed. While requirements tend to
drive design, available technology often influences requirements. The analyst suggests requirements and
design decisions for alternative concepts of operation and comparatively evaluates the alternatives. Since
the technical knowledge of what is achievable resides in the design disciplines such as software
1
CMMI
and SE-CMM
are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.
4

development, an interactive approach between the systems engineering and all design disciplines is
essential.
2.2.2 MANAGEMENT ACTIVITIES
The management activities are included for reference but do not provide the types of information that is
defined as inputs to the OOASIS method. Management activities include:
• Planning and Tracking. Management of technical tasks, manage product line evolution, manage
technical support environment, coordinate technical groups internally, with customer, and with
suppliers
• Risk. Managing system risks, including risk identification, risk assessment, risk mitigation
recommendations, risk mitigation planning and funding, and finally, tracking of the risk profiles
to closure
• Other. Additional management tasks include conducting design reviews, configuration
management, management of product data, systems engineering processes, measurement,
documentation, support new business in developing concepts for proposal opportunities, and
provide and receive the appropriate training in systems engineering topics, including
understanding of the systems and their domains.
2.2.3 DISTINGUISHING ATTRIBUTES
Two significant attributes of systems engineering distinguish it from software development or the
development of any systems component. These are broader scope of responsibility and an external view.
2.2.3.1 Broad Scope
Systems engineering is, by nature, responsible for any and all components and their technologies. It must
also integrate the concerns of various functional areas such as manufacturing and logistics support and
technical specialties such as reliability, safety, security, survivability, and life-cycle cost. Most of these
areas have well established analysis techniques. It is the unique role and responsibility of systems
engineering to interface among these functional areas and their techniques, including software
development.
2.2.3.2 External View
Where each component development effort, including software, has primary responsibility for the
activities internal to that component, systems engineering has the responsibility for the external view.
This is particularly true at the system level where systems engineering has the primary responsibility for
external interfaces and assuring that the system will perform as intended within the external environment.
As will be discussed later, this is one area where the application of use cases has limited value and an
interface with other analysis techniques must be defined.
5

2.3 SOFTWARE DEVELOPMENT
The initial tasks in any software development include definition of the requirements and the software
architecture. The following steps are described in the context of the Consortium’s OOASIS and refer to
the use of Unified Modeling Language techniques. However, they are applicable to any software
development in that the actions and decisions defined are required regardless of specific method. Further,
the overall interaction with systems engineering as provided in later sections also remains valid.
OOASIS provides pragmatic guidance to the practicing engineer for systematically applying an OO
methodology for requirements capture, analysis, and design of a software-intensive system. The
expectation is that use of OOASIS will increase quality, reduce cycle time, and reduce maintenance cost
for developed systems over approaches that do not explicitly integrate systems and software engineering
and/or employ alternative (non-OO) techniques.
2.3.1 SCOPE OF OOASIS
OOASIS does not attempt to address all issues in systems and software engineering exhaustively. Instead,
OOASIS concentrates on a software perspective of system requirements and design, appropriate for
engineering a software-intensive system. Particularly in a predominantly software system, that
perspective includes a definition of behavioral requirements at the system level. The following paragraphs
describe the OOASIS technical activities. Figure 2 shows the OOASIS Software Development Flow.
Class Statecharts
and etc. from
previous tasks
Sys Use Cases
Elaborate architecture
Elaborate sys use cases
Sys SW Arch
Implement software
Thread Models
Define
Sys SW
Arch
Design
Node
SW
Define
Sys Req’s
Realize use cases
Define sys SW allocation
Define statecharts
Define concurrency
Elaborated Sys
Use Cases
Capture sys behavioral
req’s
Sys SW Arch
Class Statecharts
and etc. from
previous tasks
Sys Use Cases
Elaborate architecture
Elaborate sys use cases
Sys SW Arch
Implement software
Thread Models
Define
Sys SW
Arch
Design
Node
SW
Define
Sys Req’s
Realize use cases
Define sys SW allocation
Define statecharts
Define concurrency
Elaborated Sys
Use Cases
Capture sys behavioral
req’s
Sys SW Arch
Figure 2. OOASIS Software Development Flow
6

2.3.1.1 Define System Requirements
The first activity is translating broad, top-level conceptions of system goals and use into specific
behavioral requirements, elicited and captured via use cases. This includes explicitly noting volatilities
due to unresolved requirement choices or other alternate conceptions of the system, and incorporating
these into System Use Cases. This effort relies on broader needs analyses and studies that have resulted in
a system concept and scope sufficient to begin software definition.
2.3.1.1.1 Capture System Behavioral Requirements
This task either receives the top-level requirements definition as a Summary Use Case or creates it if not
available. The Summary Use Cases are then translated into a prioritized set of system requirements
expressed as System Use Cases. The structuring of requirements into use cases is intended to:
• Present requirements in a way that is easy for users, customers, and other stakeholders to
understand and review
• Decompose the problem into more manageable pieces
• Organize the requirements into a more structured form
• Avoid unnecessarily constraining the System Software Architecture
The decomposition of requirements by use case is done from the stakeholders' perspective. Each use case
provides a focus on closely related requirements. As a result, multiple analysts may concurrently
elaborate different use cases.
2.3.1.2 Define System Software Architecture
As the requirements are defined, the software developer will create a preliminary System Software
Architecture based on the design constraints implied by the system behavioral requirements. Software
functionality is decomposed into static elements (a class hierarchy) and their dynamic (runtime)
interaction defined. Initially, orient this decomposition by designing in flexibility, especially to address
volatilities enumerated in the System Use Cases. Define an initial deployment for the objects in the
software architecture across the system's physical architecture using the Node-Device-Connector (NDC)
Diagram (Appendix C.) making adjustments and additions to the software architecture as necessary.
Identify additional failure scenarios in Elaborated System Use Cases by analyzing how elements of this
combined hardware and deployed software architecture interact to support the System Use Cases. Adjust
the software architecture and its deployment for performance and other concerns (such as commercial and
legacy software to be incorporated into the system, as enumerated in the OTS Software Components) and
include additional details visible at the system level of the architecture.
2.3.1.2.1 Realize System Use Cases
At this point in OOASIS behavioral requirements are captured as System Use Cases. It is now necessary
to make explicit the essential design implications or constraints inherent in the System Use Cases. This
will yield an OO System Software Architecture. The goal of this activity is to take the first step toward
that objective: for each System Use Case, define classes representing the important abstractions in the
problem environment (static model). Then combine these static models for each use case into one
comprehensive static architecture. Finally, define the interactions among these objects for each use case
7

(dynamic architecture). Together, the static and dynamic system designs make up the initial System
Software Architecture.
2.3.1.2.2 Define System Software Allocation
Allocate the classes to significant nodes for runtime deployment. This task may identify necessary
modifications to the existing software architecture. Further adjustments may be necessary to address
performance concerns. Also, add (and determine the deployment for) other supporting classes (e.g.,
device interface classes).
2.3.1.2.3 Elaborate System Use Cases
Having decided what objects to deploy on which system Nodes, enough decisions have been made about
the internal system design to elaborate the System Use Cases. Significant nodes and devices from the
NDC Diagram become participants in performing the System Use Cases. With this white box approach to
the system, you can further usage details added and more failure conditions and use case alternate courses
discovered.
2.3.1.2.4 Elaborate System Software Architecture
Based on the insight provided by the Elaborated System Use Cases, the System Software Architecture can
now be completed. This should account for possible failure conditions across all system usage scenarios.
What remains is to add details about class operations and relationships. It is also appropriate to estimate
timing budgets for nodes and operations involved in performance-sensitive usage scenarios.
2.3.1.3 Design Node Software
With classes and their interactions well defined and objects having been deployed among the significant
nodes, this stage of OOASIS concentrates on the interactions of objects within a given (type of) node and
can proceed independently for different nodes. First, define the concurrency within each node. Finally,
create Class State charts for classes having complex state behavior.
2.3.1.3.1 Define Concurrency
This OOASIS task is optional and may be tailored out when no performance or reliability requirements
challenge the system design. In this part of OOASIS, define the concurrency of the software in each node.
The treatment of concurrency necessarily varies somewhat depending on the underlying
platform/technology used to implement concurrency. Therefore, OOASIS offers alternate steps relevant
to each type of platform.
Introduce Prioritizable Concurrent Elements (PCEs) into your design for:
• Temporal correctness (response time, device characteristics)
• Clarity (cohesion/interdependency of interacting objects)
• Reliability (distinguishing critical functions or, conversely, background functions)
8

OOASIS guides a developer to add concurrency only as justified by the requirements, with full
consideration to its potential disadvantages of:
• Increased complexity
• Reduced flexibility in design
• Increased overhead
In light of these drawbacks, OOASIS encourages particular care to understand the system's as-
implemented performance characteristics under its actual usage profile before attempting to fix presumed
performance or timing problems with additional concurrency.
2.3.1.3.2 Define Statecharts
This OOASIS task is also optional. In complex, real-time systems or those with stringent dependability or
safety concerns, it is beneficial to create a more detailed dynamic model of the more complex classes
(especially with multiple, interacting Prioritizable Concurrent Elements). To represent the objects in these
classes as finite state machines, develop statecharts for each class. These statecharts will explicitly capture
all states and state transitions of objects, including interactions among objects.
2.3.1.4 Implement Software
Implementation is currently outside the scope of OOASIS. However, this section offers some general
guidance that follows directly from previous OOASIS activities. The combination of the work products
listed as inputs to this activity should suffice as a specification to implement system code.
2.3.2 OOASIS INPUTS AND RELATED ACTIVITIES EXTERNAL ACTIVITIES
OOASIS presumes other project-related activities that precede and run in parallel with OOASIS activities.
These activities generate the work products that are inputs to the OOASIS method. Their relationship to
each OOASIS activity is shown in Table 1 in the following section. The OOASIS method also addresses
how to develop the information in cases where external activities do not exist. The following are the
primary inputs to the method:
• Stakeholders
• To-Be Process (optional)
• As-Is Process (optional)
• Summary Use Cases
• Context Diagram
• NDC Diagram
• OTS Software Components
• Hardware Interfaces
9

• OTS Software Interfaces
2.4 MAPPING SYSTEMS ENGINEERING TO SOFTWARE DEVELOPMENT
Table 1 maps systems engineering activities described in Section 2.2 and their products to the inputs and
activities in software development as described in Section 2.3. The initial systems engineering activities
are predominantly part of problem definition such as needs analysis, requirements analysis, and functional
analysis. The entry for program alternatives is a combination of architecting design, trade studies analysis
and management planning. The emphasis shifts to architecting and integration with increasing problem
definition and analysis details continuing.
Basic inputs to OOASIS are in bold. Additional inputs described in the OOASIS method are also listed
and their sources in systems engineering activities identified. Although the basic mapping indicates the
production of inputs to the software process, it is not intended that this be a one-way interface. In all
cases, the decisions must be made in collaboration.
Table 1. Systems Engineering/Software Interactions
OOASIS SE OOASIS SW
Task Output Input Task/Subtasks Output
Define System Req
Stakeholders,
Summary Use
Case, Context
Diagram
Obtain Summary Use
Case
Needs Analysis Statement of
Needs, Concept
of Operations
Stakeholders Identify Actors
Functional
Analysis
Top level
functions
Goals (top level
verb noun
objectives)
Identify System Use
Cases
As-is process
o-be processT
“Text” details
Detail System Use
Cases
Functional
Analysis,
Requirements
Analysis and
Allocation
Decomposed
functions and
performance
requirements
Alternate
success paths
Functional
Failure Analysis
Functional
failure modes
Potential
problems
Alternatives
System Use
Cases
10

Requirements
analysis
Volatility
estimates
Potential
requirements
changes
Program
Alternatives
Capability
sequence
Release
sequences
Variations
Identify Key
Requirements
Requirements
Priorities
System Priorities Prioritize System Use
Cases
Define SW Arch
System Use
Cases
Realize System Use Cases System SW
Arch
Define actor IF classes actor IF
classes
Find persistent entity
classes
persistent
entity classes
Functional
analysis and
allocation
Allocated
functional
description
Model the Use Cases as
Interaction Diagrams
Interaction
Diagrams
Combine classes into
single class diagram
Combine redundant
classes
Generalize classes
Add composition
Add associations
Evaluate against
variations
Class Diagram
Allocation and
System
Architecting
Systems
Architecture
NDC, OTS SW
Components
and Interfaces
Define System SW
Deployment
System SW
Deployment
11

Obtain NDC & OTS
SW info
Deploy Actor IF
Classes
Deploy Persistent
Entity Classes
Deploy OTS SW
components
Add Manager Classes
Elaborate Actor IF
classes
System Design,
Requirements
analysis, and
allocation
Bandwidth and
processing
requirements
Bandwidth and
processing
requirements
Redeploy for
Performance Concerns
Performance
adjusted SW
Arch
Sys Use Cases,
NDC, Sys SW
Depl Models,
Sys SW Arch
Elaborate System Use
Cases
Elaborated
System Use
Cases
Functional
Analysis and
allocation
Detailed
functions,
Functions per
node
Expand Main Scenario
Functional
Analysis,
Failure analysis
Alternate paths,
failure modes
Expand Alternate
courses
Requirements
analysis, system
design
alternatives
Potential
changes and
alternative
technologies
Expand variations
12

Systems Design
and Integration
HW interfaces Sys SW Depl
Models, Sys SW
Arch, Elab Sys
Use Cases
Elaborate System SW
Architecture
Elaborated
System SW
Architecture
Realize Elaborated
System Use Cases
New classes
Functional
analysis, N2,
requirements
allocation
Operations,
parameters,
returns,
conditions,
dependencies
Identify Operations Operation
descriptions
Check Classes
Elaborate Associations
Requirements
analysis,
timelines,
allocation
Timing budgets Assign Timing Budgets ??
NDC, Sys SW
Depl Models,
Sys SW Arch,
Elab Sys Use
Cases
Define Threads Threads
Functional
analysis
threads Define initial thread set
Functional
analysis,
timelines,
Allocation, Cost
trades
Timing info,
system
alternatives,
cost of
alternatives
Performance analysis
Functional
Analysis
State diagrams Define state charts Class state
charts
Systems Design Hardware
interfaces
HW Interfaces Design Node SW
13

2.5 INTERACTION GUIDANCE
The most significant, and least novel, point is that systems engineering and software development cannot
be done properly in series. As with any system component, any attempt to fully define the system absent
input from the software component or to unilaterally push down requirements or design decisions is
doomed to failure. As a consequence, the interface relies on parallel travel into the depths of the problem
and solution and constant communication between the parties. This was depicted in Figure 1 and a key
element of Table 1.
2.5.1 TOP-LEVEL DEFINITION/DEFINE SYSTEM REQUIREMENTS
At the highest level, the requirements definition must be done in a cooperative manner by the systems
engineering and software activities. On the system engineering side, this information will be included in
various products including needs statements, concepts of operations or top-level functional analysis. This
phase in OOASIS is Define Systems Requirements. The primary inputs identified for OOASIS software
development are identification of stakeholders, a summary use case or collection of system use cases or
goals that provide the information, and a context diagram. For systems that are principally software,
these two views may be near identical. For systems with more hardware involved, some preliminary
discussion of possible allocations will be necessary. In either case, the most likely difference in viewpoint
will be the extent to which the external processes need to be modeled and included in a complete analysis.
System
Ext I/F
Concept of Operations
•Who
•What
•Where
•Why
•When
•How much
•How many
•How well
•With what others
•…..
Business Process
Needs
Goals
Context Diagram
Stake-
Holders
Summary Use Case
Public User
Scientist
Maintenance
View Report
Download Data
Analyze Data
Admin Environment
Collect Data
<<depends>>
<<depends>>
<<depends>>
Environment
Readings
Samples
Analysis
Maintenance
Requests
System Usage Reports
System
Ext I/F
•Who
•What
•Where
•Why
•When
•How much
•How many
•How well
•With what others
•…..
Business Process
Needs
Goals
Context Diagram
Stake-
Holders
Summary Use Case
Public User
Scientist
Maintenance
View Report
Download Data
Analyze Data
Admin Environment
Collect Data
<<depends>>
<<depends>>
<<depends>>
Environment
Readings
Samples
Analysis
Maintenance
Requests
System Usage Reports
Figure 3. Top-Level Interactions
2.5.1.1 Stating the Problem
The requirements as provided are not always optimal. Sometimes customers request a particular design
solution because that is the design solution with which the customer is familiar, but the systems engineer
knows or suspects some other solution may meet the need better. Design parameters in specifications
have been so common in the past, in fact, that the government has undergone a large and expensive effort
14

to move toward performance specifications. The job of stating the real problem is not easy, as it involves
considerable thought about the suggested solution, backing off to the need that the solution will or
probably is intended to satisfy, and looking at what parameters of the problem are likely to be the most
critical or most problematic to address, as they will be the key drivers for the system to be built.
2.5.1.2 Eliciting Customer Need
Often customers know they have a problem, but aren’t quite sure what technology exists to solve it. Nor
do they know what the technology is capable of solving other than the obvious problem. As a result,
requirements written solely by customers have a tendency to be incomplete, in the sense that building a
system to meet the requirements and no more and no less will not in fact make the customer happy.
(There have been many cases of this in the development of software systems). Experienced systems
engineers know that it is important to actively elicit what the actual needs are. This can be accomplished
through structured and formal sessions with users, asking why requirements are specified in order to get
at the underlying need, showing prototypes to the customers and asking for feedback, or keeping the
customer intimately involved in systems engineering activities throughout the life cycle. Additionally,
needs should be elicited by reviewing the operational concept and operational scenarios (see below). In
this way, the systems engineers ensure that the requirements will completely and accurately capture what
is actually needed by the official customer, usually a contracting organization, and by the end users.
A needs analysis, business case analysis, mission analysis or other similar analysis establishes the basic
nature and rationale for the system to be built. The analysis identifies Stakeholders and their strategic
goals that the to-be-built system will help to satisfy that will define the basics of the Summary Use Case.
An analyst may establish quantitative "measures of effectiveness" for these strategic goals to help predict
and track whether the new system is achieving those goals. In a government project, a prior Mission
Statement or Request for Proposal may have predetermined the scope of analysis and much of the
information discussed here as initial inputs into OOASIS.
2.5.1.3 Concept of Operations
This task documents how any current system is used and how the new system is expected to be used in an
operational concept and operational scenarios. The generation of a concept of operations usually involves
the actual users of the current system. In some cases the customer creates an operational concept. Then
systems engineering must review and understand this work product and may provide comments and
questions to assure full understanding.
A proposed concept of operations, or its equivalent by any name, defines a single, cohesive vision of the
system to be built. The OOASIS method assumes the prior existence of that vision to initially sketch at
least the broad outlines of the system of interest, even if there are alternative system conceptions being
pursued and evaluated in parallel, and even if the system concept at hand has a number of unresolved
options or details. A particular Concept of Operations entails or suggests a specific To-Be Process.
Embedded within the To-Be Process are the interactions between the to-be-built system and the external
world that constitute the Context Diagram and Summary Use Case.
Whether or not a specific document is created called a Concept of Operations, the systems engineering
efforts must include a definition of how the system will be used and supported. One problem is that most
concept of operations documents emphasize the final system design. For the final version, this is
appropriate. However, the error that often occurs is to overemphasize the solution on the first version.
15

This approach will further cause the early forcing of hardware architecture limitations on the software
development.
To correct this, the initial iterations should focus on the scenarios defining what the system is supposed to
accomplish in which situations and how it will be applied to operations. This will support the
development of use cases without unnecessarily restricting the software architecture.
2.5.1.4 Requirements Analysis
Requirements analysis will define the priorities particulars of how well the systems is to perform. It will
also identify other desirable properties of the to-be-built system that may not be captured directly in use
cases. These should relate to the original strategic goals of the Stakeholders. The analyst may also
quantify these non-behavioral requirements (e.g., "97% availability" or “20 % small business
participation”). Appropriate information must be conveyed to the software effort along with the use case
data.
Part of requirements analysis should be identification of the customer’s priorities. These priorities should
always be passed on to the component developers. In the cases where all requirements cannot be fully
met, the priorities will guide the most beneficial application of resources.
Requirements also should be analyzed for potential volatility. Which requirements are most likely to
change and which will probably stay unchanged? The impact of this information has long been identified
as critical to software development. Yet it is often overlooked.
2.5.1.5 Functional Analysis
A key stakeholder is the group that will be using some process to operate and use the to-be-built system
(e.g., a new accounting application must be incorporated into the procedures of the Accounting and
Finance Departments). In this example, the existing accounting procedures, i.e., the As-Is Process,
represents the parent system, involving not only interactions of accountants with the to-be-built
application, but also other interactions beyond the scope of the new system. The new accounting
application provides the opportunity to improve the as-is process as well, resulting in a new To-Be
Process matched with the to-be-built application. Thus, the analyst may be setting requirements for the
new system while concurrently reengineering the parent system. Understanding both the current and
future behavior is the focus of functional analysis.
2.5.2 LOWER-LEVEL INTERACTIONS/SOFTWARE DEVELOPMENT
In addition to the interfaces described in 2.5.1, the systems engineering activities continue to interact with
the software activities to provide additional inputs. In many cases, the interaction is to continue to amplify
the initial information as detail decisions are made, as is the case with an evolving concept of operations.
Other activities that provide new information are described below.
16

System Use Case
•Details
•Alternatives
•Variations
•Priorities
•Elaborations
•How will
alternative
solutions be
operated and
maintained
•New constraints
and requirements
Functional An
System
Arch
Include Failures
Req’s
Trade Studies
:
System Use Case
•Details
•Alternatives
•Variations
•Priorities
•Elaborations
•How will
alternative
solutions be
operated and
maintained
•New constraints
and requirements
Functional An
System
Arch
Include Failures
Req’s
Trade Studies
:
Figure 4. Mid-Level Interactions
2.5.2.1 Functional Failure Analysis
Both systems engineering and software need to consider the impact of errors and failures on system and
component performance. Functional failure analysis allows the consideration of what can possibly go
wrong without requiring the specific knowledge design and components. This information can be
provided to the software developer as possible failure conditions that should be considered for response in
the design and raise alternatives that need to be considered. Conversely, the software developer should
communicate back to the systems engineer what the likely impacts of various failures might be and what
additional failures should be analyzed.
Because software can be more easily deployed in upgrades than hardware, the application of spiral
development is frequently used and results in incremental implementation of capabilities. As systems
engineering reviews systems alternatives and priorities, this information can help in determining the
appropriate capability sequences.
2.5.2.2 Design and Deployment
As hardware technology options are selected and an architecture is developed, the deployment of software
to processing locations in the system will evolve. However, this must be a negotiated process. This is not
only an issue with object-oriented software and will be discussed as a general problem.
Analyses apart from those currently encompassed by OOASIS determine the system design for hardware
and any other non-software aspects of the system. The NDC Diagram presents the results of these
decisions relevant to software design. These activities operate in parallel with OOASIS, coordinating
decisions on the non-software portion of the system with the software design.
Similarly, the selection of OTS Software Components to be used in construction of the system occurs
externally to OOASIS. OTS Software Components are either asserted by Stakeholders (e.g., a legacy
system that is infeasible to replace), or they are evaluated and selected based on software functional needs
drawn from preliminary versions of the System Software Architecture and System Software Deployment
17

Models. These parallel activities to elaborate the definition and/or selection of physical architecture and
OTS components continue until they result in detailed Hardware Interfaces and OTS Software
Interfaces. These support low-level software design (elaboration of the System Software Architecture)
and coding.
2.5.3 GENERAL INTERFACE ISSUES
2.5.3.1 Balancing Architecture Decisions
One of the hottest issues between software developers and systems engineers revolves around old
approaches to allocation and architecture decisions. In a more classic approach, functionality is allocated
to system components and a hardware/software decision is made within each box. In modern software
intensive systems, location of specific software functionality is much less of or no concern at all. Software
developers can and prefer to develop the internal architecture of the software and then distribute it as
makes sense from a processing view. This means that attempts to force distribution to specific hardware
locations is both less than optimal from a software performance standpoint and not well received by the
software community. As a result, the systems engineer must recognize this need for delaying deployment
decisions until later in the development process and resist the urge to force functional allocations early in
the process.
On the other hand, there are often constraints and lead times that the systems engineer faces that the
software developer must be responsive to. One of the historic examples is communications limitations.
There are lots of examples of software designs that worked well on paper or on prototype systems but
could not be used in the real world. Some have been limited by security concerns, others by real world
capabilities that were as much as four orders of magnitude less than desired. The software developer must
be ready to face these constraints and work with the systems engineer to provide an optimum
compromise.
A factor in this difference of viewpoint between the two disciplines is the internal versus external view.
This is not peculiar to software. The design discipline of any component needs to focus on the internal
design of the component in question. By definition, it is the responsibility of systems engineering to
assure that those components work with the other components so that the system does what it is supposed
to. Both the systems engineer and the software engineer must be aware and live by some basic tenets.
1. The systems and software architectures are not the same thing.
The systems engineer must recognize that a software architecture needs to be developed based on the
problems to be solved in software and the actor interfaces. Negotiation of impact on system elements
should be expected as part of the software deployment activity.
2. The systems and software architectures are not totally independent.
The software developer must recognize that systems constraints and lead times require early definition of
software architecture constraints. For instance, communications limitations between two geographically
separate nodes may constrain the deployment options and force the software architecture to limit the
internode data
18

An example of the need to understand the external processes is the current effort within the air
transportation industry to add a data link capability. This system will allow pilots and controllers to pass
messages in addition to voice communications to increase the effectiveness of air traffic control. To the
software designers, the handling of message traffic can be shown in UML with the controllers and pilots
as principal actors and the software within the system described in use cases and interaction diagrams. At
the systems level, the critical factors driving the usability of the datalink concept involve the workloads of
both the pilot and controller. In order to understand these, the analyst must understand, model, and test the
activities external to the datalink system. These analyses are better supported by methods such as the
behavior diagram or other static or dynamic models.
2.5.3.2 Over- and Under-specifying
As with any component, the correct balance of specification detail is difficult to find. If the systems
engineer is unfamiliar with the issues of design that affect that discipline, it will be more difficult to
achieve the balance. If there is not an active, bi-directional communication channel in place, it will be
impossible. This is often even truer for software components.
An example of under-specification is the system that required the software to automatically reconfigure
the network if one of the links failed. No further guidance was provided. The expectation was that the
software designers could figure it out from there. After all, the maintenance crew did this regularly in the
current system.
A better approach is to be responsive to the questions that a software developer asks about the
requirement such as what reconfigurations are viable, what capabilities have priority, how many failures
must be handled, how long do we have to reconfigure, what should be done when a link comes back on
line, etc.
Over-specification, as with any component, is usually the result of forcing design rather than providing
the constraints that drive it. A typical example would be requiring either a look-up table or an algorithm
calculation rather than the accuracy requirements and letting the software developer choose the most
effective solution.
2.5.4 SE AND UML
UML has been developed as a unification of software analysis techniques. As such, it should not be
surprising that it does not yet fully cover the needs of systems engineering. This has been recognized
within the Object Management Group and a Systems Engineering Domain Special Interest Group within
OMG has issued a Request For Proposal for changes to the UML to improve coverage of systems
engineering needs. This effort is being jointly conducted with the International Council on Systems
Engineering (INCOSE). Some of the principal requirements are expanded capabilities in defining
complex behavior, systems elements, interfaces, allocation, and traceability.
It is anticipated that most of the requirements will be addressed by changes to the UML. There may be
some additional diagrams added in this effort or future changes to the UML. Beyond the scope of current
changes are various analysis techniques that have been developed by “specialty” disciplines to address
their peculiar concerns. Among them is Systems Safety with Failure Mode Analysis and Fault Tree
Analysis and testing with Design of Experiments methods for resolving issues involving complex
19

interactions and multiple alternatives. These may be incorporated at a later date or may remain an external
set of techniques that will need to interface with UML analysis as appropriate.
Another example of external analysis interfacing with the UML would be the allocation of software’s
contribution to a classic hardware property such as the range of an aircraft. Typical analysis provides
equations or mathematical model making range a function of weight, drag, lift, specific fuel consumption
and other constraints. If the design relies on software to maintain optimum attitude to affect range, that
can be included in the mathematics and the allocations recorded in the analysis. This will then be a
requirements input to the UML analysis.
2.6 SUMMARY
There are three main points that are addressed in this report.
• Systems engineering and software development techniques have been developed to address
different specific issues and concerns. However, they do overlap and the overlap increases as the
proportion of software content increases.
• Information that is common to both areas must be identified and properly exchanged.
• Systems engineering and software development should be conducted in parallel and integrated.
Doing them sequentially in an over-the-wall manner generates severe problems.
20

3. APPLYING IDEF METHODS TO DEVELOP
OOASIS INFORMATION REQUIREMENTS
The OOASIS method identifies nine information artifacts that it assumes are generated by activities that
are external to the core software-oriented activities of OOASIS. OOASIS treats these primarily as inputs
to the OOASIS method:
• Stakeholders
• Context Diagram
• As-Is Process
• To-Be Process
• NDC Diagram
The IDEF0 method is often used to perform the functional or behavioral analysis of a system. Although
some of the information is principally developed and recorded using other techniques such as concept of
operations and system architecture views, IDEF0 contains most of the information needed for the
OOASIS inputs. The application of the IDEF0 method demonstrates how this systems engineering
method may be used to satisfy some or all of the information needs represented by these artifacts. The
OOASIS information requirements represented by the first six artifacts may be fully addressed using the
IDEF0 method. The three artifacts representing OTS software and hardware components and their
interfaces are not fully addressed, but the specific components and interfaces required to meet system
requirements are identified using the IDEF0 method.
A case study using IDEF0 is provided in the appendices to this report for those interested in more details
on how that method can be applied to the software interface needs.
21

3. Applying IDEF Methods to Develop OOASIS Information Requirements
22

A.RELATING IDEF METHODS TO OOASIS
A.1 PART I. APPLYING THE IDEF0 METHOD
The OOASIS method identifies nine information artifacts that it assumes are generated by activities that
are external to the core software-oriented activities of OOASIS. OOASIS treats these primarily as inputs
to the OOASIS method:
• Stakeholders
• Context Diagram
• As-Is Process
• To-Be Process
• NDC Diagram
The OOASIS information requirements represented by the first six artifacts may be fully addressed using
the IDEF0 method. The three artifacts representing OTS software and hardware components and their
interfaces are not fully addressed, but the specific components and interfaces required to meet system
requirements are identified using the IDEF0 method as described here.
This approach to IDEF0 analyses is based upon IEEE 1320.1-1998 and the IDEF0 models developed here
comply with this standard. For the remainder of this document, unless otherwise specified, the term model
refers to an IDEF0 model. A requirements model refers to a fully decomposed IDEF0 model in which
mechanisms have not been specified. An architecture model refers to a fully decomposed IDEF0 model in
which mechanisms have been specified for all activities.
The focus of this appendix is not to teach IDEF0 modeling; we assume that the reader has some
familiarity with the IDEF0 method. The focus is first on ensuring that OOASIS information requirements
are addressed during IDEF0 model analysis and construction and second on translating this information
into artifacts understood by and useful to OOASIS and other software engineers.
23

A. Relating IDEF Methods to OOASIS Information Needs
The basis of this work is the Buoy System case study presented by the OOASIS course and website as the
vehicle for demonstrating this application. However, to reduce the number of systemic interfaces to a
manageable handful, we have recast the characters of this case study so that the problem is not deeply
embedded in a context of existing organizations and systems. We have invented the island nation of Santa
Narida to be the customer for our buoy system; the backstory about Santa Narida is given in Appendix B.
A.1.1 OVERVIEW OF METHOD
To develop the information needed by OOASIS software designers, the systems engineer will build a
family of IDEF0 models whose information elements will be mapped to the input artifacts specified by
OOASIS. Each step in the method builds upon information developed by previous steps.
1. Identify and gather source material preparatory to developing IDEF0 models.
2. Build a family of models of the interests of external stakeholders. These include models are additional
to IDEF0 but depend on the information contained in IDEF0 with a focus on stakeholder behavior.
[These models will satisfy the OOASIS requirement for external stakeholder and summary use case
information.]
3. Build a family of environmental context models for the prospective system. These models are
organized around principle outputs to satisfy the interests of external stakeholders. These models
consolidate stakeholder interests from the perspective of the prospective system. These models treat
the prospective system as a black box. [These models will satisfy the OOASIS requirement for context
and external stakeholder information.]
4. If appropriate, build an architecture model(s) of any existing system(s), to include environment
context diagrams. If you are re-engineering a system, an architecture model of the existing system is
always appropriate. If you are building a new system to provide completely new behavior, the need
for an architecture model of existing behavior is problematic and will need to be established. The
systems engineering process will generally use depictions of architecture which are additional to
IDEF0. The information in these models ties to the mechanisms in IDEF0. [This model(s) will satisfy
the OOASIS requirement for AS-IS context, external stakeholder, and process information.]
5. Build a family of requirements models for the prospective system. These requirements models
decompose the system behavior (i.e., the A0 activity) specified by the environmental context models.
The first iteration of these models will focus on expected, correct behavior (the simplest, shortest,
successful path to achieving a goal(s)). (A corollary of this modeling objective is that these
requirements models may not use call arrows.) [These models will satisfy the OOASIS requirement
for context, external stakeholder, and TO-BE process information.]
6. Build a family of architecture models for the prospective system. The architecture models allocate
mechanisms to the decomposed system behavior of the requirements models. Particular attention will
be paid in this allocation to identify internal stakeholders and COTS hardware and software. Note that
this allocation will be exploratory and tentative. The systems engineering process will generally use
depictions of architecture which are additional to IDEF0. The information in these models ties to the
mechanisms in IDEF0. [These models will satisfy the OOASIS requirement for context, external
stakeholder, and process information. In addition, these models will identify internal stakeholders,
COTS software, COTS hardware, and their interfaces.]
24

7. Build a family of system use case models. These system use case models partition and coalesce the
architecture models to specify software system boundaries and actors in a way that may be translated
directly into use case notation. [These models will satisfy OOASIS requirements for system use
cases.]
8. Build a family of NDC models. These NDC models partition and coalesce the architecture models to
specify the nodes, devices, and connectors in a way that may be translated directly into NDC diagram
notation. [These models will satisfy OOASIS requirements for NDC diagrams.]
At this point, a consistent set of information and guidance for OOASIS software practitioners should be
available. We turn attention now to exploration of (1) anomalous behaviors, (2) alternative behaviors, and
(3) enumerated behaviors. Consideration of anomalous behaviors will introduce fractal patterns into our
requirements models. Call arrows and submodels will be introduced when we consider alternative
behaviors and enumerated behaviors. The following steps will elaborate the requirements and architecture
models that we have already developed.
9. Enumerated behaviors. Extend each model in the requirements family by considering activities that
represent sets of related but mutually exclusive behaviors. (These may sometimes be inappropriately
represented by a ladder pattern in a decomposition diagram, i.e., no coupling between parallel
activities.) Such enumerated behaviors are to be represented by submodels invoked by a call arrow.
[These extensions will assist the OOASIS analysis of alternate courses and variations for system use
cases.]
10. Alternative behaviors. Extend each model in the requirements family by considering additional ways
of accomplishing the objectives of each activity, i.e., alternative decompositions. These should be
first developed as FEO pages and then migrated to submodels. Such alternative behaviors are to be
represented by submodels invoked by a call arrow. [These extensions will assist the OOASIS analysis
of alternate courses and variations for system use cases.]
11. Anomalous behaviors. Extend each model in the requirements family by considering patterns of
anomaly detection and recovery for each activity. We provide a template of fractal patterns that may
be used to guide this analysis. [These extensions will assist the OOASIS analysis of alternate courses
and variations for system use cases.]
These steps generally refer to a “family of models.” This does not imply that every exercise will
necessarily generate multiple models; a family may have only one model. How large such a family might
be will depend upon the complexity of the prospective system and the intensity of issues to be resolved to
provide adequate requirements and design guidance.
This paper discusses a recommended method for accomplishing Steps 1 though 8. Steps 9 through 11 will
be treated in a subsequent release.
Step 1. Develop a consistent understanding of system need.
• Identify and gather existing source fragments that state various aspects of the stakeholders’
problems. As in the real world, fragments of useful information are in different places. For this
case study, one set of fragments comes from the OOASIS website, another from the OOASIS
course, and the final set is the Santa Narida backstory. The OOASIS website and OOASIS course
material have been slightly edited to ensure that they are consistent with the Santa Narida
backstory. The OOASIS website teaches:
25

“A widespread fleet of buoys collects environmental data and feeds it periodically through
satellites to a land-based storage facility. Users of the system request subsets of the data and
perform analyses upon these.
The Meteorological Data system is sponsored by a government agency to provide environmental
data (mostly weather related) and analysis to scientists and the general public. The agency's goals
for this system are to provide real-time and historical data (archived from the real-time data
stream) on temperature, wind, and other conditions in a broad swath of ocean. The overall concept
for this system is that the agency will develop, deploy and maintain floating data collection buoys
throughout the area of interest. The buoys will periodically communicate their collected data
through commercial (or standard OTS) satellites to a land-based data center, where staff scientists
can access the data and run analyses from their workstations. A Web site will provide public
access to the data.
In particular, you know that the physical architecture involves buoys communicating to a land
station via satellite, and users employing work stations to access this data (probably via a large
server).”
The OOASIS course adds these thoughts:
“The case study we will use for every example will be a weather data collection system. The
system collects data from buoys floating in the Pacific Ocean and sends the data back for the land-
based subsystem to archive for future use. The buoys send the data via a satellite provided by an
international agency. The bandwidth allocations are of sufficient size as to support 6 samples per
minute for each of the 1000 buoys. If the satellite becomes over used, it may require several
orbital passes to complete these buoy transmissions.
The primary users are research scientists who perform complicated analyses on the data. Some of
the analysis is to be done by this new system, and other tools will do other analyses. Therefore,
the system must allow the scientists to download the data into a standard format for import into
other tools. The contract requires the ability for Web access. The Web access for external
scientists and general public users will be limited to downloading data; commercial shipping route
planners may access specialized weather-dependent route-planning applications.. In case of
system performance problems, route planners get priority over external scientists, and the external
scientists get priority over general public users.
Administrators of the program will be given access to the system for report generation. The data
for these reports will be based on data collected about system usage and stored in a database for
retrieval. The reports themselves need not be saved because they can be regenerated as needed.”
• Consolidate fragments into a set of statements that can be compared, contrasted, and evaluated for
consistency by building exploratory models. These models should identify points of ignorance,
ambiguities, contradictions, and assumptions as reader notes in model diagrams. The first set of
these exploratory models examines the interests of external stakeholders.
Step 2. Identify the Prospective System’s External Stakeholders
In this step we construct a family of stakeholder models. These models are concerned with stakeholders
who are external to the system; these stakeholders use the outputs of our prospective system or provide
inputs, mechanisms, or constraints for the system. (Other internal stakeholders will be developed later;
these internal stakeholders will be external to software behavior within the system. For internal
stakeholders, the prospective system is their job.)
26

We build a separate model for each distinct stakeholder (or class of fungible stakeholders). Start each
stakeholder model with this purpose statement:
To describe this stakeholder's interest in the prospective system and how the prospective system
will satisfy that interest from the stakeholder's viewpoint.
(As you gain understanding of the stakeholder’s interest, you may substitute a more pointed purpose
statement.)
Begin each stakeholder model by representing both the stakeholder and the prospective system as
mechanisms of the A0 function, that is, as means for satisfying the stakeholder’s interest.
Represent the observable manifestation of the stakeholder’s interest as output of the A0 function. The
primary output of the A0 function will be the output of interest to that stakeholder, at whatever level of
abstraction is appropriate for that stakeholder. In particular, this output is not an output of the prospective
system. This output is the output that the stakeholder will produce using the output of the prospective
system: the A0 output in a stakeholder model represents the outcome or results of operation of the
prospective system, not the outputs of the prospective system itself.
For our case study, we have developed eight stakeholder models, one each for
• The internal scientist as weather forecaster (forecaster)
• The external institute scientist (institute)
• The buoy maintenance organization (maintenance)
• The satellite communications provider (satellite provided)
• The management of the National Weather Service (customer)
• The shipping route planner (shipper)
• The national television weather show (weather media)
• The tsunami warning center (tsunami).
We will not provide a model for the environment as the provider of meteorological phenomena.
Each of these models will consist of just three pages: an A-0 diagram, an A0 diagram, and an A0T text
page. You should not expect nor need to raise the publication status of the diagrams of these stakeholder
models above working. To a traditional IDEF0 modeler, these stakeholder models will look somewhat
odd. We assume in the perspective of a stakeholder a certain lack of concern for anything other than what
directly supports the stakeholder’s interest. Thus, unlike a complete requirements or design model, in
which we must provide a total mapping of inputs to outputs and vice versa, our stakeholder models may
cheerfully ignore inputs and/or outputs that logic would require but that stakeholder may well be
oblivious to or ignorant of. (This is one reason why the diagrams will remains at the working level.)
The A0 diagrams of our stakeholder models follow:
27

Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader DateAKBocast
OOASIS SE
P.
<work>
Model: Stakeholder: Weather M edia (SWM )
Page:
A-0
AKB3 3
x12/20/2001
Present WeatherA0
I2
GOO S Imagery
C2 W e at he r S how F ormat
C3 Broadc ast S c he dule
O1
W eather S ho w
M 1 Nat ional W e at he r S e rv ic e
M 2 T e le v ision S t udio
M 3 W e a t he r Pre se nt e r
M 4 S ant a Narida Buoy S y st e m
W rit e S c ript
3
M ix B ac kdrop
2
Re ad S c ript
4
Oral Pre s e nt at ion
S c ript
F orec ast
W e at he r
1
O c ean Image ry
F ore c ast T e xt
F ore c ast Produc t s
I1
O cean O b s ervatio ns
Produc t Re que st s
C1 Ima ge S t a ndards
V isual Pre se nt at ion
Diagram 1. SWM/A0 (Present Weather)
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader DateAKBocast
OOASIS SE
P.
<work>
Model: Stakeholder: Tsunami Warning System (STW)
Page:
A-0
2
x12/20/2001
Produce Tsunami WarningsA0
I1
Oc e anographic Dat a
C 2 D ata S haring A g reem ent
O 1
T sunami W arning
M 1 T sunami W a rning S y st e mM 2 S ant a Narida Buo y S y st e m
Pro vid e
T s un am i
Pred ictio n
D a ta
1
Fus e
T s unami
S o urces
3
Pred ict
T s unam i
4
F use d T sunami Dat a
C3 T sunami Pre dic t ion M ode ls
S N O O R Tsunami Dat a
R eceive
D ata
2
Re c e iv e d T sunami Data
M ail Clie ntM ail S e rv e r
C 1 Int e rnet M ail Prot oc ols
28

Diagram 2. STW/A0 (Produce Tsunami Warnings)
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader DateAKBocast
OOASIS SE
P.
Model: Stakeholder: Institute Scientist (SIS)
Page:
A-0
AKB2 2
x12/20/2001
Research Ocean Weather PhenomenaA0
I1
O c e an O bse rv able s
C3 Re se arc h A ge nda
O1
Re se arc h Produc t s
M 3 Inst it ut e S c ient ist
C ap ture
O ce an D ata
1
S tag e
O cean Data
2
S tud y
O cean
W eathe r
3
D atas et R eques ts
R eq ues ted D atas ets
Oc e an Dat a
C 2 Dat ase t S pec ific at ions
M 2 Inst it ut e for M id- Pac ific O c e an M e t e orology
W e b Browse r
W e b S e rv e r
C1 Observ at ion S pec ific at ions
T asking
Diagram 3. SIS/A0 (Research Ocean Weather Phenomena)
29

Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader DateAKBocast
OOASIS SE
P.
Model: Stakeholder: Route Planner (SRP)
Page:
A-0
AKB3 2
x12/20/2001
Plan Ship ItineraryA0
C3 C ust ome r Re quireme nt s
O1
Rout e Plan
M 2 Rout e Planne r
Fo recas t
R o ute- S p ecific
W eather
2
Es tim ate
V es s el
S ched ules
3
D eterm ine
Feas ib le
R o utes
1
S elect
O p tim um
Itinerary
4
C2 Resourc e M inimizat ion S t rat e gy
Websit e
I1
Rout ing A lt e rnat iv e s
Fe asible Rout e s
W eather- Pro filed R o utes
R o ute- V es s el- S ched ule Es tim ates
C1 V e sse l Cha ra c te rist ic s
M 1 W e b Brow se r
I2
O c e an W e at he r Dat a
De st inat ions
S che dules
Diagram 4. SRP/A0 (Plan Ship Itinerary)
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader DateAKBocast
OOASIS SE
P.
Model: Stakeholder: Weather Forecaster (SWF)
Page:
A-0
AKB2 2
x12/20/2001
Forecast WeatherA0
I1
Oc e an Obse rv able s
C2 O ut look S c he dule
O1
F ore c ast Produc t s
M 1 W e at he r F ore c ast e rs
M2 Nat ional W e at he r S e rv ic e
C o lle ct D ata
1
Pus h D ata
2
Mo d el
W eather
3
Pub lis h
Fo recas ts
4
C 1 W e at her M ode l Re quire me nt s
Hist oric al Dat a
Proje c t e d Dat a
M e t e orology Dat aset s
30

Diagram 5. SWF/A0 (Forecast Weather)
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader DateAKBocast
OOASIS SE
P.
Model: Stakeholder: National Weather Service (SNW)
Page:
A-0
AKB2 2
x12/20/2001
Increase Puerta Oveida Market ShareA0
I2
Unde c ide d Rout ing Que st ions
C 3 M inist e rial Que st ions
O1
Ministerial Reports
O 2
F av orable Rout ing Dec isions
M 2 NW S Gene ral M anage r
M 3 S ant a Narida Buoy S y st e mM 1 S hipper
Pro vid e
W eather
In fo rm atio n
1
S elect
S hip p ing
Itinerary
2
Pro v id e
R ep o rts
3
I1
W e at he r Obse rvable s
W e at he r C onst raint s
W e bsit e A c t iv it y Re port s
C2 F ore c ast ing S c he dule
Buoy A c t iv it y Re port s
S y st e m A c t iv it y Re port s
Buoys W ebsit e S y st e m A dminist rat or
1 Actvity reports include
maintenance activity.
C1 S hipme nt Re quire ment s
Diagram 6. SNW/A0 (Increase Puerta Oveida Market Share)
31

Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader DateAKBocast
OOASIS SE
P.
Model: Stakeholder: Satellite Provider (SSP)
Page:
A-0
2
x12/20/2001
Deliver DataA0
I1
F ie ld Obse rv at ions
C1 Communic at ions Prot oc ols
C 2 S e rvic e A gre e me nt
O 1
D e liv e re d Dat a
M 2 A rgos M 3 W orld W e at he r W at c h
S end
C o m m and s
1
Mo ve
C o m m and s
2
S end D ata
3
R eceive
D ata
4
Mo ve D ata
5
A rch ive
D ata
6
O 2
A rc hiv e d Dat a
W e b Brow se r
T ransmit t ed Dat a
S ent D ata
T ransmit t e d Commands
S e nt Commands
W e b Brow se r
S at e llit e Prot oc ols
W e b Prot oc ols
W eb Prot oc ols
Buoy T ransc e iv er
Diagram 7. SSP/A0 (Deliver Data)
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader DateAKBocast
OOASIS SE
P.
<work>
Model: Stakeholder: NOAA M aintenance (SNM )
Page:
A-0
AKB2 2
x12/20/2001
Maintain BuoysA0
I1
Broke n Buoy
C1 M aint e nanc e T re at y
O 1
W orking Buoy
M 1 S ant a Narida Buoy S y st e m M 2 NOA A M 3 Pac ific Obse rv e r
R eq u es t
Maintenance
A ctio n
1
D irect
Maintenance
A ctio n
2
Fix B uo y
3
M aint ena nc e O rde r
M aint e nanc e Re que st
C2 Buoy T e c hnic al Dat a
M aint e nanc e Re port
M aint e nanc e Re c ord
M a int e nanc e Hist ory
M aint e nanc e Not ific at ion
Diagram 8. SNM/A0 (Maintain Buoys)
32

Verification. By textual exegesis.
Validation. By consensus.
Step 3. Identify Current Processes, if any
In general, you will develop an exploratory AS-IS model of the problem. This model will reveal current
business processes, if any. As we develop the TO-BE model, the AS-IS model will provide some
combination of two primary kinds of information. First, it may describe ongoing processes with which the
system concept will need to interact. Second, it may describe a legacy baseline for engineering an
improved or replacement system.
(In this case study, this step will be conveniently skipped; the terms of reference for the case study have
been adroitly chosen to preclude the need for an AS-IS model. Our prospective system will provide
completely new behavior and resources for its relevant stakeholders, with two exceptions: the Santa
Narida National Weather Service scientists and the Televisio Santa Narida weather shows. For these two
stakeholders, the behavior of the prospective system will be strictly additive; no existing behavior will be
replaced.)
Step 4. Identify Behaviors for the Prospective System
In this step, you will develop one or more requirements models (shorthand for models of behavioral
requirements) for the prospective system.
Determining How Many Models To Create
As the primary source for your analysis, you will use the external stakeholder models developed in Step
1. You will determine the minimal set of outputs required too satisfy the interests of the specified
stakeholders. Each model should bring focus to a coherent set of related outputs. Begin by creating two
models, each containing an A-0 and an A-1 diagram. If you use the requirements model template
provided by the Consortium, the A-1 diagram will be seeded with five activities: A-11, A-12, A-13, A0,
and A-15; note that the A0 function will initially be the fourth activity in the A-1 diagram.
One reason that we suggest you begin with two unpopulated models is to help you overcome the mindset
that one single model is sufficient for requirements analysis. Remember that the basic epistemological
intent of any analysis is to break a problem down into manageable parts. If we should set as our goal that
one model should include everything, we would violate our basic principles of analysis and design. Our
goal is not to produce one model but to produce and integrated and consistent set of information that
contains the minimal and sufficient information needed by an OOASIS practitioner. (Of course, this does
not preclude the possibility that our analysis may coalesce and conclude with one model.)
• Group the stakeholder models by characteristics that will help you find themes and affinities
among them. We have grouped our case study stakeholder models like this:
Affinity Grouping of Stakeholder Models
Grouping Concept: User of System Products Provider of System
Resources
Comments
Stakeholders: forecaster
institute
shipper
media
communications
maintenance
customer
33

tsunami
• Consider the canonical form for the A-1 diagram suggested by the requirements model template.
Assign stakeholders identified by the stakeholder models to this table.
Template Grouping of Stakeholder Models
User ProviderGrouping
Concept: Outputs Controls Inputs Mechanisms
institute
shipper
media
tsunami
customer communications
maintenance
This template grouping is consistent with the tentative affinity grouping, but this grouping points out that
our assessment of external stakeholders — which is based strictly on our source evidence — may be
insufficient. In particular, we realize that we have not as yet recognized any external stakeholders who
may be required to provide inputs for our prospective system.
One clear source of input is the environment, which provides the meteorological observables that will be
measured and reported by the case study system. Other than such observables, consideration of our buoy
system does not immediately offer further sources of input for the operational system. Inputs required for
maintenance seem, at least as far as we now know, the responsibility of the maintenance organization
rather than of the prospective system directly.
The environment will definitely be identified as an actor because it is the source of observations (e.g.,
measurements, signals). It may or may not be identified as a stakeholder depending on the definitions
used. It would not if the definition limits stakeholders to those having a vested interest in the system. In
this exercise, we will list it with the stakeholders to more easily transfer the information to the
identification of actors in use cases.
Successful operation of the prospective system will require competent system staff, suggesting that we
may need to consider that training will be required to prepare mechanisms. Similarly, a major constraint
on the prospective system will be a variety of scientific, communications, technical, and formatting
standards. Some of these may be negotiated with stakeholders who are external users such as the Tsunami
Warning Center. Others may be specified by resource providers such as the Argos system. Others may be
available from standards organizations and professional associations; this last order of constraint should
not require interaction beyond routine purchasing and membership transactions.
• You should then extend the content of the stakeholder grouping table to capture these ideas:
Template Grouping of Stakeholder Models
User ProviderGrouping
Concept: Outputs Controls Inputs Mechanisms
institute
shipper
customer
tsunami
communications
environment communications
maintenance
trainer
34

Armstrong bocast integration_of_systems_engineering_and_software_development_2003-libre

Armstrong bocast integration_of_systems_engineering_and_software_development_2003-libre

Recommended

Recommended

More Related Content

Similar to Armstrong bocast integration_of_systems_engineering_and_software_development_2003-libre

Similar to Armstrong bocast integration_of_systems_engineering_and_software_development_2003-libre (20)

More from Mandar Trivedi

More from Mandar Trivedi (20)

Recently uploaded

Recently uploaded (20)

Armstrong bocast integration_of_systems_engineering_and_software_development_2003-libre