Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Save more on your purchases! discount-offer-chevron-icon
Savings automatically calculated. No voucher code required.
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Newsletter Hub
Free Learning
Arrow right icon
timer SALE ENDS IN
0 Days
:
00 Hours
:
00 Minutes
:
00 Seconds
Agile Model-Based Systems Engineering Cookbook
Agile Model-Based Systems Engineering Cookbook

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

Arrow left icon
Profile Icon Dr. Bruce Powel Douglass
Arrow right icon
$45.99
Full star icon Full star icon Full star icon Full star icon Half star icon 4.8 (9 Ratings)
Paperback Mar 2021 646 pages 1st Edition
eBook
$32.99 $36.99
Paperback
$45.99
Subscription
Free Trial
Renews at $19.99p/m
Arrow left icon
Profile Icon Dr. Bruce Powel Douglass
Arrow right icon
$45.99
Full star icon Full star icon Full star icon Full star icon Half star icon 4.8 (9 Ratings)
Paperback Mar 2021 646 pages 1st Edition
eBook
$32.99 $36.99
Paperback
$45.99
Subscription
Free Trial
Renews at $19.99p/m
eBook
$32.99 $36.99
Paperback
$45.99
Subscription
Free Trial
Renews at $19.99p/m

What do you get with Print?

Product feature icon Instant access to your digital copy whilst your Print order is Shipped
Product feature icon Paperback book shipped to your preferred address
Product feature icon Redeem a companion digital copy on all Print orders
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
Product feature icon AI Assistant (beta) to help accelerate your learning
OR
Modal Close icon
Payment Processing...
tick Completed

Shipping Address

Billing Address

Shipping Methods
Table of content icon View table of contents Preview book icon Preview Book

Agile Model-Based Systems Engineering Cookbook

Chapter 2: System Specification

This chapter contains recipes related to capturing and analyzing requirements. The first four recipes are alternative ways to achieve essentially the same thing. Functional analysis generates high-quality requirements, use cases, and user stories, all of which are means to understand what the system must consist of.

By high-quality requirements, I mean requirements focused around a use case that are demonstrably the following:

  • Complete
  • Accurate
  • Correct
  • Consistent
  • Verifiable

The problem with textual requirements is that natural language is ambiguous, imprecise, and only weakly verifiable. Keeping text human-readable is very useful, especially for non-technical stakeholders, but is insufficient to ensure we are building the right system. The recipes covered in this chapter are as follows:

  • Functional analysis with scenarios
  • Functional analysis with activities
  • Functional analysis with state machines
  • Functional analysis with user stories
  • Model-based safety analysis
  • Model-based threat analysis
  • Specifying logical system interfaces
  • Creating the logical data schema

Why aren't textual requirements enough?

There are many reasons why textual requirements by themselves fail to result in usable, high-quality systems.

First, it is difficult to ensure all the following functionality is present:

  • All normal (sunny day) functionality
  • All edge cases
  • All variations of inputs, sequences, and timings
  • All exception, error, and fault cases
  • Qualities of service, such as performance, range, precision, timing, safety, security, and reliability
  • All stakeholders appropriately represented

Getting that much is a daunting task indeed. But even beyond that, there is an air gap between realizing a possibly huge set of shall statements and actually meeting the stakeholder needs. The stakeholder believes that if the system performs a specific function, then in practice, their needs will be met. Experience has shown that is not always true. Customers often ask for features that don't address their true needs. Further, requirements are volatile and interact in often subtle but potentially catastrophic ways.

We address this issue by capturing requirements both in textual and formal means via modeling. The textual requirements are important because they are human-readable by anyone even without modeling training. The model representation of the requirement is more formal and lends itself to more rigorous thought and analysis. In general, both are necessary.

Definitions

