<?xml version="1.0" encoding="UTF-8"?>
<item xmlns="http://omeka.org/schemas/omeka-xml/v5" itemId="2698" public="1" featured="0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://omeka.org/schemas/omeka-xml/v5 http://omeka.org/schemas/omeka-xml/v5/omeka-xml-5-0.xsd" uri="http://repositorio.febab.libertar.org/items/show/2698?output=omeka-xml" accessDate="2026-05-27T05:22:05-07:00">
  <fileContainer>
    <file fileId="1780">
      <src>http://repositorio.febab.libertar.org/files/original/23/2698/1812-1829-1-PB.pdf</src>
      <authentication>c79432fa8ff24d8d571e2b765d6739e6</authentication>
      <elementSetContainer>
        <elementSet elementSetId="4">
          <name>PDF Text</name>
          <description/>
          <elementContainer>
            <element elementId="92">
              <name>Text</name>
              <description/>
              <elementTextContainer>
                <elementText elementTextId="31965">
                  <text>Elicitação de requisitos para o desenvolvimento de um sistema de
informação utilizando a Etnografia: Um relato de experiência

Renato Marques Alves (Univasf) - renato.alves@univasf.edu.br
Ricardo Argenton Ramos (UNIVASF) - ricargentonramos@gmail.com
Rodrigo Pereira Ramos (Univasf) - rodrigo.ramos@univasf.edu.br
Teresinha Fróes Burnham (UFBA) - teresinhafroes@gmail.com
Resumo:
A elicitação de informações para iniciar um desenvolvimento de sistema sempre foi um grande
desafio para os desenvolvedores de software, muitas vezes por falta de tempo, ou de
experiência dos desenvolvedores ou mesmo pela dificuldade inerente a esta fase. Várias
técnicas e métodos são desenvolvidos para que se alcance o sucesso nesta fase. Um desses
métodos é a etnografia, que tem como ideia principal que o engenheiro de requisitos participe
das atividades como usuário e obtenha o conhecimento necessário para gerar os requisitos.
Este artigo apresenta um relato de experiência de um profissional bibliotecário que assumiu o
papel de engenheiro de requisitos, utilizando o método etnográfico (observação, entrevista e
consulta a documentação) para elicitar os requisitos de um sistema real, pouco comum, na
área de biofabrica. O estudo de caso foi realizado com o apoio de uma empresa especializada
na produção de insetos transgênicos em grande escala (como o Aedes aegypti). Os requisitos
obtidos foram validados através da técnica prototipação em papel. Os resultados apontam a
questão da complexidade como fator crítico para o entendimento de um sistema centrado no
gerenciamento de dados e os requisitos essenciais para o controle e monitoramento de dados
na área de biofábrica. Conclui-se afirmando que a Etnografia combinada com a prototipação
em papel foi essencial para a compreensão e definição dos requisitos.
Palavras-chave: Elicitação de requisitos. Sistema de Informação. Gerenciamento de dados.
Biofábrica
Eixo temático: Eixo 3: Gestão de bibliotecas: aquisição e tratamento de materiais no
ambiente físico e virtual, curadoria digital, coleções especiais,
desenvolvimento de serviços e produtos inovadores, bibliotecas digitais e
virtuais, portais e repositórios, acesso aberto.

Powered by TCPDF (www.tcpdf.org)

�1. Introdução
Independente do processo de desenvolvimento de software escolhido, o desenvolvedor de
software precisa, como primeiro passo, saber exatamente quais são os requisitos do sistema que
será construído. Está afirmação apesar de ser precisa em relação ao sucesso de um projeto de
software, ainda é muito negligenciada pelos desenvolvedores de software. Pesquisadores
relatam que cerca de 60% dos projetos de software que falham têm suas causas na má definição
dos requisitos. (1) O pesquisador Fred Brooks escreveu na segunda edição do seu livro
relançado 30 anos após a primeira:
A parte mais difícil de construir um sistema de software é decidir
precisamente o que construir. Nenhuma outra parte do trabalho conceitual é
tão difícil quanto a definição dos requisitos técnicos detalhados. Nenhuma
outra parte do projeto pode trazer tanto fracasso se for malfeita. Nenhuma
outra parte do projeto é tão difícil para poder corrigir mais tarde. (2)

