Hello Dr. Douglass,
I’m a newbe in MBSE and I want to learn for use the MBSE in my projects. I have bought your book “Agile System Engineer” and start to learn. I have understand the need of the tool, of the methodology and of the language, so now I have decided to apply this concepts for build a simple system.
My simple system is a quadcopter. During my university path, I have developed the math model, the control laws and the firmware, but I haven’t put all this thing together, so I think that this is a good starting point to apply the MBSE for build a prototype of my quadcopter.
The problem is the start, how I start my project? I have read in your book, that is fundamental to start, considering the stakeholders needs for gathering the stakeholder requirements. Once I have this requirements I can proceed to make the system requirements, and using those, proced in the developping the design of the system.
In my case, I have selected some possibly stakeholders that have some interest in the my system, but I’m unable to follow what is write in your book. In particular, in the chapter 4, both in the Treadmill and in the T-Wrench examples, you first start to showing the use cases of those system and after this, you start to speak on how eliciting the stakeholder requirements from this use case, see the example of your conversation between you and the doctor, for the patient ventilator.
I’m confusing because I need some use cases before to start to make questions for the stakeholders, but where to come this use cases?
Please, can you help me to understand this crucial steps?
Ps
In my project, the stakeholders that I have selected, in reality there are a single person ( that are I ) with different roles: for example i'm a programmer, i'm a pilot, i'm a technician etc… Is this correct, or I’m wrong?
Hello Dr. Douglass, many thanks for the answer!
I understood the difference between the stakeholders and actors and how i can use they.
Many Thanks!
All (human) actors are stakeholders but not all stakeholders are actors. Purchasers, for example, may never use a system, but they are still stakeholders. Non-human systems with interact with the system are actors but not stakeholders.
In the example, the Pilot and Voyeur are different actors with different interactions with the system.
I just so happened to have modeled a drone, so you lucked out. As for getting started, you can either start with the System and think about what are the large-scale things it does for/with the actors, or you can start with the actors and think about what it expects/provides to the system as a way to get started.
It sounds like you started with some detailed design (the math for the control loops and now you're stepping back and trying to engineer it.
You're right we start with stakeholder needs. Who are the stakeholders? Well, there are a number of possibilities, depending on the system. Certainly the pilot is one but there are other possibilities. Consider the Aviary System of Systems which contains a drone ("Hummingbird"), a pilot controller ("Bird Feeder") and a set of devices that can remotely view the surveilance video feed ("Bird Watchers"). Figure 1.
In this system, who are the actors? Here is a use case diagram:
What would an activity flow look like for a use case, say "Manually Directed Flight"? Figure 3
With a state mode that looks like Figure 4
Once the use case analysis for the use cases is complete, you can merge these into a systems architecture (Figure 5)
Once that's done, you can consider the "subsystems", which in this case are the component Systems as this is a SoS model. Looking at the drone, you can repeat these steps for this more narrow context, such as with Hummingbird use cases. Note that the actors are the peer subsystems in the SoS model along with the GPS, required for autonomous flight:
Which results in an architecture for the drone itself:
iIn this case, consisting of the following subsystems: Avionics, Comms, Propulsion, Power Management, Navigation, Surveillance, and Fault Management.
Of course, this was all started by focusing on the stakeholder requirements (see the attached file).
I hope this helps.
- b