Before we get into the recipes, let's agree on common terms:

  • Requirement: A stakeholder requirement is a statement of what a stakeholder needs. A system requirement is a statement of what the system must do to satisfy a stakeholder need. We will focus on system requirements in this chapter. Normally, requirements are written in an active voice using the shall keyword to indicate a normative requirement, as in the following example:

    The system shall move the robot arm to comply with the user directive.

  • Actor: An actor is an element outside the scope of the system we are specifying that has interactions with the system that we care about. Actors may be human users, but they can also be other systems, software applications, or environments.
  • Use Case: A use case is a collection of scenarios and/or user stories around a common usage of a system. One may alternatively think of a use case as a collection of requirements around a usage-centered capability of the system. Still another way to think about use cases is that they are a sequenced set of system functions that execute in a coherent set of system-actor interactions. These all come down to basically the same thing. In practice, a use case is a named usage of a system that traces to anywhere between 10-100 requirements and 3-25 scenarios or user stories.
  • Activities: An activity diagram in SysML is a composite behavior of some portion of a system. Activities are defined in terms of sequences of actions which, in this context, correspond to either a system function, an input, or an output.

    Activities can model the behavior of use cases. Activities are said to be fully constructive in the sense that they model all possible behavior of the use case.

  • State Machines: A state machine in SysML is a composite behavior of a system element, such as a block or use case. In this context, a state machine is a fully constructive behavior focusing on conditions of the system (states) and how the system changes from state to state, executing system functions along the way.
  • Scenarios: A scenario is an interaction of a set of elements in a particular case or flow. In this usage, a scenario represents a partially complete behavior showing the interaction of the actors with the system as it executes a use case. The reason that it is partially complete is that a given scenario only shows one or a very small number of possible flows within a use case. Scenarios are roughly equivalent to user stories. In SysML, scenarios are generally captured using sequence diagrams.
  • User Story: A user story is a statement about system usage from a user or actor's point of view that achieves a user goal. User stories describe singular interactions and so are similar in scope to scenarios. User stories use a canonical textual formulation such as As a <user> I want <feature> so that <output or outcome>.

    Here's an example:

    As a pilot, I want to control the rudder of the aircraft using foot pedals so that I can set the yaw of the aircraft.

    User stores tend to be most beneficial for simpler interactions, as complex interactions are difficult to write out in understandable text. Scenarios are generally preferred for complex interactions or when there is a lot of precise detail that must be specified. Consider the following somewhat unwieldy user story:

    As a navigation system, I want to measure the position of the aircraft in 3 dimensions with an accuracy of +/- 1 m every 0.5s so that I can fly to the destination.

And that's still a rather simple scenario.

Functional analysis with scenarios

As stated in the chapter introduction, functional analysis is a means to both capture and improve requirements through analysis. In this case, we'll begin with scenarios as a way to elicit the scenarios from the stakeholder and create the requirements from those identified interactions. We then develop an executable model of the requirements that allows us to verify that the requirements interact how we expect them to, identify missing requirements, and perform what-if analyses for additional interactions.

Purpose

The purpose of this recipe is to create a high-quality set of requirements by working with the stakeholders to identify and characterize interactions of the system with its actors. This is particularly effective when the main focus of the use case is the interaction between the actors and the system or when trying to gather requirements from non-technical stakeholders.

Inputs and preconditions

The input is a use case naming a capability of the system from an actor-use point of view.

Outputs and postconditions

There are several outcomes, the most important of which is a set of requirements accurately and appropriately specifying the behavior of the system for the use case. Additional outputs include an executable use case model, logical system interfaces to support the use case behavior, along with a supporting logical data schema and a set of scenarios that can be used later as specifications of test cases.

How to do it

Figure 2.1 shows the workflow for this recipe. There are many steps in common with the next two recipes:

Figure 2.1 – Functional analysis with scenarios

Figure 2.1 – Functional analysis with scenarios

Identify the use case

This first step is to identify the generic usage of which the scenarios of interest, user stories, and requirements are aspects.

Describe the use case

The description of the use case should include its purpose, and a general description of the flows, preconditions, postconditions, and invariants (assumptions). Some modelers add the specific actors involved, user stories, and scenarios, but I prefer to use the model itself to contain those relations.

Identify related actors

The related actors are those people or systems outside our scope that interact with the system while it executes the current use case. These actors can send messages to the system, receive messages from the system, or both.

Define the execution context

The execution context is a kind of modeling sandbox that contains an executable component consisting of executable elements representing the use case and related actors. The recommended way to achieve this is to create separate blocks representing the use case and the actors, connected via ports. Having an isolated simulation sandbox allows different systems engineers to progress independently on different use case analyses.

Capture use case scenarios

Scenarios are singular interactions between the system and the actors during the execution of the use case. When working with non-technical stakeholders, it is an effective way to understand the desired interactions of the use case. We recommend starting with normal, sunny day scenarios before progressing to edge case and exceptional rainy day scenarios. It is important to understand that every message identifies or represents one or more requirements.

Create ports and interfaces in the execution context

Once we have a set of scenarios, we've identified the flows from the use case to the actors and from the actors to the system. By inference, this identifies ports relating the actors and the system, and the specific flows within the interfaces that define them.

Create an executable state model

This step creates what I call the normative state machine. Executing this state machine can recreate each of the scenarios we drew in the Capture use case scenarios section. All states, transitions, and actions represent requirements. Any state elements added only to assist in the execution that do not represent requirements should be stereotyped «non-normative» to clearly identify this fact. It is also common to create state behavior for the actors in a step known as instrumenting the actor to support the execution of the use case in the execution context.

Verify and validate requirements

