PREOrg : um guia para elicitação de requisitos orientado ao desempenho organizacional

(1)

FLAYGNER MATOS REBOUC

¸ AS

PREOrg: Um Guia para Elicita¸

c˜

ao de Requisitos

Orientado ao Desempenho Organizacional

S˜

ao Crist´

ov˜

ao

2018

(2)

FLAYGNER MATOS REBOUC

¸ AS

PREOrg: Um Guia para Elicita¸

c˜

ao de Requisitos

Orientado ao Desempenho Organizacional

Vers˜ao original

Disserta¸cão apresentada à Pró-Reitoria de Pós-Gradua¸cão e Pesquisa da Universi-dade Federal de Sergipe para obten¸cão do t´ıtulo de Mestre em Ciência da Computa¸cão pelo Programa de Pós-gradua¸cão em Ciência da Computa¸cão.

´

Area de concentra¸c˜ao: Engenharia de software

Orientador: Prof. Dr. Michel dos Santos Soares

Coorientador: Prof. Dr. Rog´

erio Patr´ıcio Chagas do Nascimento

S˜

ao Crist´

ov˜

ao

2018

(3)

FICHA CATALOGRÁFICA ELABORADA PELA BIBLIOTECA CENTRAL UNIVERSIDADE FEDERAL DE SERGIPE

R292p Rebouças, Flaygner Matos PREOrg : um guia para elicitação de requisitos orientado ao desempenho organizacional / Flaygner Matos Rebouças ; orientador Michel dos Santos Soares. – São Cristóvão, 2018.

91 f. : il.

Dissertação (mestrado em Ciências da Computação)– Universidade Federal de Sergipe, 2018.

1. Ciência da computação. 2. Engenharia de software. 3. Engenharia de requisitos. I. Soares, Michel dos Santos, orient. II. Título.

(4)

Disserta¸cão de autoria de Flaygner Matos Rebou¸cas, sob o t´ıtulo “PREOrg: Um Guia para Elicita¸cão de Requisitos Orientado ao Desempenho Organizacional”, apre-sentada à Pró-Reitoria de Pós-Gradua¸cão e Pesquisa da Universidade Federal de Sergipe, para obten¸cão do t´ıtulo de Mestre em Ciência da Computa¸cão pelo Programa de P´ os-gradua¸cão em Ciência da Computa¸cão, na área de concentra¸cão Engenharia de software, aprovada em 24 de abril de 2018 pela comissão julgadora constitu´ıda pelos doutores:

Prof. Dr. Michel dos Santos Soares Presidente

Universidade Federal de Sergipe (UFS)

Prof. Dr. Rog´erio Patr´ıcio Chagas do Nascimento Universidade Federal de Sergipe (UFS)

Prof. Dr. Methanias Cola¸co Rodrigues J´unior Universidade Federal de Sergipe (UFS)

Prof. Dr. Fl´avio de Oliveira Silva Universidade Federal de Uberlˆandia (UFU)

(5)

Dedico `as raras e incr´ıveis pessoas que me ajudam a evoluir em cada di´alogo profundo ou por meio de suas lindas atitudes.

(6)

Agradecimentos

`

A minha mãe com quem aprendi sobre dedica¸cão e valores. Aos meus irmãos Fabian e Fredy com quem aprendi sobre parceria. À minha esposa Vivianne com quem aprendi sobre for¸ca. Aos meus filhos queridos, Caio, Ellis, Clarisse e Duda com quem aprendi sobre amor. Aos meus avós com quem aprendi sobre o tempo e a saudade. À minha irmã Fabiana com quem aprendi sobre manter o foco com os ombros relaxados. Aos amigos e colegas que compartilharam de sua experiência para a escrita deste trabalho. Aos colegas do IFS pela parceria e compreensão a todo instante. Ao meu orientador Prof. Dr. Michel dos Santos Soares pela confian¸ca, paciência e orienta¸cão. Ao meu coorientador Prof. Dr. Rogério P. C. do Nascimento pelas palavras de incentivo e encorajamento. Ao Prof. Dr. Methanias Cola¸co pela confian¸ca e empurrões. Ao amigo Mário Farias por representar neste mestrado aquele amigo que aparece na hora certa. Aos poucos e verdadeiros amigos, pessoas incr´ıveis com quem aprendi sobre confian¸ca e troquei minhas experiências mais profundas.

(7)

“Amar e mudar as coisas” (Belchior)

(8)

Resumo

MATOS, Flaygner. PREOrg: Um Guia para Elicita¸cão de Requisitos Orientado ao Desempenho Organizacional. 2018. 103 f. Disserta¸cão (Mestrado em Ciência da Computa¸cão) – Pró-Reitoria de Pós-Gradua¸cão e Pesquisa, Universidade Federal de Sergipe, Sergipe, 2018.

No ciclo de desenvolvimento de software, a elicita¸cão de requisitos é uma das primeiras ati-vidades a serem realizadas, podendo ser repetida em todas as demais etapas da engenharia de requisitos. O Analista de Negócios precisa entender profundamente as caracter´ısticas da organiza¸cão onde atua, entendendo os processos de negócio e buscando o conhecimento necessário à propositura de alternativas inteligentes aos processos. Técnicas de elicita¸cão de requisitos auxiliam na identifica¸cão de um maior volume de requisitos, ao sugerirem que a elicita¸cão de requisitos seja realizada de maneira próxima aos processos de negócio da organiza¸cão, todavia não observam o quanto a elicita¸cão de requisitos deve apoiar a melhoria no desempenho organizacional. O interesse por essa pesquisa surgiu mediante a preocupa¸cão com a evolu¸cão e melhorias das técnicas e metodologias encontradas na área de engenharia de requisitos, com o desafio e a necessidade de desenvolver sistemas que realmente atendam às expetativas dos stakeholders e que, acima de tudo, tenham maior engajamento com as áreas de negócio das organiza¸cões. O trabalho propõe o desenvolvi-mento de um guia para a elicita¸cão de requisitos orientada ao desempenho organizacional. O PREOrg é um guia de boas práticas para elicita¸cão de requisitos de software orientado ao desempenho organizacional que propõe a identifica¸cão de oportunidades para a gera¸cão de resultado, melhoria dos processos e apoio à tomada de decisão, desde a etapa de elicita¸cão de requisitos de software. Dois estudos de casos foram realizados com o objetivo de encontrar evidências da eficiência e a eficácia do PREOrg. O primeiro estudo de caso foi realizado na indústria envolvendo um software e o segundo numa organiza¸cão pública envolvendo três softwares. Um treinamento foi realizado, envolvendo analistas de sistemas responsáveis por elicitar requisitos para a constru¸cão dos softwares, de maneira a propiciar o conhecimento dos processos propostos pelo PREOrg. Como resultado, foram encontradas evidências de que o PREOrg contribuiu para a defini¸cão de requisitos capazes de apoiar o desenvolvimento de softwares orientados ao desempenho organizacional. O primeiro estudo de caso apresentou evidências de melhoria financeira para a organiza¸cão onde o software

(9)

foi implantado. No segundo estudo de caso foram descobertas evidências de que o uso do PREOrg é útil para a elicita¸cão de requisitos que apoiem o desenvolvimento de softwares capazes de ajudar na tomada de decisão e na melhoria dos processos organizacionais.

Palavras-chaves: Engenharia de software, engenharia de requisitos, elicita¸c˜ao de requisitos, desempenho organizacional.

(10)

Abstract

MATOS, Flaygner. PREOrg: A Good Practices Guide For Requirements Elici-tation Oriented to Organizational Performance. 2018. 103 p. Dissertation (Master of Science of Computer) – Dean of Graduate Studies and Research, Federal University of Sergipe, Sergipe, 2018.

In the software development cycle, requirements elicitation is one of the first activities to be performed and can be repeated in all other stages of requirements engineering. The Business Analyst needs to understand deeply characteristics of the organization where it operates by understanding business processes and seeking the necessary knowledge to propose intelligent alternatives to the processes. Requirements elicitation techniques help to identify a greater volume of requirements by suggesting that requirements elicitation is performed in a way close to the organization’s business processes but do not observe how elicitation of requirements should support the improvement in organizational performance. Interest in this research arose through the concern with evolution and improvements of techniques and methodologies found in the area of requirements engineering, with the challenge and the need to develop systems that truly meet the expectations of stakeholders and that, above all, engagement with business areas of organizations. This research proposes the development of a guide to requirements elicitation oriented to organizational performance. PREOrg is a guide to best practices for elicitation of software requirements oriented to organizational performance that proposes identification of opportunities for generation of results, improvement of processes and support to decision making, from elicitation of software requirements. Two case studies were performed with the objective of proving the efficiency and effectiveness of PREOrg. The first case study was carried out in industry involving software and the second in a public organization involving three softwares in both cases a training was carried out involving systems analysts responsible for eliciting requirements for the construction of the software, in order to provide knowledge of the processes proposed by PREOrg. As a result, evidence was found that PREOrg contributed to definition of requirements capable of supporting development of software oriented to organizational performance. First case study presented evidence of financial improvement for the organization where software was deployed. In the second case study, evidence was found that the use of PREOrg is useful for elicitation of requirements