Pesquisadores da área de engenharia de software trabalham em soluções para que a fase de
engenharia de requisitos seja eficiente e que, portanto, diminua a probabilidade de falhas em um
projeto de software. Assim, surgem abordagens para modelar requisitos que dão apoio desde a
orientação a aspectos, orientação a agentes e sistemas complexos entre outros. (3) Para projetos
menores, outros pesquisadores trabalham no sentido de diminuir a burocracia da etapa de
requisitos e propuseram metodologias ágeis que têm o foco na equipe de desenvolvimento e na
programação. (4) Entretanto, apesar de novas técnicas para modelar ou mesmo nos casos de
técnicas que diminuem o foco dos requisitos, todas precisam ter um investimento para
compreender o que será construído. Vale salientar que este investimento pode ter seu custo
maior ou menor dependendo de alguns fatores, tais como: i) A experiência da
equipe/desenvolvedor na área de Engenharia de Requisitos, ii) A complexidade do domínio da
aplicação, iii) O tempo planejado para a etapa de elicitação dos requisitos. (5) O contexto
descrito anteriormente, se torna real e visível em regiões com pequenas empresas de
desenvolvimento de software e com profissionais com poucas, ou nenhuma, experiência em
engenharia de requisitos. Adiciona-se a esse contexto o desafio para desenvolver softwares para
um novo tipo de empresa na área da biologia, as biofabricas. Apesar de ser uma área que já vem
sendo discutida na engenharia de software (6) não existem trabalhos científicos que apresentem
uma maneira de desenvolver softwares específicos para essa área. Este artigo apresenta um
relato de experiência sobre o levantamento de requisitos de software de uma biofabrica com a
característica de ter sido realizado por uma pessoa que não é da área da computação e nem tinha
experiência na área de engenharia de requisitos. A abordagem utilizada foi baseada no método
etnográfico. Na fase de validação dos requisitos foi utilizada a prototipação em papel e foi
testada no domínio de uma biofábrica especializada na produção, em grande escala, de insetos
Aedes aegypt transgênicos para o combate às doenças como: Dengue, Chicungunya e a Zika
vírus.
O Sistema de gerenciamento global é um projeto que envolve a colaboração de vários
pesquisadores através de uma parceria entre a Universidade Federal do Vale do São Francisco
(UNIVASF) e a biofábrica Moscamed Brasil para a construção de um sistema para o
gerenciamento global (em inglês, Global Management System) com subsistemas responsáveis
pelo processo de produção, soltura e controle do mosquito Aedes aegypti. Os vários subsistemas
estarão interligados através de uma rede de computadores. Cada um destes subsistemas trata de
uma especificidade da biofábrica, tais como: produção massal de insetos, controle das
armadilhas, controle ecológico, estimativa de produção, controle biológico e liberação dos

�insetos. A primeira etapa planejada para o desenvolvimento do projeto supracitado foi o
entendimento de cada subsistema e a produção de um documento de requisitos. Assim, cada
pesquisador envolvido no projeto teve um ou mais subsistemas sob sua responsabilidade de
acordo com sua área de conhecimento. Por exemplo, este artigo focou no levantamento de
requisitos para a construção de um subsistema de controle das armadilhas utilizadas na captura
do Aedes. Uma característica do projeto é o envolvimento e colaboração de pesquisadores de
áreas de conhecimento diferentes, tais como as ciências exatas, ciências biológicas e saúde e
ciências sociais aplicadas e humanas, tornando esse projeto de caráter multi/interdisciplinar um
desafio para alcançar os objetivos do projeto proposto.
2. Relato de Experiência
A opção metodológica assumida para condução da presente investigação foi o estudo de caso
que contou com o apoio da biofábrica Moscamed Brasil, localizada no Município de JuazeiroBA, no período de fevereiro a outubro de 2015. A pesquisa aqui desenvolvida apresentou fortes
características de uma pesquisa aplicada, por ter como objetivo “gerar um conhecimento para
aplicação prática, dirigidos à solução de problemas específicos”. (7) Para a coleta de requisitos
sobre o sistema de armadilhas de mosquitos, foram combinadas técnicas oriundas da
Antropologia (observação, entrevista e consulta a documentos) e da Engenharia de software
(prototipagem) que foram selecionadas do modelo de processo de elicitação. (8) Durante a
pesquisa de campo, um dos pesquisadores se posicionou como observador participante e
acompanhou todo o trabalho que envolvia a instalação e coleta das armadilhas, a análise do
material no laboratório e os registros dos dados coletados nos experimentos científicos. Para
complementar as informações obtidas na observação participante em relação às práticas de
gerenciamento de dados na empresa, foram realizadas entrevistas semiestruturadas cujo roteiro
foi baseado no Checklist for a Data Managment Plan, v.4 (9) e consulta à documentação
produzida para a implantação do Sistema MONITOR XYZT em funcionamento na empresa.
(10) Para validação das informações obtidas, empregou-se uma das técnicas mais utilizadas na
Engenharia de software, a prototipação. A técnica de prototipação em papel apresenta versões
em papel das telas do sistema com as quais os usuários interagem, e se projeta um conjunto de
cenários que descreve como o sistema pode ser usado. Os informantes da pesquisa foram os
especialistas no domínio (pesquisadores, funcionários, técnicos de laboratórios e agentes de
monitoramento) lotados em setores (administrativos e laboratórios de pesquisa) que
trabalhavam com a gestão parcial ou total dos dados de pesquisa na empresa.
Figura 1 – Pesquisador em campo

