Los requerimientos no funcionales de los sistemas software no son un todo homogéneo, hay una falta de consenso para responder preguntas tales como: ¿qué son? ¿cómo se clasifican dentro del contexto de desarrollo de software?, y ¿cómo se clasifican en el desarrollo de aplicaciones Web? Este trabajo presenta el estado de arte del concepto de Requerimientos No Funcionales dentro de la literatura existente en la Ingeniería de Requerimientos y establece como bases conceptuales que los Requerimientos No Funcionales son requerimientos de calidad y son restricciones. Sobre esta base se realiza un estudio comparativo de seis enfoques de desarrollo de aplicaciones Web. Se estudian los procesos de desarrollo que cada una de ellas utiliza para determinar los requerimientos no funcionales; las técnicas de la ingeniería de requerimientos que proponen para su elicitación, especificación, validación y gestión; y se establece en qué fase del ciclo de vida de desarrollo de software identifican y tratan a los requerimientos no funcionales. / Non-functional requirements of software systems are not a homogeneous whole; there is a lack of consensus to answer questions such as: what are they? How are classified within the context of software development? And how classify it in Web Applications developing? This text presents the state of art of the concept of non-functional requirements in the existing literature on the Requirements Engineering and establishes the conceptual foundations of non-functional requirements as quality requirements and restrictions. On this basis, we made a comparative study of six approaches of Web applications development. We studied the development processes that each approach uses to determine of non-functional requirements, the engineering techniques proposed for requirements elicitation, specification, validation and management, and established at what stage of software development life cycle they identify and address Non-functional requirements.

I alla systemutvecklingsprojekt har kravhanteringen en stor inverkan på projektets framgång. Hela 56 procent av källor till fel inom informationssystem kommer från brister i kravhanteringen. Trots att de finns många metoder för kravhantering används inte dessa i speciellt stor utsträckning och vidare pekar forskningen på flera orsaker varför de inte används. En orsak är att systemutvecklare tenderar att lägga större vikt på tekniska funktioner och begränsningar än sociala aspekter, vilket ses som en orsak till att traditionella kravanalysmetoderna misslyckas. Det ses även som allmänt känt att grunden till en lyckad systemutveckling ligger i att förstå de sociala och organisatoriska aspekterna. För att åstadkomma ett så användbart system som möjligt är det därmed viktigt att involvera användare i utvecklingsprocessen. Statistik visar dock att en stor del av användare inte får vara med och påverka arbetet alls. Studien syftar till att utforska och beskriva kravhantering i praktiken med särskilt fokus på användarinverkan. Metoden för studien har varit kvalitativ och datainsamlingen har skett med semistrukturerade intervjuer med respondenter från tre företag. Respondenterna utgjordes av fyra praktiker som arbetar med kravhantering inom systemutvecklingsprojekt och de resterande tre respondenterna är användare för dessa system. Empirianalysen redogör för studiens resultat som jämförs med teorin för att belysa intresseväckande eller viktiga kopplingar till hur praktiker anammar kravhantering i praktiken och hur användare involveras i denna process. Empirianalysen visar att praktiker mer tenderar att inspireras av kravhanteringsmetoder än att anamma dessa helt och hållet. Analysen visar även att standarder för kravhantering är bristfälliga i praktiken. Vidare visar studien att så kallade superusers har större möjlighet än andra användare att påverka kraven och att kommuniceringen av krav från utvecklare till användare kan förbättras. Det finns helt klart utvecklingspotential när det gäller att involvera fler användare för att undvika misstolkade eller uteblivna krav. / In every project within systems development, managing requirements in a proper way has a major impact on a project’s success. A total of 56 percent of sources of errors in information systems is a result of shortcomings in requirements engineering (RE). Although there are many methods for managing requirements, these methods are not used to a large extent, and furthermore research results within requirements engineering points to several reasons why they are not used. A reason is that system developers tend to focus on technical features and constraints, which is seen as a reason for the failure of traditional RE-methods. It is also widely known that the foundation of successful system development lies in understanding the social and organizational aspects. In order to provide a useful system, it is therefore important to involve users in the development process. However, there are statistics that shows that a large proportion of users are not involved within the process of requirements engineering. The study aims to explore and describe requirements engineering in practise with particular focus on user impact. The methodology for the study has been qualitative and data collection has been performed with semi structured interviews with respondents from three companies. The respondents consisted of four practitioners who work with requirements engineering in system development projects and the remaining three respondents are users of these systems. The empirical analysis presents the result of the study and is compared to the theory to highlight interesting or important links between how practitioners apply requirements engineering in practice and how users are involved in this process. The empirical analysis shows that practitioners more likely tend to be inspired by requirements engineering methods than to embrace them entirely. The analysis also shows that requirements engineering standards are inadequate in practice. Additionally, results of the study indicate that super users have greater potential to influence the requirements than other users and that the communication of requirements between system developers and users can be improved. It is clear that there are a lot of potential when it comes to involve users in order to avoid misinterpretation or missing requirements.

