Um Método para Construção de Modelos i* Utilizando Design … · 2019. 10. 26. · Orientadora:...

LAINO EDEMBERGUER DOS SANTOS

UM MÉTODO PARA CONSTRUÇÃO DE MODELOS I*UTILIZANDO DESIGN THINKING

Universidade Federal de [email protected]

www.cin.ufpe.br/ posgraduacao

RECIFE2016

Laino Edemberguer dos Santos

Um Método para Construção de Modelos i* Utilizando Design Thinking

Este trabalho foi apresentado à Pós-Graduação emCiência da Computação do Centro de Informática daUniversidade Federal de Pernambuco como requisitoparcial para obtenção do grau de Mestre em Ciênciada Computação.

ORIENTADORA: Prof.a Carla Taciana Lima Lourenço Silva Schuenemann

RECIFE2016

Catalogação na fonte

Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217

S237m Santos, Laino Edemberguer dos

Um método para construção de modelos i* utilizando design thinking / Laino Edemberguer dos Santos. – 2016.

104 f.: il., fig. Orientadora: Carla Taciana Lima Lourenço Silva Schuenemann. Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn,

Ciência da Computação, Recife, 2016. Inclui referências e apêndices.

1. Engenharia de software. 2. Engenharia de requisitos. I. Schuenemann, Carla Taciana Lima Lourenço Silva (orientadora). II. Título. 005.1 CDD (23. ed.) UFPE- MEI 2017-101

Laino Edemberguer dos Santos

Um Método para Construção de Modelos i* Utilizando DesignThinking

Dissertação de Mestrado apresentada aoPrograma de Pós-Graduação em Ciência daComputação da Universidade Federal dePernambuco, como requisito parcial para aobtenção do título de Mestre em Ciência daComputação

Aprovado em: 30/08/2016.

BANCA EXAMINADORA

_______________________________________________Prof. Dr. Jaelson Freire Brelaz de Castro

Centro de Informática / UFPE

_________________________________________________Prof. Dr. Gilberto Amado de Azevedo Cysneiros Filho

Departamento de Estatística e Informática / UFRPE

___________________________________________________Profa. Dra. Carla Taciana Lima Lourenco Silva Schuenemann

Centro de Informática / UFPE(Orientadora)

Aos meus pais,com toda a centelha de amor que há em mim.

AGRADECIMENTOS

A Deus que, com seu amor sublime, nos deu a vida.

A Universidade Federal de Pernambuco – representada pelo corpo docente, admi-nistradores e os demais servidores – que me ofertou um ambiente propício ao aprendizado,disseminação e aprimoramento da ciência.

A professora Dra. Carla Silva, que me orientou com afinco durante todo o meumestrado, como também pela confiança na minha capacidade científica.

Aos meus pais, Erivan Santos e Germania Santos, que me educaram com amor eme incentivaram, incondicionalmente, nas minhas escolhas profissionais e acadêmicas.

Aos meus avós – Amaro Santos (in memoriam), Manoel Oliveira, Maria Conceição,Sebastião Silva (in memoriam) e Maria Silva (in memoriam) – que, pelas experiênciasdeles na vida, me guiaram pelo caminho do bem.

Aos familiares pela compreensão que tiveram nos momentos em que me ausentei deencontros da família, assim como por todo incentivo que me deram para que eu seguissefirme neste propósito.

A minha esposa, Bianca Nascimento, por estar ao meu lado nos momentos difíceisdesta caminhada e por me ajudar a transformar mais este sonho em realidade.

Aos amigos, pela paciência de conversarem constantemente sobre este assunto epelas críticas sinceras acerca deste trabalho.

A todos que direta ou indiretamente contribuíram para minha formação profissionalou acadêmica.

“Para ter uma boa ideia,você antes precisa ter muitas ideias.”

(Linus Pauling)

RESUMOPode-se agregar criatividade em produtos de software para diferenciá-los no meio dasvárias soluções concorrentes presentes no mercado, para melhorar a interação entre eles e osusuários e até mesmo com o objetivo de repensar (redesenhar) as regras dos domínios aosquais estão inseridos. No entanto, os processos criativos demandam atividades específicasdiferentes daquelas exigidas pelos processos de software e produzem resultados que sãodifíceis de serem expressos e gerenciados como requisitos de software. A Engenharia deRequisitos possui métodos eficazes para buscar, representar, validar e gerenciar os objetivosque os stakeholders buscam num software demandado, como por exemplo o frameworkorientado a objetivos i*. Este trabalho dá continuidade aos esforços recentes de outrosautores em unir criatividade e i*, a fim de propiciar que os resultados dos processoscriativos possam ser transformados em modelos i* para serem usados como entrada paraas atividades da engenharia de requisitos, haja vista os resultados dos métodos criativosserem difíceis de ser especificados formalmente. É importante destacar que este é o primeirométodo proposto que busca fazer essa integração utilizando uma metodologia criativaamplamente difundida e fundamentada, o Design Thinking. Nesta abordagem, é definidoum método para a construção colaborativa entre os stakeholders de modelos i* criativos, apartir da aplicação do Design Thinking. Em outras palavras, o método proposto especificade forma lógica e interconectada, como, quando e por que executar técnicas e conceitosdo Design Thinking, a fim de se criar modelos i* que representem os aspectos criativoslevantados. A proposição deste método foi guiada pelo método científico pesquisa-ação,de modo que o arcabouço teórico, aliado às ações e interações sociais, possibilitaramfundamentar e testar formas eficazes de construir modelos i*, a partir da aplicação doDesign Thinking. Holisticamente, o método está baseado nos estágios de inspiração, ideaçãoe implementação do Design Thinking, exige uma postura de facilitador para o engenheiro derequisitos no processo criativo; define ferramentas e propicia um ambiente que possibilitama colaboração entre os stakeholders e apontam momentos propícios para fomentar opensamento criativo. Outro aspecto deveras relevante deste método é a possibilidade destakeholders não técnicos fazerem parte do processo de construção dos modelos i* criativos.Isso porque a modelagem i* é considerada complexa e requer experiência e conhecimentoconsolidado do framework. Para amenizar essa complexidade, este método propõe que aconstrução de modelos i* guiado pelo Design Thinking se dê da definição de modelos maisabstratos e flexíveis até a adaptação e o refinamento para modelos i* válidos.

Palavras-chave: Engenharia de requisitos. Criatividade. Orientação a objetivos. Designthinking. i*.

ABSTRACTYou can add creativity to software products to differentiate them among the variouscompeting solutions on the market, to improve the interaction between them and theusers and even in order to rethink (redesign) the rules of the domains to which theybelong. However, the creative processes require different specific activities other thanthose required by software processes and produce results that are difficult to express andmanage as software requirements. The Requirements Engineering has effective methods tosearch, represent, validate and manage the goals the stakeholders aims to achieve in thesoftware-to-be, as for example the i* goal oriented framework. This work continues therecent efforts of other authors to join creativity and i*, in order to enable the results ofcreative processes can be transformed into i* models to be used as input to the activitiesof Requirements Engineering, given that the results of creative methods are difficult toformally specify. It is worth to highlight that this is the first method that propose tomake this integration using a widespread and grounded creative methodology, the DesignThinking. In this approach, it is defined a method for collaborative construction of creativei* models among stakeholders through the application of the Design Thinking. In otherwords, the proposed method specifies in a interconnected and logical way, how, when andwhy to perform techniques and concepts of Design Thinking in order to create i* modelsrepresenting the discovered creative aspects. The proposition of this method was guided bythe reasearch-action scientific method, so that the theoretical framework, combined withsocial actions and interactions, enabled justifying and testing effective ways to constructi* models from the application of the Design Thinking. Holistically, the method is basedon the stages of inspiration, ideation and implementation of the Design Thinking; Itrequires a facilitator position for the requirements engineer in the creative process, definetools and provides an environment that enables collaboration among stakeholders andsuggest favorable moments to foster creative thinking. Another truly important aspect ofthis method is the possibility of non-technical stakeholders be part of the constructionprocess of creative i* models, this because i* modeling is considered complex and requiresexperience and consolidated knowledge of the framework. To alleviate this complexity,this method proposes the construction of i* models guided by the Design Thinking startsby the definition of more abstract and flexible models and after by adapting and refiningthem to valid i* models.

Keywords: Requirements engineering. Creativity. Goal-orientation. Design thinking. i*.

LISTA DE FIGURAS

Figura 1 – Notação básica do i* . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Figura 2 – Possíveis relações no modelo i* . . . . . . . . . . . . . . . . . . . . . . 28Figura 3 – Exemplo de modelo SD . . . . . . . . . . . . . . . . . . . . . . . . . . 29Figura 4 – Exemplo de modelo SR . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Figura 5 – Modelo SD/SR híbrido indicado para aprendizes . . . . . . . . . . . . . 32Figura 6 – Fluxo do processo de Design Thinking . . . . . . . . . . . . . . . . . . 38Figura 7 – Subprocessos do Creadtivity . . . . . . . . . . . . . . . . . . . . . . . . 45Figura 8 – Captura de tela do Creative Leaf . . . . . . . . . . . . . . . . . . . . . 50Figura 9 – Transformação do Diagrama de Contexto para modelo SD . . . . . . . 52Figura 10 – Transformação do Customer Journey Map para modelo SR . . . . . . . 53Figura 11 – Card para uma persona . . . . . . . . . . . . . . . . . . . . . . . . . . 66Figura 12 – Modelo da divisão do quadro de modelagem . . . . . . . . . . . . . . . 67Figura 13 – Ligações entre os elementos no quadro de modelagem . . . . . . . . . . 68Figura 14 – Legenda no quadro de modelagem . . . . . . . . . . . . . . . . . . . . . 69Figura 15 – Quadro de modelagem preenchido . . . . . . . . . . . . . . . . . . . . . 70Figura 16 – Estágios do método de construção de modelos i* criativos . . . . . . . 73Figura 17 – Quadro de modelagem usado na avaliação . . . . . . . . . . . . . . . . 78Figura 18 – Quadro de ideação usado na avaliação . . . . . . . . . . . . . . . . . . 78Figura 19 – Resultado do Brainstorm durante a avaliação . . . . . . . . . . . . . . 79Figura 20 – Card de persona preenchido . . . . . . . . . . . . . . . . . . . . . . . . 80Figura 21 – Resultado do Método 635 durante a avaliação . . . . . . . . . . . . . . 81Figura 22 – Modelo abstrato resultante da avaliação . . . . . . . . . . . . . . . . . 82Figura 23 – Modelo SD resultante do modelo abstrato . . . . . . . . . . . . . . . . 83Figura 24 – Modelo SR resultante do modelo abstrato . . . . . . . . . . . . . . . . 84

LISTA DE TABELAS

Tabela 1 – Principais atributos do Design Thinking . . . . . . . . . . . . . . . . . 35Tabela 2 – Comparação entre os estágios das definições distintas de Design Thinking 37Tabela 3 – Resumo do mapeamento das técnicas de criatividade no Creadtivity . . 46Tabela 4 – Notação completa do modelo abstrato . . . . . . . . . . . . . . . . . . 63

LISTA DE ABREVIATURAS E SIGLAS

AVAM Ambientes Virtuais de Aprendizagem Móvel

DT Design Thinking

ER Engenharia de Requisitos

ES Engenharia de Software

LER Laboratório de Engenharia de Requisitos

SD Strategic Dependency

SR Strategic Rationale

TI Tecnologia da Informação

UFPE Universidade Federal de Pernambuco

UML Unified Modeling Language

SUMÁRIO

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.1 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.2 Contribuições esperadas . . . . . . . . . . . . . . . . . . . . . . . . . . 181.3 Objetivos geral e específicos . . . . . . . . . . . . . . . . . . . . . . . 191.4 Escopo negativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.5 Metodologia de pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . 201.6 Estrutura da dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . . . . 232.1 Introdução à Engenharia de Requisitos . . . . . . . . . . . . . . . . . 232.1.1 Criatividade na Engenharia de Requisitos . . . . . . . . . . . . . . . . . . 242.2 i*: framework orientado a objetivos . . . . . . . . . . . . . . . . . . . 262.2.1 Uso do i* em ambientes criativos . . . . . . . . . . . . . . . . . . . . . . . 322.3 Design Thinking: uma metodologia criativa . . . . . . . . . . . . . . 332.3.1 Uso do Design Thinking na criação de software . . . . . . . . . . . . . . . 392.4 Considerações finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3 TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . 433.1 Uso do Design Thinking para concepção de softwares criativos . . . 433.2 Integração de Design Thinking e técnicas de criatividade na elicita-

ção de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.3 Uma ferramenta para integrar modelagem i* e técnicas criativas . . 483.4 Uso do i* para suportar a Engenharia de Requisitos criativa . . . . . 513.5 Considerações finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4 METODOLOGIA DE PESQUISA . . . . . . . . . . . . . . . . . . . 554.1 Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.1.1 Concepção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.1.2 Amostragem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.1.3 Definição do tema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.1.4 Ameaças à validade interna . . . . . . . . . . . . . . . . . . . . . . . . . . 574.1.5 Hipóteses assumidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.2 Execução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.3 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.3.1 O produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.4 Considerações finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5 O MÉTODO: DO DESIGN THINKING AOS MODELOS I* . . . . 625.1 Modelo abstrato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.1.1 Notação abstrata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.2 Papéis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645.2.1 Design Thinker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645.2.2 Engenheiro de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . 645.3 Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.3.1 Personas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.3.2 Quadro de modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.3.3 Quadro de ideação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.4 Técnicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.4.1 Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.4.2 Contação de histórias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.4.3 Técnicas criativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.5 Briefing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725.6 Estágios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725.6.1 Imersão no universo do problema . . . . . . . . . . . . . . . . . . . . . . . 735.6.2 Imersão no universo das soluções . . . . . . . . . . . . . . . . . . . . . . . 735.7 Transformação do modelo abstrato para o modelo i* . . . . . . . . . 745.8 Considerações finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6 AVALIAÇÃO DO MÉTODO . . . . . . . . . . . . . . . . . . . . . . 766.1 Ameaças à validade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766.2 Execução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776.2.1 Briefing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776.2.2 Estágios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776.2.3 Transformação do modelo abstrato . . . . . . . . . . . . . . . . . . . . . . 836.3 Considerações finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

7 CONSIDERAÇÕES FINAIS . . . . . . . . . . . . . . . . . . . . . . . 867.1 Contribuições científicas . . . . . . . . . . . . . . . . . . . . . . . . . . 877.2 Limitações do método . . . . . . . . . . . . . . . . . . . . . . . . . . . 877.3 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

APÊNDICES 94

APÊNDICE A – QUESTIONÁRIO DE AVALIAÇÃO DOMÉTODOPROPOSTO . . . . . . . . . . . . . . . . . . . . . 95

APÊNDICE B – RESUMO DAS AVALIAÇÕES DOMÉTODO PRO-POSTO . . . . . . . . . . . . . . . . . . . . . . . . 97

APÊNDICE C – CARD PARA PERSONAS . . . . . . . . . . . . . 99

APÊNDICE D – PROTÓTIPO INICIAL DO QUADRO DE MODE-LAGEM DURANTE A EXECUÇÃO DA PESQUISA-AÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . 100

ANEXOS 101

ANEXO A – PROTÓTIPO GERADO DURANTE A EXECUÇÃODA PESQUISA-AÇÃO . . . . . . . . . . . . . . . . . . 102

ANEXO B – MODELO SD GERADO DURANTE A EXECUÇÃODA PESQUISA-AÇÃO . . . . . . . . . . . . . . . . . . 103

ANEXO C – MODELO SR GERADO DURANTE A EXECUÇÃODA PESQUISA-AÇÃO . . . . . . . . . . . . . . . . . . 104

15

1 INTRODUÇÃO

Engenharia de Requisitos (ER) é a disciplina responsável por elicitar, analisar,documentar e validar os serviços e restrições de um software (SOMMERVILLE, 2011).Quando aplicada com uma perspectiva orientada a objetivos, é possível validar, sob aótica dos stakeholders, as razões pelas quais os requisitos foram elicitados. Ao evidenciaras aspirações dos stakeholders, a orientação a objetivos ajuda o engenheiro de requisitos agerenciar os conflitos de interesse existentes no projeto (LAMSWEERDE, 2001).

Segundo Horkoff e Maiden (2015b) em um estudo inicial, a sinergia entre mo-delagem orientada a objetivos e técnicas de criatividade muito tem a contribuir para odesenvolvimento de softwares, visto que daí resultarão softwares que atendem aos objetivose interesses dos vários stakeholders e que entregam inovação, na forma de valor percebidopelos usuários, advinda do pensamento criativo.

Horkoff e Maiden (2015b) apontam que essa sinergia entre modelagem orientada aobjetivos e criatividade traz à ER toda a maturidade da modelagem orientada a objetivos– a qual possibilita analisar, até mesmo com apoio de ferramentas automatizadas, acompletude, consistência e validade dos requisitos sob a ótica dos objetivos essenciais edesejados pelos stakeholders – como também agrega o potencial inovador daquelas técnicascriativas aos produtos/serviços – incrementando a competitividade e o valor deles emrelação aos produtos concorrentes.

No entanto, o estudo citado acima é necessariamente uma análise inicial, de formaque não define algum método prático e replicável para equipes de desenvolvimento desoftware na industria de Tecnologia da Informação (TI), limitando-se a trabalhar comconceitos abstratos de criatividade. Portanto, não faz qualquer integração com umametodologia criativa específica e amplamente usada nos projetos que visam a criatividade.

Diante disto, nosso trabalho consiste em apresentar um método capaz de conduziruma equipe à elicitação de requisitos criativos e, paralelamente, construir modelos i* querepresentem as ideias resultantes, tudo isso através da aplicação do Design Thinking.

Design Thinking (DT) é uma metodologia que busca gerar soluções criativas paraum problema a partir da aplicação das técnicas e da forma de pensamento utilizadaspelos designers (BROWN, 2010). O DT pode ser visto como uma forma de pensamentocomplementar à lógica analítica predominante em TI, desta forma, apresenta grande po-tencial em conduzir a equipe à especificação de softwares criativos (LINDBERG; MEINEL;WAGNER, 2011).

Esta dissertação intitulada “Um Método para Construção de Modelos i* Utilizando

Capítulo 1. Introdução 16

Design Thinking” objetiva oferecer diretrizes para engenheiros de requisitos construíremmodelos i*, orientados a objetivos, de requisitos criativos colaborativamente junto aosstakeholders. Nosso método se baseia na metodologia criativa DT, desta forma, buscaremosresponder as perguntas o que?, como? e por que? aplicar do DT para que se consiga, comoproduto do método, modelos i* de requisitos criativos.

Especificar um método prático é necessário porque os resultados dos processoscriativos são difíceis de serem transformados em requisitos de sistema e de serem analisados,mesmo que manualmente. De outro lado, é difícil conceber modelos i* com usuários nãotécnicos devido a complexidade da linguagem (HORKOFF, 2015; HORKOFF; MAIDEN,2015a; HORKOFF; MAIDEN, 2015b; HORKOFF; MAIDEN; LOCKERBIE, 2015). Estadissertação, então, é um passo evolutivo e prático para a integração dos domínios i*(modelagem orientada a objetivos) e DT (criatividade).

1.1 JustificativaIniciamos nossa justificativa, apontando a assertiva de Horkoff, Maiden e Lockerbie

(2015), na qual dizem que é essencial que softwares sejam tanto funcionais, atendendo asnecessidades dos usuários, como inovadores, o que lhes atribui vantagem competitiva.

Já segundo Maiden, Robertson e Robertson (2006), há uma expectativa que a buscapor produtos criativos continue a crescer, isso porque eles argumentam que a criatividadeé indispensável no projeto de produtos inovadores. Indo além, nos trazem que os requisitossão, então, a abstração-chave que encapsula os resultados dos pensamentos criativos, ouseja, os requisitos devem guardar em suas especificações todas as características e definiçõesresultantes de um processo criativo, a fim de que não se percam ou se desvirtuem.

No entanto, Horkoff, Maiden e Lockerbie (2015) argumentam que os resultados dosprocessos criativos são difíceis de serem transformados em requisitos de sistema, pois, sendocomplexos por natureza, podem não ser claros o bastante para servirem de fundamentopara tomada de decisões ao longo do projeto; assim como podem não ser facilmentecapturados por pessoas não experts no domínio inerente ao produto ou processo. Se osresultados dos processos criativos são difíceis de serem postos em um documento formalde requisitos, certamente os transformar em modelos i* é bem mais complexo.

Desse modo, há a necessidade de um método que guie esse processo de transformaçãodesses resultados em modelos de requisitos i*, para que seja possível usufruir das vantagensque a modelagem orientada a objetivos possui.

Propor um método para construir modelos i* criativos é claramente justificadoquando se percebe que, mesmo sendo evidente que a união da modelagem orientada aobjetivos e processos criativos é benéfica para a ER, não há muitos trabalhos científicos que