Fonte: Os autores

�Figura 2 – Armadinhas para captura do Aedes aegypti

Fonte: Os autores
Figura 3 – Seção de Prototipação em papel para validação dos requisitos

Fonte: Os autores
3. Resultados
Um dos aspectos identificados na definição de requisitos em processos bioindustriais diz
respeito à questão da complexidade para o correto entendimento do domínio. Esta problemática
também foi relatada no desenvolvimento de um software (11) e as estratégias para o
entendimento correto da aplicação (software), é formar equipe com membros que possuam
graduação em diferentes áreas do conhecimento e o envolver os colaboradores e gestores da
empresa na definição dos requisitos. O que foi seguido nesta pesquisa. Portanto, os requisitos
obtidos permitem que o futuro sistema forneça informações seguras sobre o principal vetor
causador da dengue, através da disponibilidade de informações tais como densidade
populacional de mosquito, localidades mais infestadas e período de alta ou baixa ocorrência do
vetor nas áreas monitoradas.

�A seguir apresentamos os requisitos chaves para sistema de controle e monitoramento de dados:
a) Permitir o cadastro das áreas (localidades) monitoradas por armadilhas;
b) Admitir o registro das datas de instalação e de coleta das armadilhas, convertendo o
calendário anual em semanas/ano;
c) Permitir o cadastro da quantidade de números de ovos, larvas e mosquitos adultos do
Aedes capturados nas armadilhas;
d) Disponibilizar o histórico dos dados estatísticos coletados; permitir o cadastro e a
visualização das coordenadas geográficas das áreas monitoradas; e
e) Apresentar relatórios, gráficos e mapas.
Quanto às sessões de prototipação com os especialistas no domínio, elas mostraram-se muito
úteis para a correção e/ou anuência de requisitos porque os informantes simulavam no papel as
tarefas do dia a dia, em relação ao registro de entradas e processamento dos dados coletados na
biofábrica. Outro achado relevante foi sobre o processo de gerenciamento de dados em um
estudo de caso real. Foi identificado que a cultura da gestão da informação ainda não está
integralizada em todos os ambientes da empresa. O trabalho de campo verificou diferentes
práticas aplicadas ao gerenciamento de dados, como: a existência de um setor que
disponibilizava de uma infraestrutura tecnológica para apoiar a sistematização dos dados via
plataforma Web, enquanto outro setor empregava o uso de arquivamento e registro dos dados
em planilhas eletrônicas armazenadas em um sistema de armazenamento nas nuvens instalado
no computador local onde é realizado também as cópias de segurança, a recuperação e o
compartilhamento como relatou um informante “quando a gente vai fazer a análise estatística
tudo isso tem que ser colocado junto, todos os dados, têm as datas; a gente precisa juntar tudo
numa planilha só pra poder fazer análise”.
O desenvolvimento de um Sistema de gerenciamento global para apoiar as atividades de
gerenciamento dos dados é um das soluções recomendadas pelo novo paradigma da curadoria
digital, pois viabiliza a socialização do uso de dados e informações a todos os integrantes da
empresa, além de garantir a preservação e conservação ao longo do tempo.
4. Considerações Finais
Tendo em vista o desafio referente à construção de uma documentação com as descrições de
requisitos para o desenvolvimento de um sistema visando o gerenciamento de dados, como uma
das alternativas para a gestão da informação, este artigo oferece ao leitor a possibilidade de
utilizar as experiências aqui relatadas para um caso semelhante. A etapa seguinte será o
desenvolvimento de um software com base nos requisitos obtidos.
Referências
1. HOFMANN, H. F.; LEHNER, F. Requirements engineering as a success factor in
software projects. IEEE software, v. 18, n. 4, p. 58, 2001.
2. BROOKS, F. P. O mítico homem-mês: ensaios sobre engenharia de software. [S.l: s.n],
2009.
3. CHENG, Betty HC; ATLEE, Joanne M. Research directions in requirements engineering.
In: FUTURE OF SOFTWARE ENGINEERING, 2007. IEEE Computer Society, 2007. p. 285303.
4. HIGHSMITH, J.; COCKBURN, A. Agile software development: the business of innovation.
Computer, v. 34, n. 9, p. 120-127, 2001.
5. NUSEIBEH, B.; EASTERBROOK, S. Requirements engineering: a roadmap. In:

�INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING, 22., 2000, Limerick,
Ireland. Proceedings of the Conference on the Future of Software Engineering New York:
ACM, 2000. p. 35-46. Disponível em:&lt; www.cs.toronto.edu/~sme/papers/.../ICSE2000.pdf.
Acesso em: 06 set 2014.
6. BOEHM, B. Some Future Trends and Implications for Systems and Software Engineering
Processes. Systems Engineering, v. 9, n. 1, 2006, pp 1-19.
7. GERHARDT, T. E.; SILVEIRA, D. T. (Orgs).Métodos de pesquisa. Porto Alegre: Editora da
UFRGS, 2009.
8. SOMMERVILLE, Ian. Requisitos. In.:______.Engenharia de Software. 8. ed. São Paulo:
Pearson, 2007. Parte 2, p.77-111.
9. DIGITAL CURATION CENTRE. Data Management Plans. 2013. Disponível em:
&lt;http://www.dcc.ac.uk&gt;. Acesso em: 10 dez. 2014.
10. XYZTEMAS CONSULTORIA &amp; SERVIÇOS LTDA.Proposta – Implantação:
MonitorXYZTEMAS. [2007?]. 12f.
11. CAUVIN, S. et al. A generic scientific information management system for process
engineering. In. EUROPEAN SYSPOSIUM ON COMPUTER AIDED PROCESS
ENGINEERING, 18., 2008, France. Computer Aided Process Engineering. Elsevier, p. 931936.

�</text>
                </elementText>
              </elementTextContainer>
            </element>
          </elementContainer>
        </elementSet>
      </elementSetContainer>
    </file>
  </fileContainer>
  <collection collectionId="23">
    <elementSetContainer>
      <elementSet elementSetId="1">
        <name>Dublin Core</name>
        <description>The Dublin Core metadata element set is common to all Omeka records, including items, files, and collections. For more information see, http://dublincore.org/documents/dces/.</description>
        <elementContainer>
          <element elementId="50">
            <name>Title</name>
            <description>A name given to the resource</description>
            <elementTextContainer>
              <elementText elementTextId="26057">
                <text>CBBD - Edição: 27 - Ano: 2017 (Fortaleza/Ceará)</text>
              </elementText>
            </elementTextContainer>
          </element>
          <element elementId="49">
            <name>Subject</name>
            <description>The topic of the resource</description>
            <elementTextContainer>
              <elementText elementTextId="26058">
                <text>Biblioteconomia&#13;