(11)

that support the development of software capable of assisting in decision making and improvement of organizational processes.

Keywords: software engineering, requirements engineering, requirements elicitation, orga-nizational performance.

(12)

Lista de ilustra¸c˜

oes

Figura 1 – PREOrg: Processo geral . . . 35

Figura 2 – Organograma classificado . . . 36

Figura 3 – Entrega da informa¸c˜ao . . . 39

Figura 4 – Parˆametros da informa¸c˜ao . . . 45

Figura 5 – Linha do tempo do estudo de caso e coleta dos dados . . . 55

Figura 6 – Gr´afico: Quantidade de Vendas . . . 57

Figura 7 – Gr´afico: QQ normal de CRM A . . . 57

Figura 8 – Gr´afico: QQ normal de CRM B . . . 58

Figura 9 – Gr´afico: Faturamento . . . 59

Figura 10 – Gr´afico: QQ normal de CRM A $ . . . 60

Figura 11 – Gr´afico: QQ normal de CRM B $ . . . 60

Figura 12 – Gr´afico: Quantidade de Stakeholders . . . 68

Figura 13 – Gr´afico: Requisitos . . . 68

Figura 14 – Gráfico: Apura¸cão de sele¸cões para a Questão 1 . . . 73

Figura 15 – Gráfico: Apura¸cão de sele¸cões para a Questão 2 . . . 74

Figura 16 – Abertura . . . 97

Figura 17 – ´Areas abordadas pelo PREOrg . . . 97

Figura 18 – O quê o PREOrg não é. . . 97

Figura 19 – PREOrg - Conceito . . . 97

Figura 20 – A meta do PREOrg . . . 97

Figura 21 – Onde atua o PREOrg. . . 97

Figura 22 – Baleias Jubarte - Exemplo que visa analisar a atividade de identifica¸c˜ao de Stakeholders . . . 98

Figura 23 – Baleias Jubarte - Quem s˜ao os Stakeholders? . . . 98

Figura 24 – Baleias Jubarte - Uma visão da importância da organiza¸cão e das pessoas afetadas no processo de identifica¸cão de Stakeholders . . . 98

Figura 25 – Baleias Jubarte - A responsabilidade do analista de sistemas na identi-fica¸c˜ao dos Stakeholders. . . 98

(13)

Figura 26 – Estudo de caso 1 - Apresenta¸cão e análise dos resultados do primeiro experimento realizado durante o processo de desenvolvimento de uma software CRM (Gestão de relacionamento com clientes). . . 99 Figura 27 – PREOrg - Imagem que apresenta a visão geral do guia . . . 99 Figura 28 – PREOrg - Imagem de abertura da Sessão que apresenta o processo:

Classifica¸cão. . . 99 Figura 29 – PREOrg - Defini¸cão do processo de classifica¸cão dos Stakeholders . . . 99 Figura 30 – PREOrg - Como classificar os Stakeholders. . . 99 Figura 31 – PREOrg - Exemplo de como classificar os Stakeholders utilizando o

organograma da organiza¸c˜ao . . . 99 Figura 32 – PREOrg - Resultado da classifica¸c˜ao dos Stakeholders do Exemplo

anterior . . . 100 Figura 33 – PREOrg - An´alise dos resultados do primeiro experimento (CRM) na

classifica¸c˜ao de Stakeholders . . . 100 Figura 34 – Atividade - Aplicar o processo de classifica¸c˜ao de Stakeholders num

projeto de software numa sessão de brainstorming com 10 minutos de dura¸cão . . . 100 Figura 35 – PREOrg - Imagem de abertura da Se¸cão que apresenta o processo: Entrega100 Figura 36 – PREOrg - Contextualiza¸cão do processo de Entrega da informa¸cão . . 100 Figura 37 – PREOrg - Contextualiza¸cão do processo de Entrega da informa¸cão . . 100 Figura 38 – PREOrg - Defini¸cão do processo de Entrega da informa¸cão . . . 101 Figura 39 – PREOrg - Defini¸cão do processo de Entrega da informa¸cão: Sa´ıdas

ativas e passivas . . . 101 Figura 40 – Entrega da informa¸cão - Sa´ıdas passivas . . . 101 Figura 41 – Entrega da informa¸cão - Sa´ıdas ativas . . . 101 Figura 42 – PREOrg - Análise dos resultados do primeiro experimento (CRM) no

processo de Entrega da informa¸c˜ao . . . 101 Figura 43 – PREOrg - Imagem de abertura da Se¸c˜ao que apresenta o processo:

Oportunidade . . . 101 Figura 44 – PREOrg - Defini¸cão do processo Oportunidades estratégicas . . . 102 Figura 45 – PREOrg - Análise dos resultados do primeiro experimento (CRM) no

(14)

Figura 46 – Atividade - Aplicar os processos, Entrega da informa¸cão e Oportunidades estratégicas num projeto de software numa sessão de brainstorming com

15 minutos de dura¸c˜ao . . . 102

Figura 47 – PREOrg - Imagem de abertura da Se¸c˜ao que apresenta o processo: Parˆametros . . . 102

Figura 48 – PREOrg - Defini¸cão do processo: Parâmetros da informa¸cão . . . 102

Figura 49 – Parâmetros da informa¸cão: Tipos de parâmetros . . . 102

Figura 50 – Parâmetros da informa¸cão: Linha de tempo da informa¸cão . . . 103

Figura 51 – Parâmetros da informa¸cão: Linha de tempo da informa¸cão estratégica . 103 Figura 52 – PREOrg - Análise dos resultados do primeiro experimento (CRM) no processo: Parâmetros da informa¸cão . . . 103

Figura 53 – Atividade - Aplicar o processo Parâmetros da informa¸cão num projeto de software numa sessão de brainstorming com 15 minutos de dura¸cão 103 Figura 54 – Encerramento e espa¸co para perguntas . . . 103

(15)

Lista de tabelas

Tabela 1 – Dados dos analistas . . . 49

Tabela 2 – Lista de requisitos antes e depois do PREOrg. . . 50

Tabela 3 – Vendas por vendedor . . . 56

Tabela 4 – Faturamento por vendedor . . . 56

Tabela 5 – Resumo Estat´ıstico para os parˆametros populacionais descritos na Tabela 3 56 Tabela 6 – Resumo Estat´ıstico para os parˆametros populacionais descritos na Tabela 4 59 Tabela 7 – Dados dos analistas . . . 65

Tabela 8 – Sistemas e seus analistas . . . 65

Tabela 9 – Quantidade de stakeholders . . . 68

Tabela 10 – Quantidade de requisitos . . . 68

Tabela 11 – Boletim de servi¸cos: Requisitos antes e depois do PREOrg. . . 69

Tabela 12 – Lato sensu: Requisitos antes e depois do PREOrg. . . 70

Tabela 13 – Jubilamento: Requisitos antes e depois do PREOrg. . . 71

Tabela 14 – Respostas `a quest˜ao 1 . . . 72

Tabela 21 – Comparativo de respostas individuais entre as quest˜oes 5 e 7 . . . 78

Tabela 24 – Respostas `a quest˜ao 10. . . 81