foquem nisto. Maiden et al. (2010) é vanguardista desse objetivo quando apontou a relaçãoentre requisitos criativos e modelagem orientada a objetivos, ressaltando a necessidade dese criar novas técnicas e ferramentas de apoio. Mas, efetivamente, essa busca só foi iniciadarecentemente nos trabalhos de Horkoff e Maiden (2015a), Horkoff e Maiden (2015b) eHorkoff, Maiden e Lockerbie (2015).

Ainda como justificativa à proposição do nosso método, defende-se que ao desejarrequisitos criativos em modelos i* é necessário ter a disposição técnicas e ferramentasque auxiliem o engenheiro de requisitos a diagnosticar quais ideias criativas contribuem eem que intensidade, para que os objetivos dos stakeholders sejam alcançados, ou mesmoprejudicados (MAIDEN et al., 2010).

Nesta mesma linha de pensamento, Horkoff, Maiden e Lockerbie (2015, pág. 4,tradução nossa) ratificam a necessidade de trabalhos que buscam integrar métodos criativosà modelagem i*.

Neste artigo, nós descrevemos o início de um programa de pesquisa quebusca explorar a sinergia entre técnicas criativas e modelagem orientadaa objetivos para a engenharia de requisitos.[...]Nós fornecemos exemplos específicos de como técnicas de criatividadepodem ser combinadas com modelagem orientada a objetivos para aengenharia de requisitos criativa. [...] Os planos futuros incluem umamaior exploração da combinação de técnicas de criatividade com a mo-delagem orientada a objetivos, incluindo domínios adicionais e técnicasde criatividade ainda mais sinérgicos (por exemplo, brainsketching, roleplay). Os futuros esforços serão concentrados em fornecer suporte deferramentas, orientando os usuários através de um processo distribuídode pensamento criativo e modelagem.

Vejamos ainda:

Para tornar requisitos convencionais em criativos precisamos de técni-cas para adicionar novos comportamentos e qualidades – técnicas quetransformem um comportamento ou qualidade necessários em novidadeatravés dos caminhos exploratório, transformacional e combinacional,enquanto ainda contribuam para o alcance dos objetivos. Novas pesquisassão necessárias para desenvolver essas técnicas. (MAIDEN et al., 2010,pág. 9, tradução nossa)

Como pode ser constatado nos trechos transcritos acima, os trabalhos até entãoestão em uma fase inicial, de modo que não há resultados concretos e replicáveis, diantedisto, é preciso que outros estudos continuem a explorar as possibilidades onde possamhaver integração entre criatividade e i*. Neste trabalho, buscamos explorar especificamentea integração entre DT e i*.

Outro aspecto que corrobora a necessidade de um método prático é que a modelagemem i* requer experiência moderada com a linguagem, de modo que novatos têm muitas


dificuldades para lidar com os diversos elementos do i* (LAUE et al., 2014; HORKOFF,2015). Essa dificuldade se agrava quando se trata de usuários não técnicos, o que tornaextremamente difícil envolver os stakeholders na construção ou validação do modelo.Stakeholders não técnicos, mesmo depois de treinamento, apresentam dificuldade ementender, quando estão modelando, as atividades e os resultados delas (HORKOFF, 2015;CARVALLO; FRANCH, 2014). Portanto, o método que propomos tem como um dosobjetivos diminuir a experiência técnica requerida, a fim de que todos os interessadospossam contribuir criativamente pelo seu conhecimento do negócio e não pelo conhecimentotécnico na linguagem i*.

Quanto ao DT, justificamos nossa escolha por esta metodologia pela evidênciaque vários estudos tem dado sobre o potencial criativo trazido à engenharia de requisitos.Ele tem como objetivo propor soluções criativas para problemas complexos, aqueles queenvolvem vários interessados e objetivos, tem a natureza colaborativa e é essencialmentecentrado no ser humano e sua interação social (BROWN, 2010; MARTIN, 2010). Dessaforma, é complacente com os anseios da ER. Neste contexto, o DT tem o papel de fomentaro pensamento divergente, questionador e abdutivo, podemos dizer que é uma quebra domodelo analítico consagrado nas ciências exatas como a computação. É, portanto, agregarà ER os métodos e ferramentas do mundo do design, o qual está consolidado como eficienteem conceber soluções criativas para problemas desde alguns séculos atrás (LINDBERG;MEINEL; WAGNER, 2011).

1.2 Contribuições esperadasO método que propomos – resultante da condução de uma pesquisa-ação – se utiliza

da metodologia DT para promover o pensamento criativo nos stakeholders, assim como fazvaler a expertise do engenheiro de requisitos quando na construção e análise dos modelosi*. Desse modo, nosso método propõe atividades para ambos os papéis, assim como osconduz nas atividades em comum.

Nosso método busca auxiliar projetos que desejam agregar valor inovador – atravésda concretização de requisitos criativos – e garantir que os usuários tenham seus objetivossatisfeitos e/ou gerenciados. É por este motivo que buscamos integrar estes dois universos.Isso implica dizer que sua aplicação está intrinsecamente ligada a natureza do projeto,pois não achamos que todas as classificações de software possam usufruir plenamente destemétodo.


1.3 Objetivos geral e específicosA fim de definirmos os objetivos do nosso estudo, tomamos como premissa a

capacidade do DT de gerar soluções criativas (BROWN, 2010) – quando considerados seusensinamentos e quando em ambiente propício à criatividade –, assim como a maturidade erecursos benéficos trazidos à engenharia de requisitos pelo framework i* (YU, 1995).

Tendo isto em mente, nosso objetivo geral é expresso como segue:

• Especificar um método que conduza os stakeholders à construção de modelos i*criativos através da aplicação da metodologia Design Thinking.

Conscientes de que o objetivo geral rege todas as decisões e ações ao decorrer doestudo, mas que não pode ser atingido senão pela plena execução de objetivos menores,seguem abaixo objetivos específicos que almejamos e nos conduziram estritamente ao longodo estudo:

1. Integrar os métodos e ferramentas do Design Thinking ao processo de modelagem i*,de modo a propiciar a criatividade.

2. Diminuir a experiência técnica requerida para os stakeholders não-técnicos durantea construção modelos i* criativos.

3. Propiciar a construção coletiva e colaborativa de modelos i* criativos.

É importante destacar que o engenheiro de requisitos deve possuir expertise emDT para que a condução da equipe e aplicação das técnicas criativas sejam maximizadas,esta necessidade é ratificada pelos autores de DT, como consta no Capítulo 2.

1.4 Escopo negativoÉ deveras importante salientar que nosso esforço foi enveredado unicamente para

atingir os objetivos previamente citados. Por este motivo, este estudo não busca provar,ou analisar, sob hipótese alguma o que segue abaixo:

• Provar que o Design Thinking é eficiente na geração de soluções criativas, como, porexemplo, medindo o quão criativos foram os modelos i* gerados.

• Melhorar, estender ou questionar o framework i*.

• Provar que o método proposto é mais eficiente na geração de modelos i* criativosque qualquer outro, mesmo porque as pesquisas desenvolvidas nesta vertente aindasão recentes para análises desta natureza.


Contrariamente a tentar provar o quão eficaz o DT é para gerar ideias criativas, temos opressuposto – pelo que nos apresentam Lindberg, Meinel e Wagner (2011), Verganti (2006),Verganti (2012), Martin (2010), Brown (2010) e Brown (2008) – que esta metodologia ébastante eficiente para fomentar o pensamento criativo. Também não pretendemos sobalguma hipótese melhorar, estender ou questionar o framework i*, em vez disso entendemose reconhecemos – através de Horkoff e Maiden (2015a) e Yu (1995) – os benefícios que eletrouxe à ER.

1.5 Metodologia de pesquisaInicialmente enveredamos para uma revisão da bibliografia existente, a fim de

formarmos um conhecimento sólido dos domínios estudados. Foi esta revisão que nospossibilitou definir a fundamentação teórica da dissertação.

Quanto ao método adotado para a condução do estudo, escolhemos o métodocientífico pesquisa-ação para, a partir de um problema complexo real do tipo wickedproblem1 , intercedermos junto à equipe de criação e inferirmos uma maneira para integraras práticas do DT à modelagem i*, de forma que produza como resultado modelos i*criativos – e que pudesse ser generalizada para outros projetos que objetivam a criatividade.A pesquisa-ação nos permitiu observar na prática os empecilhos à integração fluida, as açõesque melhoraram a capacidade criativa da equipe sem que perdêssemos o foco nos objetivosdos stakeholders, a abstração necessária ao i* para que os envolvidos não necessitassem deconhecê-lo tecnicamente e também uma maneira de converter os resultados das técnicascriativas em modelos i*.

Para Thiollent (2011), a pesquisa-ação é o estudo de uma situação social com ofim de melhorar a qualidade da ação dentro da mesma. Esse método é amplamente usadonas ciências sociais, com o objetivo de entender e considerar as relações sociais que sãodeterminantes para um fato e diante disto evidenciar o conhecimento necessário para quecoletivamente haja êxito na melhoria da ação.

Vejamos o que nos diz Gibertoni (2012, pág. 2):

[...] o mais importante na pesquisa-ação não é encontrar uma soluçãoótima, como em outros métodos, mas conseguir o compromisso com amudança a ser feita para depois relatar a aplicação da teoria e também aresistência à aplicação de determinada técnica. Além disso, cabe ressaltarque existe uma meta bem maior que o resultado que se deseja alcançar: ageração e estruturação do conhecimento. Para Thiollent (2011) o ganhode conhecimento na pesquisa-ação é obtido através da observação e

1 Segundo (RITTEL, 1967 apud CHURCHMAN, 1967), Wicked problems podem ser entendidos como"uma classe de problemas de natureza social mal formulados, onde há informações confusas, um númeroconsiderável de stakeholders com interesses conflitantes, além de não estarem evidentes as possíveisramificações que o problema pode tomar".


avaliação das ações (definidas com os participantes) e dos obstáculosencontrados. Esse conhecimento é passível de generalização parcial, umavez que está fortemente ligado ao contexto da pesquisa. A qualidade doconhecimento, porém, está limitada pela eficácia da intervenção e pelointeresse da empresa no projeto.

Quanto a postura epistemológica, a qual se relaciona ao conhecimento e como elepode ser obtido por parte dos pesquisadores, adotamos uma abordagem interpretativista,na qual o conhecimento é relativo e deve ser entendido do ponto de vista dos indivíduosdiretamente envolvidos na pesquisa (DINIZ et al., 2006).

Mais à frente descreveremos com detalhes a execução da pesquisa-ação, mas deantemão entendemos ter sido bastante adequada para alcançarmos nossos objetivos. Issoporque ela nos propiciou, de imediato, conduzir ações que levassem a produção dosmodelos i* necessários à equipe envolvida na pesquisa e, posteriormente, possibilitouexperimentar e entender a dinâmica social necessária para que este estudo pudesse seconcretizar. Não seria possível a construção deste método proposto sem que houvesseessa liberdade de experimentar e analisar social e colaborativamente as práticas para aconstrução de modelos i*, seguindo os preceitos do DT. Se tivéssemos optado por especificaro método solitariamente e testá-lo depois, certamente seria preciso realizar várias rodadasde experimentos, sem ter a certeza que as adaptações feitas entre os experimentos fariamsentido no meio social e colaborativo até que as testássemos. Resumindo, o feedback socialofertado pela pesquisa-ação foi determinante para que o método fosse definido.

1.6 Estrutura da dissertaçãoAlém desse capitulo introdutório, essa dissertação está dividida em mais 6 (seis)

capítulos:

No Capítulo 2 consta a fundamentação teórica que apresenta os conceitos eas premissas assumidas neste estudo. Tomamos o cuidado de não só apresentar estesconceitos holisticamente, mas sim conduzi-los de modo que se especializem ao contextodeste trabalho.

Já no Capítulo 3, fizemos um apanhado de trabalhos que se relacionam direta eindiretamente com o método proposto. Isso nos possibilitou entender qual a contribuiçãocientífica que poderíamos dar à área que nos propusemos a estudar, assim como devepassar aos leitores a noção do estado-da-arte na área.

Por sua vez, o Capítulo 4 contém a documentação da condução da pesquisa-ação.Tomamos o cuidado de apresentar um narrativa bastante detalhada, a fim de que sejapossível atestar as validades internas e externas do método e do construto. É neste capítuloque apresentamos detalhes das ações, dos participantes e dos resultados obtidos com a


ação.

O capítulo Capítulo 5, considerado a contribuição científica dada por esta disserta-ção, descreve o método resultante da condução da pesquisa-ação, ou seja, a consolidação doconhecimento gerado na experimentação social. Ao apresentarmos nosso método, tomamoso cuidado de fazê-lo da forma mais minuciosa possível, haja vista nossa intenção serfacilitar a construção de modelos i* criativos através da aplicação do DT.

No capítulo Capítulo 6 apresentamos a segunda avaliação realizada com o intuitode validar este método. Para isto, recrutamos uma equipe composta por 6 (seis) pessoas.Ao final da execução do método, os participantes o avaliaram através de um questionáriofechado, o que nos possibilitou algumas conclusões quantitativas. Este capítulo tambémapresenta uma demonstração didática da aplicação do método em um problema real, nestecaso o problema proposto para a avaliação.

Por fim, segue o Capítulo 7, no qual apresentamos as considerações finais desteestudo e indicamos estudos futuros que contribuirão ainda mais para a integração entre amodelagem i* e o DT.

23

2 FUNDAMENTAÇÃO TEÓRICA

Apresentar os conceitos que caracterizam os domínios envolvidos nesta pesquisaé essencial para embasá-la, assim como validá-la perante os mesmos. Neste capítulodiscutiremos sobre os domínios Engenharia de Requisitos, requisitos orientados a objetivose Design Thinking, assim como as principais contribuições que eles entregam para amelhoria de software.

Cada subitem deste capítulo abordará um domínio específico, de forma que, ini-cialmente apresentaremos uma definição teórica mais ampla e consecutivamente commaior detalhamento abordaremos o assunto com um viés voltado para a nossa pesquisa.Este segundo momento é a teorização que embasa o método que definiremos adiante noCapítulo 5.

2.1 Introdução à Engenharia de RequisitosPara Pressman (2011) a ER é o espectro das várias tarefas que conduzem os

stakeholders a um entendimento claro dos requisitos. Quanto a stakeholders, ele argumentaque é qualquer um que se beneficie direta ou indiretamente do software que está emdesenvolvimento.

Já para Sommerville (2011, p. 57), tanto a definição de requisitos, quanto de ER,estão presentes no seguinte trecho:

“Os requisitos de um sistema são as descrições do que o sistema devefazer, os serviços que oferece e as restrições a seu funcionamento. Essesrequisitos refletem as necessidades dos clientes para um sistema que servea uma finalidade determinada, como controlar um dispositivo, colocarum pedido ou encontrar informações. O processo de descobrir, analisar,documentar e verificar esses serviços e restrições é chamado engenhariade requisito”

Requisitos de software são comumente divididos em funcionais e não funcionais.Os requisitos funcionais descrevem o que o sistema deve fazer, ou seja, são declarações dosserviços que o sistema fornece, ou mesmo não fornece. Já os não funcionais são restriçõesimpostas aos serviços e funções do sistema, podem estar relacionados a confiabilidade,tempo de resposta, etc. (SOMMERVILLE, 2011).

Quanto aos processos de ER, incluem quatro atividades de alto nível, são elas:estudo de viabilidade, a qual busca saber se o sistema tem utilidade para os usuários, se éfactível técnica e economicamente; elicitação e análise, que busca descobrir os requisitos e

Capítulo 2. Fundamentação teórica 24

entender a relação entre eles; especificação, que detalha os requisitos sob alguma forma-padrão e validação, a qual checa se os requisitos levantados realmente definem o softwaredesejado pelo cliente. Estas atividades são intercaladas num processo iterativo. No entanto,devemos considerar que o entendimento dos stakeholders sobre o problema muda aolongo do processo de software, isso leva a mudanças nos requisitos. Para controlar essasmudanças e os impactos nos outros requisitos, há uma quinta atividade de alto nívelchamada gerenciamento de requisitos (SOMMERVILLE, 2011).

A ER é descrita como wicked problems. Por isso, devemos considerar as diferençassocioculturais e as diferentes habilidades técnicas dos stakeholders – assim como os fatoresdinâmicos, incertezas e riscos do contexto no qual estão inseridos – para vislumbrarmosos requisitos concernentes ao problema. Isso porque wicked problems são complexos pornatureza, nos quais comumente os requisitos estão ausentes ou incompletos, começando a sedefinirem através da interação do grupo, seja convergente, seja divergentemente. Por isso énecessário focar no coletivo em detrimento do individual, assim como reforçar a necessidadede uma equipe multidisciplinar. Aliado a isto, os usuários apresentam grande dificuldadeem descreverem o que querem, deixando a ER a obrigação de descobrir (MAHAUX et al.,2013; LINDBERG; MEINEL; WAGNER, 2011; MAIDEN; ROBERTSON; ROBERTSON,2006).

Pressman (2011) e Sommerville (2011) taxativamente dizem que, considerando ocenário mercadológico, a maioria dos produtos de software é incremento dos que já existem,portanto, carecem de inovação. Pressman (2011) declara, ainda, em um capítulo dedicadoaos tópicos emergentes na Engenharia de Software (ES), que a necessidade de gerenciara complexidade, acomodar requisitos emergentes, estabelecer modelos de processos queaceitem mudanças e coordenar equipes multidisciplinares sugerem um novo tempo, ondeferramentas que suportem a colaboração entre os stakeholders serão tão importantesquanto as que suportem os aspectos tecnológicos.

2.1.1 Criatividade na Engenharia de Requisitos

Visto que criatividade pode assumir diferentes contextos nas várias áreas doconhecimento, para ER Maiden et al. (2010) nos dizem que criatividade é a captura derequisitos que são ao mesmo tempo novos e apropriados e ainda distinguem o termoinovação, argumentando que a implementação dos requisitos criativos conduz à inovação.De acordo com Boden (2004 apud RAYASAM; NIU, 2015), a criatividade na ER podeser classificada como exploratória, a qual é obtida através de pesquisas profundas quedesvendam uma gama de possibilidades; combinacional, a qual é obtida através de conexõesentre objetos e disciplinas distintas num menos espaço de pesquisa e transformacional, queé entendida como a mais difícil de fomentar, haja vista ela buscar mudar (causar ruptura)os conceitos e regras que regem dado artefato.


O tema da criatividade tem recebido muita atenção dos pesquisadoresda Engenharia de Requisitos (RE) ao longo da última década. Engenha-ria de Requisitos também tem sido demonstrada como uma disciplinainerentemente criativa, como recentemente sintetizado por Meiden etal.. Neste documento, sugerimos que Engenharia de Requisitos não ésimplesmente um processo criativo, mas um processo criativo e colabo-rativo. A diferença é importante para a disciplina, porque, como vimosacima, criatividade individual e colaborativa são conhecidas por seremqualitativamente distintas e, portanto, requerem diferentes processos, ha-bilidades e técnicas. Nós argumentamos que as atividades de Engenhariade Requisitos quase sempre exigem criatividade colaborativa, porque asequipes de desenvolvimento precisam chegar a um consenso sobre umnovo e valioso sistema que querem construir. (MAHAUX et al., 2013,pág. 1, tradução nossa)

Lemos et al. (2012), com o objetivo de mapear sistematicamente os estudos existen-tes sobre criatividade na ER, selecionaram e analisaram vários documentos dos bancos dedados mais renomados na área de TI - ACM Digital Library, IEEE Xplore, SpringerLink,etc. - que tivessem menção direta a criatividade e a Engenharia de Requisitos. Comoresultado eles apresentaram a visão e contribuição de vários pesquisadores, assim comoobservaram a necessidade de mais pesquisas sobre a criatividade que abranjam todo oprocesso de ER, visto que a maioria dos estudos é para a fase de elicitação. Vejamos:

Nos últimos anos, o campo da criatividade para Engenharia de Requisitostem recebido um crescente interesse de pesquisadores e profissionais. [...]Levantamento de requisitos é a fase que concentra a maioria dos estudos.O estudo confirma que as técnicas de criatividade melhoram o pensamentocriativo nas atividades de requisitos. (LEMOS et al., 2012, pág. 1083,tradução nossa)

E este discurso é complementado por (MAHAUX et al., 2013, p. 9, tradução nossa):“Um apoio completo à criatividade colaborativa nos processos de Engenharia de Requisitospode ser um passo importante para uma melhor compreensão dos problemas de negócio ea geração de melhores soluções de negócio.”

