Agile Model-Based Systems Engineering Cookbook Second Edition: Improve system development by applying proven recipes for effective agile systems engineering

Contents

Preface

Who this book is for

What this book covers

To get the most out of this book

Share your thoughts

Basics of Agile Systems Modeling

What’s agile all about?

Incremental development

Continuous verification

Continuous integration

Avoid big design up front

Working with stakeholders

Model-Based Systems Engineering (MBSE)

Managing your backlog

Purpose

Inputs and preconditions

Outputs and postconditions

How to do it

Example

Measuring your success

Purpose

How to do it

Example

Some considerations

Measuring the wrong thing

Managing risk

Purpose

Inputs and proconditions

Outputs and postconditions

How to do it

Example

Product roadmap

Purpose

Inputs and preconditions

How to do it

Example

Release plan

Purpose

Inputs and preconditons

Outputs and postconditions

How to do it

Example

Iteration plan

Purpose

Inputs and preconditions

Outputs and postconditions

How to do it

Example

Estimating Effort

Purpose

Inputs and preconditions

Outputs and postconditions

How to do it

How it works

Example

Work item prioritization

Purpose

Inputs and preconditions

How to do it

How it works

Example

Iteration 0

Purpose

Inputs and preconditions

Outputs and postconditions

How to do it

Example

Architecture 0

Subsystem and component view

Concurrency and resource view

Distribution view

Dependability view

Deployment view

Purpose

Inputs and preconditions

Outputs and postconditions

How to do it

Example

Additional note

Organizing your models

Purpose

Inputs and preconditions

Outputs and postconditions

How to do it

How it works

Example

Managing change

Purpose

Inputs and preconditions

How to do it

Example

System Specification

Recipes in this chapter

Why aren’t textual requirements enough?

Definitions

Functional Analysis with Scenarios

Functional analysis with activities

Purpose

Inputs and preconditions

Outputs and postconditions

How to do it

Functional analysis with state machines

Purpose

Inputs and preconditions

Outputs and postconditions

How to do it

Example

Functional Analysis with User Stories

A little bit about user stories

Purpose

Inputs and preconditions

Outputs and postconditions

How to do it

Example

Model-Based Safety Analysis

A little bit about safety analysis

Some Profiles

Hazard analysis

Purpose

Inputs and preconditions

Outputs and postconditions

How to do it

Example

Model-Based Threat Analysis

Basics of Cyber-Physical Security

Modeling for Security Analysis

Purpose

Inputs and preconditions

Outputs and postconditions

How to do it

Example

Specifying Logical System Interfaces

A Note about SysML Ports and Interfaces

Purpose

Inputs and preconditions

Outputs and postconditions

How to do it

Example

Creating the Logical Data Schema

Definitions

Example

Purpose

Inputs and preconditions

Outputs and postconditions

How to do it

Example

Developing System Architectures

Recipes in this chapter

Five critical views of architecture

Architectural trade studies

Purpose

Inputs and preconditions

Outputs and postconditions

How to do it

Example

Architectural merge

Example

Pattern-driven architecture

Purpose

Inputs and preconditions

Outputs and postconditions

How to do it

Example

Subsystem and component architecture

Purpose

Inputs and preconditions

Outputs and postconditions

How to do it

Example

Architectural allocation

Creating subsystem interfaces from use case scenarios

Purpose

Inputs and preconditions

Outputs and postconditions

How to do it

Specializing a reference architecture

What is a reference architecture?

Purpose

Inputs and preconditions

Outputs and postconditions

How to do it

Handoff to Downstream Engineering

Recipes in this chapter

Activities for the handoff to downstream engineering

Starting point for the examples

Preparation for Handoff

Federating Models for Handoff

Logical to Physical Interfaces

Deployment Architecture I: Allocation to Engineering Facets

Deployment Architecture II: Interdisciplinary Interfaces

Demonstration of Meeting Needs: Verification and Validation

Recipes in this chapter

Verification and validation

Model simulation

Purpose

Inputs and preconditions

Outputs and postconditions

How to do it

Example

Model-based testing

Inputs and preconditions