Tabela 25 – Respostas `a quest˜ao 11. . . 83

(16)

Lista de abreviaturas e siglas

PREOrg Guia de boas pr´aticas para elicita¸c˜ao de requisitos de software orientado ao desempenho organizacional

ER Engenharia de requisitos

ES Engenharia de software

EKD Enterprise Development Knowledge

CSRML4BI A goal-oriented requirements approach for collaborative business intel-ligence

REMO-EKD Elicita¸c˜ao de Requisitos Orientada pelo modelo de processo empresa-rial

BI Business intelligence

CRM Customer Relationship Management - Gest˜ao de relacionamento com clientes

UFS Universidade Federal de Sergipe

(17)

Sum´

ario

1 INTRODUC¸ ˜AO . . . 19

1.1 Revis˜ao da literatura correlata . . . 20

1.2 Quest˜oes de pesquisa . . . 22

1.3 Objetivos da Disserta¸cão . . . 24 1.3.1 Objetivo Geral . . . 24 1.3.2 Objetivos Espec´ıficos . . . 24 1.4 Metodologia . . . 24 1.5 Organiza¸cão do Trabalho . . . 25 2 REFERENCIAL TE ÓRICO . . . 26 2.1 Engenharia de Requisitos . . . 26

2.2 Atividades da engenharia de requisitos . . . 27

2.3 Métodos e técnicas de elicita¸cão de requisitos . . . 30

2.4 Considera¸c˜oes Finais do Cap´ıtulo . . . 33

3 PREORG - GUIA PARA ELICITAC¸ ˜AO DE REQUISITOS ORIEN-TADO AO DESEMPENHO ORGANIZACIONAL . . . 34

3.1 Classifica¸c˜ao dos Stakeholders . . . 35

3.1.1 Etapa 1 - Mapear o organograma da organiza¸c˜ao . . . 37

3.1.2 Etapa 2 - Classificar os stakeholders . . . 37

3.2 Entrega da informa¸c˜ao - Sa´ıdas ativas e sa´ıdas passivas . . . 37

3.2.1 Etapa 1 - Criar sa´ıdas passivas . . . 39

3.2.2 Etapa 2 - Criar sa´ıdas ativas . . . 40

3.3 Oportunidades estrat´egicas . . . 40

3.3.1 Etapa 1 - Mapeamento da rotina dos stakeholders. . . 41

3.3.2 Etapa 2 - Defini¸c˜ao de argumentos estrat´egicos para os requisitos . . . 42

3.3.3 Etapa 3 - Apresenta¸c˜ao da proposta de solu¸c˜ao de software . . . 43

3.4 Parˆametros para a informa¸c˜ao . . . 43

3.4.1 Etapa 1 - Mapear hist´orico de informa¸c˜oes. . . 45

(18)

3.4.3 Etapa 3 - Mapear redes de indicadores . . . 46

3.4.4 Etapa 4 - Mapear perspectivas . . . 46

3.5 Treinamento PREOrg . . . 47

4 AVALIAC¸ ˜AO DO PREORG - SOFTWARE CRM . . . 49

4.1 Objetivo do estudo de caso . . . 50

4.2 Planejamento . . . 50

4.3 Opera¸c˜ao do estudo de caso . . . 53

4.3.1 Prepara¸c˜ao . . . 53

4.3.2 Execu¸c˜ao . . . 54

4.4 Resultados . . . 55

4.4.1 An´alise e Interpreta¸c˜ao de Dados . . . 55

4.4.2 Amea¸cas `a validade . . . 61

5 AVALIAÇ ÃO DO PREORG - N ÚCLEO DE TECNOLOGIA DA INFORMAÇ ÃO DA UNIVERSIDADE FEDERAL DE SERGIPE . . . 63

5.1 Objetivo do estudo de caso . . . 63

5.2 Planejamento . . . 63

5.3 Opera¸c˜ao do estudo de caso . . . 66

5.3.1 Prepara¸c˜ao . . . 66

5.3.2 Execu¸c˜ao . . . 67

5.4 Resultados . . . 67

5.4.1 An´alise Quantitativa e Interpreta¸c˜ao de Dados . . . 67

5.4.2 An´alise Qualitativa e Interpreta¸c˜ao de Dados . . . 72