A maioria dos processos da ER são processos criativos de resolução de problemas,no entanto a ênfase dada para a engenharia tem marginalizado o pensamento criativocomo uma atividade importante. As atividades de ER comumente exigem criatividadecolaborativa, uma vez que os stakeholders precisam discutir sobre o produto ou serviço, afim de elicitar e mitigar os requisitos do mesmo. Podemos notar que há uma preocupaçãoem afirmar o aspecto colaborativo da criatividade na ER, isso porque os especialistas emcriatividade distinguem criatividade individual da colaborativa, porque esta última sebaseia explicitamente nas interações dentro de um grupo para alcançar o resultado criativo(MAHAUX et al., 2013; MAHAUX; MAVIN; HEYMANS, 2012; MAIDEN et al., 2010).

Após uma longa discussão envolvendo as mais notáveis autoridades em criatividadena ER, Mahaux et al. (2013) propuseram um framework para explorar e ilustrar a


criatividade colaborativa nesta área. Em primeiro nível, este framework distingue osfatores coletivos dos individuais e em seguida os subdivide, a saber, resumidamente: dentreos fatores coletivos, sem o detalhamento das devidas subdivisões, constam objetivo, tempo,cultura, tolerância, divergência, confiança, liberdade, desafio, comunicação, liderança etécnica.

2.2 i*: framework orientado a objetivosO i* é um framework de modelagem conceitual, orientado a objetivos, que tem

por finalidade modelar contextos organizacionais para prover um mecanismo de análiseestratégica. Para isso leva em conta os atores envolvidos, seus respectivos objetivos eas relações de inter-dependência entre esses elementos. Quanto ao objetivos, eles podemser apresentados com a exigência de serem inflexíveis (goal), portanto só podem serintegralmente satisfeitos, ou flexíveis (softgoal), que podem estar parcialmente satisfeitos(YU, 1995).

O uso do i* para a construção de modelos de requisitos no desenvolvimento desoftware ameniza os problemas não resolvidos pelos processos de requisitos convencionais.Com ele é possível expressar a intenção de um ator no uso do software e quais asdependências e influências com os outros atores e objetivos. Isso é extremamente relevante,visto que as mudanças nos requisitos se dão na prática porque os objetivos dos atores nãoforam satisfeitos, ou foram prejudicados de alguma forma. Somado a isto o i* propiciaevidenciar e solucionar os conflitos de interesses existente, outro aspecto difícil de serabordado por aqueles processos (I* WIKI, 2007; YU, 1995).

A notação básica do i* está definida na Figura 1. E na Figura 2 as relações que osengenheiros de requisitos podem construir na modelagem i*. Segundo i* Wiki (2007), umdos objetivos de se criar modelos i* e a necessidade de explicitar como goals e softgoalspodem ser satisfeitos através da operacionalização, ou através de ações mais concretas edecisões de projeto incluídas no modelo. Para ele, operacionalização, ou decomposição,é o processo de encontrar alternativas que satisfaçam os goals e softgoals. Desta forma,uma boa modelagem não deve ter goals e softgoals como últimos elementos de uma cadeia(leaf elements) ou sem links de entrada apontados para eles. Essas práticas tornarão osmodelos mais completos e precisos.

Os modelos i* podem ser do tipo Strategic Dependency (SD) ou Strategic Rationale(SR). O modelo SD é usado para denotar a rede de intenções e relacionamentos estratégicosde dependência entre os atores. Já o SR provê através da operacionalização uma estruturapara representar as estratégias internas dos atores, de modo que fiquem explícitos asalternativas e caminhos possíveis para atingir os goals e as relações com os outros elementos(I* WIKI, 2007; YU, 1995).


Figura 1 – Notação básica do i*

Fonte: (I* WIKI, 2006)


Figura 2 – Possíveis relações no modelo i*

Fonte: (I* WIKI, 2006)

No SD uma relação de dependência significa uma cooperação mutua entre atores,onde o dependente (depender) e aquele do qual se depende (dependee) são unidos porum link de dependência (dependum). O dependum pode ser um goal, softgoal, recurso outarefa. Enquanto que no SR os atores têm suas fronteiras estendidas para que os elementosnecessários para satisfazer os objetivos dos atores se ligam um ao outro por um link definalidade, decomposição ou contribuição (I* WIKI, 2007; YU, 1995).

De maneira geral, já tendo definido goal e softgoal, i* Wiki (2007) define umatarefa como sendo uma forma específica de realizar algo e que pode ser decomposta emsub-elementos necessários para a execução da mesma; já um recurso é uma entidadefísica ou informacional desejada pelo ator, para este tipo de elemento não há questõesem aberto sobre como será obtido; por sua vez, as premissas são condições consideradasverdadeiras pelo ator nas relações existentes para atingir um goal; no que diz respeito alinks means-end, eles indicam a relação entre um fim (goal) e um meio de atingi-lo (tarefa);


enquanto que link de decomposição ligam uma tarefa a seus sub-elementos, os quais podemser um goal, um recurso, um softgoal ou mesmo uma sub-tarefa e, por último, links decontribuição denotam a influência de um elemento sobre o outro.

Para termos uma melhor visualização destas possibilidades de modelagem, vejamosa Figura 3, a qual ilustra um modelo SD para uma clínica de saúde e a Figura 4, queilustra um modelo SR para uma seguradora.

Figura 3 – Exemplo de modelo SD

Fonte: (YU, 1995)

Realizar análises, automáticas ou não, sob os modelos i* possibilitam ao engenheirode requisitos perceber uma falha de elicitação e especificação de requisitos precocemente elhe dá apoio para corrigir e detectar possíveis impactos no sistema como um todo. Assimcomo é uma ótima base para que possa validar mais tardiamente os requisitos levantados.Considerando, então, a parcela de falhas nos projetos de software que estão relacionadas aos


requisitos, percebemos as vantagens trazidas a engenharia de requisitos pela modelagemorientada a objetivos e, consequentemente, a contribuição dada pelo i*.

Figura 4 – Exemplo de modelo SR

Fonte: (YU, 1995)

A análise de um modelo dever ser feita através de questionamentos como: Paracada goal no modelo, o ator a quem ele pertence tem condições de alcançá-lo?; O caminhopara um ator atingir um goal passa ou depende de outro ator?; Há mais de um caminhopossível?; Os caminhos são viáveis?; O modelo como um todo é crível em satisfazer osgoals dos atores?. Isso deve ser analisado até o momento em que o modelo seja crível euma ou mais soluções viáveis sejam encontradas (I* WIKI, 2007).

O i* provê conceitos que facilitam a análise satisfatória das situações representadasno modelo. São eles: habilidade – é satisfatório quando o ator possui um caminho paraatingir o propósito em questão; trabalhabilidade (do termo inglês workability) – é satisfatórioquando o analista tem a certeza de que quando a ação for produzida o caminho apontadocomo satisfatório esterá disponível para o ator; viabilidade – está relacionado a quãoevidente é a possibilidade de um caminho ser satisfatório ou não, onde, de modo geral,


um caminho é viável quando os softgoals no modelo forem suficientemente satisfeitos e,por último, credibilidade – que diz o quão críveis são às premissas adotadas no modelo (I*WIKI, 2007).

Apesar dos benefícios apresentados, a contrapartida do i* é certamente o graude complexidade para conseguir modelos completos e precisos. Maiden et al. (2011) nosesclareceram bem este ponto quando reportaram uma análise sobre a experiência daaplicação do i* nos maiores projetos industriais que o puderam utilizar. Nesses projetos,apesar de os engenheiros de requisitos terem conhecimento técnico de i*, essa complexidadese mostrou evidente. Inicialmente eles apontam para a dificuldade que é desenvolvermodelos SD e ter uma forma eficiente de estabelecer todas as possíveis dependências,ou seja, como perceber que as possibilidades de dependência foram exploradas até ondedeviriam.

Outro ponto que pode trazer problemas é o fato de ser fácil usar a linguagemincorretamente, visto que é uma forma bastante diferente das quais a engenharia desoftware tradicionalmente havia proposto, por exemplo Unified Modeling Language (UML).UML diz apenas o que o sistema faz, enquanto i* deve dizer o que ele faz, porque faze corss-referenciar a seus goals e softgoals. Ainda, os vários elementos existentes no i*,que podem ser ligados de diferentes formas nos modelos SD e SR, trazem problemas demodelagem inerentes apenas ao i* (MAIDEN et al., 2011).

Maiden et al. (2011) ainda argumentam que, dada a rigorosidade semântica do i*, ébastante difícil encontrar os atores e dependências mais importantes para os quais começara produzir o primeiro modelo SD, a ponto de terem considerado a produção anterior de ummodelo de contexto definidos por eles e usá-lo para guiar a produção do primeiro modeloSD.

Dada as dificuldades acima para engenheiros experientes, novos usuários do i* estãosujeitos a estas e outras que seguem. Horkoff (2015) realizou um estudo experimental quedemonstrou que, mesmo trabalhando apenas nos modelos SD, grupos de novos usuáriostiveram um progresso bastante lento na modelagem, pois muito tempo foi gasto discutindoideias, dependências e atores, com consequente pouco tempo para registrarem o que haviamdiscutido. Alguns poucos grupos que começaram a modelagem SR estavam bastanteconfusos sobre os relacionamentos internos de decomposição, contribuição e means-end.Nas discussões os novos usuários tinham dificuldade em estabelecer equivalência entre osartefatos identificados no problema e os elementos representativos do i*.

A dificuldade com o uso efetivo do i* foi deveras considerável, a ponto de Hor-koff (2015) defender que a melhor estratégia para lidar com usuários novatos é fazê-lostrabalharem primariamente com um modelo híbrido de SD e SR, postulado pelo autore apresentado integralmente na Figura 5 – a qual ilustra um modelo híbrido para umserviço de estacionamento. Esse modelo intermediário inclui atores, fronteiras dos atores,


elementos internos às fronteiras e algumas dependências, mas sem entrar nos detalhes dosrelacionamentos internos do modelo SR.

Figura 5 – Modelo SD/SR híbrido indicado para aprendizes

Fonte: (HORKOFF, 2015)

E por fim, Horkoff (2015) alerta que apesar de o processo entre SD e SR ser iterativo,as equipes não demonstraram capacidade para melhorar os modelos SD delas a partir doprogresso dos SR.

2.2.1 Uso do i* em ambientes criativos

Num trabalho recente apresentado por Horkoff, Maiden e Lockerbie (2015), elesdemarcam o início de uma série de estudos que buscarão entender a sinergia existenteentre modelagem orientada a objetivos e criatividade. Esta relação é portanto bastantevanguardista e, por consequência, nosso método proposto busca contribuir para esseentendimento.

Em um desses estudos, Horkoff e Maiden (2015b) executaram experimentos com ointuito de saber se é possível alinhar atividades de modelagem orientada a objetivos comatividades de prática criativa. Como resultado nos afirmam que os grupos não observaramrestrição ao pensamento criativo devido às atividades de modelagem orientada a objetivos(i*). Contrariamente, evidenciaram que uma complementa a outra, visto que a modelagemorientada a objetivos permite a documentação clara (e técnica) das ideias levantadas pelosmétodos criativos.

Os grupos foram capazes de adicionar goals e softgoals aos seus modelos baseados


nos resultados criativos, apesar de, por limitações de tempo, não ter sido possível realizarmudanças (pela análise) nesses modelos. O experimento ainda demonstrou que a necessidadeexploratória inicial requerida pela modelagem foi essencial para iniciar as atividadescriativas, de modo que estas últimas foram melhor aceitas quando executas depois deiniciada a modelagem. Sobre este argumento, os próprios autores declaram ter sidoinfluenciado pela ordem proposta para as atividades; e nós atentamos para questionar se asatividades criativas não envolveram qualquer fase anterior de exploração do problema, poismetodologias como o DT nos encaminham inicialmente da fase de inspiração (exploraçãodo problema) adiante.

Como conclusão do experimento, Horkoff e Maiden (2015b) afirmam ser possívelter uma integração fluida entre as atividades de modelagem e de estimulo à criatividade,de modo que o fluxo mais adequado é aquele que executa as atividades concomitantemente,ou seja, intercala atividades de modelagem e de criação, a fim de que os resultados criativospossam ser expressos em modelos orientados a objetivos.

Outro experimento, realizado por Horkoff (2015), desta vez com novos usuários dalinguagem i*, também atesta que os usuários conseguiram integrar atividades de modelageme atividades criativas. Nesse estudo Horkoff (2015) conclui que os participantes não tiveramo pensamento criativo tolhido pelas atividades de modelagem e que argumentaram que amelhor forma de fazê-lo é executando essas atividades conjuntamente.

2.3 Design Thinking: uma metodologia criativaApesar de costumarmos relacionar o termo inovação à uma novidade tecnológica,

diz-se que algo é inovador quando causa impacto nas vida das pessoas que usam oproduto/serviço, quando rompem a ideia comum outrora apresentada por concorrentesou, certamente, quando há a novidade em si. Ou seja, inovação é valor percebido. Jápara o mercado, é a possibilidade de sair à frente do concorrente, de ganhar vantagemcompetitiva e de cobrar pelo valor agregado presente no produto/serviço. Ao longo dosanos, a disciplina design tem desenvolvido processos, métodos e ferramentas para resolverproblemas, os mais complexos, de forma inovadora. Ao estimular/concretizar o pensamentocriativo, os designers entregam inovação (VERGANTI, 2006; VERGANTI, 2012; MARTIN,2010; BROWN, 2010).

A inovação guida pelo design, que aposta no poder de inferência e na experiênciado designer, tem na pesquisa a fonte de inovação, ou seja, entregar inovação a partir dareleitura de produtos antigos ou da união de produtos sob a visão do designer. Deste modo,o produto apresentado atinge usuários que não esperavam, mas que acolhem a proposta elhe dão um valor único ante aos concorrentes (VERGANTI, 2006; VERGANTI, 2012).

Design Thinking, ou pensamento de design, é a abstração do modelo mental adotado


pelos designers para gerar ideias e resolver problemas. É uma metodologia que integrafatores humanos, de negócio e tecnológico no entendimento do problema. É uma proposiçãopara pensar de modo abdutivo, para que tanto a análise quanto a criatividade possam serconsideradas no universo das soluções. O DT é essencialmente colaborativo, multidisciplinare centrado nas necessidades dos stakeholders (human-centric). Diferentemente da práticacomum de delegar a um grupo pequeno de designer toda a responsabilidade de inovar, o DTevangeliza a disseminação deste modo de pensar para todos os stakeholders que objetivamou estejam envolvidos em projetos criativos (MEINEL; LEIFER, 2011; MARTIN, 2010;BROWN, 2008; BROWN, 2010; BROWN, 2009; VIANNA et al., 2012; D.SCHOOL, 2010;GREMETT; BAECK, 2011; WALOSZEK, 2012; THIENEN et al., 2011).

Vianna et al. (2012) nos apresenta uma boa síntese do que se entende por DT:

No mais, como o nome já diz, o Design Thinking se refere à maneira dodesigner de pensar, que utiliza um tipo de raciocínio pouco convencionalno meio empresarial, o pensamento abdutivo. Nesse tipo de pensamento,busca-se formular questionamentos através da apreensão ou compreensãodos fenômenos, ou seja, são formuladas perguntas a serem respondidas apartir das informações coletadas durante a observação do universo quepermeia o problema. Assim, ao pensar de maneira abdutiva, a soluçãonão é derivada do problema: ela se encaixa nele.

Ainda complementando, vejamos o que acrescenta Brown (2010):

Não se trata de uma proposta apenas centrada no ser-humano; elaé profundamente humana pela própria natureza. O design thinkingse baseia em nossa capacidade de ser intuitivos, reconhecer padrões,desenvolver ideias que tenham um significado emocional além de palavrasou símbolos. Ninguém quer gerir uma empresa com base apenas emsentimento, intuição e inspiração, mas fundamentar-se demais no racionale no analítico também pode ser perigoso. A abordagem integrada quereside no centro do processo de design sugere um terceiro caminho.

Dar-se o nome de design thinker àqueles que estejam envolvidos num projeto guiadopelo DT, mas acima disto, àqueles que possam ser enquadrados nos principais atributosdele, como mostra a Tabela 1.

É extremamente desafiador promover inovação sob fortes restrições, no entanto édever do design thinker estar disposto a aceitar e explorá-las. Um bom processo guiadopelo DT costuma identificar as principais restrições logo no início e, então, definir critériospara validá-las. As restrições podem ser avaliadas quanto ao seu grau de desejabilidade(faz sentido para as pessoas), viabilidade (modelo de negócio sustentável) e praticabilidade(funcionalmente possível). O DT busca não apenas explorar as restrições, mas pô-lasem equilíbrio quanto a essas naturezas, o que não significa dizer que que um projetobem-sucedido as terá com a mesma proporção. Uma equipe de design thinkers experientes


Tabela 1 – Principais atributos do Design Thinking

Atributo Descrição Comentário Ambiguidade Ser confortável quando as

coisas não são claras ou quando você não sabe a resposta

Design Thinking visa wicked problems (mal definidos e complicados).

Colaborativo Trabalhar juntos em todas as disciplinas

Pessoas projetam em equipes interdisciplinares.

Construtivo Criar novas ideias com base em velhas, as quais também podem ser as ideias mais bem-sucedidas

Design Thinking é uma abordagem baseada em solução que procura um resultado futuro melhorado.

Curiosidade Ser interessado em coisas que você não entende ou perceber as coisas com outros olhos

Tempo e esforço consideráveis são gastos em esclarecer os requisitos. Uma grande parte da atividade de resolução de problemas, então, consiste de definição e modelagem do problema.

Empatia Ver e entender as coisas do ponto de vista dos seus clientes

O foco está nas necessidades do usuário (contexto do problema).

Holístico Olhando pelo contexto maior para o cliente

Design Thinking tenta atender às necessidades do usuário e também o sucesso do negócio.

Iterativo Um processo cíclico onde as melhorias são feitas para uma solução ou ideia, independentemente da fase

O processo de Design Thinking é tipicamente não-sequencial e pode incluir loops de feedback e ciclos (ver abaixo).

Sem julgamento

Criar ideias sem julgamento em direção ao criador ou à ideia

Particularmente na fase de brainstorming, não há julgamentos iniciais.

Mentalidade aberta

Abraçar Design Thinking como uma abordagem para qualquer problema, independentemente do negócio ou escopo

O método incentiva a "pensar fora da caixa" ("ideias malucas"); ele desafia o óbvio e abraça uma abordagem mais experimental.

Fonte: (GREMETT; BAECK, 2011, tradução nossa)


pode naturalmente mudar o foco do problema enquanto busca concluir o projeto (BROWN,2008; BROWN, 2010).

No DT um projeto é delimitado com início, meio e fim. O início do projeto émarcado pela definição do briefing – o qual pode ser é entendido como um conjunto derestrições mentais que indicam por onde começar a exploração, podendo conter benchmarks,pelos quais é possível mensurar o progresso, assim como um conjunto de objetivos, os quaissão a destinação final do projeto. Ainda sobre o projeto, este deve ser marcado por metasclaras e objetivas a serem alcançadas. Essas metas proporcionam identificar estágios e,consequentemente, servem de termômetro para que a equipe mantenha o espírito criativoe colaborativo (BROWN, 2008; BROWN, 2010).

Quanto ao briefing, vejamos o que nos diz Brown (2010, pag. 22–23):

A analogia vai ainda mais longe. Da mesma forma que uma hipótese édiferente de um algoritmo, um briefing de projeto não é um conjuntode instruções ou uma tentativa de responder a uma pergunta antes deela ser elaborada. Em vez disso, um briefing bem elaborado levará emconta a sorte, a imprevisibilidade e os caprichos do destino, já que esse éo âmbito criativo no qual surgem as ideias inovadoras. Se você já sabe oque quer, normalmente não faz muito sentido procurar.[..] Um briefing de design abstrato demais arrisca deixar a equipe deprojeto perdida em um nevoeiro. Já um briefing que parte de um conjuntoreduzido demais de restrições praticamente garante que o resultado sejaincremental e, provavelmente, medíocre.

Resumidamente, podemos dizer que um briefing deve deixar espaço para a equipede projeto interpretar os conceitos, explorar e ... descobrir.

Quando nos referimos a equipe de projeto, Brown (2010) nos alerta que o maisimportante é efetivamente inserir o cliente como um membro design thinker. Além disso, háa recomendação de que a interdisciplinaridade se faça presente, não apenas como pessoasde formações distintas, mas como pessoas com pensamentos/saberes dinamicamenteinterligados nas diversas áreas de conhecimento.

Outro fator relevante nas equipes de projeto é o tamanho, quanto maior a equipemenor é a efetividade em gerenciá-la e cultivar o pensamento criativo entre os membros.Mesmo com ferramentas modernas de gerenciamento de tarefas e reuniões há prejuízo aofomento do pensamento abdutivo. Por este motivo, quando não for possível manter umaequipe enxuta, a literatura tem aconselhado a subdivisão em pequenas equipes gerenciadasconstantemente para se manter a unidade do projeto. Equipes grandes têm dificuldadeem se manterem focadas e, até mesmo, há prejuízo na aplicação de técnicas criativas –que normalmente preconizam uma integração afinada dos participantes (BROWN, 2008;BROWN, 2010).