Running the execution context for the use case allows us to demonstrate that our normative state machine in fact represents the flows identified by working with the stakeholder. It also allows us to identify flows and requirements that are missing, incomplete, or incorrect. These result in Requirements_change change requests to fix the identified requirement defects.

Requirements_change

Parallel to the development and execution of the use case model, we maintain the textual requirements. This workflow event indicates the need to fix an identified requirement defect.

Update the requirements set

In response to an identified requirement defect, we fix the textual requirements by adding, deleting, or modifying requirements. This will then be reflected in the updated model.

Add trace links

Once the use case model and requirements stabilize, we add trace links using the «trace» relation or something similar. This is generally a backtrace to stakeholder requirements as well as forward links to any architectural elements that might already exist.

Perform the use case and requirements review

Once the work has stabilized, a review for correctness and compliance with standards may be done. This allows subject matter experts and stakeholders to review the requirements, use case, states, and scenarios for correctness and for quality assurance staff to ensure compliance with modeling and requirements standards.

Let's have a look at an example.

Identify the use case

This example will examine the Emulate Basic Gearing use case. The use case is shown in Figure 2.2:

Figure 2.2 – Emulate Basic Gearing use case

Figure 2.2 – Emulate Basic Gearing use case

Describe the use case

All model elements deserve a useful description. In the case of a use case, we typically use the format shown here:

Figure 2.3 – Use case description

Figure 2.3 – Use case description

Identify related actors

The related actors in this example are the Rider and the Training App. The rider signals the system to change the gearing via the gears control and receives a response in terms of changing resistance. The training app, when connected, is notified of the current gearing so that it can be displayed. The relation of the actors to the use case is shown in Figure 2.2.

Define the execution context

The execution context creates blocks that represent the actors and the use case for the purpose of the analysis. In this example, the following naming conventions are observed:

  • The block representing the use case has the use case name (with white space removed) preceded by Uc_. Thus, for this example, the use case block is named Uc_EmulateBasicGearing.
  • Blocks representing the actors are given the actor name preceded with a and an abbreviation of the use case. For this use case, the prefix is aEBG_ so the actor blocks are named aEBG_Rider and aEBG_TrainingApp.
  • The interface blocks are named as <use case block>_<actor block>. The names of the two interface blocks are iUc_EmulateBasicGearing_aEBG_Rider and iUc_EmulateBasicGearing_aEBG_TrainingApp. The normal form of the interface block is associated with the proxy port on the use case block; the conjugated form is associated with the corresponding proxy port on the actor block.

All these elements are shown in the Internal Block Diagram (IBD) in Figure 2.4:

Figure 2.4 – Emulate Basic Gearing execution context

Figure 2.4 – Emulate Basic Gearing execution context

Capture use case scenarios

Scenarios here are captured to show the interaction of the system with the actors using this use case. Note that continuous flows are shown as flows with the «continuous» stereotype. This resistance at a specific level is applied continuously until the level of resistance is changed. As is usual in use case analysis, messages between the actors are modeled as events and invocations of system functions on the use case lifeline are modeled as operations.

The first scenario (Figure 2.5) shows normal gear changes from the rider. Note that the messages to self on the use case block lifeline indicate system functions identified during the scenario development:

Figure 2.5 – Emulate Basic Gearing scenario 1

Figure 2.5 – Emulate Basic Gearing scenario 1

The next scenario shows what happens when the rider tries to increment the gearing beyond the maximum gearing allowed by the current configuration. It is shown in Figure 2.6:

Figure 2.6 – Emulate Basic Gearing scenario 2

Figure 2.6 – Emulate Basic Gearing scenario 2

The last scenario for this use case shows the rejection of a requested gear change below the provided gearing:

Figure 2.7 – Emulate Basic Gearing scenario 3

Figure 2.7 – Emulate Basic Gearing scenario 3

Based on these sequences, we identify the following requirements:

  • The system shall respond to applied pedal torque with resistance calculated from the base level of resistance, current gearing, and applied torque to simulate pedal resistance during road riding.
  • The system shall send the current gearing to the training app when the current gearing changes.
  • The system shall respond to a rider-initiated increase in gear by applying the new level of gearing provided that it does not exceed the maximum gearing of the gearing configuration.
  • The system shall respond to a ride-initiated decrease in gear by applying the new level of gearing provided that it does not exceed the minimum gearing of the gearing configuration.

Create ports and interfaces in the execution context

It is a simple matter to update the ports and interface blocks to contain the messages going between the actors and the use case. The sequence diagrams identify the messages between the use case and actor blocks, so the interface blocks must support those specific flows (Figure 2.8):

Figure 2.8 – Emulate Basic Gearing ports and interfaces

Figure 2.8 – Emulate Basic Gearing ports and interfaces

Create an executable state model