Orientadora: Prof.ª Dr.ª Fabiana Soares Santana / Dissertação (mestrado) - Universidade Federal do ABC, Programa de Pós-Graduação em Ciência da Computação, 2014. / As empresas produtoras de software precisam de métodos eficientes para obter resultados competitivos. Uma das principais causas dos resultados negativos em projetos de software se deve às deficiências na engenharia de requisitos de software. A especificação de requisitos inadequada ou incompleta pode levar à construção de sistemas que não estão em conformidade com as necessidades dos clientes, resultando no aumento de custos, atrasos nos cronogramas e realização de atividades desnecessárias. A fim de minimizar os problemas na especificação de requisitos, as boas práticas de engenharia de software recomendam o entendimento adequado do ambiente de tecnologia da informação (TI) e das regras de negócio. O uso de processos de negócio tem sido adotado pela maioria das organizações para mapear as suas necessidades e alinhar o conhecimento entre as equipes de negócio e de TI. BPMN (Business Process Modeling Notation, no original em inglês, ou Notação para Modelagem de Processos de Negócios) é a notação mais comumente adotada pelo mercado para a modelagem de processos de negócio, com diversas ferramentas disponíveis para o mapeamento e simulação de processos. Além da preocupação com os processos de negócio, as organizações têm adotado arquiteturas orientadas a serviços (SOA, Service Oriented Architectures, no original em inglês) com o intuito de facilitar a integração entre processos e tecnologia, resultando em soluções mais flexíveis para atender às constantes necessidades de mudanças e oportunidades de negócio. A união de BPMN e SOA permite o melhor entendimento dos sistemas através do mapeamento e modelagem dos processos de negócio, a partir dos quais é possível identificar os serviços que devem ser encapsulados dentro de um determinado ambiente tecnológico. O resultado é o aumento na produtividade, a melhoria na qualidade dos sistemas (QoS, Quality of Software, no original em inglês) e a redução de custos. Este trabalho propõe um método para modelagem de processos na engenharia de requisitos, incorporando formalmente o uso de processos de negócios na especificação dos requisitos de software. Um estudo de caso foi desenvolvido para experimentar o método proposto e mostrar a sua aplicação. Embora experimentos adicionais sejam recomendados, os resultados do estudo de caso foram promissores e mostram que a análise minuciosa dos processos de negócios na etapa de especificação de requisitos auxilia no entendimento e na identificação mais precisa dos requisitos do sistema, melhorando o potencial de sucesso na produção de software. / Producing software companies need effective methods to achieve competitive results. A major cause of adverse outcomes in software projects is due to deficiencies in the software requirements engineering. The specification of inadequate or incomplete requirements can lead to the construction of systems that are not in accordance with customer needs, resulting in increased costs, schedule delays, and development of unnecessary activities. In order to minimize the problems in the requirements specification, best practices in software engineering recommend a proper understanding of the information technology (IT) environment and of the business rules. The use of business processes has been adopted by many organizations to map their needs and to align the knowledge among business teams and IT. BPMN (Business Process Modeling Notation) is the notation most commonly adopted by the software companies for business processes modeling. Various software tools are available for processes mapping and simulation. In addition to the concern with business processes, many organizations are adopting service-oriented architectures (SOA) in order to facilitate the integration between processes and technology, resulting in more flexible solutions to meet the ever changing IT needs and the new business opportunities. The union of BPMN and SOA allows a better understanding of the systems to be developed by mapping and modeling business processes, from which it is possible to identify the services that should be encapsulated within a particular technological environment. Results include increased productivity, improved quality of software (QoS) and cost reduction. This work proposes a method for including the processes modeling as part of the requirements engineering, formally incorporating the use of business processes in the software requirements specification. A case study was developed to experiment the proposed method and to illustrate its application. Although further experiments are recommended, the results of the case study are promising and show that a thorough analysis of the business processes as part of the requirements specification phase helps in understanding and obtaining a more accurate identification of the system requirements, improving the potential for successful software production.

