The document discusses introducing model-based systems engineering (MBSE) into existing or legacy projects, known as "brown field" or "gray field" projects. It defines key terms like green field, brown field, and gray field projects. It acknowledges the challenges of applying MBSE to existing projects where architectures and components are already defined. The document proposes an iterative approach to MBSE for existing projects that focuses on new requirements and features, uses existing system components when possible, and aims handoffs to align with downstream development sprints. It provides examples from two organizations applying these MBSE techniques to their existing weapon system and vehicle projects.

1. The
Continuous
Engineering
Experts TM
www.321gang.com

2. When The Field Isn’t Green:
Introducing Model Based Systems Engineering
into an Existing/Legacy/Maintenance Projects
Jeffrey R. Cohen, P.E.
Sr. Solutions Consultant
321 Gang
jeff@321gang.com
https://www.linkedin.com/in/jeffreyrcohen/
Twitter: CohenJeffrey
The Continuous Engineering Experts TM
www.321gang.com

3. www.321gang.comThe Continuous Engineering Experts.
TM
Today’s agenda
?
Presentation
20 - 30 minutes
Q&A
15 minutes
The Continuous Engineering Experts TM
www.321gang.com

4. www.321gang.comThe Continuous Engineering Experts.
TM
Defining Some Terms
Green Field
 New Project
 Model Based Systems Engineering from Beginning
 Major Components (Blocks) Not Defined
 Interfaces Not Defined
 Trade Studies Influence Design
Brown Field (Gray Field)
 Built onto Existing Project
• Maintenance Project
• Sustainment Project
 Document Intensive Systems Engineering
 Major Components (Blocks) Defined and Often Cannot Change
 Interfaces Defined
 Trade Studies Done Long Ago, Existing Can’t Change

5. www.321gang.comThe Continuous Engineering Experts.
TM
We Know What to do for Green Fields
For Green Field, We Know What To Do
 Harmony aMBSE (Bruce Douglass)
 MBSE Consulting and Training Method (Frasier Chadburn)
 Object Oriented Systems Engineering Method (OOSEM)
General Flow for New Projects
 Requirements Analysis
 Functional Analysis
 Architectural Analysis (with trade studies)
 Architectural Design/Design Synthesis
 Interface Detailed Design

6. www.321gang.comThe Continuous Engineering Experts.
TM
But What About Gray Fields: Problem Statement
PROBLEMS for Gray Field Projects:
 Architecture is Set
 Functional Analysis Restricted (Can’t change existing subsystems)
 No Money/Resources for Modeling Existing Systems
 Reluctance to Change to MBSE because Documents are Deliverables
 Downstream Groups Expectations
 Common Objections:
• “Why Can’t You Just…”
• “That’s Not How We Did It Before”
• “This is fixed cost, even though <<manager>> wants SysML, I don’t think we can afford it”
• “You have to understand, we’ve been maintaining <<project>> for <<number of>> years. We
know what we are doing”
• “Well, the model is fine, but I have to deliver my <<document>> on schedule”
All about selling change that increases benefits while reducing disruption

7. www.321gang.comThe Continuous Engineering Experts.
TM
Approach
 Start With Handoff Artifacts and Work Backwards
 Generic Systems Engineering Approach
 Iterative
 Align Iterations with Downstream Sprint*
Key Differences to Green Field:
Only Import New Requirements
• Existing Requirements are in Requirements Database
• Trace as Needed
Only Modeling New Features
Use Existing Components (when possible)
• New Components = New Blocks
• Modified Components = New Blocks
• Existing Unmodified Components Modeled as ”Shell” Blocks Differentiated
with Stereotype
Import New
Requirements
Use Cases for
New Features
Refine Use
Cases
Allocate
Functionality
Update
Interfaces

8. www.321gang.comThe Continuous Engineering Experts.
TM
Identify Handoff Artifacts and Work Backwards
1. Meet with Downstream to Identify Wants and Needs
• Identify Key Symptoms
• Identify Big and Little Issues that Make Life Difficult
• Identify Current Handoff
• Identify Desired Handoff Elements
• Identify Development Process
2. New (or Expanded) Features Identify Use Cases
• Features Come from Agreements with Customer (often NOT formal SOW)
• Features Descriptions from Customer Often Documented as Main Flow Only
3. Refine Use Cases with Activity Diagrams or State Charts
• Systems Engineers Prefer Activity Diagrams
• Refined Use Cases Provided Source Material for ConOps (Deliverable)
4. Entire Use Case Allocated to Subsystem with Interfaces

