# Requirements Analysis in Disruptive Engineering Solutions Using the Paradigm of Living Systems
## 3 Methodology
### Roadmap for Method Application  
As the method proposed in this paper associates the system that is going to be designed with a living system, it is possible to break down the system in any way, and to tackle each module of the set generated by the breakdown process as a whole system. In a living system every module (note: interfaces are also modules), from the cell to the whole body, is both consistent and complete. Moreover, this association visualizes a requirement as a useful, complete, and consistent unit of the system. A living system does not embed useless units, and without external harmful actions, its body is, by nature, consistent and complete. Thus, any requirement is an organic building block of an appropriate element from the system. Step 1: The first step of the roadmap is to declare the scope of the problem, or in other words, the part of the system you intend to focus on. We suggest basing the scope on the vision that describes the module for which you are going to define requirements. Vision is a visual description of the module, both internal and in relation to the external environment. Vision has the quality of indicating what generic units are included in the analyzed module and how they are interlinked. This leads to the creation of a starting map of units, links, constraints, and conflicts. By tackling each component from the angle of a living system, we can build up the list of requirements and even identify along the road missing units, links, constraints, or conflicts. The scope of the investigating space also reveals the stakeholders (note: from a practical point of view, the relevant stakeholders), the needs, goals, and objectives associated with the analyzed module of the system. Business rules define what \"100% complete\" represents for any module. Additionally, applicable design regulations and standards, as well as external issues, such as higher-level requirements, other systems, budget, schedule, or technology must be associated with the scope. They can articulate drivers and constraints, which are the key elements for visualizing the context. Step 2: The second step is to create within the scope and context the pool of scenarios, use-case, and operational concepts (all considered second-level outputs) with the involvement of representatives from all relevant stakeholders. All stages of the system's lifecycle must be considered in this respect. Both nominal and off-nominal cases must be considered. A relationship matrix between inputs (i.e., the outputs from Step 1) and second-level outputs can visualize the \"pertinent\" completeness. This is met when there is at least one strong connection along each row and along each column within the relationship matrix. Step 3: The third step is to define the interfaces between the considered module and the outside \"world\". This is a condition imposed also by the characteristics of living systems (see Table 4). Step 4: The fourth step is to apply the new method to construct the module's requirements. Because we operate with the concept of living systems in mind, there is no constraint from which to start this construction. In fact, it can be started simultaneously from different points. Using the method one can see at any moment the level of maturity in defining requirements with respect to each unit--the missing points. At this step, it is useful to consider all categories of requirements (i.e., functional requirements; performance (non-functional) requirements; operational requirements (all requirements dealing with how your system interacts with the outside world (external interfaces); x-ilities (including quality, safety, security); physical attributes of the system; and design and construction standards). In principle, following the set of subsystems and characteristics of a living system (see Tables 3 and 4), all these categories of requirements are implicitly captured.