A especificação dos requisitos de software pressupõe que se conheçam os requisitos do sistema do que será parte. Os requisitos do sistema, por sua vez, pressupõem o conhecimento do negócio (business) onde o sistema será utilizado. Para que estes conhecimentos sejam obtidos é importante o envolvimento dos stakeholders tanto no nível de sistema quanto no nível de negócio. As literaturas sobre Engenharia de Requisitos, Engenharia de Software e Engenharia de Sistemas concordam que o envolvimento dos stakeholders é fundamental. O tratamento dispensado ao assunto, no entanto, é pequeno, dada a importância do tema. Esta dissertação, utilizando conceitos da Engenharia de Métodos Situacionais e de Design Science, apresenta o ZEP Framework, um artefato, produzido com o software EPF Composer, que permite a criação de métodos para envolver o stakeholder. Estes métodos, para serem criados, devem levar em consideração as peculiaridades da organização, dos recursos disponíveis e do projeto em si. São apresentados, ainda, alguns cenários, na área de Turismo, como exemplos da utilização do framework. / The specification of software requirements implies that the system requirements are known. The system requirement requires knowledge about the business of which the system will be a part. To obtain this knowledge it is important to engage stakeholders not only at the system level, but at the business level as well. The literature on Requirements Engineering, Software Engineering and Systems Engineering consider the involvement of stakeholders as fundamental. Despite this, the treatment of the subject is not proportional to its importance. This dissertation, using concepts from Situational Method Engineering and Design Science, presents the ZEP Framework, an artifact built with the EPF Composer software, that allows the creation of methods to engage stakeholders. These methods consider the specific situation of the organization, the resources available and the characteristics of the initiative itself. Some scenarios, in the Tourism field, are presented as examples of the utilization of the framework.