Tabela 2 – Comparação entre os estágios das definições distintas de Design Thinking Estágios prototípicos

Wikipedia /Herbert Simon

IDEO Toolkit Tim Brown (IDEO)

d.school/ D-School (HPI)

d.school Bootcamp Bootleg (HPI) – Modes

Baeck & Gremett (2011)

Mark Dziersk (Fast Company)

Entender o problema

Definir Descobrir Inspirar-se Entender Simpatizar: Observar, engajar, imergir

Definir o problema a resolver

(1) Definir o problema

Observar usuários

Pesquisar Observar Buscar inspiração

Interpretar os resultados

Interpretar Ponto de vista

Definir (Afirmação do problema)

—

Gerar ideias (Idear)

Idear Idear Idear Idear Idear Idear múltiplas ideias

(2) Criar e considerar várias alternativas

Prototipar, experimentar

Prototipar Experimentar Implementar Prototipar Prototipar Gerar protótipos

(3) Refinar direções escolhidas (3.5) Repetir (opcional; etapas 2 e 3)

Testar, implementar, melhorar

Objetivos/ Escolher, implementar e aprender

Evoluir Testar Testar (inclui refinar e melhorar as soluções)

Solicitar feedback do usuário

(4) Escolher o campeão, executar

Fonte: (WALOSZEK, 2012, tradução nossa)

O último elemento que merece destaque nos projetos de DT é o que chamamos deespaço de inovação. Para Martin (2010) este espaço holisticamente deve perpassar todos ossetores de uma organização, dos operadores à alta gestão. Este espaço, enquanto culturade incentivo à criatividade, deve ser embasado por valores como otimismo, confiança eousadia, já enquanto espaço físico deve prover suporte para ações de pesquisa e desenvol-vimento, fornecer e dar assistência às ferramentas necessárias para execução das técnicasde criatividade e propiciar o convívio/contato efetivo entre os membros da equipe (designthinkers).

O DT, quando aplicado a um projeto, se apresentará invariavelmente por meio deum processo iterativo e não linear. Isso se deve ao fato de ele ser verdadeiramente umprocesso exploratório, que se levado a cabo, conduzirá a equipe a caminhos de descobertasinterligadas e contínuas, de modo que a equipe possa até mesmo ser motivada a repensaralgumas premissas outrora adotadas. Há na literatura várias divisões desse processo emestágios – vide Tabela 2 – mas para nosso estudo consideramos a definição de Brown(2008) – quarta coluna na tabela e também detalhada na Figura 6. Para entendermosmelhor essa visão, complementada com Brown (2010), vejamos o que segue.

O estágio de inspiração consiste em entender o problema e as relações dele comoutras áreas de conhecimento e com a vida social. Nele se define o estado-da-arte através de


Figura 6 – Fluxo do processo de Design Thinking

Fonte: (BROWN, 2008)

uma busca sistematizada por conhecimento, podendo inclusive ser comparado às pesquisasde campo muito praticadas nas ciências sociais. Por esse motivo, o pensamento predomi-nante nesta fase é o de análise e síntese. Durante este estágio, curiosidade, ambiguidade,holístico e empatia são os atributos mais evidenciados.

Quando falamos de curiosidade, não limitamos o design thinker a ser apenas umespectador. Como dito anteriormente, a empatia está intrinsecamente ligada. Usar técnicaspara se sentir “na pele” do usuário também é pratica recomendada.

Ao final deste estágio, a equipe deve ter um entendimento claro do estado-da-artedo problema. Assim como saberá em quais pontos podem atribuir criatividade, ou imporlimitações que devem ser respeitadas. Por exemplo, num software que pretenda revolucionaro sistema radiodifusor, as leis vigentes de direitos autorais são limitações que devem serapontadas, para que não haja risco de fracasso pré-anunciado do projeto.


Já no estágio de ideação, as técnicas de criatividade ganham maior destaque, vistoque neste momento os pensamentos convergente e divergente devem ser predominantes afim de gerar e selecionar alternativas criativas. Por exemplo, o brainstorm é muito utilizadopara gerar alternativas, enquanto a prototipação é eficiente em selecioná-las.

Neste momento, o uso das técnicas criativas é amplamente difundido, por isso osatributos colaborativo, construtivo, mentalidade aberta e não julgamento devem ser osmais cultivados pela equipe. Apesar da ideação ser, normalmente, menor que a inspiração,neste estágio se atribui o aspecto verdadeiramente criativo a solução.

Já a implementação é tida como o menor estágio, não quanto ao tempo quese gastará para concluí-lo, mas pela menor contribuição do DT para executá-lo. Nestemomento pode haver necessidade de tomar decisões sobre a execução – por exemplo,prototipar – o que deve ser apoiado por inspiração e ideação novamente, pois são osestágios onde se entende e inova o projeto.

Independente do estágio, o DT preconiza a utilização de um espaço que propicie acriatividade, de modo a fornecer conforto para manter a equipe unida e inter-acessível, alémde ferramentas que ajudem no pensamento criativo. O post-it é uma ótima ferramenta paragerenciar as ideias, dada a flexibilidade de manipular e evidenciá-lo por todos da equipe.Outra ótima ferramenta é o pensamento visual, há ideias que são melhores vislumbradasilustrativamente. Contar histórias também é extremamente importante, pois é um meio decultivar a empatia.

O último destaque feito às práticas do DT é a importância da prototipação durantetodo o projeto. Como dito por Jobst e Meinel (2014), prototipação ajuda os stakeholdersa entenderem o que querem, ajuda os designers a resolverem conflitos e indica possíveissoluções para um problema, por isso, prototipar é certamente uma prática constante a seradotada no DT.

2.3.1 Uso do Design Thinking na criação de software

Lindberg et al. (2012) e Lindberg et al. (2012) se debruçaram sobre o temada criatividade fomentada pelo DT aplicada ao mercado de TI, no projeto intituladoCollaborative Creativity of Development Processes in the IT Industry. Nele exploraram acapacidade do DT de ampliar o entendimento e solução de problemas nos processos deTI. Concluíram que esta metodologia quando aplicada ao desenvolvimento de softwaresmaximizará o potencial criativo desses produtos, ressaltando que os preceitos do DT sãoaplicáveis a todas as fases do desenvolvimento, uma vantagem efetiva diante das outrasabordagens que se limitam, geralmente, à elicitação de requisitos.

Eles ainda apontam que o DT se apresenta como um modelo de pensamentocomplementar ao já consagrado nas ciências exatas como a computação. Os design thinkers


possuem habilidades para lidar com problemas complexos e de natureza social, os wickedproblems não podem ser totalmente entendidos com o pensamento analítico disseminadoem TI.

Lindberg et al. (2012) nos diz que a forma de implementar o DT nos processos deTI depende da conceituação que se dá a esta metodologia, portanto haverá vários modelosde implementação. Isso porque para alguns o DT pode ser implementado como uma faseanterior, enquanto que para outros é um arcabouço de atitudes a ser considerado pelosprofissionais durante o clico de vida do processo de ES. Diante disto, eles nos apresentam4 (quatro) formas distintas de integrar o DT ao desenvolvimento de software.

No split project model, o DT é um processo separado executado por especialistas(time de design thinkers) antes do processo de desenvolvimento começar. Desta formao objetivo é entregar um conjunto mínimo de requisitos para o processo de ES operarsobre ele. O overlapping teams model ainda utiliza o DT como uma fase anterior isolada,mas considera a participação de membros da equipe de TI no processo de geração dasolução e estes integrantes ficam responsáveis por comunicar-se com seus pares de TIsobre o processo criativo, ou seja, são os representantes da equipe de criação na equipe dedesenvolvimento. Já no toolbox model, o DT é visto apenas como um conjunto de técnicasque podem ser utilizadas pela própria equipe de TI quando necessitarem resolver umproblema ou escolher entre possibilidades, que não possam ser alcançados com os métodosconvencionais da ES.

Mas para nosso método consideramos o unified project model. Vejamos abaixo:

No modelo de projeto unificado, design thinking é uma técnica centralà frente do próprio processo de desenvolvimento. O processo geral estáa mudar do design thinking para um processo de desenvolvimento deTI quando as concepções de problema e solução são especificadas osuficiente para traduzi-las para as tarefas de desenvolvimento. Isto implicaque existe uma forte sobreposição de papéis e responsabilidades degerenciamento entre o design thinking e as fases de desenvolvimento.(LINDBERG et al., 2012, pág. 239, tradução nossa)

Sobre a relação direta entre o DT e a ER, Vetterli et al. (2013) nos diz que podemosver a ER como inerentemente difícil e que os analistas de requisitos começam com ideiasmal definidas e muitas vezes conflitantes. O processo de ER é mais iterativo e envolvemais pessoas com diferentes origens do que outras atividades de ES. Assim como requeranálises mais meticulosas de diversos outros aspectos, como tecnológico, humano, legale cultural. No entender desses autores, o DT fornece uma metodologia para elicitar asnecessidades dos clientes, o que o torna imbuído de compreender mais profundamente asnecessidades humanas do que apenas as especificações do software, assim como produzuma série de protótipos rápidos e simples que eventualmente convergem para soluçõesinovadoras. Várias instituições e companhias adotam-no, entre elas estão: Universidade


de Stanford que estuda, testa e modifica esta metodologia nos últimos 40 (quarenta) anos;Aalto; Potsdam; St. Gallen; Proctor and Glamber; SAP e Deutsche Bank. Por começar comprotótipos rápidos, de baixa resolução, auxilia as equipes de design a divergirem dentro doespaço de projeto para evitar grandes erros mais tarde, porque para o DT quanto maiscedo a equipe errar, menor será o dano ao produto em desenvolvimento.

2.4 Considerações finaisNo nosso entendimento, o alinhamento entre DT e i* está fundamentado em três

pilares. Os dois primeiros, fortemente interligados, são o foco de ambos em satisfazer osobjetivos dos usuários e a capacidade de resolver conflitos de interesses de forma eficienteem denotar como certos elementos influenciam diretamente outros. O terceiro é o viéscentrado no usuário, de forma a representá-lo explicitamente como elemento base.

O i* possui representações explícitas para atores – seja humano , seja máquina – eos têm como elementos essenciais da modelagem. Já no DT a representação do ator sedá por meio de personas, para as quais existe o mesmo entendimento apresentado no i*.Sobre o uso de personas, vejamos:

Podem ser utilizadas em várias fases do processo, pois servem paraalinhar informações dos usuários com todas as pessoas envolvidas, massão especialmente úteis na geração e validação de ideias. Por exemplo,as necessidades das personas podem ser exploradas na fase de Ideaçãopara geração de soluções inovadoras que atendam às suas demandas.Depois disso, as mesmas ideias podem ser avaliadas pela perspectiva daspersonas de forma a selecionar as mais promissoras. Elas auxiliam noprocesso de design porque direcionam as soluções para o sentido dosusuários, orientando o olhar sob as informações e, assim, apoiando astomadas de decisão. (VIANNA et al., 2012, pág. 80)

Nielsen (2012) apresenta vários entendimentos presentes na literatura sobre persona,de modo geral, nos diz que personas podem ser criadas a partir das concepções do designersobre o problema ou que sua criação depende do embasamento encontrado na exploraçãodo problema. É neste último viés que Cooper (2004) se encontra e nosso estudo encontrouforte fundamentação no que ele nos diz sobre o tema.

Cooper (2004) ainda expande a definição de persona quando apresenta a ideiade persona primária, aquela cujo projeto fracassa se não atender aos objetivos dela. Édever da equipe identificar a persona primária e resolver os conflitos de interesse a fim deque os objetivos dela prevaleçam. Também nos diz que as personas são definidas pelosobjetivos delas e os objetivos são definidos pelas personas deles. Isso significa que ambossão descobertos da mesma forma e concomitantemente durante o processo sucessivo deexploração do problema.


Cooper (2004) tem o entendimento claro que o alvo de um projeto de design ésatisfazer os objetivos das personas. Isso é importante porque, segundo ele, a maioriados produtos de softwares que vemos são criados baseados em falsos objetivos – ou seja,objetivos não das personas, mas da equipe de desenvolvimento do software, as vezes atécom o intuito de facilitar o desenvolvimento (aspectos técnicos).

Já especificamente quanto a objetivos, Cooper (2004) nos diz que objetivos nãosão a mesma coisa que tarefas. Porque um objetivo é uma condição final, enquanto umatarefa é um processo intermediário necessário para atingir o objetivo, deste modo nãodevemos confundir objetivos com tarefas. O melhor caminho para entender essa diferença,diz ele, é que tarefas mudam quando a tecnologia muda, mas objetivos têm a propriedadede permanecerem bastante estáveis.

43

3 TRABALHOS RELACIONADOS

Neste capítulo apresentaremos trabalhos já realizados por outros autores que tratamde problemas semelhantes a este. Estes trabalhos foram identificados de três maneiras:a primeira foi a partir de pesquisas diretas às bibliotecas ACM Digital, SpringerLink eIEEE Xplore, etc.; a segunda foi através de referências feitas por estudos que compõemnosso arcabouço referencial e, por último, aqueles trabalhos aos quais fomos apresentadosa partir de chamadas públicas de defesa feitas pelo Centro de Informática da UniversidadeFederal de Pernambuco (UFPE).

Por fins didáticos, os dividimos em duas categorias: aqueles que tratam da integraçãoentre DT e ES de modo geral, por isso estão abordados resumidamente em um único tópicoe os que apresentam características referentes ao i* ou práticas criativas complacentes como nosso método, os quais estão abordados detalhadamente em tópicos individuais.

Do que veremos adiante podemos perceber que já, há um bom tempo, existemestudos que buscam introduzir práticas do DT na ES, no entanto, as pesquisas que relaci-onam diretamente i* e criatividade são deveras recentes e rudimentares. Mais importanteainda, percebemos o caráter vanguardista do nosso trabalho ao relacionar diretamente aspráticas do DT à construção de modelos i*.

3.1 Uso do Design Thinking para concepção de softwares criativosA maioria das pesquisas que buscam correlacionar DT e ES o faz por proposições

de processos de desenvolvimento de software ou engenharia de requisitos. Acreditamos queesses trabalhos muito acrescentaram para a construção de softwares inovadores. Apesar denão ser este o objetivo deste trabalho, essas integrações muito tem a nos mostrar sobrequais pontos do DT intersectam a ES como um todo.

Diante disto, abaixo descrevemos brevemente alguns estudos deste contexto quedesempenharam papel importante para nosso entendimento e consequente definição dométodo proposto.

Seguindo uma ordem cronológica, atentamos para o processo proposto por Hilden-brand e Meyer (2012), o qual tem a peculiaridade de alinhar o lean thinking com a filosofiade desenvolvimento ágil. Segundo os autores isso ajuda no desenvolvimento correto doproduto, enquanto que o DT incorpora o viés da inovação. Desta forma, suportam asatividades metodológicas comunicação, planejamento, modelagem, construção e entrega daES.

Seguidamente, Nordstrom Labs (2012) integrou o lean startup, DT e metodologia

Capítulo 3. Trabalhos relacionados 44

de desenvolvimento ágil. Podemos dizer que o principal diferencial em relação ao modelode Hildenbrand e Meyer (2012) é o fato deste suportar todo o ciclo de vida do produto, ouseja, o acompanha em fase de produção a fim de manter a inovação ante as mudanças demercado e tecnologia, por isso concluímos que suporta todas as atividades metodológicasda ES.

Já Steinert et al. (2012) e Steinert e Hirschfeld (2012) enveredaram por um caminhoparalelo, de modo que buscaram aplicar os princípios do DT como ferramenta paracontribuir na atividade técnica programação. Para os autores, o pensamento criativo deveperpassar todas as etapas da construção do software, incluindo atividades técnicas. Paraeles a atividade de codificar também requer resolução criativa de problemas, por exemplo:como implementar rotinas de processamento pesado sem deixar o sistema muito lento parao usuário?

Posteriormente Souza (2014) desenvolveu um processo pensado para ser aplicado nocontexto de Ambientes Virtuais de Aprendizagem Móvel (AVAM) – mas que posteriormentea própria autora reconheceu a possibilidade do uso genérico. Este processo objetiva suportara atividade metodológica comunicação. Ele está subdividido em três subprocessos – imersão,ideação e prototipação – e é apoiado por outras ferramentas para, por exemplo, analisaras ideias levantadas (NVivo). Ao que entendemos, os três subprocessos são executadossequencialmente, não havendo iteração entre eles e se limitando a suportar a fase deelicitação de requisitos.

Quanto ao Häger et al. (2015), eles unem o DT com o framework de desenvolvimentoágil Scrum. Ademais, sugerem que o time de desenvolvimento alterne entre modos, ondeno Design Thinking Mode a ênfase está nas atividades do DT, no Fully Integrated Modeas atividades de desenvolvimento de software são que ganham notoriedade e no InitialDevelopment Mode o time está alternando entre os dois anteriores. Os autores alinham afilosofia do Scrum a do DT intrinsecamente, definindo pré-requisitos, regras, entradas esaídas. O DT@Scrum suporta as atividades metodológicas comunicação, planejamento,modelagem, construção e entrega da ES.

Paula (2015) foi, cronologicamente, o último processo proposto. Dele podemos dizerque é uma adaptação dos processos definidos por Nordstrom Labs (2012) e Hildenbrande Meyer (2012), com a diferença de haver um ponto de fuga (pivot) mesmo quando ofluxo do processo já estiver na atividade metodológica construção. É importante notarque, assim como Nordstrom Labs (2012), este processo suporta todo o ciclo de vida doproduto. Outra característica importante é que este processo também foi pensado paraauxiliar no ensino sistematizado de inovação (caráter pedagógico).


3.2 Integração de Design Thinking e técnicas de criatividade naelicitação de requisitosO trabalho desenvolvido por Valença (2016) define um processo de software que

integra técnicas de criatividade e DT. Esse processo, denominado Creadtivity, foi definidorespeitando estritamente os estágios do DT, de modo que cada estágio equivale a umsubprocesso, são eles: Inspiração, Ideação e Implementação.

A Figura 7 apresenta os subprocessos do Creadtivity. Inicialmente Valença (2016)assumiu os estágios do DT propostos por Brown (2008), em seguida cada estágio foidefinido como um subprocesso, os quais possuem atividades criativas distintas. A faseInspiração engloba parcialmente as fases de Ideação e Implementação, o que significa quea qualquer momento a equipe pode voltar à exploração do problema proposto.

Figura 7 – Subprocessos do Creadtivity

Fonte: (VALENÇA, 2016)


O objetivo deste processo é ajudar a equipe de software a descobrir as necessidadesdos stakeholders e, então, analisar e propor, sob pontos de vista diversos, diferentessoluções criativas. Segundo Valença (2016), o objetivo não é substituir processos desoftwares tradicionais, ou mesmo ágeis, mas sim complementá-los, a fim de promover opensamento criativo e a inovação com foco no usuário.

Nosso destaque para este trabalho se deve ao fato de Valença (2016) ter realizadoum mapeamento, sob a ótica do DT, entre técnicas de criatividade e atividades dedesenvolvimento de software. Para nós, este é um passo inicial para auxiliar os engenheirosde requisitos na condução do nosso método no tocante a aplicação de técnicas criativas.O mapeamento proposto pelo Creadtivity distribui as técnicas de criatividade de acordocom as respectivas indicações delas para as atividades criativas Levantar informações,Identificar e organizar insights, Levantar ideias e Testar protótipo.

A atividade Levantar informações busca entender o ambiente e o contexto doproblema, levantar informações e explorar possibilidades. Quanto a Identificar e organizarinsights, ela oferece suporte para identificar, comparar e selecionar insights com potenciaisinovadores dentre as necessidades dos usuários levantadas. Posteriormente, a atividadeLevantar ideias auxilia na geração de ideias criativas que solucionem os insights selecionadose , por fim, a atividade Testar protótipo objetiva testar e validar juntos aos usuários osprotótipos produzidos para as soluções contempladas pela equipe para o problema.

Na Tabela 3 consta o resumo do mapeamento feito por Valença (2016), de modoque para cada técnica criativa há a indicação das atividades para as quais ela é propícia.

Tabela 3 – Resumo do mapeamento das técnicas de criatividade no Creadtivity

Atividade

Nome da técnica LevantarInformações

Identificare OrganizarInsights

LevantarIdeias

TestarProtótipo

01 Apreciação

02 Cinco Porquês

03 Técnica de Dali

04 Brainwriting

05 Cinética

06 Reverse Brainstorming

07 Método 635

08 Discussão 66

09 Exame de Fronteira

10 Rolestorming

11 Storm Rice

12 Cartoon Story Board


Tabela 3 – continuação da página anteriorAtividade



LevantarIdeias

TestarProtótipo

13 Free Association

14 Esculturas

15 SCAMPER

16 Reformulando a Matriz

17 Clarificação

18 Grid de Ideias

19 Starbusting

20 Seis Chapéus

21 False Faces

