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
€24.99 €27.99
Full star icon Full star icon Full star icon Full star icon Half star icon 4.8 (9 Ratings)
eBook Mar 2021 646 pages 1st Edition
eBook
€24.99 €27.99
Paperback
€34.99
Subscription
Free Trial
Renews at €18.99p/m
Arrow left icon
Profile Icon Dr. Bruce Powel Douglass
Arrow right icon
€24.99 €27.99
Full star icon Full star icon Full star icon Full star icon Half star icon 4.8 (9 Ratings)
eBook Mar 2021 646 pages 1st Edition
eBook
€24.99 €27.99
Paperback
€34.99
Subscription
Free Trial
Renews at €18.99p/m
eBook
€24.99 €27.99
Paperback
€34.99
Subscription
Free Trial
Renews at €18.99p/m

What do you get with eBook?

Product feature icon Instant access to your Digital eBook purchase
Product feature icon Download this book in EPUB and PDF formats
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

Billing Address

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

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 : 9781839218149
Concepts :

What do you get with eBook?

Product feature icon Instant access to your Digital eBook purchase
Product feature icon Download this book in EPUB and PDF formats
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

Billing Address

Product Details

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

Packt Subscriptions

See our plans and pricing
Modal Close icon
€18.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
€189.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
€264.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 118.97
Agile Model-Based Systems Engineering Cookbook
€34.99
Systems Engineering Demystified
€41.99
Becoming an Agile Software Architect
€41.99
Total 118.97 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

How do I buy and download an eBook? Chevron down icon Chevron up icon

Where there is an eBook version of a title available, you can buy it from the book details for that title. Add either the standalone eBook or the eBook and print book bundle to your shopping cart. Your eBook will show in your cart as a product on its own. After completing checkout and payment in the normal way, you will receive your receipt on the screen containing a link to a personalised PDF download file. This link will remain active for 30 days. You can download backup copies of the file by logging in to your account at any time.

If you already have Adobe reader installed, then clicking on the link will download and open the PDF file directly. If you don't, then save the PDF file on your machine and download the Reader to view it.

Please Note: Packt eBooks are non-returnable and non-refundable.

Packt eBook and Licensing When you buy an eBook from Packt Publishing, completing your purchase means you accept the terms of our licence agreement. Please read the full text of the agreement. In it we have tried to balance the need for the ebook to be usable for you the reader with our needs to protect the rights of us as Publishers and of our authors. In summary, the agreement says:

  • You may make copies of your eBook for your own use onto any machine
  • You may not pass copies of the eBook on to anyone else
How can I make a purchase on your website? Chevron down icon Chevron up icon

If you want to purchase a video course, eBook or Bundle (Print+eBook) please follow below steps:

  1. Register on our website using your email address and the password.
  2. Search for the title by name or ISBN using the search option.
  3. Select the title you want to purchase.
  4. Choose the format you wish to purchase the title in; if you order the Print Book, you get a free eBook copy of the same title. 
  5. Proceed with the checkout process (payment to be made using Credit Card, Debit Cart, or PayPal)
Where can I access support around an eBook? Chevron down icon Chevron up icon
  • If you experience a problem with using or installing Adobe Reader, the contact Adobe directly.
  • To view the errata for the book, see www.packtpub.com/support and view the pages for the title you have.
  • To view your account details or to download a new copy of the book go to www.packtpub.com/account
  • To contact us directly if a problem is not resolved, use www.packtpub.com/contact-us
What eBook formats do Packt support? Chevron down icon Chevron up icon

Our eBooks are currently available in a variety of formats such as PDF and ePubs. In the future, this may well change with trends and development in technology, but please note that our PDFs are not Adobe eBook Reader format, which has greater restrictions on security.

You will need to use Adobe Reader v9 or later in order to read Packt's PDF eBooks.

What are the benefits of eBooks? Chevron down icon Chevron up icon
  • You can get the information you need immediately
  • You can easily take them with you on a laptop
  • You can download them an unlimited number of times
  • You can print them out
  • They are copy-paste enabled
  • They are searchable
  • There is no password protection
  • They are lower price than print
  • They save resources and space
What is an eBook? Chevron down icon Chevron up icon

Packt eBooks are a complete electronic version of the print edition, available in PDF and ePub formats. Every piece of content down to the page numbering is the same. Because we save the costs of printing and shipping the book to you, we are able to offer eBooks at a lower cost than print editions.

When you have purchased an eBook, simply login to your account and click on the link in Your Download Area. We recommend you saving the file to your hard drive before opening it.

For optimal viewing of our eBooks, we recommend you download and install the free Adobe Reader version 9.