Documentação&#13;
Ciência da Informação</text>
              </elementText>
            </elementTextContainer>
          </element>
          <element elementId="45">
            <name>Publisher</name>
            <description>An entity responsible for making the resource available</description>
            <elementTextContainer>
              <elementText elementTextId="26059">
                <text>FEBAB</text>
              </elementText>
            </elementTextContainer>
          </element>
          <element elementId="40">
            <name>Date</name>
            <description>A point or period of time associated with an event in the lifecycle of the resource</description>
            <elementTextContainer>
              <elementText elementTextId="26060">
                <text>2017</text>
              </elementText>
            </elementTextContainer>
          </element>
          <element elementId="44">
            <name>Language</name>
            <description>A language of the resource</description>
            <elementTextContainer>
              <elementText elementTextId="26061">
                <text>Português</text>
              </elementText>
            </elementTextContainer>
          </element>
          <element elementId="51">
            <name>Type</name>
            <description>The nature or genre of the resource</description>
            <elementTextContainer>
              <elementText elementTextId="26062">
                <text>Evento</text>
              </elementText>
            </elementTextContainer>
          </element>
          <element elementId="38">
            <name>Coverage</name>
            <description>The spatial or temporal topic of the resource, the spatial applicability of the resource, or the jurisdiction under which the resource is relevant</description>
            <elementTextContainer>
              <elementText elementTextId="26063">
                <text>Fortaleza (Ceará)</text>
              </elementText>
            </elementTextContainer>
          </element>
        </elementContainer>
      </elementSet>
    </elementSetContainer>
  </collection>
  <itemType itemTypeId="8">
    <name>Event</name>
    <description>A non-persistent, time-based occurrence. Metadata for an event provides descriptive information that is the basis for discovery of the purpose, location, duration, and responsible agents associated with an event. Examples include an exhibition, webcast, conference, workshop, open day, performance, battle, trial, wedding, tea party, conflagration.</description>
  </itemType>
  <elementSetContainer>
    <elementSet elementSetId="1">
      <name>Dublin Core</name>
      <description>The Dublin Core metadata element set is common to all Omeka records, including items, files, and collections. For more information see, http://dublincore.org/documents/dces/.</description>
      <elementContainer>
        <element elementId="50">
          <name>Title</name>
          <description>A name given to the resource</description>
          <elementTextContainer>
            <elementText elementTextId="31955">
              <text>ELICITAÇÃO DE REQUISITOS PARA O DESENVOLVIMENTO DE UM SISTEMA DE INFORMAÇÃO UTILIZANDO A ETNOGRAFIA: UM RELATO DE EXPERIÊNCIA</text>
            </elementText>
          </elementTextContainer>
        </element>
        <element elementId="39">
          <name>Creator</name>
          <description>An entity primarily responsible for making the resource</description>
          <elementTextContainer>
            <elementText elementTextId="31956">
              <text>Renato Marques Alves</text>
            </elementText>
            <elementText elementTextId="31957">
              <text>Ricardo Argenton Ramos</text>
            </elementText>
            <elementText elementTextId="31958">
              <text>Rodrigo Pereira Ramos</text>
            </elementText>
            <elementText elementTextId="31959">
              <text>Teresinha Fróes Burnham</text>
            </elementText>
          </elementTextContainer>
        </element>
        <element elementId="38">
          <name>Coverage</name>
          <description>The spatial or temporal topic of the resource, the spatial applicability of the resource, or the jurisdiction under which the resource is relevant</description>
          <elementTextContainer>
            <elementText elementTextId="31960">
              <text>Fortaleza (Ceará)</text>
            </elementText>
          </elementTextContainer>
        </element>
        <element elementId="45">
          <name>Publisher</name>
          <description>An entity responsible for making the resource available</description>
          <elementTextContainer>
            <elementText elementTextId="31961">
              <text>FEBAB</text>
            </elementText>
          </elementTextContainer>
        </element>
        <element elementId="49">
          <name>Subject</name>
          <description>The topic of the resource</description>
          <elementTextContainer>
            <elementText elementTextId="31963">
              <text>Eixo 3: Gestão de bibliotecas: aquisição e tratamento de materiais no ambiente físico e virtual, curadoria digital, coleções especiais, desenvolvimento de serviços e produtos inovadores, bibliotecas digitais e virtuais, portais e repositórios, acesso aberto.</text>
            </elementText>
          </elementTextContainer>
        </element>
        <element elementId="41">
          <name>Description</name>
          <description>An account of the resource</description>
          <elementTextContainer>
            <elementText elementTextId="31964">
              <text>A elicitação de informações para iniciar um desenvolvimento de sistema sempre foi um grande desafio para os desenvolvedores de software, muitas vezes por falta de tempo, ou de experiência dos desenvolvedores ou mesmo pela dificuldade inerente a esta fase. Várias técnicas e métodos são desenvolvidos para que se alcance o sucesso nesta fase. Um desses métodos é a etnografia, que tem como ideia principal que o engenheiro de requisitos participe das atividades como usuário e obtenha o conhecimento necessário para gerar os requisitos. Este artigo apresenta um relato de experiência de um profissional bibliotecário que assumiu o papel de engenheiro de requisitos, utilizando o método etnográfico (observação, entrevista e consulta a documentação) para elicitar os requisitos de um sistema real, pouco comum, na área de biofabrica. O estudo de caso foi realizado com o apoio de uma empresa especializada na produção de insetos transgênicos em grande escala (como o Aedes aegypti). Os requisitos obtidos foram validados através da técnica prototipação em papel. Os resultados apontam a questão da complexidade como fator crítico para o entendimento de um sistema centrado no gerenciamento de dados e os requisitos essenciais para o controle e monitoramento de dados na área de biofábrica. Conclui-se afirmando que a Etnografia combinada com a prototipação em papel foi essencial para a compreensão e definição dos requisitos.</text>
            </elementText>
          </elementTextContainer>
        </element>
        <element elementId="44">
          <name>Language</name>
          <description>A language of the resource</description>
          <elementTextContainer>
            <elementText elementTextId="66661">
              <text>pt</text>
            </elementText>
          </elementTextContainer>
        </element>
      </elementContainer>
    </elementSet>
  </elementSetContainer>
  <tagContainer>
    <tag tagId="18">
      <name>cbbd2017</name>
    </tag>
  </tagContainer>
</item>