22 Ideabox

23 Revelação Progressiva

24 Frutas Futuras

25 Lista de Atributos

26 Círculo de Oportunidade

27 Ideatoons

28 Clever Trevor

29 Murder Board

30 Search Conference

31 Reciprocal Mode

32 Provocação

33 TRIZ

34 Relational Words

35 Exageração

36 Gap Analysis

37 Ideação Heurística

38 Talking Pictures

39 Synectics

40 Super-Hero

41 Story Writing

42 Similaridades e Diferenças

43 Bulletproof

44 Greetings Cards

45 Anonymous Voting

46 Mapas Mentais


Tabela 3 – continuação da página anteriorAtividade



LevantarIdeias

TestarProtótipo

47 Diagrama de Ishikawa

48 Concept Fan

49 Cherry Split

50 Técnica 7x7

51 Biônica

52 Técnica de Escada

53 Técnica de Kneper e Tragoe

54 Simplex

55 Hall da Fama

56 Think Bubbles

57 Excursão

58 S.O.D.A.

59 Focus Group

60 Técnica NAF

61 Personas

62 EPMCreate

Fonte: (VALENÇA, 2016)

3.3 Uma ferramenta para integrar modelagem i* e técnicas criati-vasHorkoff, Maiden e Lockerbie (2015) haviam apontado o início de um trabalho

que buscava criar uma ferramenta para integrar técnicas de criatividade com modelagemorientada a objetivos. Apesar de Horkoff, Maiden e Lockerbie (2015) não terem apresentadoà época a ferramenta, nossas pesquisas nos levaram a uma versão teste do resultado dotrabalho referido, a qual pode ser encontrada em Horkoff (2016). A Figura 8 nos apresentaa interface dessa ferramenta, chamada Creative Leaf, a qual é totalmente desenvolvidapara rodar na web.

Apesar de não termos encontrado publicações científicas referentes ao CreativeLeaf e por este motivo não termos muitas informações sobre ela, Horkoff (2016) indicamais uma contribuição para os domínios criatividade e modelagem orientada a objetivos.

De acordo com Horkoff (2016), a ferramenta adicionou um elemento Ideia, que


representa um resultado de uma técnica criativa, à notação i*. Trata-se dos retângulosamarelos na Figura 8. De modo geral, a Creative Leaf possui uma listagem de técnicasde criatividade que podem ser executadas na própria ferramenta e, então, os resultadosdessas técnicas são adicionados como elementos Ideia ao modelo i* em tela. Após isto, ousuário pode classificar as ideias como rejeitadas, aceitáveis ou necessárias.

Capítulo

3.Trabalhos

relacionados50

Figura 8 – Captura de tela do Creative Leaf

Fonte: (CABOT, 2016)


3.4 Uso do i* para suportar a Engenharia de Requisitos criativaHorkoff e Maiden (2015a) propuseram um método para guiar os usuários, a fim de

terem modelos i* como entrada ou saída de atividades criativas. De mameira geral, as ativi-dades criativas continuam a sequência deixada pelas mesmas em sessões anteriores, de modoque os autores indicam iniciar com atividades de preparação – que propiciem o pensamentocriativo – e posteriormente prosseguir nas atividades de criatividade transformacional,exploratória e combinacional.

Horkoff e Maiden (2015a) alertam que para conduzir as sessões criativas é precisoque o facilitador tenha domínio das técnicas, para isso os autores sugerem a utilização deferramentas que ajudem na seleção e aplicação delas, por exemplo EU-funded COLLAGE(2015a) e EU-funded COLLAGE (2015b). Pensando nessa facilitação, os autores definiramduas técnicas que devem ser usadas nas atividades de preparação, de modo que a derivaçãopara modelos i* aconteça linear e gradativamente. Ou seja, através de um processo iterativoque alterna entre modelagem e atividades criativas, os modelos i* são definidos e podemser usados para especificação dos requisitos e futura implementação.

Para exemplificar o uso do método, os autores tomaram o caso de compra de ticketspara um trem que partirá do aeroporto de Londres, com possibilidades de vários serviçose rotas.

Para produzir um modelo SD, o método se inicia com a construção de um diagramade contexto para o sistema. Neste diagrama os atores são dispostos em círculos concêntricos,de modo que quanto mais distante do centro, menor é influência deste ator. Na Figura 9,ao centro estão os atores que são parte do core do sistema Quiosque, Tela de informação eo Sistema, na extremidade o Aeroporto.

A partir dai, baseados também em outros experimentos já realizados, Horkoff eMaiden (2015a) nos dizem que os usuários tem dificuldades para iniciar os primeirosmodelos, por isso ressaltam a necessidade deste diagrama intermediário. Os autoresapontam que a criação do diagrama de contexto não é em si uma atividade criativa, massim uma busca pela definição do estado-da-arte do problema. O passo seguinte é ligaratores e rotular essas ligações com informações da relação entres os respectivos atores.

Então, para a transformação em modelo SD os passos a seguir devem ser executados:a) criar um ator ator genérico para os círculos que contenham mais de um ator e ligar numarelação “is-part-of” este ator genérico àqueles específicos correlacionados; b) transformaras informações contextuais em elemento de dependência entre os atores, como está postona Figura 9.


Figura 9 – Transformação do Diagrama de Contexto para modelo SD

Fonte: (HORKOFF; MAIDEN, 2015a)

Este diagrama de contexto, apesar de não ser atividade essencialmente criativa,desde cedo evidencia possibilidades de criatividade transformacional, senão vejamos: o fatode mudar os atores de lugar redefine completamente as regras e prioridades que regem oproblema. por exemplo, se o aeroporto fosse posto como ator mais influente nesse contexto,certamente a solução mudaria radicalmente.

Já para a construção do modelo SR, a proposta dos autores é a construção de umCustomer Journey Map. Este mapeamento objetiva detalhar os passos que os usuáriosexecutam para concluir uma ação (tarefa). O mapa é disposto em forma de raias querepresentam os atores e de ações que se localizam na raia do respectivo ator e se ligamsequencialmente uma a outra.

Na Figura 10, Horkoff e Maiden (2015a) exemplificam um Customer Journey Mappara a ação do ator Customer comprar um ticket usando o quiosque. Como pode serobservado na mesma figura, para a transformação em modelos SR é preciso: a) expandir afronteira do ator em questão; b) criar a tarefa que representa o mapa, no caso comprar umticket usando o quiosque; c) criar uma sub-tarefa dentro da fronteira do ator para cadapasso do mapa; d) criar um link de decomposição entre as sub-tarefas e a tarefa principal;e) criar relação de dependência das sub-tarefas com os respectivos atores nas raias dosquais foram definidas.


Figura 10 – Transformação do Customer Journey Map para modelo SR

Fonte: (HORKOFF; MAIDEN, 2015a)

Os autores alertam para a maior complexidade existente na transformação emmodelo SR, dada as várias possibilidades de construção permitidas pelo i*. Desta maneiradeve haver um trabalho de modelagem a fim de ajustar os modelos para se tornaremmais coerentes semanticamente. Por exemplo, na Figura 10 o ticket está expresso comoator, mas ao analisar o modelo resultante, notamos que a melhor representação seriacomo um recurso. Essas mudanças pós-transformação devem sempre ser validadas com osstakeholders. Também junto aos stakeholders devem ser resolvidas as diferenças existentesentre os modelos SD e SR, de modo os atores semelhantes sejam unificados e os outrossejam analisados a fim de haver consistência entre os modelos.

Por fim, os modelos podem ser melhorados – iterando sobre atividades de modelageme atividades criativas – a partir de técnicas de criatividade exploratória, como por exemplopor que, por que, por que?, quem, quem, quem?, etc.

3.5 Considerações finaisÉ notório que as pesquisas que objetivam integrar diretamente modelagem orientada

a objetivos e criatividade são poucas e ainda iniciais, por este motivo a maior parte dostrabalhos apresentados neste capítulo nos serviu como referência ou apoio para a elaboraçãodo nosso trabalho, mas não como uma alternativa ao método que estamos propondo. Jáquanto a integração entre ER e DT, percebemos que já há bastante trabalhos que buscamfazê-la, no entanto, também não tratam de estabelecer nenhum vínculo entre DT emodelagem orientada a objetivos.

Necessariamente, isto ratifica a importância da nossa contribuição científica comeste trabalho, mas também indica que mais estudos são necessários para que haja uma


consolidação do conhecimento sobre integração entre criatividade e modelagem orientadaa objetivos.

55

4 METODOLOGIA DE PESQUISA

Este estudo está fundamentado no método científico pesquisa-ação, que pode serentendido como um tipo de pesquisa empírica que leva em consideração os aspectos erelações sociais, condicionada a uma associação estreita, desde a concepção à realização,com uma ação ou resolução de um problema coletivo, onde os pesquisados e o pesquisadorestão envolvidos de modo cooperativo ou participativo (THIOLLENT, 2011).

Quanto a relação entre o pesquisador e pesquisados, Thiollent (2011) segue esclare-cendo que o pesquisador tem um papel ativo no equacionamento dos problemas encontrados,assim como na análise e acompanhamento das ações derivadas do problema. No entanto,não só o envolvimento do pesquisador determina a especificidade da pesquisa-ação, elatambém consiste na organização da investigação em torno da concepção, das análises dasações planejadas e do curso de execução delas.

Nossa escolha pelo método certamente está justificada pelo trecho que segue:

Em geral, a ideia de pesquisa-ação encontra um contexto favorável quandoos pesquisadores não querem limitar suas investigações aos aspectos aca-dêmicos e burocráticos da maioria das pesquisas convencionais. Querempesquisas nas quais as pessoas implicadas tenham algo a “dizer” e a“fazer”. Não se trata de simples levantamento de dados ou de relatóriosa serem arquivados. Com a pesquisa-ação os pesquisadores pretendemdesempenhar um papel ativo na própria realidade dos fatos observados.(THIOLLENT, 2011, pág. 22, grifo do autor)

É necessário destacar, também, que a pesquisa-ação pode ser empregada visandoobjetivos distintos, que pode ser o objetivo prático, o qual visa contribuir para um melhorequacionamento do problema pesquisado, para ajudar o ator na sua atividade transfor-madora da situação. Assim como pode objetivar o conhecimento, no qual busca obterinformações difíceis de serem resgatadas por outras abordagens e agregar conhecimento dasituação. Certamente, nossa pesquisa está enquadrada nesta última proposição, sobre aqual, Thiollent (2011, pág. 25) discorre:

Finalmente, existe uma outra situação, quando o objetivo da pesquisa-ação é principalmente voltado para a produção de conhecimento quenão seja útil apenas para a coletividade considerada na investigaçãolocal. Trata-se de um conhecimento a ser cotejado com outros estudos esuscetível de parciais generalizações no estudo de problemas sociológicos,educacionais, ou outros, de maior alcance. A ênfase pode ser dada a umdos três aspectos: resolução de problemas, tomada de consciência ouprodução de conhecimento.

Capítulo 4. Metodologia de pesquisa 56

A pesquisa-ação foi concebida e é bastante utilizada nas ciências sociais, mas nãose limita a este contexto, contrariamente hoje é aplicada fortemente na área a qual nospropomos, vejamos o que diz Gibertoni (2012, pág. 4):

Outro aspecto relevante é que se trata de um método de pesquisa quepode contribuir amplamente nas pesquisas realizadas com foco em ino-vação, sobretudo porque são de grande utilidade quando se pretendedesenvolver o conhecimento por meio da interação entre pesquisadore elemento pesquisado. Este método permite a alteração de rumo dapesquisa, haja vista que as ideias a serem pesquisadas inicialmente podemmudar ao longo do processo. A pesquisa-ação possibilita ainda estendero experimento por um período de tempo maior, o que facilita o trata-mento de dados qualitativos, permitindo a criação de novas ideias emsua execução.

A seguir, descreveremos sistematicamente o planejamento e a execução do estudoque realizamos, certamente feitos com a atenção necessária para obedecer o protocoloestabelecido pela pesquisa-ação.

4.1 Planejamento

4.1.1 Concepção

Nossa pesquisa surgiu através da necessidade de observar e experimentar como asdiversas práticas e conceitos do DT poderiam ser estruturados a ponto de conduzir osstakeholders, mesmo aqueles que não conheçam o framework i*, a construir modelos i*que refletissem os resultados criativos obtidos pelas práticas criativas.

De maneira geral, isto resume nossa intenção ao executar a pesquisa-ação: utilizar-se da literatura atual para planejar e executar a pesquisa com o objetivo de produzirmais conhecimento que seja cotejado e generalizado, a fim de definir, considerando ascontribuições diretas dos pesquisados e suas relações sociais, um método para conduzirequipes à construção de modelos i* criativos a partir da aplicação do DT.

Inspirados por este objetivo, o passo seguinte foi a seleção de um caso (problema),no qual pudéssemos agir para solucioná-lo e inferir o conhecimento desejado.

4.1.2 Amostragem

Nossa busca resultou em um convite, vindo de um grupo de três pessoas, para quetrabalhássemos juntos na concepção de um software. Desta feita, a equipe passou então ater quatro componentes, visto que passou a ser objetivo comum conceber o software. Anós autores, coube-nos também o dever independente de colher conhecimento necessáriopara a construção do nosso método.


Quanto a formação, a equipe era composta de 1 (um) analista da informação, 1 (um)engenheiro da computação e 1 (um) cientista da computação, onde todos trabalham na áreade TI, no entanto apenas o engenheiro da computação teve atuação prática nas atividadesde um engenheiro de requisitos. Outro fato importante é que um dos integrantes possuíapouca formação sobre engenharia de requisitos. Por fim, nenhum deles teve qualquercontato nem conhecimento sobre o framework i* e DT. Neste cenário, o autor pesquisadorassumiu também o pepel de engenheiro de requisitos e facilitador do processo de DT.

4.1.3 Definição do tema

Para a condução da pesquisa, foi estritamente necessário que definíssemos um temaque delineasse as fronteiras do problema. Diante disto, a equipe, ciente da pesquisa emcurso, acordou o que segue: Experimentar e analisar práticas e conceitos do Design Thinkingque contribuam para a construção colaborativa e sistemática de modelos i* criativos numaequipe composta por usuários experientes e não experientes em modelagem i*.

4.1.4 Ameaças à validade interna

Quanto às ameaças a validade interna e as ações correspondentes para evitá-las,temos:

• O tamanho da equipe pode não ser suficiente para aplicar o processo deDT: A equipe composta por quatro pessoas atende os requisitos do processo de DT,inclusive, como dito no Capítulo 2, equipes pequenas são bastante eficientes paraaplicar técnicas criativas e colaborar entre si. Além disso, entendemos que quatrointegrantes com poder de decisão para a concepção do sistema não difere da realidadede outros projetos que, em média, não possuem um número elevados de pessoas queatuam diretamente nas atividades da engenharia de requisitos.

• O fato de todos os integrantes “pesquisados” da equipe não conheceremo i* e DT, a percepção de integrantes técnicos sobre o método pode estarlimitada a visão do pesquisador: Para mitigar esta ameaça, tomamos a decisãode reservar tempo para (1) um integrante aprender sobre o framework i* e o DT; oengenheiro da computação foi o membro escolhido pelo interesse maior em inovação,além de maior experiência profissional na industria de TI.

• O problema apresentado pela equipe pode ser simples a ponto de não su-portar a concepção do método: Tratava-se de criar um software para candidatosa vagas em processos seletivos se prepararem para a prova. No entanto, o principaldiferencial que a equipe buscava era conceber algo inovador, que fosse diferente dastantas opções que já havia no mercado e que, portanto, atraísse os usuários dos


concorrentes pelo valor que o software concebido pudesse agregar. Foi a partir devárias discussões sobre o que consistia o produto que definimos o briefing para ométodo criativo: Como um software pode ajudar candidatos a alcançarem o objetivode serem aprovados num processo seletivo de provas? Como pode se observar peladefinição do briefing, estava claro que trabalharíamos para que objetivos fossematingidos, seja dos candidatos, seja da equipe, seja dos outros stakeholders queforam posteriormente descobertos e contemplados. Portanto, o problema atendeu asexigências de vislumbrar criatividade e orientação o objetivos.

4.1.5 Hipóteses assumidas

De antemão, transcrevemos abaixo o entendimento sobre hipóteses para umapesquisa-ação:

Pensamos que é perfeitamente viável a flexibilização do raciocínio hipo-tético, de acordo com a qual a hipótese é uma suposição criativa que écapaz de nortear a pesquisa inclusive nos seus aspectos qualitativos. Ashipóteses (ou diretrizes) qualitativas orientam, em particular, a busca deinformação pertinente e as argumentações necessárias para aumentar (oudiminuir) o grau de certeza que podemos atribuir a elas. [...] A formulaçãode hipóteses (ou de quase-hipóteses) permite ao pesquisador organizar oraciocínio estabelecendo “pontes” entre as ideias gerais e as comprovaçõespor meio da observação concreta. (THIOLLENT, 2011, pág. 42–43, grifodo autor)

Quanto às hipóteses assumidas para este estudo, temos:

• As ferramentas para construção dos modelos i* devem construí-los progressivamentee de forma transparente.

• Usuários não técnicos devem se limitar a trabalhar em cima de abstrações de fácilaprendizagem.

• É dever do engenheiro de requisitos fazer adaptações no modelo gerado a fim decorrigir incoerências semânticas e sintáticas.

• Sob nenhuma hipótese o pensamento criativo deve ser tolhido pela burocracia deatividades de modelagem.

• Todas as decisões que alterem a prioridade ou forma nas quais as ideias foramconcebidas, mesmo aquelas feitas pelo engenheiro para refinar o modelo, devem serrevalidadas perante a equipe no nível de abstração do processo criativo.


4.2 ExecuçãoA pesquisa-ação aconteceu por um período de 1 (um) mês e meio. Durante este

tempo ocorreram 18 (dezoito) reuniões com o máximo de 1 (uma) hora de duração, todasno horário de 12:30 às 13:30h, sempre nas segundas, terças e quartas-feiras na associaçãode funcionários, ou na sala de treinamento, da empresa dos referidos participantes. Aoiniciar cada encontro, os participantes debatiam rapidamente a possibilidade de continuaro processo criativo ou iniciar um seminário da pesquisa-ação para avaliações e tomada dedecisões. Obviamente, a maioria dos encontros foram de sessões criativas, mesmo porquenessas sessões é que aconteciam a prática e experimentações necessárias a definição dométodo proposto.

Nos seminários, os participantes eram ouvidos e, então, se iniciava um debate sobreas pŕaticas inseridas pelo método. Nessas discussões procuramos analisar a consonânciadas ações com as hipóteses levantadas no planejamento, assim como controlar possíveisameaças a validade da pesquisa. Além disso, as dificuldades encontradas em executar ométodo eram colaborativamente expostas e analisadas, consequentemente gerando açõespara ajuste do método.

Outra preocupação presente nos seminários foi o cuidado de que a opinião dopesquisador não assumisse um papel absolutista sobre as críticas dos participantes. Con-trariamente, qualquer opinião foi ponderada e aquelas que estiveram bem fundamentadasna literatura foram acolhidas e discutidas. Essa preocupação, antes de ser pertinente àequipe, é essencial para a validade da pesquisa-ação, visto que nesse tipo de pesquisa oparticipante tem papel ativo.

Enquanto responsabilidade única dos pesquisadores, nos coube observar nas práticasdo processo criativo as fronteiras que cada papel deveria atingir, assim como as responsa-bilidades, para que houvesse fluidez sem ferir as hipóteses da pesquisa. Também nos coubeagir como facilitador das práticas criativas, de acordo com o que está fundamentado noCapítulo 2.

4.3 ResultadosAo fim da execução, consideramos o conhecimento obtido com a pesquisa-ação

satisfatório, visto termos logrado êxito na definição do método e também conseguidoespecificar a contento os modelos para o produto desejado pela equipe.

4.3.1 O produto

Preservados os direitos reservados à equipe sobre a definição e os modelos doproduto, vale ressaltar alguns aspectos que evidenciam o caráter inovador da solução.


Contrariamente aos produtos existentes no mercado:

• O produto será entregue como uma plataforma de aprendizado colaborativo;

• A solução abre mão de proteger o conteúdo sob fortes requisitos de segurança contradownloads, contrariamente oferece um plano de negócio no qual o usuário contrataum serviço e possui acesso ilimitado a qualquer conteúdo da plataforma, inclusiveacesso offline;

• Os usuários da plataforma não possuem direito de privacidade sobre os conteúdosgerados, de modo que todas as atividades registradas pela plataforma podem serusadas para aprendizado dos demais integrantes;

• Técnicas de estudo já difundidas entre os candidatos e reportadas como eficientespor estudos científicos estarão presentes como ferramentas e práticas integradas àplataforma;

• A plataforma deve estar acessível também por dispositivos móveis;