Outputs and postconditions

How to do it

Computable constraint modeling

Purpose

Inputs and preconditions

How to do it

Example

Traceability

Some definitions

Purpose

Inputs and preconditions

Outputs and postconditions

How to do it

Example

Effective Reviews and walkthroughs

Purpose

Inputs and preconditions

Outputs and postconditions

How to do it

Example

Managing Model Work Items

Purpose

Inputs and preconditions

How to do it

Example

Test Driven Modeling

Purpose

Inputs and preconditions

Outputs and postconditions

How to do it

Example

Appendix A: The Pegasus Bike Trainer

Overview

Pegasus High-Level Features

Highly customizable bike fit

Monitor exercise metrics

Export/upload exercise metrics

Variable power output

Gearing emulation

Controllable power level

Incline control

User interface

Online training system compatible

Configuration and OTA firmware updates

Other Books You May Enjoy

Index

Landmarks

Cover

Index

Agile Model-Based Systems Engineering Cookbook

Second Edition

Improve system development by applying proven recipes for effective agile systems engineering

Dr. Bruce Powel Douglass

BIRMINGHAM—MUMBAI

Agile Model-Based Systems Engineering Cookbook

Second Edition

Copyright © 2022 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Senior Publishing Product Manager: Denim Pinto

Acquisition Editor – Peer Reviews: Saby Dsilva

Project Editor: Meenakshi Vijay

Content Development Editor: Rebecca Robinson

Copy Editor: Safis Editing

Technical Editor: Srishty Bhardwaj

Proofreader: Safis Editing

Indexer: Pratik Shirodkar

Presentation Designer: Rajesh Shirsath

First published: March 2021

Second edition: December 2022

Production reference: 3050123

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80323-582-0

www.packt.com

Foreword

As a systems engineer, you may know that viewpoints are important to understand context. When you read this foreword, you should be aware that I wrote it from my individual viewpoint. My own professional role involves the development of methods, templates, and training to make Systems engineering applicable for organizations, and also producing complex systems consisting of mechanical and electrical hardware, software, and the human beings operating it or interacting with it. Systems engineering is nowadays challenged with several constraints and boundary conditions requiring permanent change in the organization and its processes, methods, and tools. The need to work closely cross-domain (e. g. mechanical and hardware designers working together with software programmers, testers, and stakeholders), the need to quickly react to external (and internal) disruptions, and the need to bridge cross-cultural gaps require several significant changes in parallel. And this is difficult for bigger organizations and hard to realize. This is where this book helps significantly and contributes to mastering such challenges. The answer to those challenges lies in the introduction and application of Systems Engineering (SE) and in agile methods. The definition, deployment, implementation, maturation, and management of those two changes is a huge challenge to bigger companies and this book provides simple (not easy!) recipes to approach those changes.

This book perfectly fills a couple of gaps existing today in this area. Typically, there are two ways for companies to start their Systems Engineering journey: either they start first with training and educating Systems engineers theoretically or they start introducing a Model-Based Systems Engineering (MBSE) tool to provide a tool to do Systems Engineering. I’m not saying that the one or other method is better or worse, but I have observed this for years. Actually, both are necessary as, Systems Engineers need a good theoretical background on the methods and on tools. For re-use and communication, modern MBSE tools are optimally suited to implement SE formally in all development processes. However, to implement Systems Engineering broadly in a cross-domain development organization it is critical to follow strict modelling rules and to install syntactic and semantic guidelines.

In this area this book perfectly meets the needs of any SE practitioner and each company implementing or applying SE. The practical guidelines, the step-by-step descriptions, the cross-domain designed examples, and the provided downloads allow companies and individuals to get quickly and easily to the core of the method and mind set. With the provided references and additional sources, this book offers many further paths to go into more detail in many domains if needed or desired.

The second critical area covered by this book is the agile aspects of modern development organizations. The beauty of this book is that it holds agile at its core, the agile manifesto, and does not reduce or limit it to one of the many agile process implementations. The book provides excellent directions and practices to become more agile, independent of the development domain (not limited to software development), and also builds the bridge on how to use SE and MBSE in particular to foster an agile development process in general. Using the different SE artifacts as deliverables, prioritizing them accordingly to build a useful backlog, employing methods to track progress and risk, etc. are well described and practically applicable. As said before, practical examples and step-by-step guidelines are the core enablers for immediate practical application.