This step constructs the normative state machine for the use case as well as instrumenting the actors with their own state machines. The state machine of the use case block is the most interesting because it represents the requirements. Figure 2.9 shows the state machine for the Emulate Basic Gearing use case:

Figure 2.9 – Emulate Basic Gearing state machine

Figure 2.9 – Emulate Basic Gearing state machine

To support the execution, the system functions must be elaborated enough to support the execution and simulation. These system functions include applyResistance(), checkGearing(), and changeGear(). Figure 2.10 shows their simple implementation:

Figure 2.10 – Emulate Basic Gearing system functions

Figure 2.10 – Emulate Basic Gearing system functions

The system variable gear is represented as a Real (from the SysML value type library), representing the gear multiplier, in a fashion similar to gear-inches, a commonly used measure in cycling. The flow properties appliedTorque and resistance are likewise implemented as Reals.

The state machines for the actor blocks are even simpler than those of the use case block. Figure 2.11 shows the Rider state machine:

Figure 2.11 – Rider actor block state machine

Figure 2.11 – Rider actor block state machine

Figure 2.12 shows the TrainingApp state machine and the implementation of its displayGearing() function:

Figure 2.12 – TrainingApp actor block state machine

Figure 2.12 – TrainingApp actor block state machine

Lastly, some constants are defined. DEFAULT_GEARING is set to the same value as MIN_GEARING; in this case, 30 gear-inches. MAX_GEARING is set to about the same as a 53x10 gearing, 140. The GEAR_INCREMENT is used for incrementing or decrementing the gearing and is set to 5 gear-inches for the purpose of simulation.

Verify and validate requirements

To facilitate control of the execution, a panel diagram is created. The buttons insert events in the relevant objects and the text boxes display and support modification of the value and flow properties. A panel diagram is a useful feature of the IBM Rhapsody modeling tool used to create these models:

Figure 2.13 – Emulate Basic Gearing panel diagram

Figure 2.13 – Emulate Basic Gearing panel diagram

The execution of the state model recreates the sequence diagrams. Figure 2.14 shows the recreation of Scenario 1 (Figure 2.5) by the executing model. The creation of such sequence diagrams automatically from execution is another useful Rhapsody feature:

Figure 2.14 – Animated sequence diagram from model execution

Figure 2.14 – Animated sequence diagram from model execution

While in review, the project lead notices that there is no requirement to display the initial starting value for the gearing, before a specific gear has been selected. Additionally, we see that the requirement to notify the training app was missing. These are identified as missing requirements that must be added.

Requirements_change

In this example, we notice that we omitted a requirement to update the rider display of the gearing. The change has already been made to the state machine.

Update requirement set

We add the following requirements to the requirements set:

  • The system shall display the currently selected gear.
  • The system shall default to the minimum gear during initialization.

Add trace links

In this case, we ensure there are trace links back to stakeholder requirements as well as from the use case to the requirements. This is shown in the use case diagram in Figure 2.15. The newly identified requirements are highlighted with a bold border:

Figure 2.15 – Emulate Basic Gearing requirements

Figure 2.15 – Emulate Basic Gearing requirements

Perform a use case and requirements review

The requirements model can now be reviewed by relevant stakeholders. The work products that should be included in the review include all the diagrams shown in this section, the requirements, and the executing model. The use of the executing model allows a what-if examination of the requirements set to be easily done during the review. Such questions as What happens to the gearing if the rider turns the system off and back on? or What is absolute maximum gearing to be allowed? can be asked. The simulation of the model allows the questions to either be answered by running the simulation case or can be identified as an item that requires resolution.

Left arrow icon Right arrow icon
Download code icon Download Code

Key benefits

  • Learn how Agile and MBSE can work iteratively and collaborate to overcome system complexity
  • Develop essential systems engineering products and achieve crucial enterprise objectives with easy-to-follow recipes
  • Build efficient system engineering models using tried and trusted best practices

Description

Agile MBSE can help organizations manage constant change and uncertainty while continuously ensuring system correctness and meeting customers’ needs. But deploying it isn’t easy. Agile Model-Based Systems Engineering Cookbook is a little different from other MBSE books out there. This book focuses on workflows – or recipes, as the author calls them – that will help MBSE practitioners and team leaders address practical situations that are part of deploying MBSE as part of an agile development process across the enterprise. Written by Dr. Bruce Powel Douglass, a world-renowned expert in MBSE, this book will take you through important systems engineering workflows and show you how they can be performed effectively with an agile and model-based approach. You’ll start with the key concepts of agile methods for systems engineering, but we won’t linger on the theory for too long. Each of the recipes will take you through initiating a project, defining stakeholder needs, defining and analyzing system requirements, designing system architecture, performing model-based engineering trade studies, all the way to handling systems specifications off to downstream engineering. By the end of this MBSE book, you’ll have learned how to implement critical systems engineering workflows and create verifiably correct systems engineering models.