Business environments in modern organizations, especially the Universities, have suffered deep transformations in the past few years, and so become more complex, what demands more information from the managers for the decision taking processes. In this sense, it can be observed that the result of the decision can take place, mostly, in accordance to the quality of the decision process, when the ideal would be to concentrate the whole management in an only system. However, in the Universities case, this is not possible, once many if those systems are adopted by the Federal Government. Therefore, in the Businnes Intelligence tools, it was found a probable alternative to minimize the complexity of the decision taking process, once this kind of system is properly used to work in a concentrated way with several sources of information. Thus, this is the problem in this study: Which are the requirements of a business intelligence system to Universidade Federal do Pampa. The research is characterized as an only case study, the approach is qualitative and exploratory. In order to elicit the requirements, documental research techniques, legacy systems analysis, interviews with some institution’s managers and prototyping were used. The prototype was built with the HTML language, following the same pattern of GURI system, to facilitate the users’ development and adaptation. The prototype was validated by the institution’s managers, being the main method for documenting the functional requirements. / Os ambientes de negócio das organizações contemporâneas, em especial das Universidades, têm passado por profundas modificações nos últimos anos, tornando-se cada vez mais complexos, o que exige dos gestores melhores informações para o processo de tomada de decisão. Logo, observa-se que o resultado da decisão pode se dar, em grande parte, em função da qualidade do processo decisório e que o ideal seria centralizar toda a gestão em um único sistema. No entanto, no caso das Universidades, isso não é possível, pois muitos desses sistemas são adotados por determinação do Governo Federal. Encontrou-se, então, nas ferramentas de Business Intelligence uma possível alternativa para minimizar a complexidade do processo de decisão, uma vez que este tipo de sistema é justamente utilizado para trabalhar de forma centralizada com variadas fontes de informação. Assim, a problemática deste estudo é a seguinte: Quais os requisitos de um sistema de business intelligence para a Universidade Federal do Pampa? A pesquisa caracteriza-se como um estudo de caso único com abordagem qualitativa e exploratória. Para elicitação de requisitos foram utilizadas as técnicas de pesquisa documental, análise dos sistemas legados, entrevistas com gestores da instituição e prototipação. O protótipo foi construído utilizando a linguagem HTML, e seguiu o mesmo o padrão do sistema GURI, para facilitar o desenvolvimento e a adaptação dos usuários. O protótipo foi validado por gestores da instituição, sendo a principal forma de documentação dos requisitos funcionais.

A especificação dos requisitos de software pressupõe que se conheçam os requisitos do sistema do que será parte. Os requisitos do sistema, por sua vez, pressupõem o conhecimento do negócio (business) onde o sistema será utilizado. Para que estes conhecimentos sejam obtidos é importante o envolvimento dos stakeholders tanto no nível de sistema quanto no nível de negócio. As literaturas sobre Engenharia de Requisitos, Engenharia de Software e Engenharia de Sistemas concordam que o envolvimento dos stakeholders é fundamental. O tratamento dispensado ao assunto, no entanto, é pequeno, dada a importância do tema. Esta dissertação, utilizando conceitos da Engenharia de Métodos Situacionais e de Design Science, apresenta o ZEP Framework, um artefato, produzido com o software EPF Composer, que permite a criação de métodos para envolver o stakeholder. Estes métodos, para serem criados, devem levar em consideração as peculiaridades da organização, dos recursos disponíveis e do projeto em si. São apresentados, ainda, alguns cenários, na área de Turismo, como exemplos da utilização do framework. / The specification of software requirements implies that the system requirements are known. The system requirement requires knowledge about the business of which the system will be a part. To obtain this knowledge it is important to engage stakeholders not only at the system level, but at the business level as well. The literature on Requirements Engineering, Software Engineering and Systems Engineering consider the involvement of stakeholders as fundamental. Despite this, the treatment of the subject is not proportional to its importance. This dissertation, using concepts from Situational Method Engineering and Design Science, presents the ZEP Framework, an artifact built with the EPF Composer software, that allows the creation of methods to engage stakeholders. These methods consider the specific situation of the organization, the resources available and the characteristics of the initiative itself. Some scenarios, in the Tourism field, are presented as examples of the utilization of the framework.

