Introduction
For successful system development, it is important to handle “constraints” well. While “constraints” are something that must be taken into account when building a system, they often cause cognitive discrepancies and sometimes cause major rework. The authors have also faced various restrictions in the development of microsatellite and WEB systems.
In this series, we will explain three times why it is necessary to deal with “constraints” in system development, what is difficult, and how to handle it well.
What is a “constraint”?
The system must meet various requirements. Among these, there are not only demands that are directly linked to the provision of value to customers and users = so-called needs but also demands that come from various “constraints”. Whereas the source of a need is clear (although it’s difficult to capture), “constraints” can’t even be noticed without knowing the source in the first place. If you proceed with development without noticing it, it may lead to unexpected rework or cause a serious accident.
The treatment of “constraints” is also a hot topic in the world of “requirements engineering”.
For example, suppose that a company that has the technology to measure the temperature of an object by thermography in the industrial field will use this technology to enter the medical field. Is it easy to understand that we are trying to develop a thermometer that can measure body temperature in a non-contact manner within 1 second in response to the need to “reduce the trouble of measuring body temperature”? Since there are technologies and products (radiative thermometers) that measure the temperature of things in a non-contact manner, it seems that it is not so difficult to make a thermometer if you start from your needs. However, here comes the pitfall of “constraints”. Since the thermometer is a medical device, it is necessary to comply with the Pharmaceutical Machinery Law, and it is necessary to obtain approval for various items such as whether it does harm to humans. Devices that utilize similar technologies can meet the needs, but because the “constraints” are different, the requirements that the system must meet will be different. If you proceed with development without noticing such “restrictions”, you will not be able to obtain certification due to a lack of data to be acquired, you will not be able to put it on the market, or you will miss a business opportunity because the launch time is delayed. It leads to such a situation.
By the way, what is the reason for distinguishing between “needs” and “constraints”? From the point of view of “Is the system made correctly?”, It is sufficient that the system requirements are satisfied, and there is no difference between the system requirements derived from the needs of customers and users and the system requirements derived from constraints.
On the other hand, from the perspective of “Is the correct system created?”, It is important to keep thinking “Why do such requests exist?” And “Are there any requests that are overlooked?” Needs and constraints differ in how they are found, how they are incorporated into system requirements, and how they are validated. Therefore, I think it is better to treat the two separately.
“How to handle constraints”
Ultimately, both needs and constraints fall into the baseline system requirements, but the handling and identification methods will change.
The key to functional requirements that come from needs is to be aware of the hierarchy of requirements and how to draw out the needs of layers with a high degree of abstraction. If you are interested, please take a look as it was dealt with in the previous seminar.
On the other hand, in this article, I would like to introduce what kind of approach should be taken by focusing on “constraints”.
The key is to find and control the “recognition gap” = “division”. As the system becomes more complex, it involves many people with different experiences, knowledge, and interests. Different perspectives can work for the better, but in many cases they are inconsistent and “divided”, leading to project delays and failures.
In particular, constraints are prone to this division, and it is necessary to discover and control the division at the following three points.
- Division of perception of constraints
- Division about what it should be
- Division of forest perspective and tree perspective
In this article, let’s focus on the “division of perception of what the constraints are.”
Restrictions on a small satellite development
One of the authors was involved in the development of three artificial satellites (OPUSAT, OPUSAT-KIT, and HIROGARI) while working as a faculty member at Osaka Metropolitan University. Two of them have already taken off into space.
The needs for small satellites are for scientific and engineering missions. For example, HIROGARI was a satellite for a demonstration experiment in outer space of a deployed structure that utilizes a new method called plate Miura folding and a system that measures the shape of the structure in orbit. Understanding the needs and thinking about what functions and performances are required to achieve the mission is no different from general system development, but it must also meet various restrictions peculiar to small satellites.
Division of perception of constraints
As a premise to talk about constraints, we must explain how small satellites go into space. Since we are developing satellites as a university, we do not have the budget to procure rockets and send them into space. Therefore, it can be carried on a rocket by carpooling with another satellite developed for tens of billions of yen, or it can be carried on a transport mechanism to a space station (also a development cost of several trillion yen). I get it and get it released. So, of course, we can’t damage other systems or astronauts, and we also ask the carpoolers to properly verify them.
That’s why we have to somehow meet the heavy constraint that “HIROGARI is safe enough and does not damage other systems or astronauts.”
This leaves room for a great deal of disparity in perceptions of constraints.
What is “safe”?
If you try to reduce this constraint to words that the system should satisfy, you can see that various interpretations are likely to occur.
In fact, it was very difficult for stakeholders to have different perceptions of this safety constraint.
For example, even if erroneous radiation of radio waves or an erroneous deployment of an antenna occurs in a system on the ground, I think that it is a malfunction that causes only minor injuries. However, such malfunctions in rockets and space stations can cause quite serious problems, and NASA has imposed various requirements on system design.
NASA believes that the restrictions of “preventing erroneous radio wave radiation” and “preventing erroneous antenna deployment” are extremely important for safety, and “the artificial satellite system has two failures. I hope that the system requirement of “maintaining soundness if any” (triple redundancy) will be derived. On the other hand, students who have no experience in satellite development do not think that it is such an important constraint, and if they work properly in the test, they do not need to take measures to prevent mis-radiation and mis-deployment. Due to the division of recognition for the restrictions of “preventing erroneous radiation of radio waves” and “preventing erroneous deployment of antennas”, the system requirements that are subsequently derived will differ. Ultimately, this requirement is a software function requirement (such as “to ensure a waiting time of 300 seconds or more before issuing an antenna deployment instruction after emission”) and a requirement for printed circuit board wiring (“battery line”). If you move to the detailed design with the recognition gap here, it will lead to a big rework later. Surprisingly, it is often the case that the design proceeds with an arbitrary interpretation without understanding the “constraints” at the upper level, and in the development of HIROGARI, it was decided to remake it many times.
Make the team aware of the constraints
In the case of university satellites, the main development is students. For example, in the case of HIROGARI, a total of more than 40 university students have spent several years developing satellites, and there will be a change in people. Even if hundreds of constraints are dropped like a waterfall, it is not understandable, and it is inevitable that the recognition of constraints will be divided as it is. When that happens, the results are clear, they can’t pass NASA’s review, and they can’t send satellites into space.
The division cannot be resolved simply by listing the restrictions in the document, so what should I do? We adopted a system model. Using a method called GSN (Goal Structuring Notation), we decomposed constraints and how to satisfy them on the tree so that stakeholders and students can understand each other without conflict. Specifically, with the top goal of “guaranteeing the safety of artificial satellites”, we will break it down into sub-goals from the perspective of “what kind of accident should be minimized”, and “to minimize the risk”. What kind of design should the system be and how to verify it? ”Is organized on the tree. NASA’s review was also possible thanks to the fact that we were able to align the “awareness of constraints” by matching the design intent using this model, along with specific design information such as system requirements specifications and drawings. I think I was able to pass.
It is difficult to align the recognition of constraints
The task of finding constraints is often personal, so finding all the important constraints depends on the experience and skills of the person doing the task. Furthermore, even if someone finds a constraint, it is also difficult to align their awareness of the constraint, and in the latter half of development, a discrepancy in recognition is discovered and it often happens at the development site.
Various methods for finding constraints have been proposed for each domain, such as hazard analysis and non-functional requirements grades. On the other hand, there may be few commentary articles on how to match the perception of constraints.
The method Levi proposes to align awareness is model-based communication. In artificial satellite development, constraints are managed using stylized documents such as hazard reports, but it is not the case that developers can understand constraints correctly if they have documents. Also, even if you set up a place called a meeting about restrictions and discuss it using a whiteboard etc., it will be a feeling that you understand on the spot, but when you try to drop it in the design, your hands stop. It can be chilly or difficult to share with people who weren’t there.
We believe that it is important for system development to have a reasonably well-formulated and cognitive space. The method for that is communication using a model, which was introduced in the example of satellite development.
MBSE (Model-based Systems Engineering) is a well-known method for advancing system design using models, but MBSE experts are required to produce results. On the other hand, at Levi, we believe that we can benefit from modeling if we can decompose and communicate with appropriate viewpoints without an expert, and we summarize that idea in a framework called “systemization”. ..
Handling constraints in software development
Even in software development, recognition discrepancies in constraints are likely to occur, and the same goes for later problems.
In many cases, the most difficult thing is to reach out to your customers. In agile software development, I think that development is often carried out step by step while verifying whether it can meet user needs. On the other hand, there are some things that need to be considered first in order to determine the constraints and system limits that come from non-functional requirements such as security and performance.
Suppose there is no common understanding of non-functional requirements between customers/vendors. In that case, there are risks in system operation such as “operation in unexpected or extreme conditions” and projects such as “change of system infrastructure and discovery of problems in downstream processes”. The risk is high.
In order to eliminate the division of awareness about constraints related to non-functional requirements such as availability and performance, it is important to match the awareness of the social impact of the system and how it is used with customers. For that purpose, it is effective to express the context and business flow as a model while interacting with the customer and grasping the ideal state of the system. For details on how to draw these models, please see Levi’s website.
In conclusion
“Restrictions” often lead to cognitive discrepancies and can sometimes cause major rework. That is why it is important to handle “constraints” well in order to succeed in system development. This time, I explained “the division of perception about what kind of restrictions there are” with the experience of the author. It is reasonably well-formulated, and by providing a place for cognition, this division can be resolved. At Levi, we are developing and providing a platform “Balus” for communicating using models by summarizing these ideas into a framework called “systemization”.
In the 2nd and 3rd sessions, we will deal with “division of the ideal form” and “division of the viewpoint of the forest and the viewpoint of the tree”, respectively.
If you ever want to know about similar things, check out the Facebook page Maga Techs