Who is this book for?

If you are a systems engineer who wants to pursue model-based systems engineering in an agile setting, this book will show you how you can do that without breaking a sweat. Fundamental knowledge of SysML is necessary; the book will teach you the rest.

What you will learn

  • Apply agile methods to develop systems engineering specifications
  • Perform functional analysis with SysML
  • Derive and model systems architectures from key requirements
  • Model crucial engineering data to clarify systems requirements
  • Communicate decisions with downstream subsystem implementation teams
  • Verify specifications with model reviews and simulations
  • Ensure the accuracy of systems models through model-based testing
Estimated delivery fee Deliver to Chile

Standard delivery 10 - 13 business days

$19.95

Premium delivery 3 - 6 business days

$40.95
(Includes tracking information)

Product Details

Country selected
Publication date, Length, Edition, Language, ISBN-13
Publication date : Mar 31, 2021
Length: 646 pages
Edition : 1st
Language : English
ISBN-13 : 9781838985837
Languages :
Concepts :

What do you get with Print?

Product feature icon Instant access to your digital copy whilst your Print order is Shipped
Product feature icon Paperback book shipped to your preferred address
Product feature icon Redeem a companion digital copy on all Print orders
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
Product feature icon AI Assistant (beta) to help accelerate your learning
OR
Modal Close icon
Payment Processing...
tick Completed

Shipping Address

Billing Address

Shipping Methods
Estimated delivery fee Deliver to Chile

Standard delivery 10 - 13 business days

$19.95

Premium delivery 3 - 6 business days

$40.95
(Includes tracking information)

Product Details

Publication date : Mar 31, 2021
Length: 646 pages
Edition : 1st
Language : English
ISBN-13 : 9781838985837
Languages :
Concepts :

Packt Subscriptions

See our plans and pricing
Modal Close icon
$19.99 billed monthly
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Simple pricing, no contract
$199.99 billed annually
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Choose a DRM-free eBook or Video every month to keep
Feature tick icon PLUS own as many other DRM-free eBooks or Videos as you like for just $5 each
Feature tick icon Exclusive print discounts
$279.99 billed in 18 months
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Choose a DRM-free eBook or Video every month to keep
Feature tick icon PLUS own as many other DRM-free eBooks or Videos as you like for just $5 each
Feature tick icon Exclusive print discounts

Frequently bought together


Stars icon
Total $106.97 $119.97 $13.00 saved
Systems Engineering Demystified
$54.99
Becoming an Agile Software Architect
$54.99
Agile Model-Based Systems Engineering Cookbook
$45.99
Total $106.97$119.97 $13.00 saved Stars icon

Table of Contents

6 Chapters
Chapter 1: The Basics of Agile Systems Modeling Chevron down icon Chevron up icon
Chapter 2: System Specification Chevron down icon Chevron up icon
Chapter 3: Developing System Architectures Chevron down icon Chevron up icon
Chapter 4: Handoff to Downstream Engineering Chevron down icon Chevron up icon
Chapter 5: Demonstration of Meeting Needs: Verification and Validation Chevron down icon Chevron up icon
Other Books You May Enjoy Chevron down icon Chevron up icon

Customer reviews

Top Reviews
Rating distribution
Full star icon Full star icon Full star icon Full star icon Half star icon 4.8
(9 Ratings)
5 star 77.8%
4 star 22.2%
3 star 0%
2 star 0%
1 star 0%
Filter icon Filter
Top Reviews

Filter reviews by