The main aim of this thesis is to explore the industrial practices of requirements negotiation and conflict resolution within distributed software development. The motivation for this study is to get insight of the industrial practices in particular interventions (Communication tools, Models, Communication media) that used by practitioners to resolve requirements negotiation and conflicts resolution between clients and suppliers, since many researchers purposed interventions in the literature for requirements negotiation and conflicts resolution in distributed software development. Context: In Requirements Engineering, requirements negotiation and conflict resolution are crucial activities to achieve a common ground between clients and suppliers, it is considered as one of the crucial factors for delivering successful software. However, the shift from traditional collocated practices to a distributed environment offers both benefits and drawbacks which were studied earlier by researcher, but surprisingly there are few studies with insight of exploring the distributed requirements negotiations and conflict resolution practices. This research investigates the state of requirements negotiation and conflict resolution activities in distributed software development with an insight on their importance and relevance to this research area. Objectives: Overall goal of this thesis is to understand how requirements negotiations and conflict resolution are performed in distributed software development, knowing what are the available tools to perform requirements negotiation and conflict resolution, whether these existing tools are good enough to cope up with the industrial practices, knowing most widely used tools, methods and approaches, most importantly does the present research able to bridge the gap with in distributed software development? Methods: This thesis study comprises of two research methodologies. 1. Systematic mapping study (SMS)- To identify the proposed interventions in the literature to perform requirements negotiation and conflict resolution activities in Industrial Software Development within a distributed environment. 2. Industrial Survey- To identify industrial practices to perform rei quirements negotiation and conflict resolution in Industrial Software Development within a distributed environment. Results: 20 studies were identified through systematic mapping study (SMS). After analyzing the obtained studies, the list of interventions (Preparatory activities/communication tools/ Models) were gathered and analyzed. Thereupon, an industrial survey is conducted from the obtained literature, which has obtained 41 responses. Effective communication media for preparatory activities in requirements negotiations and conflict resolution are identified, validation of communication tools for effective requirements negotiations and conflict resolution is performed. Apart from the validation, this study provided list of factors that affects the requirement negotiations and conflict resolution activities in distributed software development. Conclusions: To conclude, the obtained results from this study will benefit practitioner in capturing more insight towards the requirements negotiations and conflict resolution in distributed software engineering. This study identified the preparatory activities involved for effective communication to perform requirements negotiation activities, effective tools, models and factors affecting of requirements negotiations and conflict resolution. In addition to this, validation of results obtained from the literature is carried through survey. Practitioners can be benefitted from the end results of by knowing the effective requirements negotiation and conflict resolution interventions (Communicational tools/ Models/ Communication media) for early planning in distributed software development. Researchers can extend the study by looking in to the real-time approaches followed by the practitioners to perform the both activities in the direction of future studies.

Submitted by Jean Medeiros (jeanletras@uepb.edu.br) on 2017-07-17T11:52:47Z No. of bitstreams: 1 PDF - Júlia Cibelle Freire de Queiroz Arnaud.pdf: 23071946 bytes, checksum: 1107c01b26b40906b0869fa7c2cee053 (MD5) / Approved for entry into archive by Secta BC (secta.csu.bc@uepb.edu.br) on 2017-07-20T12:23:22Z (GMT) No. of bitstreams: 1 PDF - Júlia Cibelle Freire de Queiroz Arnaud.pdf: 23071946 bytes, checksum: 1107c01b26b40906b0869fa7c2cee053 (MD5) / Made available in DSpace on 2017-07-20T12:23:22Z (GMT). No. of bitstreams: 1 PDF - Júlia Cibelle Freire de Queiroz Arnaud.pdf: 23071946 bytes, checksum: 1107c01b26b40906b0869fa7c2cee053 (MD5) Previous issue date: 2017-03-31 / The number of health information systems is increasing in quantity and complexity, and their quality is essential to improve the quality of the services delivered to the population. Normally, the development of medical device software presents requirements that normally are not addressed by the traditional software development of non-safety critical industry. In this sense, projects of health information systems start to face new challenges imposed by regulators, society and suppliers since they start to interact with medical devices, personal health devices and diagnostic solutions. Requirements engineering processes are very important for the reduction of the involved risks in the development of these systems. Most agile processes used by several companies, although following well established activities for software development, have some gaps in the requirements engineering activities, turning the way in which requirements are developed in the context for health often incomplete. Health system development should be supported by an appropriate requirements engineering process, which in addition to guiding the development process, also fits in the treatment of specific requirements that these software products need. This work proposes the definition of a requirements engineering process that enables the development and management of requirements in a traceable way, while at the same time aligning with the agile development process. The process defines activities, inputs, outputs and guidelines that, in an integrated way and guides the requirements engineering in an effective way. Finally, an experimental study is presented in the context of health information systems to evaluate the viability of the proposed process. / O número de sistemas de informação em saúde está aumentando em quantidade e complexidade, e sua qualidade é essencial para melhorar a qualidade dos serviços prestados à população. O desenvolvimento de software para dispositivo médico apresenta requisitos que normalmente não são abordados pelo desenvolvimento de software tradicional. Neste sentido, os projetos de sistemas de informação de saúde começam a enfrentar novos desafios impostos pelos reguladores, sociedade e fornecedores, uma vez que começam a interagir com os dispositivos médicos, dispositivos pessoais de saúde e soluções de diagnóstico. Os processos de engenharia de requisitos são muito importantes para a redução dos riscos envolvidos no desenvolvimento destes sistemas. Muitos dos processos ágeis utilizados por várias empresas, apesar de seguir um ciclo de atividades para o desenvolvimento do software, apresentam algumas lacunas nas atividades da engenharia de requisitos, tornando a forma com que os requisitos são desenvolvidos no contexto para saúde muitas vezes incompleta. O desenvolvimento de sistemas na área da saúde deve ser apoiado por um processo de engenharia de requisitos apropriado, que além de guiar processo de desenvolvimento, também se encaixe no tratamento de requisitos específicos que estes produtos de software necessitam. Este trabalho propõe a definição de um processo de engenharia de requisitos que possibilite o desenvolvimento e gerenciamento dos requisitos de maneira rastreável, ao mesmo tempo que se alinha ao processo de desenvolvimento ágil. O processo define atividades, entradas, saídas e diretrizes que de forma integrada, orientam a engenharia de requisitos de maneira eficaz. Finalmente é apresentado um estudo experimental no contexto de sistemas de informação em saúde para avaliar a viabilidade do processo proposto.

