I received the following comment concerning our blog entitled: “MBSE and Requirements“.
“I’ve read your article about MBSE and requirements and found it very good (as usual). In the MBSE group on LinkedIn there’s a discussion about how and why MBSE tools should provide document generation functionality and I think your article gives a perfect answer. I’m writing here concerning a specific phrase you made at the end of the article: “Trying to force MBSE on small, simple, one-time projects…” What do you mean by “one-time projects”? I think you are referring to projects delivering something that won’t be likely extended but I might be wrong. The reason why I’m asking is that a project is expected to be “one-time” given the definition of project so there must be another meaning.”
The short answer to your question is that what I really meant by “one-time” is really the use (continuing use or reuse) of the model rather than in support of a one-time project. Will the model being developed be used only once during the life of the project and then thrown away, or will the model continue to be used after the project is over? I elaborate in the following discussion.
As stated in the previous blog, I am an advocate of the philosophy that “one-size doesn’t fit all”. One of the themes of my previous blog was to address management’s concerns about the application of MBSE to projects. There are some projects that the return on investment (ROI) does not justify the additional effort and cost to use MBSE. Thus the question to be addressed is “What type of projects will benefit from the use of MBSE and which type of projects will not see a worthwhile benefit?”
I use small vs medium vs large as one measure. For small projects just the cost alone probably would prohibit the use of MBSE given the cost of the tool, cost of maintenance, cost of training, cost of tailoring, time to produce the model, time and effort to maintain the model, etc. In this case, it would be hard to justify the use of MBSE. For medium and large projects, the cost is not as much of an issue depending on the other two factors of simple vs complex and one-time use type projects.
Because of the complexity of some projects, MBSE really shines as it is hard to imagine being able to manage the complexity without MBSE type tools. MBSE allows you to better understand the system, the interactions (interfaces) between internal systems as well as systems external to the system. Also in complex systems, there are many requirements that have dependencies – both negative and positive – where a change in one requires a change in the other. For complex systems, MBSE helps you develop a set of requirements that are complete, correct, and consistent.
Also for complex systems, if you have modeled your system and corresponding requirements, the tool is a prerequisite to being able to manage change. Change happens. The MBSE tool allows you to do a much better job of accessing the impact of changes to the rest of the requirements and system. If someone changes a performance requirement, how does that change ripple through the requirement set and resulting design? For complex systems the MBSE tool is really the only way to accurately assess these types of impacts. For simple systems with a smaller set of requirements, this is not as much of an issue.
The last factor “one-time” use is the focus of the question. By one-time I am referring to the use of the tool, both during the project and after the product has been delivered. It is true that a classic project has a well-defined beginning and end. The reason for a project may be to develop and deliver a product. There are some projects where once the product is delivered, the team will have no further involvement with the product. In this case, the costs and efforts associated with an MBSE approach may not have provided much benefit, especially for small and simple projects. For large and complex projects it is rare were the team can wash their hands and have no further involvement with the product.
For many products, once a product has been delivered there is sustaining engineering where problems are discovered and solutions proposed and implemented. Revisions are issued that include a fix to the problem. If the requirements and system were modeled, then the impact of these changes can be better assessed in the tool AND the final resolution modeled in the tool to represent the current configuration. Again for small, simple systems this is not as much of an issue. For some organizations, like NASA, a spacecraft is built that will be in space for an extended period of time. In some cases this time period can be substantial (10 years or more.) Having a good model of the spacecraft is key to the operations team being able to resolve issues that frequently come up during the mission.
Another consideration is reuse of the model. There are many product lines that involve a periodic upgrade and a new release or model is put into the market. These upgrades or new models are the focus of a new project team. (Members of the old team may not be accessible for the new project.) Being able to the reuse the model of the existing system in support of the upgrade is invaluable. It will be much cheaper and require less time to get the project going. You understand the current state, the desired state for the new release of model, and do a gap analysis. What needs to be changed or what changes do you plan to make? With the existing model, you start making the changes from the top down. Because all the requirements are properly linked and the resulting design modeled, the team can easily see the ripple effects of all the changes and avoid untended consequences. The end result is being able to build on the knowledge of the previous project team and being able to develop a new release or model cheaper and in less time – increasing profits.
Comments to this blog are welcome.
If you have any other topics you would like addressed in our blog, feel free to let us know via our “Ask the Experts” page and we will do our best to provide a timely response.