Last but not least, while the book follows the full development cycle and covers the aspects of functional analysis, architecting, trade studies, system design, verification, and validation, it also details the important aspects of system safety and security.

I highly recommend this book to all SE practitioners and to anyone considering how to implement SE in a company or how to become more agile. This second edition, with all of its enhancements and improvements in the step-by-step description and its additional areas covering things such as system security, is a must have in each SE’s library.

Thank you Bruce, and well done!

Christian von Holst

Global Tractor Systems Engineering Lead at John Deere

Contributors

About the author

Dr. Bruce Powel Douglass has received an MS in exercise physiology from the University of Oregon and a Ph.D. in neurocybernetics from the USD Medical School. He has worked as a software developer and systems engineer in safety-critical real-time embedded systems for almost 40 years and is a well-known speaker, author, and consultant in the area of real-time embedded systems, UML, and SysML. He is a coauthor of the UML and SysML standards, and teaches courses in real-time systems and software design and project management. Bruce has also authored articles for many journals and periodicals, especially in the real-time domain, and authored several other books on systems and software development. He has worked at I-Logix, Telelogic, and IBM on the Rhapsody modeling tool. He is currently a senior principal agile systems engineer at MITRE, and the principal at A-Priori Systems.

About the reviewers

Jaime Robles has more than a decade of experience in the development of complex engineered systems across the entire lifecycle. Currently, he is working as a Systems Engineer at the ALMA Observatory, the world’s most powerful telescope at millimeter and submillimeter wavelengths. Previously, he has worked in the development of small space systems for planetary surface exploration and as a consultant in systems engineering with MBSE focus at SPEX Systems.

He is an aerospace engineer, an OMG certified Systems Modeling Professional – Model Builder Advanced (OCSMP-MBA), an INCOSE associate Systems Engineering professional, and an active member of this professional organization participating in several groups (Space Systems WG, Requirements WG, LATAM Chapter). He also holds an MIT certificate in Architecture and Systems Engineering and has gained work experience in the United States, Switzerland, and Chile.

A word of acknowledgment to the author for sharing his vast knowledge with the MBSE community and for the opportunity to contribute with a grain of sand as a technical reviewer. Also, a special thanks to my family for their kind support and patience during the time invested in the review process.

Dr. Saulius Pavalkis is global MBSE Ecosystem Transformation Leader and MBSE R&D Cyber Portfolio Manager NAM at Dassault Systemes. He is also an INCOSE CAB Representative and on the CSE Board of Advisors at the University of Texas. 

He has 20 years of MBSE solutions experience, and is a product owner and analyst with the Cameo core team, chief solution architect, consultant, and trainer. He is a world-leading expert in MBSE ecosystem, digital engineering, system architecture and simulation.

Throughout his career, he has been actively involved in building excellent MBSE ecosystem solutions in aerospace, defense, automotive and other areas as a former affiliate for JPL NASA for MBSE consulting and a contractor for Boeing's MBSE transformation.

Dr Saulius Pavalkis contributed to the MBSE SysML Based Method and Framework MagicGrid book and recently the Agile MBSE Cookbook by Dr. Bruce Douglass. He guides 2,000 subscribers—the largest SysML systems simulation community on YouTube (youtube.com/c/MBSEExecution). Saulius has INCOSE CSEP, OMG OCSMP, the No Magic lifetime modeling and simulation excellence award, a PhD in software engineering in the models query area, and a MS and BS in telecommunications and electronics from Kaunas University of Technology. 

I would like to thank Dr. Bruce Douglass for amazing opportunity to review his latest book on Agile MBSE application. Dr. Bruce is a leading expert in effective and efficient MBSE application and has made this book is the best in class as an MBSE transformation guide. It is a must-have for any company or expert. Thank you, Dr. Bruce Douglass!

Join our community on Discord

