O Design Thinking (DT) tem sido usado na Engenharia de Requisitos (ER) para auxiliar o processo de descoberta das necessidades dos usuários, ao focar em princípios de prototipação e empatia com estes. Uma vez que o Design Thinking pode ser utilizado de diferentes formas, partiu-se de artigos recentes publicados sobre o uso do DT dentro da ER para identificar as suas diferentes alternativas no processo de desenvolvimento de software e traçar categorias de uso do DT na ER. Paralelamente, há restrições em todo o projeto de software que direcionam decisões de design e existem devido a uma série de fatores: o campo de aplicação, regulamentações, escolhas de stakeholders, relações de custo/eficiência, dentre outras. Parte significativa dessas restrições são manifestadas em um projeto na forma de requisitos não-funcionais (RNF), que devem ser endereçadas em algum momento. O objetivo deste projeto é analisar como se dá a consideração de RNF dentro do DT e como isto se reflete em restrições de design, considerando o uso dos resultados do DT para a ER. Para isso, foram realizadas três estudos, a saber: (1) uma revisão sistemática de literatura para identificar possíveis problemas gerais do DT na ER, (2) uma pesquisa de opinião qualitativa com desenvolvedores de software com experiência no DT buscando evidenciar a percepção de possíveis problemas sobre RNF no DT e (3) um estudo de caso composto de entrevistas semi-estruturadas com profissionais da indústria que reportaram a respeito de projetos de software em que se utilizou o DT como abordagem de elicitação de requisitos, com o intuito de explorar problemas relacionados a RNF, como estes impactam o software final e em que momento são descobertos. No uso do DT como abordagem de elicitação de requisitos em um projeto de software, os resultados apontam problemas relacionados aos RNF: quando não estão diretamente conectados ao contexto do projeto, ao histórico do time participante do DT ou não se trata de pontos comuns de interesse ao mercado em que o software ou a empresa se inserem, RNF tendem a ser ignorados durante o DT. Esses são, entretanto, descobertos mais tarde e exigem readequações significativas de projeto para serem acomodados. Tendo em vista a correlação entre os RNF e as restrições de design impostas, esta situação aponta para a necessidade de que RNF sejam descobertos o mais cedo possível em um projeto, sob risco de se perder o potencial de inovação do DT ou que a solução inicial idealizada se mostre inviável. Este trabalho mapeou problemas identificados na literatura associados ao tema e casos práticos reportados por profissionais, compilando projetos reais de uso do DT na ER e problemas atrelados a RNF descobertos durante o DT e após este. São também apresentadas lições aprendidas por profissionais, melhores técnicas sugeridas e boas práticas para a descoberta de RNF o mais cedo possível.

Design Thinking (DT) has been used in Requirements Engineering (RE) to help with the process of discovery of user needs, by focusing on principles of prototyping and empathy with users. Since Design Thinking can be used in different formats, this work starts with recent published articles regarding the use of DT in RE to identify its different alternatives in the process of software development in order to establish use categories of DT in RE. In the meantime, there are restrictions in every software project that drive design decisions and exist due to a number of factors: the field of the application, regulations, stakeholders choices, cost-efficiency relations, among others. A significant part of these restrictions are manifested in a project in the form of non-functional requirements (NFR), which have to be addressed at some point in time. The objective of this project is to analyze how NFR are considered in DT, and how this reflects on design restrictions, considering the use of DT results for RE. For that, three researches have been conducted: (1) a systematic review of literature to identify general possible problems of DT in RE, (2) a qualitative survey with software developers who had experience in DT to search for evidence of possible NFR problems in DT, and (3) a case study composed of semi-structured interviews administered with software developers with DT experience who reported on software projects in which DT was used as a requirements elicitation approach, with the goal of investigating problems related to NFR, how these impact the final software, and at which point they are discovered. In the use of DT as an approach of requirements elicitation in a software projects, the results point out to problems related to NFR: when these are not directly connected to the context of the project, to the background of the participating DT team, or they do not concern common points of interest to the market in which the software or the company pertain to, NFR tend to be overlooked during DT. These are, however, later discovered and demand significant project adjustments in order to make room for them. Considering the correlation between NFR and the imposed design restrictions, this situation denotes the need for NFR to be discovered as early as possible in a project, under jeopardy of losing the DT innovation potential, or that the initial ideated solution be unfeasible. This work has mapped problems identified in the literature associated with the theme and practical cases reported by professionals, compiling real use projects of DT in RE and problems linked to NFR discovered during and after DT. Lessons learned by professionals, as well as suggested best practices and techniques for the early discovery of NFR are also presented.