Eldad Palachi Apr 23, 2021
Full star icon Full star icon Full star icon Full star icon Full star icon 5
This book is a must-read for hands-on architects, development managers and engineers who want to apply UML/SysML in a methodical, contemporary and effective manner.It is well organized around workflows that cover the whole development lifecycle (from product planning to validation) and every chapter follows a consistent structure which makes it easier to readers to focus on what is relevant to them. I really liked the "How to do. it..." sections with diagrams that outline the steps of the different workflows and I found the examples to be at just the right level of complexity to understand how to apply this MBSE approach.Another thing that sets this book apart is the coverage of hazards and safety aspects as well as verification and validation described in chapter 5.You can really see that the author is not someone who just speaks about MBSE, but also practices it in the field.
Amazon Verified review Amazon
Amazon Customer Apr 17, 2021
Full star icon Full star icon Full star icon Full star icon Full star icon 5
This is an excellent addition to the literature for practical systems engineers who want to take advantage of agile and MBSE techniques. Bruce is a wonderful combination of being an expert in the field as well as teaching. I was a bit skeptical that another book was needed but I stand corrected. This book will be very helpful for people who have some knowledge on the subject but need a bit of assistance on how to apply them in their real world jobs.The first thing that stands out to me is the focus on critical activities systems engineers need to master. He shows how to develop requirements, perform trade studies or create architectures using agile and MBSE. You’re not going to have academic ramblings of a topic in isolation of what it is you’re trying to accomplish. The opposite of just modeling for modeling sake.Other things that stand out to me include having a nice balance between descriptive text and worked examples. This is a book you can quickly find material on the relevant topic and get the help you need to remove your roadblock. And the models used in the book are available to download so you can poke around with the specific syntax if that is desired. A major value I got from the book are seemingly endless tidbits of help that will assist you moving from playing with the techniques to mastering them and improving your work. Some of the points apply for small efforts such as the value of different SysML behavioral diagrams and some are helpful for working on large projects where the approach needs to support many people working concurrently. Finally, I appreciate how Bruce is not dogmatic in this book. The material is written in a clear, understandable manner, and he is still able to talk about pros and cons of different ways to solve the same problem. Well done!- Tom Wheeler
Amazon Verified review Amazon
W. V. D. Heiden Apr 06, 2021
Full star icon Full star icon Full star icon Full star icon Full star icon 5
System Engineering taken out of the dry theoretical area into the world of fun combined with thorough understanding of systems engineering.Bruce is still the king of explaining tough subjects in an almost light way and makes you understand the topics almost easily.I’ve read all his books and although all books have an overlap, this one is still not boring or disappointing, on the contrary, there are always new topics and insights that, at least for me, help me in applying MBSE in my work.The online examples are very recommended to download, if you do not own Rhapsody, you can download an evaluation version from IBM that helps you in better understanding the examples in the book.Only small drawback is that the examples are only for IBM but I’m sure that is not difficult to convert to Sparx or NoMagic. Highly recommended for everyone working (or planning to work) with MBSE.
Amazon Verified review Amazon
J. D. Baker May 28, 2021
Full star icon Full star icon Full star icon Full star icon Full star icon 5
A couple years ago I wrote a Review of Agile Systems Engineering that started with the statement "This is the best book that Bruce has written in his prolific career - or at least it is the one that I like best." That statement is still true, however, the Agile MBSE Cookbook is a very close second. I like and appreciate that Bruce states from the very beginning that the output of a systems engineering effort is not an executable product but a specification. I also like the notion that the specification can have executable elements as part of the model. I spent a lot of time in chapter 2 because other methods focus too much on the object-oriented style and not enough on functional analysis. We get 4 different recipes for functional analysis in the Cookbook. The challenge will of course be to pick the one that is best for whatever we are working on. I have read the book but I can't claim to fully understand it yet. There's enough here to keep me studying for quite a while.If the examples aren't available in your favorite modeling tool, I suggest you take the time to do your own implementation, which is what I am doing. The book is quite tool agnostic.
Amazon Verified review Amazon
Moshe C. Apr 13, 2021
Full star icon Full star icon Full star icon Full star icon Full star icon 5
Many books cover Model Based Systems Engineering (MBSE), but this one extends the scope of MBSE to other areas that most MBSE practitioners probably don't touch, such as (the elephant in many rooms) deploying MBSE as part of an Agile development process across the enterprise, or leveraging the system models to drive early verification and validation. More on this later.I found it easy to use the book for practical situations, primarily because it is focused on workflows, or as the author calls them - recipes. Each workflow starts with its purpose and then defines its inputs and outputs, how to do it and - where applicable - an actual example. I liked it because it allowed me to focus right away on the workflows where I needed clarity, where other workflows can wait. And in case you want to go deeper, you can even download the example models. I didn't have a need for this (yet) as the examples are well explained throughout the book, with plenty of screenshots. And as the author has a deep experience with the IBM MBSE tool, and the reviewer has a deep experience with the Dassault MBSE tool, the book is useful regardless of your favorite MBSE tool!I also liked the fact that the book addresses the needs of several types of engineers (or, as often is the case - engineers wearing multiple hats). It covers the application of Agile across the enterprise as an integral part of MBSE, from managing backlogs, to Agile planning, to prioritization, to release planning, product roadmaps and even effective reviews and walk-throughs. These are topics that many systems engineers, especially in industries such as A&D and Automotive, never learned back in Engineering school.I found the chapter on Functional analysis, or what some may call Logical models, very interesting. The workflows in the book lead you to modeling that is an elaboration on the requirements with scenarios, activities, state machines or even user stories, resulting in models that while they are design independent, they are also executable. This allows you to analyze the requirements for their correctness, completeness, safety and security.Other workflows address the more common aspects of Systems Engineering, such as Architectural Design going down to Detailed Design, leveraging patterns, abstraction layers, etc. However, the book does not assume that a System always ends up in software (like in a SysML to UML transition). It addresses the workflows for the creation of a deployment architecture and interdisciplinary interfaces that enable a handoff to downstream engineering in multiple domains, such as electrical, mechanical, etc. in addition to software.Another set of workflows that describe "cool ideas" that only now are starting to be deployed as part of MBSE around leveraging MBSE for early Verification and Validation on one hand, and on the other hand to be used as a reference, and on the other other hand as a test driver for the actual product. The book takes you through all the steps, from identifying the system under test (aka SUT), to the test architecture, test cases, test coverage and even test-driven modeling. These too are subjects that many of us did not learn back at school, and if we did, it was nothing more than just being mentioned in class. The screenshots in the book make all of these concepts very concrete.And if you are a cyclist, you are already ahead of those who aren't, because the example used throughout the book is a Pegasus bike trainer... actually, a very cool example, easy to understand, not too complex, but not trivial either.I highly recommend this book, especially if you are an MBSE practitioner, or managing teams of MBSE practitioners.
Amazon Verified review Amazon
Get free access to Packt library with over 7500+ books and video courses for 7 days!
Start Free Trial