Join our community’s Discord space for discussions with the author and other readers:

https://packt.link/cpVUC

Preface

Welcome to the Agile Model-Based Systems Engineering Cookbook! There is a plethora of published material for agile methods, provided that you want to create software. And the system is small. And the team is co-located. And it needn’t be certified. Or safety-critical or high-reliability.

MBSE is none of these things. The output of MBSE isn’t software implementation but system specification. It is usually applied to more complex and larger-scale systems. The teams are diverse and often spread out across departments and companies. Much of the time, the systems produced must be certified under various standards, including safety standards. So how do you apply agile methods to such an endeavor?

Most of the work in MBSE can be thought of as a set of workflows that produce a set of interrelated work products. Each of these workflows can be described with relatively simple recipes for creating the work products for MBSE including system requirements, systems architecture, system interfaces, and deployment architectures. That’s what this book brings to the table and what sets it apart.

In this second edition, some new recipes have been added and all the examples and figures have been done using the Cameo Systems Modeler SysML tool.

Who this book is for

The book is, first and foremost, for systems engineers who need to produce work products for the specification of systems that include combinations of engineering disciplines, such as software, electronics, and mechanical engineering. More specifically, this book is about model-based systems engineering using the SysML language to capture, render, and organize the engineering data. Further, the book is especially about how to do all that in a way that achieves the benefits of agile methods – verifiably correct, adaptable, and maintainable systems. We assume basic understanding of the Systems Modeling Language (SysML) and at least some experience as a systems engineer.

What this book covers

Chapter 1, Basics of Agile Systems Modeling, discusses some fundamental agile concepts, expressed as recipes, such as managing your backlog, using metrics effectively, managing project risk, agile planning, work effort estimation and prioritization, starting up projects, creating an initial systems architecture, and organizing your systems engineering models. The recipes all take a systems engineering slant and focus on the work products commonly developed in a systems engineering effort.

Chapter 2, System Specification, is about agile model-based systems requirements – capturing, managing, and analyzing the system specification. One of the powerful tools that MBSE brings to the table is the ability to analyze requirements by developing computable and executable models. This chapter provides recipes for several different ways of doing that, as well as recipes for model-based safety and cyber-physical security analysis, and specifying details of information held within the system.

Chapter 3, Developing Systems Architecture, has recipes focused on the development of systems architectures. It begins with a way of doing model-based trade-studies (sometimes known as analysis of alternatives). The chapter goes on to provide recipes for integrating use case analyses into a systems architecture, applying architectural patterns, allocation of requirements into a systems architecture, and creating subsystem-level interfaces.

Chapter 4, Handoff to Downstream Engineering, examines one of the most commonly asked questions about MBSE: how to hand the information developed in the models off to implementation engineers specializing in software, electronics, or mechanical engineering. This chapter provides detailed recipes for getting ready to do the hand off, creating a federation of models to support the collaborative engineering effort to follow, converting the logical systems engineering interfaces to physical interface schemas, and actually doing the allocation to the engineering disciplines involved.

Chapter 5, Demonstration of Meeting Needs Verification and Validation, considers a key concept in agile methods: that one should never be more than minutes away from being able to demonstrate that, while the system may be incomplete, what’s there is correct. This chapter has recipes for model simulation, model-based testing, computable constraint modeling, adding traceability, how to run effective walkthroughs and reviews, and – my favorite – Test-driven modeling.

Appendix, The Pegasus Bike Trainer, details a case study that will serve as the basis for most of the examples in the book. This is a smart stationary bike trainer that interacts with net-based athletic training systems to allow athletes to train in a variety of flexible ways.

It contains aspects that will be implemented in mechanical, electronic, and software disciplines in an ideal exemplar for the recipes in the book.

To get the most out of this book

To get the most out of this book, you will need a solid, but basic, understanding of the Systems Modeling Language (SysML). In addition, to create the models, you will need a modeling tool. The concepts here are expressed in SysML so any standards-compliant SysML modeling tool can be used.

All the example models in this book are developed using the Cameo Systems Modeler tool. To execute models and run simulations, you will need the Simulation Toolkit, included with the tool:

Download the example models

You can download the example models for this book from the author’s website at www.bruce-douglass.com. Note that these models are all in Cameo-specific format and won’t generally be readable by other modeling tools.

We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!

Where to go from here

Visit the authors, website at www.bruce-douglass.com for papers, presentations, models, engineering forums, to download the models from this book, and more.

Download the color images

We also provide a PDF file that has color images of the screenshots/diagrams used in this book. You can download it here: https://packt.link/av1n2.

Conventions used

There are a number of text conventions used throughout this book.

Bold: Indicates a new term, an important word, or words that you see on the screen. For instance, words in menus or dialog boxes appear in the text like this. For example: "Select System info from the Administration panel.

Warnings or important notes appear like this.

Tips and tricks appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: Email

[email protected]

and mention the book’s title in the subject of your message. If you have questions about any aspect of this book, please email us at

[email protected]

.

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you reported this to us. Please visit http://www.packtpub.com/submit-errata, click Submit Errata, and fill in the form.

Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at

[email protected]

with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit http://authors.packtpub.com.

Share your thoughts

Once you’ve read Agile Model-Based Systems Engineering Cookbook, Second Edition, we’d love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we’re delivering excellent quality content.

Download a free PDF copy of this book

Thanks for purchasing this book!

Do you like to read on the go but are unable to carry your print books everywhere?Is your eBook purchase not compatible with the device of your choice?

Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost.

Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical books directly into your application. 

The perks don’t stop there- you can get exclusive access to discounts, newsletters, and great free content in your inbox daily.

Follow these simple steps to get the benefits:

Scan the QR code or visit the link below:

https://packt.link/free-ebook/9781803235820

Submit your proof of purchase.

That’s it! We’ll send your free PDF and other benefits to your email directly.

1

Basics of Agile Systems Modeling

For the most part, this book is about systems modeling with SysML, but doing it in an agile way. Before we get into the detailed practices of systems modeling with that focus, however, we’re going to spend some time discussing important project-related agile practices that will serve as a backdrop for the modeling work.

Almost all of the agile literature focuses on the three people in a garage developing a simple application scope. The basic assumptions of such projects include:

The end result is software that runs on a general-purpose computing platform (i.e., it is not embedded).

Software is the only truly important work product. Others may be developed but they are of secondary concern. Working software is the measure of success.

The software isn’t performance, safety, reliability, or security-critical.

It isn’t necessary to meet regulatory standards.

The development team is small and co-located.

The development is time-and-effort, not fixed-price cost.

The development is fundamentally code-based and not model- (or design)-based.

Any developer can do any task (no specialized skills are necessary).

Formalized requirements are not necessary.

Yes, of course, there is much made about extensions to agile practices to account for projects that don’t exactly meet these criteria. For example, some authors will talk about a scrum of scrums as a way to scale up to larger teams. That works to a point, but it fails when you get to much larger development teams and projects. I want to be clear – I’m not saying that agile methods aren’t application to projects that don’t fall within these basic guidelines – only that the literature doesn’t address how it will do so in a coherent, consistent fashion. The further away your project strays from these assumptions, the less you will find in the literature for agile ways to address your needs.

In this book, we’ll address a domain that is significantly different than the prototypical agile project. Our concerns will be projects that:

Are systems-oriented, which may contain software but will typically also contain electronic and mechanical aspects. It’s about the system and not the software.

Employ a Model-Based Systems Engineering (MBSE) approach using the SysML language.

May range from small- to very large-scale.

Must develop a number of different work products. These include, but are not limited to:

Requirements specification

Analysis of requirements, whether it is done with use case or user stories

System architectural specification

System interface specification

Trace relations between the elements of the different work products

Safety, reliability, and security (and resulting requirements) analyses

Architectural design trade studies

Have a handoff to downstream engineering that includes interdisciplinary subsystem teams containing team members who specialize in software, electronics, mechanical, and other design aspects.

But at its core, the fundamental difference between this book and other agile books is that the outcome of systems engineering isn’t software, it’s system specification. Downstream engineering will ultimately do low-level design and implementation of those specifications. Systems engineering provides the road map that enables different engineers with different skill sets, working in different engineering disciplines, to collaborate together to create an integrated system, combining all their work into a cohesive whole.