• Todos as vídeo-aulas serão produzidas sob um algoritmo que possibilita a interaçãoentre o vídeo e os outros recursos da plataforma. Por exemplo, uma vídeo-aulapode ser programaticamente interrompida em certo momento para que o candidatoresponda uma lista de exercício automaticamente referenciada, ou mesmo ao longoda vídeo-aula flashcards programados podem ser apresentados para o candidato, oqual pode ou não adicioná-lo a sua coleção – semelhante ao que se vê em Merkley(2012);

• A plataforma receberá uma engine de gamificação a fim de incentivar o cumprimentodas metas de estudo definidas pelos candidatos.

Outro fato que merece destaque é que o método ao prescrever um estágio inicial depesquisa, como será detalhado no Capítulo 5, levou os participantes a domínios bastanteopostos ao dos produtos concorrentes. Haja vista a solução ter enveredado para umaunião de conceitos pedagógicos, técnicas de memorização, técnicas de motivação para oscandidatos e plano de negócio viável a todos. Podemos, então, afirmar que este passoinicial de pesquisa preparou a equipe para as 3 (três) possibilidades da criatividade:exploratória, combinacional e transformacional. Mas, com maior ênfase, foi capaz depromover efetivamente a criatividade transformacional, quando mudou as regras existentesao priorizar o ator Candidato em função dos demais.

A título de exemplo, deixamos no Anexo A uma das primeiras prototipaçõesrealizadas durante a execução da pesquisa-ação. Assim como constam no Anexo B eAnexo C alguns modelos i* também gerados pela equipe.


4.4 Considerações finaisQuanto ao método sugerido como proposta desta dissertação, o Capítulo 5 tratará

de apresentá-lo em detalhes.

De modo geral, inicialmente tínhamos dois domínios distintos: o i* e o DT. O DTnos apresentava ferramentas que eram destinadas ao estimulo da criatividade em geral,independente de um domínio específico; enquanto o i* exigia que qualquer integração fossefeita com o objetivo exclusivo de levantar requisitos sob a forma orientada a objetivos.

Então, construímos o entendimento de que era necessário uma nova ferramentabaseada no DT especificamente para o nosso método, a qual seria a junção entre os doisuniversos. Desta forma, concebemos a ferramenta, da qual falaremos adiante, chamadaquadro de modelagem. O quadro de modelagem foi concebido para que a equipe pudessepadronizar a representação dos requisitos criativos elicitados na forma orientada a objetivos.

O desafio posterior foi conceber um quadro de modelagem que não desfavorecesseo pensamento criativo e que propiciasse a colaboração. Neste momento buscamos respaldoem Horkoff (2015), haja vista eles terem indicado, como foi exposto no Capítulo 2, umaabstração do i* ideal para usuário iniciantes e não técnicos.

Em seguida, trabalhamos com o objetivo de adaptar essa abstração à realidade daspráticas do DT, para que esta nova ferramenta pudesse ser usada pela equipe criativa deforma integrada às outras já existentes. Esta adaptação sofreu várias mudanças ao longodo tempo, de acordo com as avaliações feitas pela equipe e a percepção dos pesquisadoressobre a ação. A fim de exemplificar a evolução da ferramenta quadro de modelagem, constano Apêndice D a proposta inicial, a qual nada se assemelha ao resultado após modificaçõesfeitas pela equipe durante a pesquisa-ação.

Como preconiza a pesquisa-ação, a equipe forneceu feedback qualitativo para opesquisador durante a aplicação e, explicitamente, nas reuniões marcadas para discutirexclusivamente as ações tomadas e as influências nos resultados. Para termos ideia, àmedida que o modelo crescia no quadro de modelagem, novas adaptações eram necessáriaspara melhor uso da ferramenta e melhor representação do modelo. Assim, muitos testesaconteceram até a definição atual do quadro e para que a conversão para modelos i* fossemais fluida.

É importante destacar que a ferramenta integradora, quadro de modelagem, per-mitiu que naturalmente as descobertas da equipe rumassem para a forma orientada aobjetivos, o que não estava claro antes da concepção da ferramenta.

De modo geral, a equipe analisou a necessidade de adaptação e criação de ferra-mentas do DT para que contribuíssem para a construção de modelos i*. Isso tudo permitiua definição do método, como consta no Capítulo 5.

62

5 O MÉTODO: DO DESIGN THINKINGAOS MODELOS I*

Neste capítulo definiremos o método proposto como resultado da nossa pesquisa.O objetivo deste método é conduzir os stakeholders através da aplicação do DT paraconstrução colaborativa de modelos i* que representem os resultados criativos. Outroponto a se evidenciar é que nós buscamos reduzir a complexidade da modelagem i* atravésda abstração de conceitos complexos do framework e da união com práticas já consagradasnos processos de DT.

Este método busca auxiliar diretamente a ER na atividade de elicitação e análise,no entanto, oferece apoio indireto para as atividades de especificação e validação. Via deregra, este método foi concebido para projetos de softwares que objetivam aplicar ERcriativa orientada a objetivos.

Neste capítulo serão apresentados os conceitos e práticas referentes a este método,já no Capítulo 6 apresentaremos de forma didática como aplicá-lo em um projeto.

5.1 Modelo abstratoPara fins didáticos, o primeiro conceito a ser apresentado é o que denominamos

modelo abstrato. O modelo abstrato é, primeiramente, uma abstração dos elementos pre-sentes no framework i*. Esta abstração foi definida para que todos os stakeholders, mesmoaqueles que não conheçam tecnicamente o framework i*, possam participar efetivamentedo processo de representação dos requisitos criativos na forma orientada a objetivos.

Este modelo está de acordo com experimentos realizados por Horkoff (2015),apresentado na Figura 5, os quais buscaram identificar as dificuldades que a complexanotação do i* impunha aos usuários iniciantes. No entanto, para torná-lo comum às práticasdos processos baseados no DT, desconsideramos a representação gráfica (sintática), deforma que essa representação fosse feita com uso de post-its, o que oferece mais facilidade,liberdade e dinamismo à equipe para trabalhar com o modelo abstrato. Também nãofizemos distinção entre os elementos goal e soft-goal. Nosso esforço se deu para que novosusuários consigam, num primeiro contato, entender o que cada elemento significa.

Todos os stakeholders deverão modelar, durante todas os estágios do método,baseados nesta abstração. Durante os estágios do método não deverá haver, portanto, atosde comparação entre elementos do i* e do modelo abstrato. A única ressalva existente épara os engenheiros de requisitos, sobre a qual falaremos mais a frente.

Capítulo 5. O método: do Design Thinking aos modelos i* 63

Quanto a semântica, uma regra geral atribui coerência ao modelo: objetivos seligam a personas e tarefas; tarefas se ligam tanto a objetivos quanto a tarefas; e recursosse ligam a tarefas.

5.1.1 Notação abstrata

Como exposto na Tabela 4, a notação completa é constituída apenas de quatroelementos, são eles: Persona, Objetivo, Tarefa e Recurso.

Tabela 4 – Notação completa do modelo abstrato

Elemento Descrição

Persona Representação abstrata personificada de um grupo de indivíduos cominteresses comuns no domínio do problema.

Objetivo Intenção, desejo ou meta atribuídos a uma persona.Tarefa Ação necessária para atingir um objetivo.

RecursoMaterial (físico ou lógico) necessário para executar uma tarefa. Éimportante notar que os resultados providos por interação com softwaresalheios ao que está sendo modelado são considerados recursos.

Fonte: (AUTOR, 2016)

A Persona é uma prática bastante difundida no DT, de modo geral, é a representaçãode grupos de indivíduos com mesmos comportamentos, características, posição social ouposição ideológica. De certa forma, a persona faz as vezes dos atores no i*, porém elasse limitam a representar indivíduos importantes ao sistema e que foram descobertosao longo do processo criativo. Fica salientado, então, que personas não representamsistemas computacionais, como é feito por alguns atores no i*. Mesmo tendo dito isto,consideramos que softwares com características individuais, inteligências artificiais, podemser coerentemente representados por uma persona. Por fim, o modelo abstrato permiteque premissas sejam atribuídas às personas, como estará detalhado mais a frente.

Já Objetivo é uma intenção, desejo ou meta que se possa atribuir às personas.Com outras palavras, objetivos são as razões pelas quais as personas executam tarefas. Épossível que se relacione diretamente os conceitos de objetivos do modelo abstrato aos doi*, acrescentando apenas que o modelo abstrato não faz ramificações de tipos de objetivos.Desta forma, um softgoal é representado da mesma forma que um goal.

Quanto a Tarefa, ela é a representação de uma ação necessária para atingir umobjetivo. Quando ela é complexa a ponto de requerer várias ações descendentes ou abstrataa ponto de possibilitar vários caminhos para executá-la, é necessário que esta tarefa sejadecomposta em outras tarefas ou objetivos filhos, os quais deverão estar ligados àquelasque os originaram.


Por sua vez, Recurso é definido como qualquer material, lógico ou físico, que sejanecessário para executar uma tarefa. Assim como no i*, não há que se definir como umrecurso será provido, no entanto, é de bom grado, quando sabido, especificar a fonte que oprover.

Todos os elementos do modelo abstrato não possuem forma predefinida de repre-sentação. Isto é feito da forma que for conveniente à equipe, atentando para manter-se aunidade representacional para cada elemento. Como será exposto adiante, este métodoprescreve defini-los textualmente em post-its de cores pré-acordadas para cada elemento.

5.2 PapéisConstruir software requer várias atividades técnicas de profissionais especializados,

por isso, a inclusão de stakeholders não técnicos deve ser bem delineada. Pensando nisto,este método trata de definir papéis, os quais possuem atribuições específicas que delimitamas atividades nas quais podem contribuir para a construção dos modelos i* criativos.

No tocante a este método, é essencial que esteja definido quem tratará de atividadestécnicas inerentes a ER e quem participará das atividades criativas do método. Assim,definimos que há dois papéis distintos: o Design Thinker e o Engenheiro de Requisitos.

5.2.1 Design Thinker

O design thinker é todo stakeholder que que segue os princípios do DT. Para atingiro pensamento criativo em toda a equipe, é preciso que todos os envolvidos assumam estepapel. Para ele é exigida apenas a participação efetiva no processo criativo, não sendonecessário conhecimentos técnicos inerentes a processos de software. Foi com foco nestepapel que definimos o modelo abstrato, de modo que a complexidade do i* não sejaempecilho para que ele participe efetivamente da construção dos modelos i* criativos.

O dever do design thinker é contribuir colaborativamente para gerar uma soluçãocriativa a partir de seu conhecimento e experiência sobre o domínio do problema.

5.2.2 Engenheiro de Requisitos

Ao engenheiro de requisitos cabe as atribuições técnicas já difundidas nos processosde software. Mas, para este método, cabe também o dever de converter o modelo abstratopara o modelo i*, seguindo as heurísticas que serão apresentadas mais a frente, assimcomo, analisar, solucionar problemas sintáticos e semânticos do modelo i* resultante e,quando necessário, levar à equipe criativa os problemas encontrados para que possam sersolucionados criativa e colaborativamente. No mínimo, a equipe criativa deve contar com 1(um) engenheiro de requisitos, ademais não há limitação de quantidade.


Uma última atribuição é a condução deste método em si. Portanto, o engenheirode requisitos deve trabalhar para manter o pensamento criativo na equipe. Deve conduzira equipe através dos estágios e práticas prescritas neste método, a fim de que a equipeconsiga representar suas ideias criativas através do modelo abstrato. Isso significa quecabe ao engenheiro de requisitos conduzir a equipe para usar as ferramentas e técnicasadequadas para a construção do modelo abstrato.

5.3 FerramentasPara possibilitar e registrar o pensamento criativo da equipe, este método conta

com algumas ferramentas de apoio, das quais algumas tem propósito geral e outras usospontuais. Na prática, é através do uso delas que o modelo é construído colaborativamentepela equipe.

5.3.1 Personas

A importância das personas para nosso método está evidenciada desde o Capítulo 2,quando discorremos sobre o alinhamento entre o DT e o i*, até a presença dela no modeloabstrato. Mas como ferramenta, criamos um modelo de representação de uma persona,presente na Figura 11, no qual é possível fornecer informações que caracterizam as personase definem a importância delas dentro da solução.

Entre os elementos básicos, um card de persona possui espaços reservados paraatribuição de um nome único e representativo para a persona e uma frase de efeito quepossa representar o entendimento dela quanto ao problema em questão. No entanto, osoutros elementos possuem uma relevância maior, visto que agregam valor ou modificamdiretamente o modelo abstrato.

Um dos espaços é reservado às premissas da persona quanto ao problema e àsolução. Isso implica que o conteúdo dele é dinâmico e pode ser modificado a medida quese avança na aplicação do método. Essas premissas serão consideradas pelo engenheirode requisitos quando na conversão do modelo abstrato para o i*, visto que elas estãodiretamente ligadas ao elemento belief do i*.

O outro espaço é reservado para definir um número ascendente de prioridade que asolução deve dar àquela persona, de modo que o número 1 (um) é a persona primária dasolução e, por isto, há o cuidado de que seus objetivos sejam satisfeitos em detrimento dosdemais quando houver conflitos, como preconiza Cooper (2004).

Além disto, a priorização de personas possibilita à equipe a busca pela criatividadetransformacional, visto que, ao mudar as prioridades, a solução certamente deve ser todarepensada, então é possível que daí surja uma quebra de paradigma forte o suficiente para


gerar uma solução inovadora.

A Figura 11 contém o modelo de persona indicado por este método, o qual seráutilizado para representar as personas no quadro de modelagem. É possível encontrá-lo noApêndice C para que possa ser impresso, recortado e usado em aplicações futuras destemétodo.

Figura 11 – Card para uma persona


5.3.2 Quadro de modelagem

O quadro de modelagem é uma ferramenta essencial para a construção colaborativado modelo abstrato. Esta ferramenta foi pensada para que todos os resultados das outrasferramentas possam ser expressos sob as regras desta principal. Ou seja, a equipe devetrabalhar para definir o modelo abstrato, para que, posteriormente, o engenheiro derequisitos possa transformá-lo em modelos i*. Ou seja, esta é a ferramenta que conduz aequipe a pensar de modo orientado a objetivos.

É preciso localizá-lo num “espaço” considerável, de fácil acesso e locomoção, paraque os integrantes da equipe possam interagir com ele. Por isto, apesar do nome, éperfeitamente viável ter-se algo como uma “bancada de modelagem”.

A divisão recomendada para um quadro de modelagem está apresentada na Fi-gura 12. Nesta figura vemos um quadro dividido em duas seções (ilustrativamente marcadas


por letras em vermelho), das quais a seção “A” é o espaço reservado para modelar aspersonas e as possíveis ligações com os outros elementos do modelo abstrato. Já a seção“B” é especialmente reservada a modelar os objetivos, tarefas e recursos do sistema emdesenvolvimento (funções do sistema).

Os tamanhos apresentados para as seções A e B não são definitivos, portantopodem ser ajustados de acordo com a necessidade da equipe. No entanto, observamosque a seção A, a maior entre as duas, requer bastante espaço pelo fato de conter todasas personas do sistema e suas respectivas ligações. Já a seção B, apesar de normalmenteconter maior número de elementos quando comparados aos de uma persona, mostrou-sesuficiente para representar o sistema ao longo da aplicação do método. Também porque emdado momento do método, o engenheiro de requisitos pode decidir deixar apenas algumaspersonas no quadro de modelagem, comumente a persona primária, para trabalhar oselementos delas isoladamente, e isto certamente reflete no número de elementos da seçãoB.

Figura 12 – Modelo da divisão do quadro de modelagem


Buscando atender a dinâmica dos métodos criativos baseados no DT, recomendamosa utilização de post-its para representar os elementos do modelo abstrato. Deste modo, asrelações que estes elementos podem ter uns com os outros são feitas utilizando linhas retas


que os interligam diretamente. Para evitar a poluição visual causada por muitas linhasatravessando o quadro, esta linha pode ser interrompida e rotulada com um identificadore em outra parte do modelo haverá outra linha com o mesmo identificador ligada a umelemento, representando a continuação da linha. Como pode ser visto na Figura 13.

Figura 13 – Ligações entre os elementos no quadro de modelagem


A título de exemplificação, ao início da modelagem, define-se as cores de post-itsreferentes a cada elemento do modelo abstrato e esses são expostos na área de legendado quadro de modelagem (canto inferior direito, vide Figura 14). Então, à medida quea colaboração criativa elenca os elementos, os post-its correspondentes são colados einterligados no quadro de modelagem. Para estar sempre visível, a regra geral de semânticafica transcrita no centro inferior do quadro.


Figura 14 – Legenda no quadro de modelagem


Certamente, a representação da persona é feita com o card de persona, o qualdeve ser colado no quadro de modelagem e, então, ser explorado a fim de descobrir aspremissas, os objetivos, as tarefas e os recursos aos quais está relacionado. A medidaque estes outros elementos vão sendo descobertos, o card de persona deve ser atualizadoconforme a necessidade.

Tanto os post-its quanto o card de persona são dinâmicos e podem ser alteradosou rearranjados dentro do modelo proposto. Outro ponto de destaque é que as linhasrotuladas se dão, também, entre os elementos da seção A (personas) e os da seção B(sistema), de modo a considerarmos um modelo uniforme.

Todos os elementos do modelo abstrato são expressos na forma textual, mas épossível que outras formas de comunicação possam agregar valor à escrita (desenho,ícones, etc.). A título de exemplificação, a Figura 15 demonstra um quadro de modelagempreenchido.


Figura 15 – Quadro de modelagem preenchido


5.3.3 Quadro de ideação

Quanto ao quadro de ideação, trata-se de um quadro sem nenhuma marcaçãoespecial, ou seja, um espaço completamente livre para que os integrantes possam representare construir suas ideias de forma gráfica. Brown (2010) destaca que qualquer método baseadono DT deve prover formas mais representativas de expressar os pensamentos criativos,visto que esta ferramenta serve para o propósito da colaboração e da prototipação rápida.

Portanto, apesar da simplicidade da ferramenta, sabemos que ela desempenha umpapel importantíssimo no entendimento comum do problema e na construção colaborativada solução criativa. Quanto a prototipação, é recomendado que a faça sempre que possível,da forma mais simples possível, mas de modo que possibilite à equipe navegar e decidirentre as opções que se desdobrarão.

5.4 TécnicasEste método não faz qualquer limitação à natureza ou à utilização de técnicas

que buscam fomentar o pensamento criativo. Contrariamente, ratificamos a necessidadedos engenheiros de requisitos buscarem aplicar aquelas que considerem convenientes parao contexto. No entanto, é preciso considerar que os resultados destas técnicas devemconvergir para o quadro de modelagem, haja vista ele ser a ferramenta que garante aabordagem orientada a objetivos do nosso método.

A seguir, discorreremos sobre algumas técnicas já consagradas no DT para ofomento do pensamento criativo (BROWN, 2010; MARTIN, 2010).


5.4.1 Pesquisa

A pesquisa está definida como a prática principal no estágio de inspiração do DTsegundo Brown (2010), assim como é fundamental para o entendimento do problema deacordo com Martin (2010). Já para Rayasam e Niu (2015), a criatividade exploratóriaé pré-requisito para os outros tipos de criatividade e, de modo geral, ela se dá atravésda pesquisa intensa. É pelo papel que a pesquisa exerce na preparação e viabilização dopensamento criativo que a identificamos como uma técnica primordial para nosso método.

Entendemos que ela deve ser aplicada como a busca intensiva e sistematizadapelo entendimento do problema. É preciso que essa prática de pesquisa possibilite aosstakeholders entender não só o domínio principal do problema, mas que eles busquementender as relações com outros universos adjacentes ou mesmo opostos. Além disso,o conhecimento deve ser compreendido a ponto de poder ser repassado para a equipeem momentos propícios ou, mais importante ainda, para a equipe ser capaz de realizarconexões com outros conhecimentos apresentados durante a execução deste método.

5.4.2 Contação de histórias

Uma técnica simples, mas que auxilia bastante na descoberta de uma solução,é a contação de histórias. Segundo Brown (2010), compartilhar as experiências, reaisou fictícias, por si e por outrem, ajuda a equipe a entender o problema, evidenciar osempecilhos e vislumbrar alternativas. Para nosso método, percebemos que esta técnicapossui muita eficiência no início da construção do modelo abstrato, pois permite a equipedescobrir as personas, os objetivos, as tarefas e até os recursos que estão envolvidos noproblema proposto.

5.4.3 Técnicas criativas

As técnicas criativas são bastante usadas para gerar e selecionar alternativas desoluções, principalmente no universo do design. Há uma vasta gama destas técnicas, depropósito geral ou propósitos específicos. Portanto, durante a execução do método, oengenheiro de requisitos irá aplicá-las constantemente.

Apenas atentamos para a expertise necessária em escolher a técnica e o momentopropício para aplicá-la. Já há vários trabalhos que buscam classificar, situar e exemplificara aplicação dessas técnicas em processos de software, por exemplo, Vieira, Alves e Duboc(2012) e Valença (2016). Assim como há outras ferramentas que fazem classificações eindicações relacionadas diretamente ao tipo de criatividade desejado pela equipe, porexemplo EU-funded COLLAGE (2015a) e EU-funded COLLAGE (2015b).


