## 3 The Framework
### Activities  
The main activities of the proposed framework are shown in Figure 4. The process starts when the integrator makes and handles the requirements specification of the application to the developer usually with explicit or implicit objectives. In this document, the regulations/standards/policies to be taken into account are also commonly included. After a quick inspection, if the developer finds the need for any information not available in order to start the requirement analysis, a request for information must be made. Otherwise, the next activity is to analyze the application requirements. Generally, in this first stage, ambiguities are found, these must be avoided and well defined with the approval of both parts. For instance, \"the motor must be highly efficient\". This statement is not quantifiable; therefore, a measurable quantity should be assigned either by a standard nomenclature (E2, E3, E4) or a restriction (>80%). The activity, analyze the application requirements, is composed of the different actions that are shown in Figure 5. First, the developer should verify all the requirements and objectives from the integrator are within the application context in order to state the changes or to avoid additional work. Once this is done the requirements must be classified into the different generalized non-functional groups that are described in Section 3.2. Figure 4: Main activity diagram of the framework. The next activity is to verify the technical viability of the requirements that contain the actions shown in Figure 6. To verify the technical viability of the requirements is necessary to derive requirements into the different disciplines involved in the project, these disciplines were described in Section 3.2. The analysis to derive requirements into the different disciplines is application dependent. This process may involve meetings, measurements on-site, testing, simulations, and all the activities that lead to obtaining the operating characteristics of the driven load. An example is presented in the use case example in Section 4. When the requirements are defined, their technical viability and cost feasibility must be verified. Once this is done, the result is a set of revised and verified requirements. Resuming the activities of Figure 5, the requirement identification considering its approval, rejection, or modification takes place. The requirements must have an attribute that states one of the aforementioned options. The next step in the main activity diagram (Figure 4) is to handle the requirements that are of interest to the integrator to approve, reject, or modify them. In addition, the motor type must  
Figure 5: Analyze the application requirements activity. Figure 6: Verify technical viability activity. be selected if it is not explicitly defined in the initial document. This is done by comparing costs and technical criteria among the different motor technologies considering the one that best fits the application system. Examples can be found in [16; 17]. The integrator must validate the requirements and motor type. This activity is illustrated in Figure 7. Definite or revised requirements are the output of this activity. Revised requirements must be transferred to the developer to be approved, rejected, or changed. This is a cycle that must end when both parts agree with the requirements (definite requirements) and when both parts consider the project is well-defined in order to start the design phase. Once the definite requirements are available, it is good practice for the integrator to redo the requirements specification from his perspective. The next step is to create a detailed requirements specification for the motor development. It is here where the derivation of requirements to the specific-domains that are mentioned in Section 3.2 take place. This derivation of requirements is done from the different disciplines to each specific-domain.