FAQs

What is the digital copy I get with my Print order? Chevron down icon Chevron up icon

When you buy any Print edition of our Books, you can redeem (for free) the eBook edition of the Print Book you’ve purchased. This gives you instant access to your book when you make an order via PDF, EPUB or our online Reader experience.

What is the delivery time and cost of print book? Chevron down icon Chevron up icon

Shipping Details

USA:

'

Economy: Delivery to most addresses in the US within 10-15 business days

Premium: Trackable Delivery to most addresses in the US within 3-8 business days

UK:

Economy: Delivery to most addresses in the U.K. within 7-9 business days.
Shipments are not trackable

Premium: Trackable delivery to most addresses in the U.K. within 3-4 business days!
Add one extra business day for deliveries to Northern Ireland and Scottish Highlands and islands

EU:

Premium: Trackable delivery to most EU destinations within 4-9 business days.

Australia:

Economy: Can deliver to P. O. Boxes and private residences.
Trackable service with delivery to addresses in Australia only.
Delivery time ranges from 7-9 business days for VIC and 8-10 business days for Interstate metro
Delivery time is up to 15 business days for remote areas of WA, NT & QLD.

Premium: Delivery to addresses in Australia only
Trackable delivery to most P. O. Boxes and private residences in Australia within 4-5 days based on the distance to a destination following dispatch.

India:

Premium: Delivery to most Indian addresses within 5-6 business days

Rest of the World:

Premium: Countries in the American continent: Trackable delivery to most countries within 4-7 business days

Asia:

Premium: Delivery to most Asian addresses within 5-9 business days

Disclaimer:
All orders received before 5 PM U.K time would start printing from the next business day. So the estimated delivery times start from the next day as well. Orders received after 5 PM U.K time (in our internal systems) on a business day or anytime on the weekend will begin printing the second to next business day. For example, an order placed at 11 AM today will begin printing tomorrow, whereas an order placed at 9 PM tonight will begin printing the day after tomorrow.


Unfortunately, due to several restrictions, we are unable to ship to the following countries:

  1. Afghanistan
  2. American Samoa
  3. Belarus
  4. Brunei Darussalam
  5. Central African Republic
  6. The Democratic Republic of Congo
  7. Eritrea
  8. Guinea-bissau
  9. Iran
  10. Lebanon
  11. Libiya Arab Jamahriya
  12. Somalia
  13. Sudan
  14. Russian Federation
  15. Syrian Arab Republic
  16. Ukraine
  17. Venezuela
What is custom duty/charge? Chevron down icon Chevron up icon

Customs duty are charges levied on goods when they cross international borders. It is a tax that is imposed on imported goods. These duties are charged by special authorities and bodies created by local governments and are meant to protect local industries, economies, and businesses.

Do I have to pay customs charges for the print book order? Chevron down icon Chevron up icon

The orders shipped to the countries that are listed under EU27 will not bear custom charges. They are paid by Packt as part of the order.

List of EU27 countries: www.gov.uk/eu-eea:

A custom duty or localized taxes may be applicable on the shipment and would be charged by the recipient country outside of the EU27 which should be paid by the customer and these duties are not included in the shipping charges been charged on the order.

How do I know my custom duty charges? Chevron down icon Chevron up icon

The amount of duty payable varies greatly depending on the imported goods, the country of origin and several other factors like the total invoice amount or dimensions like weight, and other such criteria applicable in your country.

For example:

  • If you live in Mexico, and the declared value of your ordered items is over $ 50, for you to receive a package, you will have to pay additional import tax of 19% which will be $ 9.50 to the courier service.
  • Whereas if you live in Turkey, and the declared value of your ordered items is over € 22, for you to receive a package, you will have to pay additional import tax of 18% which will be € 3.96 to the courier service.