5.5 BriefingO recebimento ou definição do briefing pela equipe marca o início da execução

deste método. Como dito no Capítulo 2, o briefing norteia a equipe para o entendimentodo problema e delimita o escopo da solução.

É dever do engenheiro de requisitos avaliar a viabilidade do briefing, uma vez queBrown (2010) nos alerta que o sucesso do projeto está diretamente ligado ao escopo dobriefing. Uma definição muito genérica pode levar a uma busca imensa por caminhospossíveis, já uma definição muito específica pode já ser a solução do problema. Via deregra, o briefing também deve passar pelos critérios de viabilidade, praticabilidade edesejabilidade do DT, descritos no Capítulo 2.

5.6 EstágiosEste método está dividido em dois estágios, conforme a Figura 16. De maneira

geral, a equipe criativa deverá iniciar na imersão no problema. Subsequentemente, atransição entres esses dois estágios é feita de foram iterativa, de acordo com a percepçãodo engenheiro de requisitos. Necessariamente, o primeiro estágio oferece suporte para oimersão na solução e este último oferece suporte ao primeiro, ou seja, a equipe obtém deum estágio o suporte necessário para prosseguir no outro. Dada a dinamicidade da ER, énecessário continuar os ciclos de iteração a cada esforço de elicitar requisitos criativos.

Cada iteração deverá acontecer de forma fluida para a equipe, mas que deve tera necessidade percebida pelo engenheiro de requisitos. A cada iteração é preciso que eleanalise os riscos do problema, para decidir se é viável prosseguir na busca da solução, oucaso já haja uma solução, analise os riscos dela para eventualmente conduzir a equipe auma nova imersão no problema. Brown (2010) nos diz que, se houver a percepção de queos critérios de viabilidade, praticabilidade e desejabilidade não possam ser alcançados, énecessário reconhecer o fim inconclusivo do projeto.

Cada encontro da equipe, independente do estágio, é denominado de sessão criativa.É necessário que os estados das ferramentas sejam mantidos entre as sessões criativas – ouseja, que as ferramentas do método reflitam o estado deixado anteriormente pela equipe– e que o ambiente esteja propício para o pensamento criativo – preceito básico do DTapresentado no Capítulo 2 – para que se tenha a continuidade da busca por uma solução.É dever do engenheiro de requisitos conduzir e explicar as técnicas e ferramentas que aequipe venha a usar para a construção colaborativa da solução.


Figura 16 – Estágios do método de construção de modelos i* criativos


5.6.1 Imersão no universo do problema

A imersão no problema é o momento propício, primeiramente, para criar um sensocomum quanto ao entendimento do problema; depois para identificar o estado-da-arte dassoluções existentes, assim como aprofundar o conhecimento da equipe quanto ao domíniodo problema e a relação dele com outros domínios. Neste estágio buscamos alcançar acriatividade exploratória, por isso a pesquisa é a técnica mais aplicada.

A medida que a pesquisa avança e a troca de conhecimento acontece através dasferramentas, outros elementos mais significativos à criatividade aparecerão no quadro demodelagem, visto que o entendimento do problema e as correlações entre os domínios setornam mais sólidos.

5.6.2 Imersão no universo das soluções

Para que haja uma imersão nas soluções, pressupomos que a imersão no problematenha acontecido satisfatoriamente. Neste estágio, buscamos alcançar mais fortemente ascriatividades combinacional e transformacional, o que significa que as ferramentas quadrode modelagem e quadro de ideação são predominantes, assim como as técnicas criativas.

O uso dessas ferramentas possibilita a geração e seleção de alternativas criativase será refletido diretamente no quadro de modelagem, visto que é neste estágio que asolução se completa. Cabe ao engenheiro de requisitos transitar para o estágio imersão no


problema caso não considere plausíveis as soluções levantadas ou caso queira aprofundarainda mais o entendimento da equipe em uma solução encontrada.

5.7 Transformação do modelo abstrato para o modelo i*A medida que o quadro de modelagem vai se formando, cabe ao engenheiro de

requisitos, nos hiatos das sessões criativas, transformar o modelo abstrato em modeloi* e realizar adaptações sintáticas e semânticas. Nas sessões seguintes, o engenheiro derequisitos deve expor à equipe os problemas referentes ao negócio/solução percebidosdurante a transformação, para que sejam resolvidos criativa e colaborativamente usandoas ferramentas deste método.

É necessário que o engenheiro de requisitos que realizará a transformação tenhaparticipado ativamente do método criativo, a fim de entender os contextos e significadosda solução proposta. Para auxiliar na transformação do modelo abstrato para o modeloi* SD ou SR, apesar de intuitiva para o engenheiro de requisitos, deixamos abaixo asheurísticas inerentes a este método:

1. Deve-se criar um ator Sistema, onde as fronteiras desse ator correspondem ao espaçoreservado no quadro de modelagem para o sistema;

2. Deve-se criar um ator no modelo i* para cada persona do modelo abstrato, conside-rando o tipo de ator i* mais coerente;

3. Quando necessário, cria-se um ator genérico para personas do modelo abstrato querepresentam relação de parentesco, desse modo, liga-se através de uma relação is_aos atores filhos ao respectivo pai.

4. Deve-se criar um goal ou softgoal, a depender do senso crítico, no modelo i* paracada objetivo do modelo abstrato;

5. Deve-se criar um tarefa no modelo i* para cada tarefa do modelo abstrato;

6. Deve-se criar um recurso no modelo i* para cada recurso do modelo abstrato;

7. Deve-se criar um beliefs no modelo i* para cada premissa dos cards de persona;

8. As ligações do modelo abstrato devem ser replicadas no modelo i*.

9. Elementos internos da fronteira de um ator, quando ligados diretamente a outroselementos pertencentes a fronteiras de outros atores (comumente ligações rotuladas),devem ser duplicados fora das suas fronteiras e, então, interligados aos elementosinternos àquelas fronteiras.


10. As ligações feitas nas heurísticas anteriores devem ser refinadas/redefinidas para quesejam semânticas no modelo i*.

11. Quando necessário, o ator Sistema deve ser analisado a fim de evidenciar possíveissub-sistemas (partes do sistema maior) e suas respectivas relações.

5.8 Considerações finaisEste método proposto busca inserir os conceitos e práticas do DT no processo de

construção colaborativa de modelos i*. Para que isso fosse possível, trabalhamos paradiminuir o conhecimento técnico requerido pelo i* para os indivíduos envolvidos, hajavista a equipe guiada pelo DT estar mais focada em desenvolver uma solução criativa,enquanto o engenheiro de requisitos busca especificar os requisitos resultantes em modelosi*, ciente dos benefícios da modelagem i* para o ciclo de vida do software em questão.

Portanto, é um método indicado para engenheiros de requisitos que pretendamenvolver a equipe numa busca por soluções criativas, mas que também desejem utilizaro i* para especificar, analisar e validar requisitos. Isso significa que o poder decisóriopara utilização desse método é do engenheiro de requisitos, assim como já cabe a eleentender e escolher as outras técnicas convencionais para desenvolver as atividades da ER.Ademais, ratificamos a necessidade do engenheiro de requisitos, ao optar pela utilizaçãodeste método, ter conhecimento nas duas áreas principais: i* e DT.

76

6 AVALIAÇÃO DO MÉTODO

Este capítulo descreve os procedimentos adotados para avaliar o método em outraequipe diferente daquela usada na pesquisa-ação. Este passo foi essencial para podermosafirmar que o nosso método possui um nível de abstração que o permite ser aplicado aoutro problema, permanecendo de acordo com os preceitos do DT e voltado a modelagemorientada a objetivos.

A fim de exemplificar como o engenheiro de requisitos deve aplicar este método auma equipe, também adequamos este capítulo para que a avaliação seja apresentada comoum caso didático de execução do método.

Para realizarmos a avaliação do método, selecionamos uma equipe de 5 (cinco)integrantes design thinkers mais 1 (um) integrante engenheiro de requisitos. Todos osparticipantes pertencem ao Laboratório de Engenharia de Requisitos (LER) e possuemalgum contato com o framework i*. O método foi executado em 4 (quatro) horas, hajavista nossa pretensão ser apenas a avaliação em si, portanto não houve imersão profundapela equipe nem no problema nem na solução.

Ao final da avaliação os integrantes design thinkers foram submetidos a um formu-lário, Apêndice A, com o objetivo de coletar dados referentes às impressões deles quanto afacilidade de uso do método.

6.1 Ameaças à validadePara que o resultado desta avaliação pudesse ser usado como embasamento para

nosso método, tivemos a necessidade de combater algumas ameaças, são elas:

• O problema ser complexo a ponto de não gerar resultados no tempodefinido para a avaliação: para anular esta ameaça, escolhemos um problemacorriqueiro para os integrantes da equipe e sem complexidade notável. O propostafoi um sistema facilitador de reuniões, problema bastante revisto pelos integrantesdo LER durante os estudos de i*.

• O fato de a equipe ser composta apenas de integrantes técnicos: mesmo aequipe sendo composta apenas de pessoas técnicas, nossa coleta de dados atestoudiferenças nas experiências em i* dos integrantes. Ainda que todos tivessem bastanteexperiência, acreditamos que, pelo fato de a equipe avaliada outrora durante apesquisa-ação ser composta em sua maioria por usuários não técnicos, esta segunda

Capítulo 6. Avaliação do método 77

avaliação ser composta de usuários técnicos apenas valida a eficácia do método paraambos os perfis.

6.2 ExecuçãoAo iniciar a execução do método, a primeira providência do engenheiro de requisitos

foi alertar a equipe sobre a necessidade da estarem imersos na dinâmica proposta e atentosas instruções passadas, para que não houvesse prejuízo ao pensamento criativo. Nestemesmo momento, o engenheiro de requisitos fez uma breve explanação do que significapensar orientado a objetivos e as vantagens inerentes a esta forma de concepção derequisitos de software.

6.2.1 Briefing

Em seguida, a providência tomada foi apresentar para a equipe o briefing doproblema proposto, assim como explicar o que era o briefing e quais fronteiras ele impunhapara a equipe desenvolver a solução. O briefing apresentado foi: Propor um software facili-tador de reuniões, de modo que o processo de agendamento e realização seja transparente,conveniente e rápido para os participantes. É importante que se leve em consideração queos participantes estão dispostos a empenhar o menor esforço necessário, para isso buscamna tecnologia o apoio requerido.

6.2.2 Estágios

Tendo em vista que a apresentação do briefing leva equipe diretamente ao estágiode imersão no problema, os integrantes receberam materiais impressos descrevendo funcio-nalidades de softwares concorrentes. É necessário atentar para o fato de que esse materialsó foi pré-selecionado devido a limitação temporal da avaliação, de outra forma este é umtrabalho árduo que deve ser exaustivamente desempenhado por todos da equipe, a fim deentender completamente o estado-da-arte do problema em questão.

Após lerem e discutirem entre si sobre o material proposto, o engenheiro derequisitos apresentou a equipe o quadro de modelagem e iniciou o primeiro momento demodelagem, imersão na solução. Esta modelagem após a primeira imersão no problemacomumente constrói um modelo que representa o estado-da-arte, sem muitos aspectoscriativos. Ciente disto, é conveniente que nesta primeira modelagem o engenheiro derequisitos busque apenas identificar as personas, objetivos, assim como recursos, evidentese tarefas superficiais. Isso para forçar a equipe a posteriormente expandir o modelo jápensando criativamente. Após essa modelagem inicial, o quadro de modelagem refletia oque se vê na Figura 17.


Figura 17 – Quadro de modelagem usado na avaliação


É possível notar na Figura 17 que houve uma adaptação do quadro de modelagemdevido a falta de um quadro grande, isto comprova a flexibilidade do método exigida peloDT. Neste caso, o engenheiro de requisitos utilizou barbantes e fitas colantes para ligar oselementos no quadro e para demarcar a área reservada aos elementos do Sistema. Quantoa legenda do modelo abstrato, o engenheiro de requisitos reservou um espaço no quadrode ideação para ela, conforme Figura 18.

Figura 18 – Quadro de ideação usado na avaliação



Durante a modelagem o engenheiro de requisitos interveio quando a equipe sentiudificuldades em representar seus pensamentos na forma orientada a objetivos, por exemplo,em alguns momentos houve dúvidas quanto a representar um pensamento como tarefaou objetivo. Para este caso, o engenheiro de requisitos aplicou junto à equipe a técnicacriativa dos 5 porquês, deste modo foi possível questionar o porquê de algo a fim de testarse este já era a própria razão (objetivo) ou era um passo (tarefa) para um motivo maior.

Após a primeira sessão de modelagem, o engenheiro de requisitos aplicou umbrainstorm a fim de elencar possíveis ideias criativas para prosseguir no modelo abstrato.No entanto, o resultado do brainstorm, presente na Figura 19, não mostrou ser proveitoso,pois as ideias foram poucas e consideradas inapropriadas pela equipe por meio de umbrainstorm destrutivo realizado em cima das alternativas geradas.

Figura 19 – Resultado do Brainstorm durante a avaliação


Diante disto, a equipe foi conduzida a uma nova imersão no problema. Desta vezos integrantes receberam pesquisas que apresentavam dados estatísticos sobre o porquê dealgumas reuniões serem improdutivas, porque costumam demorar, porque causam cansaçoe também dicas para conduzir uma reunião eficientemente. Ou seja, a intensão foi expandiro conhecimento da equipe para outros domínios. Após a leitura, os integrantes discutiramentre si sobre os novos conceitos aprendidos.

Logo após a pesquisa, a equipe foi conduzida ao quadro de modelagem e o engenheirode requisitos solicitou que as personas e suas prioridades fossem repensadas, a fim derefletir a nova realidade do pensamento criativo da equipe. A propósito, a Figura 20 nosmostra um card já priorizado de uma das personas identificadas.


Figura 20 – Card de persona preenchido


Em seguida a equipe retomou a imersão na solução. Desta vez a opção foi desenvolveralgumas ideias mais racionalmente, haja vista agora ser possível explorar correlações entreos domínios pesquisados, por isso a equipe foi submetida à técnica criativa Método 635.Nessa técnica seis pessoas podem desenvolver racionalmente até três ideias distintas numintervalo de 5 minutos, de modo que do segundo participante em diante é possível continuaruma ideia anterior ao invés de apresentar uma nova, indicando que o participante apoiaaquela proposta e, portanto, deve aprimorá-la. No resultado desta técnica, presente naFigura 21, foi possível destacar uma ideia criativa relevante, com a qual todos os integrantescontribuíram, inclusive o engenheiro de requisitos que também participou ativamente datécnica.

Em posse da ideia escolhida e após a equipe entender ser esta a solução final, foinecessário voltar ao quadro de modelagem e a desenvolver. O modelo abstrato resultantepode ser visto na Figura 22.


Figura 21 – Resultado do Método 635 durante a avaliação


Capítulo

6.Avaliação

dométodo

82

Figura 22 – Modelo abstrato resultante da avaliação



6.2.3 Transformação do modelo abstrato

Por fim, a tarefa do engenheiro de requisitos foi transformar o modelo abstratoem modelos i*. Os modelos gerados estão representados pelas Figura 23 e Figura 24. Épreciso destacar que no modelo SR os 2 (dois) elementos beliefs do ator Sistema foraminferidos do briefing pelo engenheiros de requisitos, o que evidencia a importância dese fazer refinamentos no modelo i* resultante da transformação. Outro caso que merecedestaque é que alguns objetivos do modelo abstrato, após transformação, viraram soft-goalnos modelos i*, também resultante da expertise do engenheiro de requisitos.

Na Figura 23 notamos que, apesar da limitação de tempo da avaliação, a equipeconseguiu enveredar por uma solução que está mais interessada em preparar os materiaise inteirar os participantes da pauta da reunião para que haja maior produtividade na horado encontro em si, do que marcar a reunião, que é a proposta das soluções atuais. Issoevidencia as vastas possibilidades que podem ser vislumbradas ao entender e solucionar oproblema.

Figura 23 – Modelo SD resultante do modelo abstrato


Capítulo

6.Avaliação

dométodo

84

Figura 24 – Modelo SR resultante do modelo abstrato



6.3 Considerações finaisNosso entendimento é que a avaliação trouxe mais validade ao método proposto.

Consideramos o resultado satisfatório, mesmo porque a consolidação das respostas dosparticipantes design thinkers ao formulário foi deveras positiva. No Apêndice B constauma consolidação detalhada do feedback desses participantes.

De modo geral, os participantes design thinkers tinham boa experiência com i* epouca experiência com DT. No entanto, consideraram que o método foi transparente aponto de não apresentar qualquer dificuldade em utilizar as ferramentas para expressar opensamento criativo na forma orientada a objetivos, principalmente o quadro de modelagem.Após lerem as heurísticas de transformação do modelo abstrato em modelo i*, eles tambémafirmaram que não há dificuldades em correlacionar os elementos dos dois modelos.

Apesar do conhecimento da equipe avaliada em modelagem orientada a objetivos,observamos que a construção do modelo abstrato não exigiu dos participantes tal conhe-cimento. Do contrário, apenas ao engenheiro de requisitos coube o dever de conhecer oi* para aplicação das heurísticas de transformação. Nossos esforços se deram para que omodelo abstrato fosse familiar também à modelagem i*, diminuindo o esforço necessáriopara a transformação.

86

7 CONSIDERAÇÕES FINAIS

Já tendo apresentado o método, é mister tecermos algumas considerações sobreele. De antemão deixamos o registro da nossa satisfação com os resultados obtidos nesteestudo, haja vista termos logrado êxito em atingir os objetivos geral e específicos definidosno Capítulo 1.

Isso se deve ao suporte teórico no qual nos baseamos, aliado ao método científicopesquisa-ação, o qual possibilitou construir e testar o nosso método num caso real, levandoem conta a dinâmica social inerente ao contexto da engenharia de requisitos. Da conduçãoda pesquisa-ação resultou: no campo da ação, a especificação dos requisitos por parte daequipe estudada, os quais são de propriedade da equipe; já no campo do conhecimentoresultou a observação e os testes das práticas do DT relevantes para a construção demodelos i* criativos, o que é deveras importante para nós, porque a partir disto alcançamosnosso objetivo geral “Especificar um método que conduza os stakeholders à construção demodelos i* criativos através da aplicação da metodologia Design Thinking”.

Dado o esforço que empenhamos em abstrair os conhecimentos resultantes daaplicação da pesquisa-ação que fossem inerentes puramente a DT e orientação a objetivos,afirmamos que nosso método está depurado a ponto de ser aplicável a outras equipes quebuscam construir modelos i* criativos através do DT. Ou seja, o método desta pesquisaestá generalizado a ponto de ser aplicável a qualquer equipe que siga os preceitos do DT,como pode ser atestado pela avaliação descrita no Capítulo 6.

Levando em conta termos adaptado o processo, as práticas e as ferramentas do DTpara que conduzissem a produção de modelos i* criativos, temos como validado o primeiroobjetivo específico “Integrar os métodos e ferramentas do Design Thinking à modelagem i*,de modo a propiciar a criatividade”. Também considerando que o método proposto retirousignificativamente a complexidade do framework i*, através da adaptação do modelohíbrido proposto por Horkoff (2015), de modo que os stakeholders não técnicos operaramexclusivamente em cima desta adaptação, consideramos validado o segundo objetivoespecífico “Diminuir a experiência técnica requerida para os stakeholders não-técnicosdurante a construção modelos i* criativos”.

Ademais, validamos o último objetivo específico “Propiciar a construção coletivae colaborativa de modelos i* criativos” através da constatação do caráter coletivo ecolaborativo inerente ao DT, mas também porque o método como um todo está pensadopara que a equipe construa os modelos colaborativamente, senão vejamos: quadro demodelagem, quadro de ideação, personas, técnicas criativas, contação de histórias eresolução conjunta de conflitos inerentes ao modelo e domínio.

Capítulo 7. Considerações finais 87

7.1 Contribuições científicasQuanto às contribuições científicas alcançadas por este estudo, por ora, consideramos

o que segue abaixo:

• Revisão da literatura sobre as relações diretas entre os domínios ER, i* e DT;

• Definição do estado-da-arte no tocante à integração entre modelagem i* e criatividade;

• Definição de um método para construir modelos i* criativos a partir da aplicação doDT;

• Inserção dos stakeholders não técnicos na produção colaborativa de modelos i*criativos;

• Capacidade de transformar os resultados de técnicas criativas em entradas para osprocessos da ER.

Acreditamos que nossas contribuições são bastantes significativas, mas devido aospoucos estudos existentes sobre a integração ente i* e criatividade muito ainda há que sepesquisar nesta área.

7.2 Limitações do métodoÉ deveras importante explicitar dois aspectos que, por ora, este método não prover