O início deste século foi marcado pela mudança de paradigma na economia e nos processos produtivos, migrando de uma orientação a bens materiais para uma orientação a serviço. Ao mesmo tempo, os processos de automação da manufatura e integração de sistemas estão sofrendo alteração, onde modelos clássicos orientados a produto estão sendo substituídos por modelos sustentados por sistemas de informação (eventualmente cognitivos). A tese central deste trabalho é que a abordagem orientada a serviço deve ser baseada na engenharia de sistemas, com sistemas de informação atuando como elementos integradores automatizados do processo de co-criação dos serviços. Neste trabalho são analisadas propostas de formalização e fundamentação (teórica e prática) do processo de design de sistemas de serviço que sigam esta nova tendência, resultando em elementos integradores automatizados. É apresentado um framework, chamado SoftDiss, para especificação de sistema de informação de serviço, orientado a modelos, que provê recursos para os processos de eliciação, modelagem e análise de requisitos, baseado em métodos semi-formais (UML e SOMF) e formais (SysML e Petri Nets), visando antecipar a formalização da especificação e contemplar os diversos viewpoints. O uso do SoftDiss mostra que a utilização de melhores práticas, ferramentas comerciais e métodos formais, tendo como objetivo co-criação de valor, neste caso, entre desenvolvedores humanos e os sistemas incluídos no processo de design, viabilizam antecipar a formalização e contemplar os diversos viewpoints de requisitos. O SoftDiss é aplicado a três casos com estrutura distinta: o primeiro onde a base tecnológica é um sistema Smart Grid urbano, o segundo associado a projetos desenvolvidos em laboratórios de pesquisa e desenvolvimento, e o terceiro dedicado aos serviços associados à agricultura de precisão. A diversidade de tipos de serviço deste conjunto mostra a exibilidade do SoftDiss que é associado ao conceito de serviço e não ao tipo, função ou nicho de aplicação. / The beginning of this century was marked by a paradigm shift in the modeling and design of processes, which moved from goods-dominant to a service-dominant approach. At the same time, manufacturing automation and integration are evolving, opening the possibility for classical models, oriented to products has being replaced by service models, supported by information systems (eventually cognitive). The thesis of this work is that the service oriented approach should be based on systems engineering, with information systems acting to integrate and automate service co-creation. First of all some proposals are considered to formalize and fundament (from a theoretical and practical point of view) the design process of these new service systems and how they turn in key elements for integration and automation. In the following we introduce an framework called SoftDiss for specifying information systems service, model oriented, that provides resources to the processes of elicitation, requirements analysis and modeling, based on semi-formal (SOMF and UML) and formal (SysML and Petri Nets) methods which can anticipate the formal specification, while addressing different viewpoints. The use of SoftDiss shows that using best practices, business tools and formal methods to co-create value - in this case involving human developers and machine systems included in the design process, will lead to the anticipation and a formal representation to requirements viewpoints. SoftDiss is applied to three distinct case studies: the first where the basic technology from an urban Smart Grid, the second associated with projects developed in research laboratories and development, and the third dedicated to services associated with precision agriculture. The diversity of service types shows the flexibility of SoftDiss which is associated with the concept of service and not to the kind, function or application domain.