9. www.321gang.comThe Continuous Engineering Experts.
TM
Hardly a Trend, but Similar Handoff Desires
Two organizations, Very Different Spaces, Similar Issues
 Organization 1: Defense Contractor on Sustainment for Old Weapon System
 Organization 2: Modifying a Manned Vehicle to an Unmanned Vehicle
Organization 1 Findings:
 Exception Conditions Not Specified
 Some Functionality Specified too Deep
 Little Understanding of Cross-Functional Dependencies Leads to Errors During Integration
Test
 Power Point and <<document>> were not maintained with latest requirement changes under
source control. The result was misaligned code going to build/test
Organization 2 Handoff Elements:
 A Lot of Systems Engineering Already Done, but Model Desired to Explain Complexity
 Activity diagrams, sequence diagrams. Indicate where changes will occur
 Interfaces did not change for this project due to the messaging structure

10. www.321gang.comThe Continuous Engineering Experts.
TM
Example Findings: Key Symptoms (Org 1)
 Frequent Interruptions by Downstream Teams
 Unknown Rippled Failures
 No Optimization Analysis Leading to Resource Constraints
 Rework
oRework S/W due to missing requirements for non-normative conditions
oFailed both V&V
oRequirements Rework
 Required Document Out of Sync with Code

11. www.321gang.comThe Continuous Engineering Experts.
TM
Example: Handoff Today
Org 1 Sustainment Projects
 SRS (interim <<concept document>>) 4 x per year
 PowerPoint diagrams from customer meetings
• Only sunny day scenarios, few exceptions
• Sometimes Markups from Meetings Not Delivered to Team
Org 1 New Development
 Requirements from Customer
• Often incomplete
• Not fully analyzed for FMEA
 PowerPoint
• Changes
• Interface
• Text and Pictures
Org 2 Development
 Requirements in DOORS
 Con Ops Documents

12. www.321gang.comThe Continuous Engineering Experts.
TM
Example: Handoff– What S/W Finds Useful (Org 1)
Interfaces
• Logical
Blocks/Ports/Interface Blocks
• Detailed Design
Enumerations
Interface Block with message structure
Behavior Model
• State Charts
• Activity Diagram
• Sunny day and non-normative paths (Sequence Diagrams)
Overall Behavior for the Changed Thread of Execution
Text Requirements with traces

13. www.321gang.comThe Continuous Engineering Experts.
TM
Example: Typical Desired Handoff Environment
 System/Subsystem Model visible to Software Engineer
 Systems Model included by Reference – Does not get
modified during a sprint
 Systems Model “delivered” to CM at end of each
Systems sprint. Picked up by Software for their next
sprint.
 Packages included by Reference to trace
*NOTE: Screenshot for reference only. Not a real screenshot from
Org 1 or Org 2

14. www.321gang.comThe Continuous Engineering Experts.
TM
So What’s a Systems Engineer to do?
Start with the handoff artifacts in mind
 Deliver Use Cases refined with Activity Diagrams
 Indicate Likely Regions for Change
 Assume Interaction and Allocation Among New Components (or those funded to change)
 Assume Interface Message Structures will ONLY Change if Necessary
 Move to Iterative Development Aligned with Software Sprints (a la SAFe)
For Internal Model Elements
• Blocks to represent External Entities and Existing Entities
• Tried actors, but ended up creating blocks to show interfaces
• Interfaces and Interface Blocks for LOGICAL Interfaces
• New Functionality Allocated as Use Cases Refined with Activity Diagrams
• All Actions on an Activity Tend to be Allocated to One Subsystem (block or part)
• Some Actions were allocated to multiple subsystems including existing subsystems
• Required more modeling; Required new interfaces; Required new qualification tests

15. // Shameless Promotion
The Continuous Engineering Experts TM
www.321gang.com
See My New Modeling
Video Series:
https://ptdrv.linkedin.com/fg24i8v

16. The Continuous Engineering Experts TM
Contact us:
info@321gang.com
jeff@321gang.com
Questions?
www.321gang.com

17. The Continuous Engineering Experts TM
www.321gang.com
Strategy.
Execution.
Results.
Offering consulting,
training & software solutions
for companies building
complex, highly regulated systems.

18. The
Continuous
Engineering
Experts TM
© 2018 321 Gang, Inc. All rights reserved.
The information herein is for informational purposes only and represents the current view of 321 Gang, Inc. as of the date of this presentation.
Because 321 Gang, Inc. must respond to changing market conditions, it should not be interpreted to be a commitment on the
part of 321 Gang, and 321 Gang cannot guarantee the accuracy of any information provided after the date of this presentation.
321 GANG MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.
IBM is a registered trademark of IBM in the United States.
Other names may be trademarks of their respective owners.