apoio a contento, são eles:

• Definir uma maneira prática e colaborativa da equipe criativa expressar através domodelo abstrato as premissas do ator Sistema, referentes aos beliefs na conversãopara o i*, representado pela seção “Sistema” do quadro de modelagem. Essa limitaçãose dá porque as premissas do ator Sistema normalmente não estão explicitas nosresultados das técnicas utilizadas por este método, contrariamente, é preciso queo engenheiro de requisitos, no papel técnico a ele atribuído e como integrante dométodo criativo, busque analiticamente inferir essas premissas, que as vezes sãoresultados da junção de premissas de personas distintas e aspectos tecnológicos ousociais intrínsecos.

• Definir heurísticas distintas direcionadas à transformação do modelo abstrato emmodelos SD e SR diretamente. Essa limitação está ligada a nosso objetivo de nãodificultar a construção do modelo abstrato para os usuários não técnicos, de modo aevitar cobrar deles distinções entres os modelos SD e SR, mas exigir do engenheirode requisitos conhecimento técnico necessário para a transformação.

Capítulo 7. Considerações finais 88

7.3 Trabalhos futurosSalvaguardadas as contribuições dadas por este estudo, entendemos que outras novas

pesquisas devam surgir com o intuito de contribuir para a consolidação do conhecimentosobre modelagem orientada a objetivos e criatividade. Isso porque este tema é bastantenovo, tendo sido iniciado recentemente por Horkoff, Maiden e Lockerbie (2015).

Já especificamente quanto a futuras contribuições para o método, acreditamos quea concepção de ferramentas de apoio automatizadas é um próximo passo para tornar ométodo mais prático, a exemplo de ferramentas como EU-funded COLLAGE (2015a) eEU-funded COLLAGE (2015b) que buscam ajudar na aplicação das técnicas criativascomo um todo. Além da praticidade, estas ferramentas poderão prover melhor suportepara rastrear os impactos nos requisitos causados por mudanças e criação de ideias duranteas sessões criativas.

Também é preciso que novos estudos investiguem técnicas de criatividade eficazespara a construção de modelos i* criativos – que ajudem especificamente no aspecto daorientação a objetivos – e apontem o melhor momento nas sessões criativas para usá-las.Poderia ser um catalogo, a exemplo do que foi feito por Vieira, Alves e Duboc (2012) eValença (2016), que mapearam as técnicas e os contextos propícios, mas o fizeram para aengenharia de requisitos como um todo.

Outro trabalho futuro é construir técnicas eficazes para inserir as práticas deoperacionalização de objetivos do i* como meio de geração de alternativas criativas na fasede ideação. Neste ponto, entendemos que o quadro de modelagem poderá ajudar nessastarefas.

Por fim, com o objetivo de amadurecer os estudos sobre a integração entre DT e i*,entendemos que futuramente este método deva ser aplicado e avaliado mais vezes e, acasooutros métodos com esse propósito surjam, possa ser comparado para que essa integraçãoesteja cada vez mais afinada e praticável. Essa comparação deve ser feita com o objetivode avaliar o grau de dificuldade dos stakeholders em participar ativamente do método,o quão satisfatório os resultados são para os clientes ou, mais teoricamente, comparar opotencial criativo dos métodos.

89

REFERÊNCIAS

BODEN, M. A. The creative mind: Myths and mechanisms. [S.l.]: Psychology Press, 2004.Citado na página 24.

BROWN, T. Design thinking. Harvard business review, v. 86, n. 6, p. 84, 2008. Citado 6vezes nas páginas 20, 34, 36, 37, 38 e 45.

BROWN, T. Tim Brown: Designers – think big! TEDGlobal, 2009. Internet. Disponívelem: <http://www.ted.com/talks/tim_brown_urges_designers_to_think_big>. Acessoem: 10 abr. 2015. Citado na página 34.

BROWN, T. Design Thinking. Rio de Janeiro: Campus - RJ, 2010. Citado 11 vezes naspáginas 15, 18, 19, 20, 33, 34, 36, 37, 70, 71 e 72.

CABOT, J. Creative Leaf: Browser-based Creative Requirements Modeling. ModelingLanguages, 2016. Internet. Disponível em: <http://modeling-languages.com/creative-leaf-requirements-modeling/>. Acesso em: 01 ago. 2016. Citado na página 50.

CARVALLO, J. P.; FRANCH, X. Lessons Learned on the use of i * by Non-TechnicalUsers. In: Proceedings of the Seventh International i* Workshop. [S.l.: s.n.], 2014. Citadona página 18.

CHURCHMAN, C. W. Wicked Problems. In: INFORMS. Management Science. [S.l.],1967. v. 14, n. 4, p. B141–B142. Citado na página 20.

COOPER, A. The Inmates Are Running the Asylum. [S.l.]: Sams Publishing, 2004.Citado 3 vezes nas páginas 41, 42 e 65.

DINIZ, E. H.; PETRINI, M.; BARBOSA, A. F.; CHRISTOPOULOS, T. P.;MÔNACO-DOSSANTOS, H. Abordagens epistemológicas em pesquisas qualitativas: alémdo positivismo nas pesquisas na área de sistemas de informação. Encontro da AssociaçãoNacional de Pós-Graduação e Pesquisa em Administração (Enanpad), v. 31, 2006. Citadona página 21.

D.SCHOOL, S. Bootcamp Bootleg. Stanford d.school, p. 47, 2010. Citado na página 34.

EU-funded COLLAGE. Creative Engine. 2015a. Disponível em: <http://becreative.city.ac.uk/>. Acesso em: 03 jan. 2016. Citado 3 vezes nas páginas 51, 71 e 88.

EU-funded COLLAGE. Bright Sparks. 2015b. Disponível em: <http://brightsparks.city.ac.uk/>. Acesso em: 15 mai. 2016. Citado 3 vezes nas páginas 51, 71 e 88.

GIBERTONI, D. A Contribuição da Pesquisa-ação para Obtenção da Inovação Tecnológica.Revista Interface Tecnológica, são Paulo, v. 9, n. 1, 2012. Citado 2 vezes nas páginas 20e 56.

GREMETT, P.; BAECK, A. Design Thinking: Expanding UX Methods Beyond Designers.In: DEGEN, X. Y. H. (Ed.). Primeira. [S.l.]: McGraw-Hill Osborne Media, 2011. Citado2 vezes nas páginas 34 e 35.

http://www.ted.com/talks/tim_brown_urges_designers_to_think_big

http://modeling-languages.com/creative-leaf-requirements-modeling/

http://modeling-languages.com/creative-leaf-requirements-modeling/

http://becreative.city.ac.uk/

http://becreative.city.ac.uk/

http://brightsparks.city.ac.uk/

http://brightsparks.city.ac.uk/

Referências 90

HÄGER, F.; KOWARK, T.; KRÃ¼GER, J.; VETTERLI, C.; ÃœBERNICKEL, F.;UFLACKER, M. Dt@scrum: Integrating design thinking with software developmentprocesses. In: PLATTNER, H.; MEINEL, C.; LEIFER, L. (Ed.). Design ThinkingResearch. [S.l.]: Springer International Publishing, 2015, (Understanding Innovation). p.263–289. Citado na página 44.

HILDENBRAND, T.; MEYER, J. Intertwining lean and design thinking: Softwareproduct development from empathy to shipment. In: MAEDCHE, A.; BOTZENHARDT,A.; NEER, L. (Ed.). Software for People. [S.l.]: Springer Berlin Heidelberg, 2012,(Management for Professionals). p. 217–237. Citado 2 vezes nas páginas 43 e 44.

HORKOFF, J. Observational studies of new i* users: Challenges and recommendations.In: First iStar Teaching Workshop (iStarT15). [S.l.: s.n.], 2015. Citado 8 vezes naspáginas 16, 18, 31, 32, 33, 61, 62 e 86.

HORKOFF, J. Creative Leaf. City University London, 2016. Internet. Disponível em:<http://creativeleaf.city.ac.uk/>. Acesso em: 01 ago. 2016. Citado na página 48.

HORKOFF, J.; MAIDEN, N. Supporting Creative RE with i *. p. 37–42, 2015a. Citado6 vezes nas páginas 16, 17, 20, 51, 52 e 53.

HORKOFF, J.; MAIDEN, N. Creativity and conceptual modeling for requirementsengineering. In: REFSQ Workshops. [S.l.: s.n.], 2015b. p. 62–68. Citado 5 vezes naspáginas 15, 16, 17, 32 e 33.

HORKOFF, J.; MAIDEN, N.; LOCKERBIE, J. Creativity and goal modeling for softwarerequirements engineering. In: ACM. Proceedings of the 2015 ACM SIGCHI Conference onCreativity and Cognition. [S.l.], 2015. p. 165–168. Citado 5 vezes nas páginas 16, 17, 32,48 e 88.

I* WIKI. iStarQuickGuide. 2006. Disponível em: <http://istarwiki.org/tiki-index.php?page=iStarQuickGuide>. Acesso em: 01 dez. 2015. Citado 2 vezes nas páginas 27 e 28.

I* WIKI. i* Guide. 2007. Disponível em: <http://istarwiki.org/tiki-index.php?page=i*+Guide>. Acesso em: 02 dez. 2015. Citado 4 vezes nas páginas 26, 28, 30 e 31.

JOBST, B.; MEINEL, C. How prototyping helps to solve wicked problems. In: LEIFER,L.; PLATTNER, H.; MEINEL, C. (Ed.). Design Thinking Research. [S.l.]: SpringerInternational Publishing, 2014, (Understanding Innovation). p. 105–113. Citado napágina 39.

LAMSWEERDE, A. V. Goal-oriented requirements engineering: A guided tour. In: IEEE.Requirements Engineering, 2001. Proceedings. Fifth IEEE International Symposium on.[S.l.], 2001. p. 249–262. Citado na página 15.

LAUE, R.; HOGREBE, F.; BÖTTCHER, B.; NÜTTGENS, M. Preliminary Results onthe Understandability of ı Notations. Ceur-Ws.Org, p. 1–6, 2014. Citado na página 18.

LEMOS, J.; ALVES, C.; DUBOC, L.; RODRIGUES, G. N. A systematic mapping studyon creativity in requirements engineering. In: ACM. Proceedings of the 27th Annual ACMSymposium on Applied Computing. [S.l.], 2012. p. 1083–1088. Citado na página 25.

http://creativeleaf.city.ac.uk/

http://istarwiki.org/tiki-index.php?page=iStarQuickGuide

http://istarwiki.org/tiki-index.php?page=iStarQuickGuide

http://istarwiki.org/tiki-index.php?page=i*+Guide

http://istarwiki.org/tiki-index.php?page=i*+Guide

Referências 91

LINDBERG, T.; KöPPEN, E.; RAUTH, I.; MEINEL, C. On the perception, adoptionand implementation of design thinking in the it industry. In: PLATTNER, H.; MEINEL,C.; LEIFER, L. (Ed.). Design Thinking Research. [S.l.]: Springer Berlin Heidelberg, 2012,(Understanding Innovation). p. 229–240. Citado 2 vezes nas páginas 39 e 40.

LINDBERG, T.; MEINEL, C.; WAGNER, R. Design thinking: A fruitful concept for itdevelopment? In: Design Thinking. [S.l.]: Springer, 2011. p. 3–18. Citado 4 vezes naspáginas 15, 18, 20 e 24.

MAHAUX, M.; MAVIN, A.; HEYMANS, P. Choose your creativity: why and howcreativity in requirements engineering means different things to different people. In:Requirements Engineering: Foundation for Software Quality. [S.l.]: Springer, 2012. p.101–116. Citado na página 25.

MAHAUX, M.; NGUYEN, L.; GOTEL, O.; MICH, L.; MAVIN, A.; SCHMID, K.Collaborative creativity in requirements engineering: Analysis and practical advice. In:IEEE. IEEE 7th International Conference on Research Challenges in Information Science(RCIS). [S.l.], 2013. p. 1–10. Citado 2 vezes nas páginas 24 e 25.

MAIDEN, N.; JONES, S.; KARLSEN, K.; NEILL, R.; ZACHOS, K.; MILNE, A.Requirements engineering as creative problem solving: A research agenda for idea finding.Proceedings of the 2010 18th IEEE International Requirements Engineering Conference,RE2010, p. 57–66, 2010. Citado 3 vezes nas páginas 17, 24 e 25.

MAIDEN, N.; JONES, S.; NCUBE, C.; LOCKERBIE, J. Using i * in RequirementsProjects : Some Experiences and Lessons. Social Modeling for Requirements Engineering,p. 1–24, 2011. Citado na página 31.

MAIDEN, N.; ROBERTSON, S.; ROBERTSON, J. Creative requirements: inventionand its role in requirements engineering. In: ACM. Proceedings of the 28th internationalconference on Software engineering. [S.l.], 2006. p. 1073–1074. Citado 2 vezes nas páginas16 e 24.

MARTIN, R. Design de Negócios. 1. ed. Rio de Janeiro: Campus–Elsevier, 2010. Citado7 vezes nas páginas 18, 20, 33, 34, 37, 70 e 71.

MEINEL, C.; LEIFER, L. Design Thinking Research. In: MEINEL, C.; LEIFER,L.; PLATTNER, H. (Ed.). Design Thinking. [S.l.]: Springer Berlin Heidelberg, 2011,(Understanding Innovation). p. xiii–xxi. Citado na página 34.

MERKLEY, R. Ryan Merkley: Online video – annotated, remixed and popped. TEDGlobal,2012. Internet. Disponível em: <https://www.ted.com/talks/ryan_merkley_online_video_annotated_remixed_and_popped>. Acesso em: 19 jan. 2016. Citado na página60.

NIELSEN, L. Personas. In: SOEGAARD, R. F. D. M. (Ed.). Segunda. InteractionDesign Foundation, 2012. cap. 30. Disponível em: <https://www.interaction-design.org/literature/book/the-encyclopedia-of-human-computer-interaction-2nd-ed/personas>.Acesso em: 11 nov. 2015. Citado na página 41.

NORDSTROM LABS. Our Process Told as our Team’s Timeline. 2012. Internet.Disponível em: <http://secure.nordstrominnovationlab.com/pages/our_process_told_as_our_team_s_timeline>. Acesso em: 9 abr. 2015. Citado 2 vezes nas páginas 43 e 44.

https://www.ted.com/talks/ryan_merkley_online_video_annotated_remixed_and_popped

https://www.ted.com/talks/ryan_merkley_online_video_annotated_remixed_and_popped

https://www.interaction-design.org/literature/book/the-encyclopedia-of-human-computer-interaction-2nd-ed/personas

https://www.interaction-design.org/literature/book/the-encyclopedia-of-human-computer-interaction-2nd-ed/personas

http://secure.nordstrominnovationlab.com/pages/our_process_told_as_our_team_s_timeline

http://secure.nordstrominnovationlab.com/pages/our_process_told_as_our_team_s_timeline

Referências 92

PAULA, D. F. O. Model for the Innovation Teaching (MoIT): Um Modelo Baseadoem Design Thinking, Lean Startup e Ágil para Estudantes de Graduação. Dissertação(Mestrado em Ciência da Computação) — Universidade Federal de Pernambuco, Recife,2015. Citado na página 44.

PRESSMAN, R. S. Engenharia de Software. 7. ed. Porto Alegre: McGraw Hill Brasil,2011. Citado 2 vezes nas páginas 23 e 24.

RAYASAM, S.; NIU, N. Using i* for Transformational Creativity in RequirementsEngineering. In: Proceedings of the Eighth International i* Workshop - iStar 2015. [S.l.:s.n.], 2015. p. 67–72. Citado 2 vezes nas páginas 24 e 71.

SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson Education, 2011.Citado 3 vezes nas páginas 15, 23 e 24.

SOUZA, C. L. de C. Uso do Design Thinking na Elicitação de Requisitos de AmbientesVirtuais de Aprendizagem Móvel. Dissertação (Mestrado) — Universidade Federal dePernambuco, Recife, 2014. Citado na página 44.

STEINERT, B.; HIRSCHFELD, R. Applying design knowledge to programming. In:PLATTNER, H.; MEINEL, C.; LEIFER, L. (Ed.). Design Thinking Research. [S.l.]:Springer Berlin Heidelberg, 2012, (Understanding Innovation). p. 259–277. Citado napágina 44.

STEINERT, B.; TAEUMEL, M.; CASSOU, D.; HIRSCHFELD, R. Adopting designpractices for programming. In: PLATTNER, H.; MEINEL, C.; LEIFER, L. (Ed.). DesignThinking Research. [S.l.]: Springer Berlin Heidelberg, 2012, (Understanding Innovation). p.247–262. Citado na página 44.

THIENEN, J.; NOWESKI, C.; MEINEL, C.; RAUTH, I. The co-evolution of theory andpractice in design thinking – or – “mind the oddness trap!”. In: MEINEL, C.; LEIFER,L.; PLATTNER, H. (Ed.). Design Thinking. [S.l.]: Springer Berlin Heidelberg, 2011,(Understanding Innovation). p. 81–99. Citado na página 34.

THIOLLENT, M. Metodologia da pesquisa-ação. 18. ed. [S.l.]: Cortez Editora, 2011.Citado 3 vezes nas páginas 20, 55 e 58.

VALENÇA, M. C. L. Creadtivity: Um Processo que Integra Design Thinking e Técnicasde Criatividade na Elicitação de Requisitos de Software. Dissertação (Mestrado) —Universidade Federal de Pernambuco, Recife, 2016. Citado 5 vezes nas páginas 45, 46, 48,71 e 88.

VERGANTI, R. Innovating through design. Harvard business review, n. 12, 2006. Citado2 vezes nas páginas 20 e 33.

VERGANTI, R. Design-driven Innovation. 1. ed. São Paulo: Canal Certo, 2012. Citado 2vezes nas páginas 20 e 33.

VETTERLI, C.; BRENNER, W.; UEBERNICKEL, F.; PETRIE, C. From Palaces toYurts. IEEE Computer Society, v. 13, p. 91–94, 2013. Citado na página 40.

VIANNA, M.; VIANNA, Y.; ADLER, I. K.; LUCENA, B.; RUSSO, B. Design Thinking.Rio de Janeiro: MJV Press, 2012. Citado 2 vezes nas páginas 34 e 41.

Referências 93

VIEIRA, E. R.; ALVES, C.; DUBOC, L. Creativity patterns guide: Support for theapplication of creativity techniques in requirements engineering. In: Human-CenteredSoftware Engineering. [S.l.]: Springer, 2012. p. 283–290. Citado 2 vezes nas páginas 71e 88.

WALOSZEK, G. Introduction to Design Thinking. 2012. Disponível em: <http://experience.sap.com/skillup/introduction-to-design-thinking/>. Acesso em: 20 ago. 2015.Citado 2 vezes nas páginas 34 e 37.

YU, E. Modelling strategic relationships for process reengineering. 124 p. Tese (Doutoradoem Computação) — University of Toronto, Toronto, 1995. Citado 6 vezes nas páginas 19,20, 26, 28, 29 e 30.

http://experience.sap.com/skillup/introduction-to-design-thinking/

http://experience.sap.com/skillup/introduction-to-design-thinking/

APÊNDICES

95

APÊNDICE A – QUESTIONÁRIO DEAVALIAÇÃO DO MÉTODO PROPOSTO

APÊNDICE A. Questionário de avaliação do método proposto 96

97

APÊNDICE B – RESUMO DASAVALIAÇÕES DO MÉTODO PROPOSTO

1. Você possui experiência com métodos criativos?

2. Você possui experiência com Design Thinking?

3. Você possui experiência com i*?

4. Como um participante design thinker, você sentiu dificuldade em colabo-rar com a solução criativa?

APÊNDICE B. Resumo das avaliações do método proposto 98

5. Se sim, esta dificuldade se deve a:

6. Você sentiu dificuldades em construir colaborativamente o modelo abs-trato?

7. Se sim, esta dificuldade se deve a:

8. Se você conhece o i*, você sentiu dificuldades em correlacionar os elemen-tos do modelo abstrato com os elementos do i*?

99

APÊNDICE C – CARD PARA PERSONAS

100

APÊNDICE D – PROTÓTIPO INICIAL DOQUADRO DE MODELAGEM DURANTE A

EXECUÇÃO DA PESQUISA-AÇÃO

ANEXOS

102

ANEXO A – PROTÓTIPO GERADODURANTE A EXECUÇÃO DA

PESQUISA-AÇÃO

103

ANEXO B – MODELO SD GERADODURANTE A EXECUÇÃO DA

PESQUISA-AÇÃO

104

ANEXO C – MODELO SR GERADO DURANTE A EXECUÇÃO DAPESQUISA-AÇÃO

Um Método para Construção de Modelos i* Utilizando Design … · 2019. 10. 26. · Orientadora:...

Documents

Transcript of Um Método para Construção de Modelos i* Utilizando Design … · 2019. 10. 26. · Orientadora:...