Submitted by Franciele Moreira (francielemoreyra@gmail.com) on 2017-09-15T18:05:16Z No. of bitstreams: 2 Dissertação - Antônio Carlos de Freitas Silva - 2017.pdf: 3034588 bytes, checksum: 5c0e2f3957772c07bfd32c3d625ef453 (MD5) license_rdf: 0 bytes, checksum: d41d8cd98f00b204e9800998ecf8427e (MD5) / Approved for entry into archive by Luciana Ferreira (lucgeral@gmail.com) on 2017-09-18T11:57:55Z (GMT) No. of bitstreams: 2 Dissertação - Antônio Carlos de Freitas Silva - 2017.pdf: 3034588 bytes, checksum: 5c0e2f3957772c07bfd32c3d625ef453 (MD5) license_rdf: 0 bytes, checksum: d41d8cd98f00b204e9800998ecf8427e (MD5) / Made available in DSpace on 2017-09-18T11:57:55Z (GMT). No. of bitstreams: 2 Dissertação - Antônio Carlos de Freitas Silva - 2017.pdf: 3034588 bytes, checksum: 5c0e2f3957772c07bfd32c3d625ef453 (MD5) license_rdf: 0 bytes, checksum: d41d8cd98f00b204e9800998ecf8427e (MD5) Previous issue date: 2017-08-16 / Coordenação de Aperfeiçoamento de Pessoal de Nível Superior - CAPES / About 5% of worldwide population is deaf, and for this reason Sign Language (SL) is their natural language. The LS is not limited to communication, it is also important for learning, access to information, cultural and social interactions. A Systematic Literature Review (SR) in order to identify the papers in Software Engineering with deafs. The results of SR presents a gap in Requirements Engineering with deaf stakeholders. This work presents a approach the process for Requirements Engineering with deaf stakeholders using SL, your natural language. In development of this paper, a research group was created, containing researchers of Instituto de Informática (INF/UFG) and Faculdade de Letras (FL/UFG). This group counted with Sign Language Traders and Interpreters (TILS) and a deaf deaf teacher. The study case was a software to manage the tickets of TILS in UFG, the name is Central dos Intérpretes. / Cerca de 5% da população mundial é surda. Os surdos têm como língua natural a Língua de Sinais (LS). A LS não é limitada somente a comunicação, sendo também importante para a educação, acesso a informação, interação cultural e social. Foi realizada uma Revisão Sistemática da Literatura (RS) em busca de trabalhos de Engenharia de Software voltados para surdos. Os resultados dessa RS apresentam uma lacuna na Engenharia de Requisitos quando tratado com stakeholders surdos. Este trabalho apresenta uma abordagem para um processo de Engenharia de Requisitos com stakeholders surdos por meio da LS. Durante o desenvolvimento do trabalho um grupo de pesquisa foi formado entre pesquisadores do Instituto de Informática (INF/UFG) e Faculdade de Letras (FL/UFG). Este grupo conta com Tradutores e Intérpretes de Língua de Sinais (TILS) e uma professora surda. Com alvo foi definido um sistema para gerir as demandas dos TILS no âmbito da UFG, intitulado Central dos Intérpretes, pois era algo tangível para todos os envolvidos.