The International Council of Systems Engineering (INCOSE) defines systems engineering as a transdisciplinary and integrative approach to enable the successful realization, use, and retirement of engineered systems, using systems principles and concepts, and scientific, technological, and management methods (https://www.incose.org/about-systems-engineering/system-and-se-definition/systems-engineering-definition). This book will not provide a big overarching process that ties all the workflows and work products together, although it is certainly based on one. That process – should you be interested in exploring it – is detailed in the author’s Agile Systems Engineering book; a detailed example is provided with the author’s Harmony aMBSE Deskbook, available at www.bruce-douglass.com. Of course, these recipes will work with any other reasonable MBSE process. It is important to remember that:

The outcome of software development is implementation;

The outcome of systems engineering is specification.

What’s agile all about?

Agile methods are – first and foremost – a means for improving the quality of your engineering work products. This is achieved through the application of a number of practices meant to continuously identify quality issues and immediately address them. Secondarily, agile is about improving engineering efficiency and reducing rework. Let’s talk about some basic concepts of agility.

Incremental development

This is a key aspect of agile development. Take a big problem and develop it as a series of small increments, each of which is verified to be correct (even if incomplete).

Continuous verification

The best way to have high-quality work products is to continuously develop and verify their quality. In other books, such as Real-Time Agility or the aforementioned Agile Systems Engineering books, I talk about how verification takes place in three timeframes:

Nanocycle: 30 minutes to 1 day

Microcycle: 1–4 weeks

Macrocycle: Project length

Further, this verification is best done via the execution and testing of computable models. We will see in later chapters how this can be accomplished.

Continuous integration

Few non-trivial systems are created by a single person. Integration is the task of putting together work products from different engineers into a coherent whole and demonstrating that, as a unit, it achieves its desired purpose. This integration is often done daily, but some teams increment this truly continuously, absorbing work as engineers complete it and instantly verifying that it works in tandem with the other bits.

Avoid big design up front

The concept of incremental development means that one thing that we don’t do is develop big work products over long periods of time and only then try to demonstrate their correctness. Instead, we develop and verify the design work we need right now, and defer design work that we won’t need until later. This simplifies the verification work and also means much less rework later in a project.

Working with stakeholders

A key focus of the Agilista is the needs of the stakeholders. The Agilista understands that there is an air gap between what the requirements say and what the stakeholder actually needs. By working with the stakeholder, and frequently offering them versions of the running system to try, they are more likely to actually meet their needs. Additionally, user stories – a way to organize requirements into short usage stakeholder-system usage scenarios – are a way to work with the stakeholder to understand what they actually need.

Model-Based Systems Engineering (MBSE)

Systems engineering is an independent engineering discipline that focuses on system properties – including functionality, structure, performance, safety, reliability, and security. MBSE is a model-centric approach to performing systems engineering. Systems engineering is largely independent of the engineering disciplines used to implement these properties. Systems engineering is an interdisciplinary activity that focuses more on this integrated set of system properties than on the contributions of the individual engineering disciplines. It is an approach to developing complex and technologically diverse systems. Although normally thought of in a V-style process approach (see Figure 1.1), the left side of the V emphases the specification of the system properties (requirements, architecture, interfaces, and overall dependability), the lower part of the V has to do with the discipline-specific engineering and design work, and the right side of the V has to do with the verification of the system against the specifications developed on the left side:

Figure 1.1: Standard V model life cycle

Of course, we’ll be doing things in a more agile way (Figure 1.2). Mostly, we’ll focus on incrementally creating the specification work products and handing them off to downstream engineering in an agile way:

Figure 1.2: Basic Agile systems engineering workflow

The basis of most of the work products developed in MBSE is, naturally enough, the model. For the most part, this refers to the set of engineering data relevant to the system captured in a SysML model. The main model is likely to be supplemented with models in other languages, such as performance, safety, and reliability (although you can use SysML for that too – we’ll discuss that in Chapter 2, System Specification—Functional, Safety and Security Analysis). The other primary work product will be textual requirements. While they are imprecise, vague, ambiguous, and hard to verify, they have the advantage of being easy to communicate. Our models will cluster these requirements into usage chunks – epics, use cases, and user stories – but we’ll still need requirements. These may be managed either as text or in text-based requirements management tools, such as IBM DOORS™, or they can be managed as model elements within a SysML specification model.

Our models will consist of formal representations of our engineering data as model elements and the relationships among them. These elements may appear in one or more views, including diagrams, tables, or matrices. The model is, then, a coherent collection of model elements that represent the important engineering data around our system of interest.

In this book, we assume you already know SysML. If you don’t, there are many books around for that. This book is a collection of short, high-focused workflows that create one or a small set of engineering work products that contain relevant model elements.

Now, let’s talk about some basic agile recipes and how they can be done in a model-centric environment.

Managing your backlog

The backlog is a prioritized set of work items that identify work to be done. There are generally two such backlogs. The project backlog is a prioritized list of all work to be done in the current project. A subset of these is selected for the current increment, forming the iteration backlog. Since engineers usually work on the tasks relevant to the current iteration, that is where they will go to get their tasks. Figure 1.3 shows the basic idea of backlogs:

Figure 1.3: Backlogs

The work to be done, nominally referred to as work items, is identified. Work items can be application work items (producing work that will be directly delivered) or technical work items (doing work that enables technical aspects of the product or project). Work items identify work to do such as:

Analyzing, designing, or implementing an epic, use case, or user story, to ensure a solid understanding of the need and the adequacy of its requirements

Creating or modifying a work product, such as a requirements specification or a safety analysis

Arranging for an outcome, such as certification approval

Addressing a risk, such as determining the adequacy of the bus bandwidth

Removing an identified defect

Supporting a target platform, such as an increment with hand-built mechanical parts, lab-constructed wire wrap boards, and partial software

The work items go through an acceptance process, and if approved, are put into the project backlog. Once there, they can be allocated to an iteration backlog.

Purpose

The purpose of managing your backlog is to provide clear direction for the engineering activities, to push the project forward in a coherent, collaborative way.

Inputs and preconditions

The inputs are the work items. The functionality-based work items originate with one or more stakeholders, but other work items might come from discovery, planning, or analysis.

Outputs and postconditions

The primary outputs are the managed project and iteration backlogs. Each backlog consists of a set of work items around a common purpose, or mission. The mission of an iteration is the set of work products and outcomes desired at the end of the iteration. An iteration mission is defined as shown in Figure 1.4:

Figure 1.4: Iteration mission

In a modeling tool, this information can be captured as metadata associated with tags.

The term metadata literally means data about data; in this context, we add metadata to elements using tags.

How to do it

There are two workflows to this recipe. The first, shown in Figure 1.5, adds a work item to the backlog. The second, shown in Figure 1.6, removes it:

Figure 1.5: Add work item

Figure 1.6: Resolve work item

Create a workflow item

From the work to be done, a work item is created to put into the backlog. The work item should include the properties shown in Figure 1.7:

Figure 1.7: Work item

Name.

Description of the work to be done, the work product to be created, or the risk to be addressed.

The acceptance criteria – how the adequacy of the work performed, the work product created, or the outcome produced will be determined.

The work item classification identifies the kind of work item it is, as shown on the left side of Figure 1.3.

The work item’s priority is an indication of how soon this work item should be addressed. This is discussed in the Prioritize work item step of this recipe.

The estimated effort is how much effort it will take to perform the task. This can be stated in absolute terms (such as hours) or relative terms (such as user story points). This topic is addressed in the Estimating effort recipe later in this chapter.

Links to important related information, such as standards that must be met, or sources of information that will be helpful for the performance of the work.

Approve work item

Before a work item can be added, it should be approved by the team or the project leader, whoever is granted that responsibility.

Prioritize work item

The priority of a work item determines in what iteration the work will be performed. Priority is determined by a number of factors, including the work item’s criticality (how important it is), its urgency (when it is needed), the availability of specialized resources needed to perform it,