5.4.3 Amea¸cas `a validade . . . 85

6 CONCLUS ˜AO . . . 87

6.1 Contribui¸c˜oes . . . 88

6.2 Trabalhos futuros . . . 89

(19)

APˆ

ENDICES

96

APˆENDICE A – SLIDES UTILIZADOS NO TREINAMENTO

(20)

19

1 Introdu¸c˜

ao

Requisitos são o ponto de partida para a defini¸cão de um sistema e, consequente-mente, são fatores decisivos no desenvolvimento do produto final (BOURQUE; FAIRLEY et al., 2014). Ainda segundo os autores citados anteriormente, é constante a evolu¸cão das técnicas para processos de desenvolvimento de software mais confiáveis e que satisfa¸cam as necessidades do cliente final. Todavia, apesar do esfor¸co, as técnicas estão voltadas para a identifica¸cão de um maior número de requisitos e que esses satisfa¸cam às necessidades apresentadas pelos stakeholders, mas sem orienta¸cão para os objetivos das organiza¸cões onde os softwares irão operar.

Entender os requisitos de um problema está entre as tarefas mais dif´ıceis enfrentadas por um engenheiro de software. É importante entender o que o cliente quer antes de come¸car a projetar e construir um sistema baseado em computador (SOMMERVILLE, 2011). A elicita¸cão de requisitos abrange a identifica¸cão e descoberta das necessidades dos interessados pelo software (stakeholders), com objetivo de determinar e apresentar as caracter´ısticas e funcionalidades do software quando este for entregue (CARRIZO; DIESTE; JURISTO, 2014).

O estudo (BURNAY; JURETA; FAULKNER, 2015), à respeito da relevância de requisitos, aponta que profissionais responsáveis pelas atividades relacionadas a requisitos de software podem não notar a relevância de um requisito devido ao seu direcionamento mais aprofundado em tecnologia ou pela falta de experiência em um dom´ınio comercial espec´ıfico, ou mesmo devido a sua baixa experiência. A elicita¸cão de requisitos é parte essencial da engenharia de requisitos para assegurar o sucesso do projeto com alta qualidade. O envolvimento dos usuários é um ponto importante nessa etapa de defini¸cão de um software, o que pode vir a exigir do profissional de requisitos criatividade, envolvimento com o negócio da organiza¸cão demandante e experiência para transformar informa¸cões em solu¸cão de software (AL-ZAWAHREH; ALMAKADMEH, 2015).

No artigo (LOUCOPOULOS; GARFIELD, 2009) são apresentados desafios sobre como enfrentar a semântica empresarial, que muitas vezes são dependentes da cultura e das competências interculturais necessárias aos engenheiros de requisitos que operam nesses ambientes. O mesmo artigo afirma que novas técnicas para elicita¸cão de requisitos

(21)

Cap´ıtulo 1. Introdu¸c˜ao 20

precisam se concentrar não apenas no alvo técnico do software, mas também na intera¸cão entre negócios e suas funcionalidades, ajudando a reduzir o espa¸co de comunica¸cão entre stakeholders e os analistas.

1.1 Revis˜

ao da literatura correlata

No estudo (POPOVA; SHARPANSKYKH,2010) uma estrutura foi sugerida para formalizar o conceito de “indicador”, juntamente com suas caracter´ısticas, rela¸cões com outras medidas de desempenho e rela¸cões com outras no¸cões comuns da engenharia de requi-sitos, como metas, processos e papéis. Em (POURSHAHID et al.,2009)(POURSHAHID; RICHARDS; AMYOT, 2011), a linguagem de requisitos orientada a objetivos (GRL) foi ampliada para integrar indicadores com o goal model. Além disso, a adi¸cão de elementos de dados aos modelos de objetivos foi sugerida (POURSHAHID et al.,2013).

Em (VIEIRA et al.,2012), os autores sugerem que a técnica REMO é mais eficiente que formas tradicionais de defini¸cão de requisitos de software (como entrevistas). A técnica REMO-EKD propõe que os processos de negócio precisam ser representados por modelos BPMN. Esta restri¸cão motivou os autores a adaptar a técnica para contemplar o maior número de nota¸cões para modelagem de processos de negócio, propondo assim a técnica REMO-EKD, que consiste em um conjunto de heur´ısticas. O resultado do experimento apontou que não houve consenso geral sobre a facilidade de uso e utilidade da técnica quando aplicada, apesar que os sujeitos indicaram que as heur´ısticas são claras, de fácil compreensão e que aprenderam novas habilidades usando essas heur´ısticas. Importante ressaltar que os resultados da pesquisa sugerem que a técnica pode maximizar o número de requisitos encontrados.

Em (OLIVEIRA et al., 2013), os autores propuseram e avaliaram, por meio de um experimento, a técnica REMO-EKD, que consiste em um conjunto de heur´ısticas para a elicita¸cão de requisitos de software baseados na abordagem Enterprise Development Knowledge (EKD), uma maneira eficaz de entender e caracterizar o contexto organizacional sob diferentes perspectivas. A técnica REMO-EKD - Elicita¸cão de Requisitos Orientada pelo modelo de processo empresarial, visa apoiar a obten¸cão de requisitos de software baseados em modelos EKD, suportando a identifica¸cão de requisitos funcionais e não funcionais, bem como regras de negócio baseadas em modelos organizacionais previamente definidos com base na abordagem EKD. A REMO-EKD é uma adapta¸cão da técnica

(22)

REMO (VIEIRA et al., 2012) ao propor o uso da t´ecnica em organiza¸c˜oes que utilizam a EKD para definir seus modelos organizacionais.

Em (KUMARI; PILLAI,2015), uma extensão do estudo de Nidumolu (NIDUMOLU, 1995)(NIDUMOLU, 1996) foi realizada, como uma tentativa de aplicar os principais resultados da valida¸cão emp´ırica do modelo de contingência (Nidumolu’s contingency model ) para projetos em tempo real. No estudo, o modelo foi testado em 10 projetos de software de grandes organiza¸cões distribu´ıdas globalmente, selecionados aleatoriamente com base em critérios pré-definidos. O resultado da pesquisa forneceu um apoio razoável para as previsões do modelo de contingência proposto por Nidumolu, indicando uma influência positiva sobre a fase de elicita¸cão de requisitos, minimizando problemas-chave e contribuindo para um bom desempenho do projeto. Com base em tais observa¸cões estat´ısticas e feedbacks obtidos a partir de partes interessadas de cada projeto, os autores puderam concluir que os resultados e recomenda¸cões deste modelo de contingência pode ser estendido em larga escala com o objetivo de analisar, validar e confirmar sua eficiência.

Em (TERUEL et al., 2014), uma estrutura orientada a objetivos, CSRML4BI (A goal-oriented requirements approach for collaborative business intelligence), foi proposta para suportar a obten¸cão de requisitos de sistemas de BI, juntamente com uma abordagem para modelagem de requisitos de business intelligence proposta em (MAZ ÓN; PARDILLO; TRUJILLO, 2007). O objetivo é permitir a modelagem cuidadosa dos requisitos de BI colaborativo junto aos usuários e stakeholders que trabalham de maneira isolada.

Em (BEG R.; MUQEEM; FAROOQUI,2013), os autores apontam que a atividade de elicita¸cão de requisitos deve ser a primeira etapa no processo de desenvolvimento de um produto de software, com a clara finalidade de construir uma compreensão do problema. Os autores afirmam que é fundamental um processo de comunica¸cão entre o analista de requisitos e as várias partes interessadas (stakeholders) e que a técnica de entrevista é uma atividade intensa, que exige várias táticas e habilidades de comunica¸cão para além da experiência e do conhecimento e que, num processo de entrevista há a comunica¸cão verbal e outra não-verbal. Inúmeros trabalhos têm sido realizados para melhorar o processo de entrevista com enfoque na comunica¸cão verbal, mas a área da comunica¸cão não-verbal é ainda pouco explorada na área de levantamento de requisitos (BEG R.; MUQEEM; FAROOQUI, 2013). O autores sugerem que o entrevistador deve dar

ˆ

enfase à comunica¸cão não-verbal, juntamente com a comunica¸cão verbal, com o objetivo de obter os requisitos de forma mais eficiente e eficaz. Os autores enfatizam em seu estudo

(23)

os aspectos comportamentais de comunica¸cão não-verbal, ou seja, o uso de expressões faciais, contato visual, gestos, tom de voz, postura corporal, orienta¸cão, toque, e várias pistas e sinais, como a distância entre o entrevistado e o entrevistador, o n´ıvel de humor, e até mesmo caracter´ısticas como o n´ıvel de sonolência, est´ımulo, agita¸cão e sudorese. O estudo aborda uma visão pouco ou ainda não explorada sobre aspectos comportamentais durante a comunica¸cão não verbal, sugerindo que sua observa¸cão pode minimizar os problemas encontrados durante o levantamento de requisitos, de modo que as exigências sejam extra´ıdas e registradas com maior eficácia.

Os estudos apontam que essas técnicas auxiliam na identifica¸cão de um maior volume de requisitos, ao sugerirem que a elicita¸cão de requisitos seja realizada de maneira próxima aos processos de negócio da organiza¸cão. Todavia, os estudos realizados não abordaram se o uso dessas técnicas pode apoiar a melhoria no desempenho organizacional.

O interesse por essa pesquisa surgiu mediante a preocupa¸cão com a evolu¸cão e melhorias das técnicas e metodologias encontradas na área de ER, considerada tão importante para a ES. Os desafios e a necessidade de desenvolver sistemas que realmente atendam às expetativas dos stakeholders e que, acima de tudo, tenham maior engajamento com as áreas de negócio das organiza¸cões. Mais especificamente, este projeto irá considerar o problema da elicita¸cão de requisitos orientada ao desempenho organizacional de forma a apoiar na tomada de decisão, ou na melhoria dos processos ou no aumento dos resultados financeiros. O PREOrg propõe que ao elicitar requisitos com o aux´ılio de técnicas já utilizadas na organiza¸cão e apoiando-se no contexto organizacional, é importante preocupar-se com os resultados que o software depreocupar-senvolvido trará.

1.2 Quest˜

oes de pesquisa

Questões de pesquisa definem o que é necessário saber para cumprir o objetivo do estudo (RUNESON; H ÖST, 2009). A pesquisa descrita em (PERRY; SIM; EASTER-BROOK, 2004) sugere que um estudo de caso tenha questões de pesquisa estabelecidas desde o in´ıcio, os dados sejam coletados de forma planejada e consistente, inferências sejam feitas a partir dos dados para responder à questão de pesquisa e amea¸cas à validade sejam abordadas.

Dois estudos de caso foram realizados neste trabalho, e para cumprir os prop´ositos de pesquisa, ambos foram planejados de acordo com as diretrizes apresentadas em (WOHLIN

(24)

et al.,2012) e seus objetivos foram formalizados utilizando o modelo GQM (Goal-Question-Metric) (BASILI; WEISS, 1984). A execu¸cão de cada estudo de caso está descrita nos Cap´ıtulos 4e 5, desde o planejamento até os resultados obtidos.

Esta pesquisa está embasada na premissa de que “O PREOrg, quando aplicado no processo de elicita¸cão de requisitos de software, pode ajudar a construir softwares que melhorem o desempenho das organiza¸cões”.

Para avaliar esta premissa, duas quest˜oes de pesquisa foram elaboradas para cada estudo de caso:

Quest˜oes de pesquisa do primeiro estudo de caso:

Q1: A partir da aplica¸cão do PREOrg na constru¸cão de um software de CRM, pode-se deduzir diferen¸ca estat´ıstica significativa na média do número de ve´ıculos vendidos em uma concessionária de ve´ıculos?

Q2: A partir da aplica¸cão do PREOrg na constru¸cão de um software de CRM, a empresa aumentou a média dos valores de venda, o que reflete num aumento do seu faturamento?

As questões de pesquisa para o primeiro estudo de caso são respondidas no Cap´ıtulo 4, onde é feita a análise dos resultados obtidos em sua realiza¸cão.

Quest˜oes de pesquisa do segundo estudo de caso:

Q1: A lista de stakeholders e de requisitos podem sofrer incremento ap´os a aplica¸c˜ao do PREOrg?

Q2: Com base na avalia¸cão dos analistas de sistemas envolvidos no estudo de caso, os novos requisitos podem servir de base para solu¸cões de software que apoiem a melhoria do desempenho da Universidade Federal de Sergipe (UFS), seja atraindo resultados diretos, ou melhorando a eficiência nos processos ou apoiando a tomada de decisão?

As questões de pesquisa para o segundo estudo de caso são respondidas no Cap´ıtulo 5, onde é feita a análise dos resultados obtidos em sua realiza¸cão.

(25)

1.3 Objetivos da Disserta¸c˜

ao

1.3.1 Objetivo Geral

O objetivo geral desse trabalho é propor e testar um guia de boas práticas para elicita¸cão de requisitos orientada ao desempenho organizacional, com a finalidade de desenvolver softwares eficientes no apoio a processos e na tomada de decisão sob o ponto de vista dos analistas de requisitos e dos gestores no contexto das organiza¸cões.

1.3.2 Objetivos Espec´ıficos

• Propositura e desenvolvimento de um guia de boas práticas para elicita¸cão de requisitos, que leve os profissionais da engenharia de software a elicitar requisitos de sistemas com ênfase em melhorar o desempenho das organiza¸cões;

• Aplicar o guia proposto na ind´ustria com o objetivo de avaliar preliminarmente sua eficiˆencia;

• Aplicar o guia proposto num departamento responsável pelo desenvolvimento de solu¸cões de software para uma organiza¸cão pública, com o objetivo de avaliar se também há eficiência de sua aplica¸cão nesse cenário;

• Avaliar quantitativamente e qualitativamente os resultados da aplica¸cão do guia proposto, por meio das melhorias nos processos organizacionais, ou em seu n´ıvel de apoio à tomada de decisão, ou na melhoria dos resultados financeiros para a organiza¸cão.

1.4 Metodologia

No intuito de alcan¸car os objetivos propostos, foi realizada uma revis˜ao da literatura e dois estudos de caso como instrumentos de pesquisa.

O objetivo de realizar a revisão da literatura, apresentada na Se¸cão 1.1, foi buscar trabalhos que ajudassem a adquirir conhecimentos sobre técnicas para elicita¸cão de requisitos, descobrir o estado da arte e como essas técnicas podem ser utilizadas. As buscas foram restritas aos últimos dez anos e o idioma em inglês, consultadas nas bases digitais IEEExplore, ACM, Scopus e ScienceDirect.

(26)

O PREOrg foi avaliado em dois estudos de caso, o primeiro deles apresentado no Cap´ıtulo 4, buscou em uma análise quantitativa, relacionar o aumento na quantidade de ve´ıculos vendidos e no faturamento de uma concessionária no estado da Bahia ao se utilizar um software desenvolvido a partir dos requisitos elicitados com a aplica¸cão do PREOrg. O segundo estudo de caso, apresentado no Cap´ıtulo 5, buscou avaliar quali-tativamente, sob o ponto de vista de analistas de sistemas da Universidade Federal de Sergipe, o quanto o PREOrg pode ajudar a desenvolver softwares capazes de melhorar o desempenho organizacional, seja no apoio à tomada de decisão ou na melhoria dos processos organizacionais.

A análise dos resultados foi realizada mediante a compara¸cão dos dados obtidos antes e depois da aplica¸cão do PREOrg. Neste sentido, o primeiro estudo de caso analisou a equipe de vendas da concessionária comparando o seu desempenho nas vendas ao utilizar um software CRM desenvolvido com a aplica¸cão do PREOrg contra o desempenho nas vendas dessa mesma equipe ao utilizar um software de apoio às vendas desenvolvido sem a aplica¸cão do PREOrg. No segundo estudo de caso foram analisadas as listas de requisitos e de Stakeholders de três softwares, antes e depois da aplica¸cão do PREOrg. Em seguida, os analistas de sistemas envolvidos no estudo de caso responderam a um questionário de pesquisa com o intuito de permitir uma avalia¸cão qualitativa dos resultados obtidos com a aplica¸cão do PREOrg.

1.5 Organiza¸c˜

ao do Trabalho

No Cap´ıtulo2são apresentados conteúdos relevantes para a realiza¸cão deste trabalho. Inicialmente, conceitos sobre engenharia de requisitos e suas atividades são explanadas. Em seguida, as técnicas para elicita¸cão de requisitos utilizadas no PREOrg são explicadas. No Cap´ıtulo 3 o modelo proposto pelo PREOrg é apresentado, e suas etapas e atividades são detalhadas. Por fim, o planejamento do treinamento para o guia é descrito.

No Cap´ıtulo 4 s˜ao apresentados o planejamento, a execu¸c˜ao e os resultados do primeiro estuco de caso realizado nesta pesquisa.

No Cap´ıtulo 5 s˜ao apresentados o planejamento, a execu¸c˜ao e os resultados do segundo estudo de caso realizado nesta pesquisa.

Por fim, no Cap´ıtulo6 são apresentadas as respostas às questões da pesquisa, as contribui¸cões do trabalho e as sugestões de trabalhos futuros.

(27)

26

2 Referencial Te´

orico

2.1 Engenharia de Requisitos

Requisitos de Software expressam as necessidades e limita¸cões em um produto de software que contribui para a solu¸cão de algum problema do mundo real (BOURQUE; FAIRLEY et al., 2014). Pode-se afirmar que os requisitos de um software incluem es-pecifica¸cões das funcionalidades que o software deve fornecer, limites sob as quais ele deve operar, propriedades gerais do software e restri¸cões que devem ser satisfeitas no seu processo de desenvolvimento (SOMMERVILLE, 2011).

A Engenharia de Requisitos (ER) é definida em (BOEHM, 1989) como uma disciplina cujo objetivo é desenvolver uma especifica¸cão completa, consistente e não amb´ıgua, servindo de base para um acordo entre todas as partes envolvidas e descrevendo o que o produto de software irá fazer ou executar, mas não como ele será feito. A ER está envolvida com os objetivos e metas, fun¸cões e restri¸cões de um software. Também está relacionada com especifica¸cões precisas do comportamento do software para futuras manuten¸cões e atualiza¸cões (LAPLANTE, 2013). A ER é imprescind´ıvel para resolver os problemas encontrados nas organiza¸cões com rela¸cão às defini¸cões necessárias para o sucesso de projetos de software. Os autores do artigo (BHATTI; USMAN; JADI, 2015) afirmam que a engenharia de requisitos come¸ca com a elicita¸cão dos requisitos e que a elicita¸cão mal feita desses requisitos leva à falha de projetos.

Os autores do artigo (AL-ZAWAHREH; ALMAKADMEH,2015) afirmam que a elicita¸cão de requisitos é parte essencial da engenharia de requisitos para assegurar o sucesso do projeto com alta qualidade e que o envolvimento dos usuários é um ponto importante nessa etapa de defini¸cão de um software, o que pode vir a exigir do analista de requisitos criatividade, envolvimento com o negócio da organiza¸cão demandante e experiência para transformar informa¸cões em solu¸cão de software. Esses profissionais precisam entender melhor seu papel nesse cenário, buscando mudar a maneira como os usuários os enxergam nas organiza¸cões. Para isso, é preciso acreditar que o produto de software deve buscar benef´ıcios diretos para as organiza¸cões, mudando a forma como estas gerenciam seus processos ou tomam suas decisões. Esses profissionais devem se aprofundar nos processos

(28)

Cap´ıtulo 2. Referencial Te´orico 27

das organiza¸cões onde atuam, buscando o conhecimento necessário à propositura de alternativas inteligentes e eficazes, entender como os usuários resolvem seus problemas, observando os processos manuais ou mesmo os automatizados, trazendo uma visão cr´ıtica e construtiva que apontem melhorias.

Os autores dos artigos (CHENG; ATLEE, 2007) (JWO; CHENG, 2010) afirmam que, mesmo com uma equipe competente de gestão de projetos, é poss´ıvel ainda cometer falhas relativas aos requisitos ao longo das atividades de desenvolvimento de um software. As necessidades dos usuários podem não ser corretamente e completamente identificadas durante a fase de elicita¸cão de requisitos.

A Engenharia de Requisitos - ER envolve principalmente os processos de identificar, documentar, analisar e verificar as restri¸cões e servi¸cos de um software (SOMMERVILLE, 2011). Os processos na engenharia de requisitos variam muito de uma organiza¸cão para outra, principalmente em fun¸cão das caracter´ısticas dos projetos. Definir processos apropri-ados traz muitos benef´ıcios, pois estes fornecerão orienta¸cões capazes de reduzir falhas no projeto de software e trarão benef´ıcios diretos, como maior agilidade no desenvolvimento, diminui¸cão de custos, redu¸cão de retrabalho, melhor comunica¸cão, redu¸cão nas mudan¸cas de escopo, estimativas mais assertivas e a maior satisfa¸cão dos demandantes.

2.2 Atividades da engenharia de requisitos

A ER pode ser dividida em dois grupos de atividades: o desenvolvimento de requisitos, que inclui as atividades de como elicitar, documentar, analisar e validar os requisitos, e o gerenciamento de requisitos, que inclui atividades relacionadas à manuten¸cão, tais como rastreabilidade e gerenciamento de mudan¸cas de requisitos (LAMSWEERDE, 2000)(PARVIAINEN et al.,2005)(CARRIZO; DIESTE; JURISTO,2014). Essas atividades são brevemente explicadas a seguir.

• Elicita¸c˜ao:

A elicita¸cão de requisitos é o processo por meio do qual o demandante e o fornecedor descobrem, avaliam, articulam e compreendem os requisitos do sistema e o seu ciclo de vida (IEEE, 2011). A elicita¸cão de requisitos é a fase inicial do processo de engenharia de requisitos e envolve atividades de descoberta desses requisitos. Nessa fase, é necessário um esfor¸co conjunto de todos os stakeholders. Entender a

(29)

organiza¸cão e seus processos, as necessidades e, até mesmo, poss´ıveis deficiências de sistemas existentes, fazem parte dessa importante etapa na engenharia de requisitos. Consideram-se interessados no sistema todas as pessoas que são afetadas por ele de alguma maneira, dentre elas, clientes, usuários finais e gestores em todos os seus n´ıveis.

• Documenta¸c˜ao:

Elicita¸cão e documenta¸cão de requisitos são atividades iniciais que consistem na defini¸cão das funcionalidades que serão criadas para o software (PRESSMAN; MA-XIM, 2016) (BRAUDE; BERNSTEIN, 2016). Os requisitos em n´ıvel de usuário são focados no dom´ınio do problema e são o principal meio de comunica¸cão entre os clientes e os desenvolvedores (PAECH et al.,2005). Os requisitos devem ser revisados e aprovados por todos os envolvidos nessa etapa (SOMMERVILLE, 2011).

A documenta¸cão de requisitos em n´ıvel de usuário é utilizada em todas as fases do ciclo de vida do desenvolvimento do software, desde as fases iniciais até a homologa¸cão e entrega do produto final (LAPLANTE, 2013)(WIEGERS; BEATTY, 2013)(BRAUDE; BERNSTEIN, 2016). A partir da documenta¸cão de requisitos em n´ıvel de usuário, outros artefatos, como requisitos em n´ıvel de sistema que são descri¸cões mais detalhadas dos requisitos, como também diagramas e tabelas que auxiliam na interpreta¸cão dos requisitos, podem ser utilizados para apoiar outras fases da Engenharia de Software, como a fase de desenvolvimento e testes de software onde são criados o código fonte e os casos de teste (POHL,2010)(BUEDE; MILLER, 2016).

Entre os problemas encontrados na ER, os relacionados à documenta¸cão de requi-sitos, que muitas vezes é realizada de forma incompleta e de dif´ıcil compreensão pelos envolvidos no projeto, continuam como desafios a serem superados (HALL; BEECHAM; RAINER, 2002)(MAFRA et al., 2016). As principais causas de pro-blemas relacionados à documenta¸cão de requisitos em um projeto de software são: falhas de comunica¸cão entre equipe de desenvolvimento e o cliente; não utiliza¸cão de um processo bem definido para realizar ER; utiliza¸cão de técnicas de elicita¸cão de requisitos deficientes; utiliza¸cão deficiente ou não utiliza¸cão de um modelo para documenta¸cão dos requisitos e a falta de especialistas em requisitos envolvidos no projeto (FERN ÁNDEZ et al., 2015)(MAFRA et al., 2016).

(30)

Defeitos gerados a partir de erros inseridos em um documento de requisitos podem ser catastróficos para um projeto de software, devido ao efeito cascata gerado pelo uso desse documento em todas as fases do processo (BERRY, 2004). Erros nos documentos de requisitos podem proliferar pelas várias fases do processo de desenvolvimento, levando a um software de baixa qualidade (ELLIS; BERRY, 2013). A documenta¸cão destes requisitos desempenha um papel crucial em engenharia de software na medida em que deve comunicar os requisitos para os clientes de uma forma compreens´ıvel e definir requisitos em detalhes precisos para os desenvolvedores do sistema (NICOL ÁS; TOVAL,2009). É importante que os requisitos sejam capazes de transmitir com clareza os objetivos do usuário, que sejam de fácil manuten¸cão e possibilitem aos engenheiros de software validar sua implementa¸cão (IEEE,2011).

• An´alise:

A análise de requisitos descreve as tarefas e técnicas utilizadas por um analista de negócios para analisar requisitos declarados, no intuito de definir as capacidades requeridas de uma solu¸cão potencial para atender às necessidades das partes in-teressadas (IIBA, 2015). Esta fase é fundamental para o sucesso do processo de desenvolvimento do software. Nela, o engenheiro de requisitos especifica as fun¸cões e desempenho do software, indica a interface do software com outros sistemas e estabelece as restri¸cões de projeto do software (PRESSMAN; MAXIM, 2016).

• Valida¸c˜ao:

A valida¸cão de requisitos é um trabalho de garantia de qualidade da engenharia de requisitos que busca assegurar que todos os requisitos especificados estejam alinhados com os requisitos de negócio. Ou seja, procura garantir que todas as necessidades de negócio das partes interessados no escopo do projeto serão satisfeitas (VAZQUEZ; SIM ÕES, 2016).

O custo para descobrir e corrigir um defeito de software na fase de testes é de 5 a 100 vezes maior que o custo para se corrigir o mesmo problema ainda na fase de requisitos (BOEHM; BROWN; LIPOW, 1976)(IN; BOEHM, 2001). Um estudo envolvendo empresas europeias de desenvolvimento de software registrou que mais de 50% delas apontaram problemas na área de especifica¸cão de requisitos (BRIAND et al., 2000).

(31)

• Rastreabilidade:

Uma das atividades relativas ao gerenciamento de requisitos é a rastreabilidade de requisitos, que é um mecanismo importante para a gestão e auditoria de todo o processo de desenvolvimento de software (LAGO; MUCCINI; VLIET,2009). A rastre-abilidade influencia na qualidade de produtos de software facilitando sua reutiliza¸cão (CLELAND-HUANG et al., 2012). A prática efetiva de rastreabilidade ajuda na compreensão do software, análise de impacto, debug do software e comunica¸cão entre os membros da equipe (ASUNCION; FRANÇ OIS; TAYLOR, 2007). A utiliza¸cão de ferramentas ajuda a aprimorar a precisão e reduz o tempo necessário para identificar rela¸cões de rastreabilidade (LUCIA et al., 2007) obtendo benef´ıcios econômicos, técnicos e sociais (FILHO, 2011).

• Gest˜ao de mudan¸cas de requisitos:

O processo de gerência de requisitos envolve as atividades que ajudam a equipe de desenvolvimento a identificar, controlar e rastrear requisitos e gerenciar mudan¸cas de requisitos em qualquer momento ao longo do ciclo de vida do software ( SOMMER-VILLE, 2011) (PRESSMAN; MAXIM, 2016). Os principais objetivos desse processo são: gerenciar altera¸cões nos requisitos acordados; gerenciar relacionamentos entre requisitos e gerenciar dependências entre requisitos e outros documentos produzidos durante o processo de software (SOMMERVILLE, 2011). Para tal, o processo de gerência de requisitos inclui diversas atividades, como controle de mudan¸cas, controle de versão, acompanhamento do estado dos requisitos e rastreamento de requisitos.

O controle de mudan¸ca define os procedimentos, processos e padrões que devem ser utilizados para gerenciar as altera¸cões de requisitos, assegurando que qualquer proposta de mudan¸ca seja analisada conforme os critérios estabelecidos pela orga-niza¸cão. Mudan¸cas podem ser necessárias em diferentes momentos e por diferentes razões. Para garantir uma abordagem consistente, recomenda-se que as organiza¸cões definam um conjunto de pol´ıticas de gerência de mudan¸ca (SOMMERVILLE, 2011).

2.3 M´etodos e t´ecnicas de elicita¸c˜

ao de requisitos

A norma ISO 29148 descreve a elicita¸cão de requisitos como uma atividade iterativa onde várias técnicas para identificar requisitos podem ser utilizadas (IEEE, 2011). A

(32)

atividade de elicita¸cão de requisitos pode contar com o uso dessas técnicas, as quais visam melhorar a comunica¸cão entre os envolvidos e facilitar o entendimento de suas necessidades. Uma técnica deve explorar atividades espec´ıficas da elicita¸cão de requisitos, por isso a combina¸cão de mais de uma técnica é comum. O uso correto de técnicas de elicita¸cão é uma competência decisiva para o sucesso do projeto e melhores resultados são alcan¸cados com uma combina¸cão de várias técnicas diferentes (POHL, 2010). Todavia, a eficiência prática dessas técnicas pode variar de acordo com a sistemática de sua aplica¸cão num projeto de software. Apenas os analistas experientes percebem intuitivamente qual método ou técnica é efetiva em cada circunstância e conseguem aplicá-la com eficiência durante o processo de elicita¸cão de requisitos.

Diversas técnicas e modelos estão descritos na literatura para a elicita¸cão de requi-sitos de software, como por exemplo entrevista, questionários, brainstorming, workshops, observa¸cão de ambiente ou padrões de trabalho (Etnografia), revisão da documenta¸cão técnica, análise de mercado ou avalia¸cão do sistema competitivo, simula¸cões, prototipagem, entre outras (IEEE,2011)(SOMMERVILLE,2011)(CARRIZO; DIESTE; JURISTO,2014). As técnicas definidas a seguir, são utilizadas nos processos propostos pelo PREOrg e nos estudos de caso utilizados em sua valida¸cão:

• Entrevistas:

Entrevista é uma conversa direcionada com um propósito espec´ıfico, que utiliza um formato pergunta-resposta (KENDALL; KENDALL, 2010). Entrevistas são usadas em quase todos os esfor¸cos de levantamento de requisitos. Nelas, os analistas formulam questões para os interessados e os requisitos são derivados das respostas a essas perguntas (SOMMERVILLE, 2011).

As entrevistas podem ser fechadas, nas quais o interessado responde a um conjunto de perguntas previamente elaboradas; ou abertas, para as quais não existe um roteiro predefinido. Neste último tipo, o analista explora vários assuntos com o objetivo de compreender as necessidades dos stakeholders. Geralmente, as entrevistas são uma combina¸cão dos dois tipos, dado que as discussões completamente abertas dificilmente funcionam bem, por isso algumas perguntas podem ser elaboradas como ponto de partida para conduzir a outros questionamentos discutidos de maneira menos estruturada (SOMMERVILLE,2011).

(33)

• Question´arios:

Questionários ou survey é a técnica de levantamento de informa¸cões que permite ao analista capturar, entre várias pessoas afetadas pelo sistema, atitudes, cren¸cas, comportamentos e caracter´ısticas. Atitudes referem-se a o que as pessoas na orga-niza¸cão dizem querer; cren¸cas referem-se a o que as pessoas pensam ser realmente verdade; comportamento é o que as pessoas fazem; caracter´ısticas são propriedades de pessoas ou coisas (KENDALL; KENDALL, 2010).

Questionários proveem um meio eficiente de coletar informa¸cões de vários interessados. Entretanto, são limitados no que tange à profundidade do conhecimento que pode ser levantado, uma vez que não permitem que um tópico seja aprofundado ou que ideias sejam expandidas (WOHLIN et al., 2005). Cada usuário responde o questionário individualmente e depois os requisitos são identificados por meio de análise das respostas fornecidas (BARBOSA et al., 2009).

• Brainstorming:

Técnica em que stakeholders com diferentes interesses se reúnem para apresentar tantas ideias quanto poss´ıveis sobre os requisitos do sistema, sem focar a aten¸cão em nenhuma delas. O diferencial dessa técnica é a promo¸cão da livre expressão, e isso favorece a descoberta de solu¸cões inovadoras para os problemas existentes (WOHLIN et al., 2005).

As ideias são postas de maneira que todos os presentes possam ser influenciados e possam opinar. Em seguida, o processo de sele¸cão das ideias é reiniciado, podendo ser alteradas ou mescladas, buscando engajar diferentes grupos de interessados em um debate informal em busca de ideias poss´ıveis. Um diferencial dessa técnica é que ela promove a livre expressão, favorecendo a descoberta de novas e inovadoras solu¸cões para problemas existentes (WOHLIN et al.,2005).

• Etnografia:

Consiste em observar o comportamento dos indiv´ıduos em seu ambiente de trabalho. Técnica útil, pois com ela é poss´ıvel identificar como as atividades são realizadas e qual tipo de suporte computacional será realmente necessário. A técnica pode ainda confirmar ou refutar informa¸cões obtidas por outras técnicas. A etnografia é o estudo de pessoas em seu ambiente natural. No contexto do levantamento de

(34)

requisitos, envolve a participa¸cão ativa ou passiva do analista nas atividades normais dos usuários. Técnicas de etnografia são especialmente úteis para endere¸car fatores contextuais e de ambientes de trabalho cooperativo (WOHLIN et al., 2005).

2.4 Considera¸c˜

oes Finais do Cap´ıtulo

A aplica¸cão de técnicas durante o processo de elicita¸cão de requisitos pode ajudar a garantir o sucesso do projeto de software, todavia, apesar de inúmeras técnicas estarem dispon´ıveis, elas buscam melhorar o processo de elicita¸cão de requisitos com vistas à abrangência dos requisitos elicitados, de forma que o melhor produto de software seja entregue ao invés de a melhor solu¸cão de software para um negócio preocupada com os resultados que o software poderá trazer para a organiza¸cão demandante. O PREOrg irá propor uma nova visão do processo de elicita¸cão de requisitos, preocupada com os processos de negócio da organiza¸cão, todavia não apenas quanto às suas necessidades, mas também com as oportunidades que sua automatiza¸cão poderá lhe render, seja em desempenho para a organiza¸cão, atraindo resultados financeiros, eficiência nos processos ou apoiando gestores na tomada de decisão.

(35)

34

3 PREOrg - Guia para Elicita¸c˜

ao de

Requisi-tos Orientado ao Desempenho

Organizaci-onal

O PREOrg é um guia de boas práticas para elicita¸cão de requisitos orientado ao desempenho organizacional, cujo objetivo é aumentar a eficiência no processo de elicita¸cão de requisitos, de maneira que os requisitos elicitados possam servir de base para solu¸cões de software que apoiem a melhoria do desempenho das organiza¸cões, seja atraindo resultados financeiros, eficiência nos processos ou apoio à tomada de decisão.

O PREOrg tem o objetivo de disciplinar os profissionais da engenharia de requisitos a construir softwares que melhorem o desempenho das organiza¸cões, independente das técnicas aplicadas durante o processo de elicita¸cão requisitos, afinal o PREOrg não é uma técnica, mas sim um guia que deve apoiar os processos desenvolvidos pelas técnicas utilizadas na organiza¸cão para este fim.

A Figura 1 apresenta o modelo proposto numa abordagem em quatro estágios aplicáveis: classifica¸cão, entrega, oportunidade e parâmetro, conforme explicado a seguir.

• Classifica¸cão: propõe que os stakeholders sejam classificados de maneira a definir uma abordagem estratégica durante a elicita¸cão de requisitos.

• Entrega: define estratégias de entrega da informa¸cão, de maneira a criar maior engajamento do usuário quanto ao uso do software que será desenvolvido.

• Oportunidade: propõe que argumentos sejam definidos para os requisitos de software propostos, de maneira a mostrar sua aplica¸cão e seus objetivos estratégicos.

• Parâmetro: define que as informa¸cões da organiza¸cão possam ser comparadas a parâmetros e indicadores visando o melhor entendimento organizacional.

(36)

Cap´ıtulo 3. PREOrg - Guia para Elicita¸c˜ao de Requisitos Orientado ao Desempenho Organizacional 35

Figura 1 – PREOrg: Processo geral

3.1 Classifica¸c˜

ao dos Stakeholders

Uma das tarefas em um projeto de software é a identifica¸cão das partes interessadas (stakeholders), indiv´ıduos que são afetados ou responsáveis pelo resultado de um projeto de software. Tanto a pesquisa como a prática sugerem que stakeholders com capacidade de influenciar em projetos desempenham papel crucial para o sucesso destes projetos (WANG; HUANG, 2006)(ASSUDANI; KLOPPENBORG,2010)(AALTONEN, 2011). Pacheco e Garcia (PACHECO; GARCIA, 2012) investigam em sua revisão como a identifica¸cão dos Stakeholders na elicita¸cão de requisitos é realizada com o objetivo de identificar e caracte-rizar as diferentes abordagens e técnicas utilizadas. O estudo observou que a identifica¸cão dos stakeholders na fase de elicita¸cão tem recebido pouca aten¸cão. Os requisitos de um software promovem entradas e sa´ıdas de informa¸cão. As informa¸cões de entrada partem de uma origem, que pode ser uma pessoa, um arquivo ou até mesmo um outro software. Por outro lado, as informa¸cões de sa´ıda estão, geralmente, armazenadas na estrutura provida pelo próprio software, nesse caso o banco de dados. Sendo assim, os requisitos que promovem sa´ıdas de informa¸cão são dependentes daqueles responsáveis pelas entradas, portanto é importante identificar as origens das informa¸cões, que estão normalmente na camada mais operacional da organiza¸cão e o porquê dessas informa¸cões serem armazenadas

(37)

pelo software. As informa¸cões de sa´ıda, quando promovidas de maneira estratégica, podem ajudar os stakeholders a entender melhor a organiza¸cão, apoiando na tomada de decisão, na melhoria dos processos e dos resultados. Por isso, essas informa¸cões precisam chegar à camada mais estratégica da organiza¸cão de alguma maneira. Pode-se então classificar os stakeholders em Operacionais ou Estratégicos e garantir que as informa¸cões que entram no software, normalmente provenientes de um stakeholder operacional, devem ser entregues aos stakeholders estratégicos.

A classifica¸cão de stakeholders deve ser realizada durante o processo de elicita¸cão de requisitos, utilizando técnicas convencionais como entrevista ou brainstorming. Conhecer o organograma da organiza¸cão poderá facilitar o entendimento da estrutura organizacional e permitirá uma visualiza¸cão clara de como as áreas estão relacionadas. Pode-se mapear visualmente a classifica¸cão dos stakeholders no próprio organograma da empresa, o que permite uma visão mais ampla da organiza¸cão no tocante ao processo de desenvolvimento de software, servindo de aux´ılio à lista de stakeholders.

A Figura 2ilustra um exemplo de uma classifica¸c˜ao de stakeholders aplicado num organograma.

Figura 2 – Organograma classificado

Como fazer: na pr´atica a classifica¸c˜ao dos stakeholders deve ser realizada em duas etapas:

(38)

3.1.1 Etapa 1 - Mapear o organograma da organiza¸c˜

ao

O organograma representa a estrutura formal de uma organiza¸cão. Ou seja, é a representa¸cão gráfica clássica de uma estrutura organizacional. Com o organograma o profissional de requisitos saberá a quem os colaboradores e gestores devem prestar contas das suas atividades e qual a estrutura completa de cada setor, pois é nele que estão definidos os n´ıveis hierárquicos dos colaboradores, organizando quem deve responder à quem na organiza¸cão e a estrutura de seus setores. No organograma, anota¸cões devem ser realizadas de maneira a identificar cada pessoa envolvida nos setores, em todos os seus n´ıveis. Para cada pessoa identificada, deve-se anotar o seu contato, horário de trabalho e sua aloca¸cão no organograma.

Ao final da etapa, o profissional de requisitos terá a percep¸cão das áreas de negócios da organiza¸cão, compreendendo quem são os responsáveis pelos setores, quem realiza as opera¸cões e processos, e quais deles tem potencial de envolvimento com o software a ser desenvolvido.

3.1.2 Etapa 2 - Classificar os stakeholders

Após mapeado o organograma, pessoas devem ser abordadas em seus setores, com o intuito de identificar o n´ıvel de envolvimento nos processos de sua área e seu perfil, Operacional ou Estratégico. No organograma, as caixas mais baixas indicam, em geral, o n´ıvel mais operacional, enquanto as caixas mais altas apresentam os gestores, a diretoria e a presidência. Pode-se utilizar cores distintas nas caixas do organograma para identificar cada classe de stakeholders, conforme visto no exemplo da Figura 2.

´

E importante que nesta etapa sejam identificados os gestores que podem precisar das informa¸cões do software para tomar decisões, esses serão stakeholders estratégicos para o software. Entrevistas nos postos de trabalho das pessoas identificadas na Etapa anterior ajudarão nesse processo.

3.2 Entrega da informa¸c˜

ao - Sa´ıdas ativas e sa´ıdas passivas

As áreas de uma organiza¸cão possuem processos e atividades em volume e comple-xidade distintos, isso acaba por influenciar diretamente na disponibilidade de tempo dos gestores e de sua equipe para a realiza¸cão de análises das informa¸cões que um software irá

(39)

prover, além disso alguns gestores podem dar maior ou menor importância às informa¸cões dispon´ıveis. Pode-se distinguir os profissionais que buscam a informa¸cão e disponibilizam maior tempo para sua análise, daqueles que não disponibilizam de tanto tempo para isso. Todavia, um software precisa cumprir sua fun¸cão de entregar a informa¸cão aos stakeholders estratégicos, a questão é como atingir esse objetivo.

Softwares constru´ıdos com visão estratégica promovem maior aproxima¸cão entre a informa¸cão e os objetivos da organiza¸cão. Quanto maior a maturidade do software, maior a preocupa¸cão com a entrega da informa¸cão aos seus usuários. De maneira objetiva, pode-se afirmar que toda informa¸cão armazenada por um software deverá prover ao menos uma sa´ıda para essa mesma informa¸cão. As entregas devem estar alinhadas com a disponibilidade dos stakeholders em rela¸cão ao tempo que disponibilizam para análises das informa¸cões providas pelo software.

A entrega da informa¸cão pode ocorrer por meio de sa´ıdas passivas ou ativas. Sa´ıdas passivas dependem da a¸cão do usuário para que a informa¸cão seja apresentada, portanto serão disponibilizadas por meio de relatórios ou gráficos, podendo trazer maior detalhamento da informa¸cão. Normalmente as sa´ıdas passivas farão parte do dia-a-dia dos stakeholders que se apoiam na informa¸cão para execu¸cão de suas atividades. Esses stakeholders estarão entre os usuários que terão o software como sua fonte de apoio para a execu¸cão de seus processos e para a tomada de decisões importantes. As sa´ıdas ativas devem disponibilizar uma visão mais geral e objetiva da informa¸cão, que podem servir a qualquer perfil de usuário, todavia, serão cruciais para a entrega da informa¸cão aos gestores com menor tempo dispon´ıvel para a análise dessas informa¸cões.

As sa´ıdas ativas não precisam da a¸cão do usuário para que a informa¸cão seja entregue. Utilizando tecnologias que permitam integra¸cão, o software deverá enviar as informa¸cões aos seus usuários de maneira ativa, todavia essas informa¸cões devem ser claras e objetivas, de maneira que atraiam a aten¸cão do stakeholder para que este possa ter o interesse despertado e venha a buscar maior detalhe da informa¸cão nas sa´ıdas passivas. O estudo (SU et al., 2015) sugere que com o rápido desenvolvimento das tecnologias de comunica¸cão móvel, vários tipos de conteúdo podem ser entregues entre usuários móveis para compartilhamento de conteúdo.

Pode-se citar inúmeras oportunidades para a cria¸cão de sa´ıdas ativas num software, incluindo envio de torpedos SMS, e-mail, ou até mesmo meios de comunica¸cão mais abertos como portais de transparência e revistas eletrônicas. Essas últimas poderão permitir

(40)

uma entrega ativa até mesmo a stakeholders externos. Desta forma, é poss´ıvel interligar diferentes entidades (pessoas, dispositivos e sistemas) em locais diferentes (SU; XU, 2015). Uma Intranet poderá ser utilizada para os indiv´ıduos que operam processos ou tomam decisões importantes, portais (Extranet ou Internet) podem disponibilizar a informa¸cão para uma amostra da popula¸cão que tenha interesse pela mesma, mecanismos de integra¸cão para softwares externos podem facilitar a entrega da informa¸cão a organiza¸cões externas.

A Figura3ilustra o fluxo da informa¸c˜ao de um software com sa´ıdas ativas e passivas.

Figura 3 – Entrega da informa¸c˜ao

Como fazer: O processo de entrega da informa¸c˜ao deve ser executado em duas etapas:

3.2.1 Etapa 1 - Criar sa´ıdas passivas

Durante o processo de elicita¸cão de requisitos é necessário dar importância não apenas aos requisitos que tratam das entradas de dados no software, mas também dos requisitos que normalmente são demandados pelos stakeholders estratégicos. Ao classificar stakeholders novas oportunidades para elicitar requisitos surgirão, principalmente nas

(41)

áreas mais estratégicas, e são essas áreas que trazem maior número de demandas por informa¸cão a serem utilizadas para o apoio à tomada de decisão. O profissional de requisitos deve influenciar os stakeholders estratégicos a demandarem relatórios, painéis gráficos e gerenciais, além de qualquer outra fonte de informa¸cão a partir dos dados armazenados no software. Cabe a este, identificar dados que apoiem gestores em seu trabalho diário, identificando necessidades a serem utilizadas em reuniões estratégicas ou em sua rotina.

Planilhas de dados utilizadas por gestores podem ajudar a elicitar novas demandas, para isso é importante identificar material de apoio utilizado em reuniões gerenciais, criar protótipos de relatórios, de consultas e de gráficos, com vistas a melhorar o poder de decisão dos gestores.

3.2.2 Etapa 2 - Criar sa´ıdas ativas

Sa´ıdas ativas devem ser utilizadas para facilitar a entrega da informa¸cão aos usuários e aumentar o engajamento no software. Nem sempre os softwares são utilizados em sua totalidade devido a falta de engajamento ou mesmo de conhecimento dos usuários. Ao identificar requisitos que promovem sa´ıdas passivas o profissional de requisitos deve observar quais facilidades podem ser criadas para o usuário por meio de sa´ıdas ativas. Sumários de dados podem ser enviados por e-mail diariamente com um resumo de informa¸cões gerenciais, alertas podem ser enviados por SMS ou notifica¸cões por meio de aplicativos em dispositivos móveis. As informa¸cões mais importantes para os gestores devem ser utilizadas em sa´ıdas ativas de maneira a aumentar o interesse pelo uso do software e se poss´ıvel devem disponibilizar links diretos para relatórios criados a partir das sa´ıdas passivas identificadas na epata anterior.

3.3 Oportunidades estrat´egicas

As organiza¸cões procuram vantagem competitiva em termos de custo, qualidade e flexibilidade no desenvolvimento de software, procurando aumento da produtividade bem como a dilui¸cão do risco (SENGUPTA; CHANDRA; SINHA, 2006). É importante estabelecer valores mais objetivos ao software durante o processo de defini¸cão do mesmo, buscando compensar os custos por meio daquilo que o software poderá oferecer à or-ganiza¸cão. As organiza¸cões devem justificar custos e recursos para desenvolvimento de

(42)

software e sistemas e outros servi¸cos de TI. Muitas vezes, tal justificativa exige uma demonstra¸cão concreta de como esse desenvolvimento contribuirá para os objetivos globais dos negócios da organiza¸cão (BASILI et al., 2010).

Envolver stakeholders com visão estratégica sobre a organiza¸cão poderá ajudar na identifica¸cão de oportunidades estratégicas para o software. É provável que entrevistas individuais com esses stakeholders possam ajudar a identificar sa´ıdas que apoiem a tomada de decisão ou a melhoria de processos da organiza¸cão ou até mesmo o aumento de seus resultados financeiros, seja por meio da redu¸cão de custos ou pelo aumento dos lucros. Após a abordagem individualizada desses stakeholders é importante tentar cruzar informa¸cões e refinar os requisitos.

Após a fase de entrevistas com os stakeholders estratégicos, o analista terá uma lista de requisitos para valida¸cão, deve-se organizar esses requisitos e identificar com clareza a maneira como a informa¸cão será entregue aos usuários. Em seguida, em uma sessão de brainstorming envolvendo esses stakeholders, os requisitos elicitados poderão ser refinados e validados.

Como fazer: Serão definidas a seguir três etapas que buscam facilitar a identifica¸cão de oportunidades estratégicas durante o processo de elicita¸cão de requisitos e colocar a solu¸cão de software proposta num âmbito estratégico da organiza¸cão sob o ponto de vista de seus gestores.

3.3.1 Etapa 1 - Mapeamento da rotina dos stakeholders

No contexto do levantamento de requisitos, a etnografia envolve a participa¸cão ativa ou passiva do analista nas atividades normais dos usuários. A técnica é especialmente útil para endere¸car fatores contextuais e de ambientes de trabalho cooperativo (WOHLIN et al., 2005). A etnografia é um método contextual que permite descrever a visão dos stakeholders, suas necessidades e seus costumes organizacionais (REDDIVARI et al.,2017). A técnica pode ser de dif´ıcil aplica¸cão em stakeholders estratégicos, uma vez que nem sempre suas agendas permitirão a disponibilidade de tempo necessária e que parte de suas atividades podem ser de conteúdo sigiloso. Todavia, entender o dia-a-dia desses stakeholders apoiará tanto na identifica¸cão de informa¸cões que precisam ser entregues, como na defini¸cão da maneira em que estas serão disponibilizadas, se em sa´ıdas ativas ou passivas. As rotinas