How can I cancel my order? Chevron down icon Chevron up icon

Cancellation Policy for Published Printed Books:

You can cancel any order within 1 hour of placing the order. Simply contact customercare@packt.com with your order details or payment transaction id. If your order has already started the shipment process, we will do our best to stop it. However, if it is already on the way to you then when you receive it, you can contact us at customercare@packt.com using the returns and refund process.

Please understand that Packt Publishing cannot provide refunds or cancel any order except for the cases described in our Return Policy (i.e. Packt Publishing agrees to replace your printed book because it arrives damaged or material defect in book), Packt Publishing will not accept returns.

What is your returns and refunds policy? Chevron down icon Chevron up icon

Return Policy:

We want you to be happy with your purchase from Packtpub.com. We will not hassle you with returning print books to us. If the print book you receive from us is incorrect, damaged, doesn't work or is unacceptably late, please contact Customer Relations Team on customercare@packt.com with the order number and issue details as explained below:

  1. If you ordered (eBook, Video or Print Book) incorrectly or accidentally, please contact Customer Relations Team on customercare@packt.com within one hour of placing the order and we will replace/refund you the item cost.
  2. Sadly, if your eBook or Video file is faulty or a fault occurs during the eBook or Video being made available to you, i.e. during download then you should contact Customer Relations Team within 14 days of purchase on customercare@packt.com who will be able to resolve this issue for you.
  3. You will have a choice of replacement or refund of the problem items.(damaged, defective or incorrect)
  4. Once Customer Care Team confirms that you will be refunded, you should receive the refund within 10 to 12 working days.
  5. If you are only requesting a refund of one book from a multiple order, then we will refund you the appropriate single item.
  6. Where the items were shipped under a free shipping offer, there will be no shipping costs to refund.

On the off chance your printed book arrives damaged, with book material defect, contact our Customer Relation Team on customercare@packt.com within 14 days of receipt of the book with appropriate evidence of damage and we will work with you to secure a replacement copy, if necessary. Please note that each printed book you order from us is individually made by Packt's professional book-printing partner which is on a print-on-demand basis.

What tax is charged? Chevron down icon Chevron up icon

Currently, no tax is charged on the purchase of any print book (subject to change based on the laws and regulations). A localized VAT fee is charged only to our European and UK customers on eBooks, Video and subscriptions that they buy. GST is charged to Indian customers for eBooks and video purchases.

What payment methods can I use? Chevron down icon Chevron up icon

You can pay with the following card types:

  1. Visa Debit
  2. Visa Credit
  3. MasterCard
  4. PayPal
What is the delivery time and cost of print books? Chevron down icon Chevron up icon

Shipping Details

USA:

'

Economy: Delivery to most addresses in the US within 10-15 business days

Premium: Trackable Delivery to most addresses in the US within 3-8 business days

UK:

Economy: Delivery to most addresses in the U.K. within 7-9 business days.
Shipments are not trackable

Premium: Trackable delivery to most addresses in the U.K. within 3-4 business days!
Add one extra business day for deliveries to Northern Ireland and Scottish Highlands and islands

EU:

Premium: Trackable delivery to most EU destinations within 4-9 business days.

Australia:

Economy: Can deliver to P. O. Boxes and private residences.
Trackable service with delivery to addresses in Australia only.
Delivery time ranges from 7-9 business days for VIC and 8-10 business days for Interstate metro
Delivery time is up to 15 business days for remote areas of WA, NT & QLD.

Premium: Delivery to addresses in Australia only
Trackable delivery to most P. O. Boxes and private residences in Australia within 4-5 days based on the distance to a destination following dispatch.

India:

Premium: Delivery to most Indian addresses within 5-6 business days

Rest of the World:

Premium: Countries in the American continent: Trackable delivery to most countries within 4-7 business days

Asia:

Premium: Delivery to most Asian addresses within 5-9 business days

Disclaimer:
All orders received before 5 PM U.K time would start printing from the next business day. So the estimated delivery times start from the next day as well. Orders received after 5 PM U.K time (in our internal systems) on a business day or anytime on the weekend will begin printing the second to next business day. For example, an order placed at 11 AM today will begin printing tomorrow, whereas an order placed at 9 PM tonight will begin printing the day after tomorrow.


Unfortunately, due to several restrictions, we are unable to ship to the following countries:

  1. Afghanistan
  2. American Samoa
  3. Belarus
  4. Brunei Darussalam
  5. Central African Republic
  6. The Democratic Republic of Congo
  7. Eritrea
  8. Guinea-bissau
  9. Iran
  10. Lebanon
  11. Libiya Arab Jamahriya
  12. Somalia
  13. Sudan
  14. Russian Federation
  15. Syrian Arab Republic
  16. Ukraine
  17. Venezuela