Federal Institute of Education, Science and Technology Fluminense - IFFluminense, Campos dos Goytacazes, Rio de Janeiro, Brazil.
Federal Institute of Education, Science and Technology Fluminense - IFFluminense, Campos dos Goytacazes, Rio de Janeiro, Brazil.
Federal Institute of Education, Science and Technology Fluminense - IFFluminense, Campos dos Goytacazes, Rio de Janeiro, Brazil.
Federal Institute of Education, Science and Technology Fluminense - IFFluminense, Campos dos Goytacazes, Rio de Janeiro, Brazil.
Federal Institute of Education, Science and Technology Fluminense - IFFluminense, Campos dos Goytacazes, Rio de Janeiro, Brazil.
Federal Institute of Education, Science and Technology Fluminense - IFFluminense, Campos dos Goytacazes, Rio de Janeiro, Brazil.
Highlights: The quality of requirements is of great importance for the success of a software, both in relation to its operation and the costs involved in the development process. Requirements Management is an important process of software engineering and the present work presents an approach on requirements quality with focus on the Requirements Management Process (RMP), present in the G level of the MPS.BR (Brazilian Software Process Improvement). The MPS.BR software reference model brings the results to be achieved; however, they are difficult to implement because they do not present instructions on how to reach these results. The modeling of processes, through visual models, can be used as a facilitator for the understanding and execution of these results.
Objective: This work proposes the modeling of activities and subprocesses, through the BPMN (Business Process Model and Notation), necessary to achieve each of the expected results in the RMP, where such modeling seeks to support the professionals who work in the implementation of the RMP for software development projects.
Methodology: It is divided into four steps: (i) Stage I - bibliographic review, (ii) Stage II - documental analysis of MPS.BR guides, (iii) Stage III - process modeling through the BPMN for the GRE at the MPS.BR G level, and (iv) validation of the modeling proposed through research with professionals who work in areas related to ICT (Information and Communication Technology).
Results: The sample of professionals who validated the proposed models generated results deemed satisfactory for improving the understanding of the activities necessary for implementing requirements management in software development projects.
Practical Implications: This work is mainly intended to facilitate the execution of the expected results of the RMP.
Originality: process modeling is presented as a visual means to define the activities necessary to achieve the processes proposed in standards and/or guidelines.
Keywords: Software Engineering; Requirements Management; Quality; Process Modeling; BPMN.
The Brazilian Software Process Improvement Program (SPI.BR) is responsible for elaborating reference models for process improvement involving software related issues. The program proposes three reference models of software process improvement (SPI): a model related to the software development process, a model related to human resources in the ICT (Information and Communication Technology) area, and a model related to services that supports the model related to software development.
MPS.BR is a long-term mobilizing program, created in December 2003, coordinated by the Association for the Promotion of Brazilian Software Excellence (SOFTEX), with support from the Ministry of Science, Technology and Innovation (MCTI), Financier of Studies and Projects (FINEP), Brazilian Service in Support of Micro and Small Enterprises (SEBRAE) and Inter-American Development Bank (IDB/FUMIN). The MPS.BR program aims to increase the competitiveness of organizations by improving their processes (SOFTEX, 2016b). According to Stuchi (2015), its main objective is to define models of improvement and process assessment.
The implementation of MPS.BR models has as main benefit the enhancement of product quality, from the improvement of processes, increasing the competitiveness of the company in relation to others of the same production sector (Silva, 2013).
According to SOFTEX (2016b), the reference models of the SPI are:(i) SPI-SW: it is the model for software and its objective is to meet the need to implement the principles of software engineering in accordance with the main international approaches for definition, assessment and improvement of software processes; (ii) SPI-SV: it is the model for services, which was developed to complement the SPI Software model, both to support the improvement of service processes and to offer an assessment process that attests the adherence of the organization's practices to the sector's best practices; (iii) SPI-HR: is the SPI model for people management, which aims to provide organizations with guidelines for implementing HR management practices in the ICT industry.
This work addresses the SPI.BR Reference Model for Software Processes (RM-SPI-SW), which proposes 22 processes grouped into seven maturity levels. This article focuses on the initial maturity level "G", which represents the "Partially Managed" maturity level.
According to Rocha et al. (2005), even with the use of the RM-SPI-SW model and the implementation guide, the development teams find difficulties due to the nonexistence of tools to support the understanding of SPI.BR processes.
One of the processes that presents difficulties for its correct implementation is the requirements management process, which is part of the "G" maturity level. This process addresses five results that the software development team must achieve in order to obtain maturity.
According to Aguilar et al. (2018), software requirements can be defined as customer needs, According to Aguilar et al. (2018), software requirements can be defined as the needs of customers, the services that users want the system to provide, and the constraints under which they must operate, which is a very important step for later moments such as software design, implementation and evaluation. These requirements may change due to changes in the context in which the software is inserted, new customer and user expectations, and negotiation between customers and developers (Sayão et al., 2003). It is important to highlight that they must be well documented, in order to ensure traceability and history of the decisions made by those involved in the project planning. Hussain et al. (2016) point out that failures in software projects are often costly and risky. Thus, projects that neglect requirements engineering tend to suffer from failures, challenges and other associated risks, which represent not only new high costs, but also loss of competitiveness.
According to Sayão et al. (2003), the costs of discovering defects in the testing phase of a software are five to one hundred times higher than the cost of discovering and correcting the problem in the requirements process, and 50% of the failures detected in the testing phase are caused by defects in requirements. According to Leite (2000), the process of defining software requirements is an activity that is extremely important and independent from other software engineering activities, requiring its own rationale and processes, which must be planned and managed throughout the entire life cycle.
Given this context, the present work aims to propose a modeling of activities, through BPMN (Business Process Model and Notation), necessary for the expected results of the RM-SPI-SW requirements management process to be achieved. With the proposed modeling, it seeks to improve the understanding of these activities through a visual model and increase productivity during the implementation of this process.
Besides this introduction, this article is organized in the following way: section 2 addresses the bibliographic review, dealing with subjects such as software quality and requirements management in the SPI.BR; section 3 presents the methodology used, divided in three phases: document analysis, visual modeling, and validation; section 4 presents the results of the proposed modeling, as well as the results of its validation; and section 5 presents the conclusions and future works.
In the literature review the central theme is related to the issue of quality and process management.
Quality, according to ISO/IEC 9000 (2005), refers to the degree to which a set of characteristics inherent to a product, process or system can meet the requirements initially stipulated. The issue of quality addressed in this work is directed to software quality, which is divided into product quality and process quality.
According to Bourque and Fairley (2014), software quality is an area of knowledge in software engineering that can refer to "the desired features of software products, the extent to which a specific software product possesses those features, and the processes, tools and techniques that are used to ensure those features. Thus, it aims to ensure software quality through the definition and standardization of development processes".
According to Kalinowski et al. (2010), the constant improvement of the development capacity is something essential for software companies to prosper in competitive markets. Over the years, this has led to the emergence of reference models to guide the improvement of software engineering process capability. An example of these models is the SPI.BR.
RM-SPI-SW has seven maturity levels, which are sequential and cumulative, based on CMMI (Capability Maturity Model Integration). Each one of these levels is composed of a set of processes, which are at a given capacity level. The maturity levels establish process evolution levels, which characterize process implementation improvement stages in a given organization. These levels, in increasing order of maturity, are: G (partially managed), F (managed), E (partially defined), D (broadly defined), C (defined), B (quantitatively managed) and A (in optimization) (SOFTEX, 2016b).
In this work, greater emphasis is given to the G level, which encompasses the requirements management process. As shown in Table 1 (SPI.BR levels and their processes), the requirements management process corresponds to the G level of the SPI.BR. Its purpose is to manage the requirements of the product and components of the project's product, identify inconsistencies between the requirements, the project's plans and the project's work products (SOFTEX, 2016b).
According to Brezezinski and Gomes (2014), the objective of the requirements management process is to control the evolution of the product, manage all the requirements received or generated by the project (functional and non-functional) and document the product requirements and their changes, a process that can be supported by traceability. According to Gonçalves et al. (2004), a requirements document is traceable if each one of its demands (requirements) is clear and facilitates the identification of the same demand in future stages of development or documentation.
Chart 1. SPI.Br levels and their processes
Source: Adapted from Softex (2016b)
According to the SPI Software General Guide (SOFTEX 2016b), the expected results for the Requirements Management (RQM) process are:
• RQM 1. The understanding of the requirements is obtained from the suppliers of requirements;
• RQM 2. The requirements are evaluated based on objective criteria and a commitment of the technical team to these requirements is obtained;
• RQM 3. Two-way traceability between requirements and work products is established and maintained;
• RQM 4. Reviews on project plans and work products are performed in order to identify and correct inconsistencies with the requirements;
• RQM 5. Changes in requirements are managed throughout the project.
The software process can be defined as the way in which an organization develops its products and support services, defining which steps should be followed in each phase of production, and supporting the elaboration of estimates, development plan, and quality measurement, and the process should begin with the expected results, designing these steps to achieve the results (Lepmetz et al., 2012).
To define the software processes, some elements must be considered: the characteristics of the organization, the needs of the project, the techniques and methods to be used in software development, the adherence to standards and reference models, and the restrictions of time and resources.
According to Mendoza e Silveira (2017), According to Mendoza and Silveira (2017), the use of business process models can contribute to the specification of software requirements, something that facilitates communication and understanding of the business among the parties involved, such as software managers and designers. According to Esteves et al. (2015), the human being has a greater capacity to capture information through visual sense and, thus, a universal communication can be achieved, allowing people outside the process to also understand the information.
According to Stuchi (2015), the BPM (Business Process Model) approach could add a lot of value to the software development area. Therefore, the use of BPMN was defined for the modeling of the processes of this work. The graphical notations used in business process modeling facilitate their understanding, highlighting certain concepts, activities and relationships, and provide conditions for collaborative management. Besides BPMN, other notations can be used for business process modeling, such as: EPC (Event-Driven Process Chain), UML (Unified Modeling Language), flow chart, among others.
Oliveira et al. (2010) point out that although the SPI.BR describes a model of gradual improvement of software processes, it does not establish how to implement them. Thus, the authors present a suite of free software tools to support the implementation of SPI.BR processes, called SPIDER - Tool Suite for Quality. This project presents a survey of free software tools with adequate characteristics to enable the creation of products of works derived from the expected results described in the process objectives of maturity levels G, F and E of the SPI.BR model, which are initial levels and of great complexity. The project also seeks to present viable alternatives regarding software tools to help the implementation of the SPI.BR model in organizations, without the need of acquiring proprietary software. In addition, the tool can be customized to meet the specificities of the organization, reducing costs and time along the implementation of this maturity program.
Yoshidome et al. (2012) present a proposal of tooling support for the implementation of the Requirements Development process, present in CMMI and SPI.BR programs, through the exclusive use of free software tools. It is worth mentioning that the research is focused on the Requirements Development process, not covering the RQM process. The authors emphasize that the characteristics related to the Requirements Development process are managed in a better way when the process is systematized using tools, which tends to reduce time and effort. In this way, it was elaborated a flow of activities using BPMN, where in each activity, the name of the tool necessary to perform it is included. According to the authors, the proposed set of free tools is capable of fully implementing the expected results of the RM-SPI Requirements Development process and the specific practices of this area in CMMI-DEV, provided it is used in a planned manner, following the methodology presented by the authors.
Cardias Junior et al. (2010) state that the characteristics related to the RQM process of the SPI.BR model can be better managed when the process is automated through the use of tools, reducing time and effort. For this, a methodology using free software tools is presented. According to the authors, when these tools are used together, it is possible to meet the implementation of the RQM process of the SPI.BR model, thus obtaining the expected results of this process. It is important to emphasize that the methodology proposed by the authors seeks to add facilities in the execution of the process from the use of organizational assets through free software tools, without proposing the definition and institutionalization of an organizational process of RQM, nor replacing it. The authors point out that the analysis of the tools presented is a proposal for implementing the RQM process, and each organization can adapt it according to their needs. It is also highlighted that the set of tools used was analyzed in an isolated and non-integrated manner, and there may be unfeasibility in applying the methodology in projects involving the allocation of human resources on a large scale.
METHODOLOGY
The methodology used was divided into four steps, as shown in Figure 1.
Figure 1. Work Methodology
Source: The authors
The following is a description of each step that makes up the methodology represented by Figure 1:
• Stage I - bibliographic review: is described in section 2 of this paper;
• Stage II - documental analysis: elaborated through the use of the general SPI software guide (SOFTEX, 2016b), with the objective of identifying the purpose and the expected results for the G level of the SPI.BR. However, despite pointing out these results, this guide does not present information on how an organization can achieve them. Thus, the Implementation Guide - Part 1: Justification for G-Level Implementation of RM-SPI-SW (SOFTEX, 2016a) was also used, which presents more details for implementing the model. Besides these guides, the works of Sayão and Leite (2005) and Stuchi (2015) were also used;
• Stage III - process modeling: it aims to facilitate the understanding and implementation of the expected results for the RQM level process of the SPI.BR, through the elaboration of process modeling using BPMN. After the analysis of the information contained in the referred Implementation Guide - Part I (SOFTEX, 2016a), it was identified that the use of complementary material would make the modeling more understandable and the information to be used in this modeling was identified in the guide. This information was divided in order to allow the identification of each one of them as an activity or a subprocess (set of activities). This procedure took place for the elaboration of the modeling regarding the expected results RQM 1, RQM 2 and RQM 5. The modeling of the RQM 3 result was based on the work of Sayão and Leite (2005), while the modeling of the RQM 4 result was based on the work of Stuchi (2015). The modeling for all the expected results was done using BPMN through the Bizagi (2018) software;
• Stage IV - validation: in order to verify whether the models elaborated are easy to assimilate and whether their use, both in academic and professional environments, would facilitate the understanding and implementation of the expected results, two surveys were carried out through specific questionnaires applied to a sample of professionals working in ICT-related areas. The first survey aims to verify, through the first questionnaire, the profile of the professionals that make up the sample, where information was requested regarding professional experience (profession, time in the profession, and training) and previous knowledge regarding process modeling, BPMN and SPI.BR, and in relation to the latter, a survey on certification, use of guides, and time of use was conducted. The second survey is related to the professionals who participated in the first survey and who have previous knowledge in the topics covered. The questionnaire applied in the second research aims to evaluate the models proposed as related to the following questions: understanding of the information presented, degree of difficulty in locating the information to define the tasks, degree of difficulty found to define the tasks and creation of the documents in SPI.BR, degree of difficulty found to define the tasks and creation of the documents in the elaborated models, degree of facilitation of the understanding of the information presented in the SPI.BR guides and how they are related. Such issues were analyzed according to the following scale: difficult, moderately difficult, normal, moderately easy, and easy. In addition to the questions listed above, the questionnaire also provides the identification of positive points (ease in locating the desired information, speed in locating the information, simple language, detailed information, and the possibility of viewing the flow of information in the process) and negative points (difficulties in understanding the modeling used and problems with the terms used) in the proposed models. The respondents were given the option of not identifying any positive and/or negative points, as well as identifying positive and negative points different from those mentioned above. And to finish the questionnaire, it was verified whether the respondent would use the proposed models to facilitate their work regarding the use of the SPI.BR Guides.
The models and their validation are presented in this section.
Modeling of the expected results of the G-level Requirements Management process of the SPI.BR.
The first model (Figure 2) represents a general view of the G-level RQM process of the SPI.BR, while the other modelings represent the processes necessary to obtain each of the expected RQM results.
In Figure 2, we can see that each sub-process represents an expected result of the RQM, except for the first sub-process which represents two expected results, thus showing a visual modeling of the process as a whole. Each subprocess of Figure 2 will be described through a detailed modeling of the activities to achieve each result represented.
Figure 2. Modeling the expected results of RQM: an overview
Source: The authors
Figure 3 represents the RQM 1 modeling. The understanding of the requirements is obtained from the requirements providers. The flow of activities proposed to obtain the result of RQM 1 can be described as follows: the technical team collects information about the requirements suppliers; defines techniques for elicitation of requirements; performs two activities in parallel, a meeting with requirements suppliers and document analysis; holds a meeting to record the information; verifies if all the requirements were understood, documenting the requirements, assessing their technical quality, and holding another meeting with suppliers, if positive; checks if the requirements meet the needs, registering the acceptance of the requirements and finalizing the process, if positive; return to define requirements elicitation techniques and follow the flow, if negative; and return to define requirements elicitation techniques and follow the flow, if negative.
To better understand the other figures, it is necessary to analyze them with the same form of description used for Figure 3. Thus, Figure 4 represents the modeling of RQM 2, Figure 5 represents the modeling of RQM 3, Figure 6 represents the modeling of RQM 4, and Figure 7 represents the modeling of RQM 5.
Figure 3. Modeling RQM 1.
Source: The authors
Figure 4. Modeling RQM 2.
Source: The authors
Figure 5. Modeling RQM 3.
Source: The authors
Figure 6. Modeling RQM 4.
Source: The authors
Figure 7. Modeling RQM 5.
Source: The authors
In the first survey, the questionnaire designed to identify the respondents' profile was sent to a random sample of 32 professionals working in the ICT area, and from this sample, 75% return was obtained.
Regarding the respondents' profile, 100% stated that they know process modeling; 83.30% know the BPMN; 83.30% know the SPI.BR, but only 16.70% use it at work. None of the respondents has an SPI.BR certificate. In relation to the profession, 100% are university professors, and of these, 60% have worked as consultants in the area of processes and/or quality. The majority of the sample has more than ten years of experience, 40% are PhDs and 60% are masters in areas related to ICT. The second survey occurred with 80% of the sample that returned the information about the profile, because only those who had knowledge in process modeling, BPMN and MPS.BR were selected.
Figure 8 presents the main questions regarding the assessment of the models and the results found.
Figure 8. Result of the evaluation of the proposed models
Source: The authors
From Figure 8 it can be observed that, in relation to the sample used in the research, the "understanding of the information presented" and the "difficulty in locating the information to define the tasks" were considered easy by the majority; the "definition of the tasks and creation of the documents in the SPI.BR" was considered easy to moderately difficult; the "definition of the tasks and creation of the documents in the elaborated models" was considered easy to moderately easy; and the question of the models proposed to reach the objective of facilitating the understanding of the information presented in the SPI.BR guides and the relationship among them was considered easy to moderately easy. Figure 9 presents the positive points indicated by the sample.
Figure 9. Positive points indicated by the sample
Source: The authors
In Figure 9, it can be observed that the most positive points indicated by the sample in relation to the proposed models were the "simple language" and the "possibility of viewing the flow of information in the process". Some respondents suggested the "visual understanding of the entire process" as another positive point of the proposed models.
For 83% of the sample, the negative points in relation to the proposed models were not identified, and for 17% of the sample, the proposed models present as a negative point the need to know the BPMN to understand the model.
Thus, observing the results obtained through the application of the questionnaires, it can be seen that the models elaborated have achieved their objective, since most of the questions concerning them were evaluated as "easy" or "moderately easy".
An important point to highlight is that 100% of the respondents informed that they would use the proposed models to facilitate the work of using the SPI.BR guides.
Through this work the modeling of the processes was elaborated, with the objective of facilitating the understanding and the implementation of the necessary activities to obtain the expected results of the RQM process of the SPI.BR level. Six models were elaborated, the first one representing an overview of the RQM level of the SPI.BR, which is detailed through the other models, where each model represents an expected result of this process.
Considering the answers obtained in the validation, it can be concluded that the main contribution of this work lies in the proposed use of visual models, such as process modeling through the BPMN used, which can help understanding the activities necessary for each expected result to be obtained. Thus, the modeling elaborated can be used as a kind of script to be followed, not only indicating what the objectives are, but mainly, identifying which activities are necessary in the path to be followed in order to achieve the results.
A limiting factor of this work refers to the sample size, which is considered small. Therefore, for future works a new validation with a more significant sample size is suggested in order to obtain more expressive results.
Moreover, for future works, it is suggested the expansion of the methodology proposed for the other processes of all levels of the SPI.BR in the reference model for software. This way, it would be possible to demonstrate through a visual model the activities and sub-processes necessary for the expected results and all the processes, making easier the understanding and implementation of the RM-SPI-SW.
Aguilar, J.A. et al. 2018. A Survey About the Impact of Requirements Engineering Practice in Small-Sized Software Factories in Sinaloa, Mexico. In: Gervasi, O. et al. (Orgs.). Computational Science and Its Applications 10963, 331-340. https://doi.org/10.1007/978-3-319-95171-3_26
Bizagi. 2018. https://www.bizagi.com/pt/produtos/bpm-suite/modeler
Bourque, P.; Fairley, D. 2014. SWEBOK 3.0 Guide to the Software Engineering Body of Knowledge. [S.l.]: IEEE Computer.
Brezezinski, T., Gomes, M.C. 2014. Uma abordagem para a criação da especificação de requisito e caso de teste no modelo MPS.BR nível G. Tecnologias em Projeção 5, 2:26–40.
Cardias Junior, A.B. et al. 2010. Uma Análise Avaliativa de Ferramentas de Software Livre no Contexto da Implementação do Processo de Gerência de Requisitos do MPS.BR. WER.
Esteves, R.R. et al. 2015. Aplicação da Gestão Visual como Ferramenta de Auxílio para o Gerenciamento de Projetos de Arquitetura e Engenharia em uma Universidade Pública. Revista de Gestão e Projetos 3, 3:71–83. https://doi.org/10.5585/gep.v6i3.367
Gonçalves, A. et al. 2004. IEEE Std 830 - Prática recomendada para especificações de exigências de software, abril, 42.
Hussain, A. et al. 2016. The Role of Requirements in the Success or Failure of Software Projects. International Review of Management and Marketing, 6, 7S:306-311. https://econjournals.com/index.php/irmm/article/view/3272/pdf
ISO/IEC. The International Organization for Standardization and the International Electrotechnical Commission. 2005. ISO 9000: Quality management systems – Fundamentals and vocabulary, Geneve: ISO (https://prezi.com/zvpaoydvj6vx/norma-isoiec-25000-square/).
Kalinowski, M. et al. 2010. MPS.BR: Promovendo a Adoção de Boas Práticas de Engenharia de Software pela Indústria Brasileira. https://www.softex.br/wp-content/uploads/2015/09/CIBSE2010_MPSBR_CameraReady1.pdf
Leite, J.C. 2000. Análise e especificação de requisitos. Notas de aula.
Lepmetz, M. et al. 2012. Goal alignment in process improvement. The Journal of Systems and Software 85, 6. https://doi.org/10.1016/j.jss.2012.01.038
Mendoza, V.Y., Silveira, D.S. 2017. Verificando a compreensão do BPMN com gestores de negócio. Revista Brasileira de Computação Aplicada 9, 4:60-75. https://doi.org/10.5335/rbca.v9i4.7076.
Oliveira, S. et al. 2010. SPIDER – Um Suite de Ferramentas de Software Livre de Apoio à Implementação do Modelo MPS.BR. https://www.enacomp.com.br/2010/anais/artigos/resumidos/enacomp2010_43.pdf
Rocha, A.R. et al. 2005. Dificuldades e Fatores de Sucesso na Implementação de Processos de Software Utilizando o MR_MPS e o CMMI. https://www2.unifap.br/furtado/files/2017/04/007.pdf
Sayão, M. et al. 2003. Qualidade em Requisitos. Monografias em Ciências da Computação, n° 47/03. Rio de Janeiro: PUC. file:///C:/Users/carin/Downloads/03_47_sayao.pdf
Sayão, M.; Leite, J.C.S.P. 2005. Rastreabilidade de Requisitos. Monografias em Ciências da Computação, n° 20/05. Rio de Janeiro: PUC. http://www.dbd.puc-rio.br/depto_informatica/05_20_sayao.pdf
Silva, D. 2013. O que é o MPS-Br? http://www.blogdaqualidade.com.br/o-que-e-o-mps-br/
SOFTEX. 2016a. Guia de Implementação – Parte 1: Fundamentação para Implementação do Nível G do MR-MPS-SW:2016. https://www.softex.br/wp-content/uploads/2016/04/MPS.BR_Guia_de_Implementacao_Parte_1_2016.pdf
SOFTEX. 2016b. Guia Geral do MPS de Software. https://www.softex.br/wp-content/uploads/2013/07/MPS.BR_Guia_Geral_Software_2016.pdf
Stuchi, R. B. 2015. Mapeamento de ontologias empresariais para modelos de processos de negócio em BPMN, com aplicação em processos de software. Dissertação, Universidade Estadual Paulista - UNESP, São José do Rio Preto, SP.
Yoshidome, E. et al. 2012. Um apoio Sistematizado à Implementação do Processo de Desenvolvimento de Requisitos do MPS.BR e CMMI a partir do Uso de Ferramentas de Software Livre. http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER12/paper_9.pdf
Received: 15 May 2020
Approved: 02 Nov 2020
DOI: 10.20985/1980-5160.2020.v15n3.1637
How to cite: Silva, S.V.; Barreto, D.L.; Matos, M.R. et al. (2020). Process modeling proposal to support the implementation of the MPS.BR requirements management process. Revista S&G 15, 3, 263-276. https://revistasg.emnuvens.com.br/sg/article/view/1637