In this section, the requirements framework is presented through the Systems Modeling Language (SysML) diagrams. It is broken down into five subsections: the stakeholders, classification of requirements package, activities, qualification of requirements, and tools. This requirement engineering framework aims to provide a specialized guideline to electric motor developers. Users may adjust, add, or skip any aspect of the framework to suit their project.

The use case diagram shown in Figure 2 illustrates both actors with their implications within the context of this framework. In summary, it can be seen that the integrator defines the motor requirements from the application point of view, which includes a clear description or explanation of the application system. On the other hand, the electric motor developer must derive the integrators’ requirements into the different technical domains to develop the motor following an efficient process. This includes the process of interpreting each requirement; it may also include an engineering assessment of the application system, i.e., to model the application system to obtain its operating characteristics. Finally, both actors are involved in the approval, editions, or rejections of requirements during the entire development process.

The framework identifies two stakeholders, the integrator and the motor developer (designer/manufacturer). The integrator is the actor or actors that are interested in integrating the developed electric motor into the application for which it is designed. The integrator is considered the expert in the particular application; in other words, the integrator has a complete knowledge in the application system, but usually no expertise regarding electric motor design. The electric motor developer is the actor or actors responsible for the design/manufacturing of the motor satisfying the integrators’ requirements. The generalization of the latter actor is shown in Figure 1 . This generalization shows that the developer can be represented by several actors with expertise in the different fields that are involved in the electric motor development process. The framework is made from the electric motor developer’s perspective.

3.3. 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

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 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. For instance, in the case that the design needs to have low levels of vibrations and noise (mechanical requirements), a requirement that limits the torque ripple can be derived to the electromagnetic domain. The integrator may specify the vibration or noise level but not a torque ripple constraint (if he is not aware of the term), so this job must be carried out by the developer.

The next activity (make sizing and performance results estimations) involves checking the possibility to make an early virtual prototype with previous designs or with analytical models to give the integrator an idea of what is possible to be achieved. What this step tries to accomplish is the validation in a preliminary way (not definite) of the space constraints, costs, materials, or any other parameter of interest. However, this is not always possible more so when the project is innovative. If it can be done, the integrator can develop new requirements or prioritize objectives. If objectives are prioritized, then the developer can better define general objectives to be optimized. At the end of the process, the developer has a motor requirements design specification that allows him to start the design phase. Obviously, the requirements, during the development process may be subjected to modifications or new requirements may appear. Therefore, the appropriate step must be retaken.