Use of Checklist for Requirements Revalidation in Legacy Software: Case Study RETEC D.V. Neves and S. S Prietch

Transcrição

1 1 Abstract The technologies employed in computer systems have evolved quickly in recent years. Not always the institutions manage to stay updated to new technologies and often they keep using obsolete technologies. The migration of those systems to new platforms come up against many difficulties with regard to restructuring and migration to morn platforms, unrstanding what the system does, or should to do. Based on this principle, the problem in hand is to conduct activities related to an electronic journal, which currently are performed out manually. In this sense, this study aims to adapt and inclu RETEC to the national magazine publishing mol, called SEER, as well as examine if the features of this platform meets the needs of publishers. The methodology adopted the following steps: requirements elicitation, implementation stage and system validation. During this study, it was also veloped a requirement validation methodology by conducting a checklist test. The method veloped allowed specifications, in the requirements document, to be verified and validated in an objective, efficient and standardized way. Therefore, the methodology veloped and used in this study has characteristics that make it feasible to be applied during inspection and validation of requirements for a good quality software with a low number of errors, inpenntly of analyzed tool. Keywords Requirements Engineering, Electronic Journal, Data Base. C Use of Checklist for Requirements Revalidation in Legacy Software: Case Study RETEC D.V. Neves and S. S Prietch I. INTRODUÇÃO OM o processo automatização, é cada vez mais comum que empresas ou organizações, utilizem sistemas para o gerenciamento e armazenamento suas informações. Com o aumento na manda por dados qualida, respostas imediatas e soluções eficientes, o processo migração software se tornou uma prática bastante realizada em empresas e instituições. Desta forma, durante o processo escolha um terminado software, pom surgir complicações inesperadas como, por exemplo, à escolha um sistema que utiliza processos inaquados ou ainda à escolha um programa que não contemple a real necessidas da organização. Partindo ste princípio, surge a necessida da utilização uma metodologia durante o processo revalidação requisitos softwares já existente, uma vez que a sua ausência po gerar uma dificulda na compreensão das funcionalidas um terminado sistema. A Revista Exatas e TECnológicas (RETEC), é uma revista online com edições digitais, a qual é vinculada a uma Universida pública. Esta revista tem por finalida a divulgação artigos científicos nas áreas computação, ensino em tecnologia e nas diversas subáreas que compõem seus fundamentos. Des sua criação, a RETEC vem sendo disponibilizada em forma website simples, não oferecendo D. V. Neves, Universida Feral do Mato Grosso (UFMT) / Câmpus Rondonópolis. Brasil, diego@vieiraneves.com S. S. Prietch, Dra., Universida Feral do Mato Grosso (UFMT) / Câmpus Rondonópolis. Brasil, soraia@ufmt.br um sistema para armazenamento, recuperação e gerenciamento dos processos editoriais. A falta sse tipo sistema torna o processo editoração da revista moroso. Neste sentido, em busca alternativas, verificou-se que o Instituto Brasileiro Informação em Ciência e Tecnologia [11] disponibiliza o SEER, que é um software senvolvido para a construção e gestão uma publicação periódica eletrônica. Esta ferramenta contempla ações essenciais para a automação das atividas editoração periódicos científicos, sendo é um sistema recomendado pela Coornação Aperfeiçoamento Pessoal Nível Superior (CAPES). De acordo com o IBICT [11], o SEER é uma tradução e customização brasileira do sistema open source nominado Open Journal System (OJS), o qual faz parte do Project Knowledge Project (PKP). O PKP é uma iniciativa comprometida ao acesso aberto, em especial, que apoia a ampliação do acesso aos resultados pesquisa. Camargo e Vidotti [4] expõe, que as revistas eletrônicas possibilitam o controle, a preservação e a visibilida da produção científica, minimizando custos publicações e permitindo o acesso irrestrito outras comunidas universitárias e pesquisa e da socieda em geral. Consirando o exposto, este trabalho tem como objetivo o senvolvimento um método para realizar a revalidação requisitos software existentes e sta formar realizar a aquação e inclusão da RETEC ao molo nacional periódicos SEER, bem como analisar se os recursos do processo editoração da plataforma atenm as necessidas da revista forma satisfatória. Isso por que as atividas relacionadas à publicação da RETEC, s sua criação, vêm sendo realizadas manualmente. Neste aspecto, a submissão dos artigos pelos autores, o convite aos avaliadores para revisar os artigos, as notificações para autores e avaliadores, e o envio dos artigos aos avaliadores são realizados por . Vale stacar ainda, que o cadastro das submissões e dos dados dos avaliadores, a elaboração da tabela com as distribuições dos artigos aos avaliadores (consirando a área conhecimento), a verificação se existe conflito interesse, bem como, os cálculos das médias das avaliações por artigo são realizadas usando planilhas do Excel. O único processo automatizado, no momento, é o formulário avaliação utilizado pelos avaliadores. Para cada avaliador é gerado um login e senha, o avaliador acessa o formulário online para informar seu parecer sobre os artigos revisados. Tais pareceres são armazenados para posterior cálculo das médias. O formulário foi elaborado com base no trabalho Ali et al. [1]. De modo a apresentar o trabalho senvolvido, na sequência constam organizadas em seções as seguintes: o embasamento teórico, a metodologia, o estudo caso RETEC, os resultados e discussão, e as consirações finais. I. EMBASAMENTO TEÓRICO Segundo Ferreira [7], um sistema gerenciador periódicos possibilita o aumento no número leitores atingidos, bem como auxilia na rapiz do fornecimento da informação. Conforme explica o autor, a capacida armazenar arquivos

2 em meio eletrônico e a possiblida realizar manutenção nas páginas e servidores, que armazenam os arquivos referentes à publicação, são estrutura mínima que uma revista eletrônica precisa. Neste sentido, um sistema gerenciador periódicos ainda ve levar em consiração suas diversas etapas, a saber: (a) cadastrar autores e avaliadores; (b) efetuar submissões trabalhos; (c) distribuir trabalhos aos avaliadores; (d) receber avaliações; (e) efetuar as médias e organizar em orm crescente (ranking) os resultados por nota; (f) notificar os autores dos resultados; e, (g) publicar os artigos daquela edição da revista. De acordo com Silva [21], as tecnologias empregadas no senvolvimento sistemas informatizados têm evoluído rapidamente nos últimos anos e nem sempre as empresas conseguem manter-se atualizadas quanto as novas tecnologias e muitas vezes mantém em funcionamento sistemas senvolvidos com tecnologias antigas, ultrapassadas ou obsoletas. Por outro lado, conforme explica o autor [21] a migração sses sistemas para novas plataformas esbarra em muitas dificuldas e não tem como ser feita forma rápida. Para verificar se um sistema pronto dispõe das funcionalidas e recursos almejados, faz-se necessária a elicitação e análise dos requisitos e realização testes. Para isso, Sommerville [22] relata que os requisitos um sistema pom ser finidos como um conjunto especificações ou scrições dos serviços que vem ser fornecidos pela aplicação. Segundo Genvigir et al. [10], diversas atividas pom ser finidas para o processo da intificação requisitos. Ainda conforme o autor [10], a diversida existente entre os processos finidos por vários autores se ve a complexida da área, a interpretação da resolução dos problemas ou as diferentes áreas aplicação da engenharia requisitos. Desta forma, segundo Marcons e Sayão [13], é necessária a elaboração um documento requisitos que refletirão as diretrizes e as políticas gerais adotadas pela instituição. De modo, que esses requisitos vão estabelecer uma métrica para avaliação dos softwares disponíveis atualmente. Powell [18] explica, que durante essa etapa, a cisão sobre a escolha da nova plataforma software que será utilizada ve levar em consiração o enquadramento da aplicação, às diretrizes e políticas organizacionais e estratégicas da instituição, bem como o seu ajustamento à infraestrutura disponibilizada por ela para o projeto. Neste sentido, a elaboração do documento requisitos neste trabalho levou em consiração as recomendações da norma ISO/IEC 12207:2008, que estabelece uma padronização comum para os processos do ciclo vida software [12]. Conforme explica Tonini et al. [23], essa norma apresenta uma terminologia bem finida e contém processos, atividas e tarefas que vem ser usados para a aquisição, fornecimento, senvolvimento, operação, testes e manutenção do software. Para estabelecer a priorida dos requisitos, foram adotadas as nominações: essencial, importante e sejável. Vale ressaltar, que o grau priorida um requisito é estabelecido em função da regra negócio e a necessidas do usuário final, bem como, a capacida compreensão e entendimento do analista responsável pelo projeto. Conforme explica Sommerville [22], durante o processo elicitação requisitos, alguns são consirados mais importantes do que outros. Segundo o autor essa etapa envolve a interação com os stakeholrs, para scobrir os requisitos mais importantes e classificá-los como maior, mediana e menor priorida. Após essa ativida, o analista inicia a especificação da documentação, priorizando os requisitos mais importantes no processo senvolvimento do sistema. Ramalho et al. [19] expõe, ainda, que um plano testes ve ser elaborado e que o mesmo ve incluir todos os passos necessários para garantir que todos os requisitos intificados nas fases anteriores foram satisfeitos. O autor afirma ainda, que durante essa etapa é importante realizar a documentação todos os processos, referente a instalação, configuração e a funcionalidas apresentadas pelo sistema analisado. De modo que, tais informações permitam a comparação aquada suas vantagens e svantagens. No entanto, um cuidado ve ser tomado durante a realização dos testes, pois conforme expõe Ferreira [7] as simulações e análise das possibilidas vem ser realizadas em uma base testes para, posteriormente, repetir o processo em um âmbito maior escala (ambiente real). Corroborando com [7], [3] informa que uma migração sistema somente verá ser realizada após o novo ter sido testado e suas funções verificadas para averiguar se são compatíveis com as necessidas especificadas no documento requisitos. Ainda, é importante stacar que essa temática - o uso do (ou migração para o) SEER/OJS - já foi explorada em diversos trabalhos pesquisa, a citar: [2]; [5]; [6]; [8]; [9]; [14]; [15]; [16]; e, [20]. No entanto, o enfoque tais trabalhos, em sua maioria, é voltado para o âmbito cursos graduação e pós-graduação em Biblioteconomia ou Ciência da Informação, sendo somente um trabalho proveniente um curso Sistemas Informação [18]. Dentre esses 09 (nove) trabalhos, dois possuem foco na área Interação Humano- Computador (IHC) [2][20]. Diversos trabalhos abordam a necessida da finição e organização técnicas para o processo revalidação requisitos. Consirando os trabalhos temas correlatos, mencionados no parágrafo anterior, verificou-se que nenhum les efetuou investigação semelhante a presente proposta; a qual se preocupou em realizar a especificação, verificação e validação requisitos para garantir que as atividas atualmente sempenhadas manualmente fossem realizadas uma forma similar, ou melhor, no sistema editoração eletrônica periódicos. Esse diferencial é a contribuição acadêmico-científica que o trabalho traz, uma vez que o enfoque é voltado para temas que envolvem engenharia software, IHC e banco dados, que são disciplinas em cursos Sistemas Informação em todo o país. Vale ressaltar ainda que as metodologias utilizadas atualmente para validação requisitos, em sua maioria abrangem os conceitos engenharia e reengenharia reversa, entretanto tais conceitos têm por finalida apenas a compreensão do sistema existente, sendo comumente aplicado quando existe a necessida entendimento das regras negócio ou recuperar a documentação um projeto. Desta forma, a metodologia utilizada neste trabalho, consistiu na execução controlada teste com base em uma checklist senvolvida a partir dos requisitos elencados durante a elicitação requisitos. E teve como principal objetivo analisar as funcionalidas do sistema, para verificar se ele comporta-se como esperado, conforme as especificações scritas na documentação requisito. Conforme afirma Sommerville [22] os testes além scobrir falhas no software, tem por finalida comprovar aos senvolvedores e ao usuário final que o programa aten aos requisitos e está em conformida com suas especificações. Pressman [17] expõe ainda, que para que os testes software sejam executados, é preciso que seja finida uma Estratégia Teste que, segundo o autor, ve fornecer um roteiro que indica o caminho a ser seguido, finindo como e quando os passos referentes aos testes serão

3 planejados e executados, além do tempo, esforço e recursos necessários. II. METODOLOGIA DE PESQUISA De modo a atingir os objetivos propostos, se fez necessária a realização um estudo talhado sobre o SEER, analisando as especificações necessárias para a sua instalação e configurações. Após a instalação do SEER, elaborou-se um fluxograma atividas a serem seguidas. Tais atividas estão relacionadas a 03 (três) etapas principais, que nortearam a realização ste trabalho. A elicitação requisitos, etapa na qual os requisitos do sistema são levantados buscando o entendimento das necessidas do usuário e dos requisitos negócio. Deste modo, esse procedimento teve como principal objetivo a verificação da existência ou não um terminado requisito e o entendimento do que é mandado pelo sistema. A análise requisitos, etapa na qual os requisitos são analisados e confirmados pelos principais interessados do projeto, os stakeholrs. A validação requisitos, etapa que envolve a revisão todos os requisitos levantados, assim como a realização testes dos requisitos. Durante as etapas elicitação e análise dos requisitos, foi elaborado um documento que reúne os requisitos acordados, mostrando os talhes e especificação dos recursos e funcionalidas que o sistema veria apresentar. Segundo a norma ISO/IEC 12207:2008, essa documentação é extremamente importante, por que tem por finalida o registro das informações produzidas durante um processo ou ativida do ciclo vida do software. Com o objetivo compreenr melhor a necessidas dos stakeholrs, bem como da revista, o levantamento requisitos foi realizado levando em consiração as funcionalidas que o sistema veria apresentar. Para a validação tais recursos e funcionalidas, foi senvolvida uma checklist, contendo perguntas sobre especificações dos requisitos a serem analisados. Tais perguntas foram obrigatoriamente respondidas acordo com as diretrizes terminadas na documentação requisitos. Deste modo, a checklist senvolvida foi utilizada como uma metodologia teste para terminar se a aplicação do SEER seria capaz atenr forma satisfatória as necessidas da revista. A estrutura da checklist senvolvida apresenta informações tais como nome do artefato, número intificador do requisito seguido uma scrição sucinta do teste a ser realizado contendo os passos a serem seguidos. Além disso, a checklist apresenta ainda a data, hora inicial e final em que foi realizado a verificação, seguido do tempo total gasto e resultado final do teste. Conforme sugere a norma ISO/IEC 12207:2008, a rotina testes garante que os softwares estejam em conformida com os requisitos e planos estabelecidos e que estes atenm as condições impostas a eles nas atividas anteriores. Segundo BRASIL [3], os testes permitem intificar se os requisitos atenm ao uso específico pretendido, modo que se durante essa etapa for intificada inconsistências no sistema, a partir dos resultados obtidos será possível finir um processo para analisar e resolver os problemas qualquer natureza ou fonte tectados. III. ESTUDO DE CASO RETEC Esta seção conta com a scrição do senvolvimento do trabalho, conforme a sequência: instalação do SEER, levantamento e análise dos requisitos e criação da checklist e validação requisitos. INSTALAÇÃO DO SEER Com o objetivo manter a integrida das informações da revista, durante a realização do presente trabalho, foram utilizadas duas bases dados. A primeira se refere à base homologação, on foram realizados os testes e validações dos requisitos; e a segunda se refere à base oficial da RETEC. Optou-se por utilizar duas bases como medidas segurança; sta forma, se durante a realização alguns dos procedimentos ocorresse um erro irreversível, a base oficial da revista não seria prejudicada. Neste sentido, tais alterações somente foram replicadas na base oficial após a confirmação que todas as especificações foram analisadas, impedido possíveis problemas integridas dados. Deste modo, o servidor homologação foi configurado para funcionar em sua forma original, possibilitando um estudo e a aprendizagem das funcionalidas do SEER, bem como validação dos requisitos sem interferir na integrida das informações da revista. Após obter resultados satisfatórios durante os testes na base homologação, as mesmas ações foram replicadas posteriormente na base da revista. É válido mencionar que no website do IBICT constam alguns manuais, inclusive instalação do SEER, contudo, dada a evolução rápida das versões do sistema, o manual que constava disponível referia-se a uma versão antiga (v1.0), não corresponndo à versão mais atualizada (v2.5). Sendo assim, houve algumas dificuldas em efetuar tal instalação. Neste sentido, um manual contendo o passo-a-passo para a instalação e a configuração da plataforma do SEER foi elaborado. Além da dificulda inicial instalação, que tomou consirável quantida tempo, s a criação da RETEC, esta consta disponível em um website, o qual foi senvolvido em HTML, CSS e alguns elementos em PHP. No entanto, todos os dados das edições publicadas, cadastro avaliadores e submissões, e resultados das avaliações vem sendo armazenados em arquivos ntro pastas no servidor hospedagem; não sendo utilizado banco dados para guardar as informações e gerenciá-las. Neste aspecto, a iia efetuar a migração ou importação automática dos dados do website para a revista no SEER não foi possível ser realizada. Desta forma, as informações constantes no website tiveram que ser manualmente copiadas (uma a uma) para a revista no SEER. LEVANTAMENTO E ANÁLISE DOS REQUISITOS O levantamento dos requisitos tomou como base as características, áreas conhecimento, e elementos interface algumas revistas já cadastradas no SEER, bem como o processo gerenciamento submissões exposto por Ferreira [9]. A partir disso, um documento requisitos foi elaborado com três finalidas. A primeira finalida foi para fornecer aos usuários as informações necessárias para a compreensão e utilização do sistema; a segunda, para a realização testes e validação dos requisitos da ferramenta; e, a terceira, para auxiliar no processo migração do atual website da RETEC para o SEER. O processo levantamento requisito é uma ativida interpessoal, essa prática é pennte da capacida entendimento do analista e da habilida do stakeholrs em expressar as suas necessidas. Desta forma, visando atenr tais especificações, foram sugeridas categorias artefatos que refletem as principais tarefas envolvidas no processo

4 gerenciamento submissõess e publicação revistas eletrônicas, a saber: (a) Controle acessos; (b) Controle permissões; (c) Controle submissões; (d) Controle avaliação; e, (e) Controle editoração. Dentro cada artefato, um conjunto requisitos (funcionais e não funcionais) foi mapeado e scrito, levando em consiração as funcionalidas acordadas durante entrevistas com os stakeholrs. Neste contexto, foram documentados 42 requisitos funcionais e 17 requisitos não funcionais. Para estabelecer a priorida dos requisitos, foram adotadas as nominações: essencial (priorida 1), importante (priorida 2) e sejável (priorida 3). Ainda no documento requisitos, o molo caso uso foi especificado contendo as principais atividas passíveiss realização durante o processo editoração da revista. Posteriormente, essa documentação foi utilizada paraa a elaboração da checklist teste. CRIAÇÃO DA CHECKLIST E VALIDAÇÃO DE REQUISITOS A validação requisitos por meio da checklist, teve como objetivo certificar que as especificações provenientes da fase levantamento e criação do documento requisitos apresenta a scrição das funcionalidas solicitadas. Desta forma, como ponto inicial cada artefato, antes iniciar as questões da checklist, algumas informações são talhadas, modo que outros pesquisadores possam realizar os mesmos passos e chegar ao mesmo resultado obtido neste trabalho. Nesse sentido, alguns cenários este são scritos, no escopo cada artefato da checklist, bem como os procedimentos a serem executados para realizar a verificação e validação dos requisitos. Tais informações são apresentadas e exemplificadas no Quadro I. QUADRO I DOCUMENTAÇÃO DOS ARTEFATOS NA CHECKLIST Descrição Exemplo Artefato Localização Objeto teste Caso teste Pré-condição Procedimento 001 Controle acessos Menu > Acesso Operações referentes ao Controle acesso Testar os requisitos Controle acesso Para realizar testes referentes ao(à) ): (1) Cadastro, o usuário não po ter cadastro no sistema; (2) Edição perfil, o usuário precisa estar vidamente cadastrado no sistema; (3) Edição senha, o usuário precisa estar vidamente cadastrado no sistema; (4) Inativação usuário, o usuário precisa estar vidamentee cadastrado no sistema; (5) Acesso ao sistema, o usuário ve tentar acessar o sistema utilizando os principais navegadores e sistemas operacionais; (6) Recuperação senha, o usuário ve ter cadastro no sistema. Funcionalida Cadastro : (1) Entrar na tela: Menu > Acesso > Não está cadastrado? Cadastre-se no sistema; (2) Preencher os campos solicitados com informações do novo usuário; (3) Selecionar uma das opções tipos usuários (Autor e/ou Avaliador); (4) Caso selecione a opção Avaliador, tentar realizar o cadastro sem informar área conhecimento; (5) Informar dados incorretos ( e senha) para verificar se o sistema realiza a validação dos dados; (6) Deixar campos obrigatórios em branco, para verificar se o sistema notifica o usuário; ( 7) Clicar no botão Cadastrar. * Definição dos procedimentos, da mesma forma, para a validação paraa as funcionalidas enumeradas no item Pré-condição. O cenário, exibidoo no Quadro I, é fundamental para que rotina validação dos requisitos do sistema seja executada com sucesso. Neste cenário é intificado que o stakeholr tem a necessida cadastrar um novo usuário ou editar as informações um cadastro já existe (como por exemplo, informações pessoais,, senha etc.). Além disso, o stakeholr tem como opção a inativação do cadastro realizado. Nessee sentido, os testes realizados têm como principal objetivoo procurar erros que possam ser encontrados na utilização do sistema pelo stakeholr, através casos uso que simulam operações ou tarefas por ele executadas. Desta forma, os testes validação criado sobre este cenário procura testar ass operações e inclusão e edição, com o objetivo buscar algum erro causado em alguma stas tarefas, que possa fazer com quee as especificações do documento requisitoo não sejam cumpridas. A checklist elaborada e utilizada foi organizada para responr a diretrizes scritas nos artefatos da documentação requisitos, ou seja, cada item da checklist foi um item analisado acordo com as especificações solicitadas. Desta forma, foi colocada como condiçãoo que os testes realizados veriam responr obrigatoriamente cada item (1:1, uma questão por requisito) ). Um recorte para exemplificação disso consta na Fig. 1. Figura 1. Recorte para exemplificação da checklist. [Fonte própria]. Conforme exposto anteriormente, os testes foram realizados na base homologação como medida segurança. Com o objetivoo verificar a quantida tempo utilizada para realizar os testes, cada item do documento checklist foi cronometrado durantee o processo verificação (Fig. 1). Desta forma, verificou-se qual foi o tempo total, stinado para realizar as validações dos requisitos, o que resultou em 04h:20m:35s. Nesse sentido, foi possível comprovar que a metodologia utilizadaa e apresentada neste trabalho, permite uma redução significativa no tempo gasto paraa realizar a revalidação dos requisitos sistemas legados. Assim como em qualquer checklist, foi colocada também como condição, que quando a resposta para um item for Sim não é necessário incluir comentário algum no campo Observações. Entretanto paraa respostas Não, o preenchimento do campo Observações é obrigatório, pois possibilita o entendimento do porquê um terminado requisitoo não foi atendido, possibilitando a intificação do problema e posteriormente a correções necessárias. Além disso, todas as respostas para as questões da checklist validadas, usando o SEER com os conteúdos da RETEC, foram registradas na forma captura tela. I. RESULTADOS E DISCUSSÃO Ao concluir as validações observou-se que ntre os 42 Requisitos Funcionaiss (RF) levantados e testados, 29 foram aprovados e 13 foram reprovados. No que se referem aos

5 Requisitos Não Funcionais (RNF), dos 17 levantados e testados, obteve-se 14 aprovados e 03 reprovados. Neste contexto, como po ser evinciado, dos 59 itens analisados, 73% dos requisitos atenram forma satisfatória as especificações solicitadas, e 27% foram reprovados. Esses resultados foram analisados, levando em consiração os artefatos especificados no documento requisito. Desta maneira, os resultados das análises dos requisitos atendidos, segundo especificações artefatos, são os seguintes: (a) Controle acessos: 87% atendidos; (b) Controle permissões: 100% atendidos; (c) Controle submissões: 62% atendidos; (d) Controle avaliações: 54% atendidos; e, (e) Controle editoração: 50% atendidos. Os testes realizados mostraram que algumas melhorias serão necessárias nos processos : acesso, submissão, avalição e editoração. Contudo, os resultados mostram que o sistema atenu 73% das especificações solicitadas na documentação requisitos. No que se refere aos níveis prioridas os testes apontaram que, dos 39 requisitos classificados como essencial, 35 foram aprovados e apenas 04 foram reprovados. Dentre os 08 requisitos classificados como importante, 07 foram reprovados e apenas 01 foi aprovado. Os testes mostraram ainda que, dos 12 requisitos classificados como sejável, 07 foram aprovados e 05 foram reprovados. Com esse resultado é possível observar que, embora 87% dos requisitos classificados como importante não foram atendidos, 90% dos classificados como essencial para o funcionamento da revista foram aprovados. Partindo do princípio que os requisitos classificados como essenciais são imprescindíveis para o funcionamento do sistema, e que os classificados como importantes são opcionais pondo ser implementado ou não, conforme sugere Tonini et al. [23], embora o software necessite algumas melhorias, po-se afirmar que a plataforma do SEER aten as necessidas da RETEC. Os requisitos consirados reprovados significam que a questão da checklist, referente àquele requisito foi negada perante teste, ou seja, o sistema não apresenta aquela funcionalida ou facilida uso para o usuário. Nestes casos, para os problemas foram apontadas sugestões solução, as quais foram incluídas no próprio corpo da checklist e são apresentadas na Quadro II. Requisit os RNF13 RF29 RF30 RNF17 RF34 RF36 RF37 RF38 RF40 RF42 Sugestões solução possível implementar as rotinas permissão usuário no sistema. Se faz necessário conhecer a estrutura do sistema para verificar se é possível implementar as rotinas notificação usuário. Durante o envio do contendo as recomendações dos avaliadores, o coornador po realizar a inclusão dos s dos coautores; ste modo, todos os autores serão notificados. Atualmente o sistema permite que o processo distribuição trabalhos para os avaliadores cadastrados na revista seja feito coornador, entretanto como solução para esse problema, sugere-se a implementação uma rotina no sistema modo, que verifique as diretrizes conflito interesse e áreas conhecimento, e com base nesses dados realize a distribuição forma automática. O sistema notifica o coornado da revista sempre que o trabalho é aceito por um avaliador, e ainda é possível configurar um prazo para a entrega da avaliação. Porém, o sistema não realiza a notificação caso o avaliador esqueça realizar a avalição. Sugere-se como solução sse problema a implementação uma rotina que verifique os prazos estipulados pelo coornador e notifique ambos caso o avaliador esqueça realizar a avalição. O sistema apresenta a opção que permite que o avaliador informe as diretrizes conflito interesse durante a avaliação. Porém, o sistema não apresenta um mecanismo que verifique tais conflitos. Sugere-se como solução para esse problema a implementação um mecanismo que verifique antes realizar a distribuição trabalhos, se o do avaliador não foi vinculado a uma submissão, e se a instituição ensino não e a mesmo do autor que submeteu o trabalho. O sistema permite a criação um formulário avaliação personalizado; ste modo, como solução para esse problema sugerese, criar um formulário personalizado no qual po ser adicionado o campo para que o avaliador atribua uma nota para o trabalho avaliado. Após a criação do formulário avaliação personalizado, no qual o avaliador porá informar uma nota para os trabalhos avaliados por ele, porá ser criada uma aplicação para fazer a leitura dos dados do formulário. Através uma consulta via banco dados será possível calcular a média das notas atribuídas pelos autores. Após a criação do formulário avaliação personalizado, no qual o avaliador porá informar uma nota para os trabalhos avaliados por ele, porá ser criada uma aplicação para fazer a leitura dos dados do formulário. Através uma consulta via banco dados será possível apresentar para ao usuário coornador um ranking com as médias trabalhos avaliados. O sistema permite que o processo editoração seja realizado forma manual, ste modo após o processo avalição, o coornador da revista porá fazer a publicação dos artigos que foram aprovados pelos avaliadores. Sugere-se como solução para esse problema a implementação um mecanismo que realize a publicação dos trabalhos realizados acordo as parametrizações do coornador como, por exemplo, a publicação dos 20 melhores classificados no ranking avaliações. Recomenda-se que o coornador da revista realize a publicação um novo trabalho, inserindo o arquivo (com a versão completa da revista) na edição. QUADRO II SUGESTÕES DE SOLUÇÃO: REQUISITOS FUNCIONAIS (RF) E REQUISITOS NÃO FUNCIONAIS (RNF) Requisit os RF3 RF7 RF22 RF23 RNF12 RF27 Sugestões solução Sugere-se realizar a alteração diretamente no código fonte. Deste modo, verá ser implementada uma opção on o usuário verá selecionar as áreas interesse através um checkbox modo que essa opção seja obrigatória, caso o usuário selecione a opção avaliador durante a realização seu cadastro. O sistema permite que o procedimento inativação usuário seja realizado pelo coornador da revista. Desta forma, para realizar a inativação do cadastro o usuário verá enviar ume para o coornador da revista e solicitar a inativação sua conta. O sistema permite configurar diretrizes para o usuário seguir e solicita a marcação um campo informando que está ciente do tipo extensão arquivo que verá ser utilizado para fazer o upload durante a submissão dos trabalhos. Sugere-se realizar a alteração diretamente no código fonte. Deste modo, verá ser implementada uma opção on o usuário verá selecionar as áreas interesse através um checkbox modo que essa opção seja obrigatória durante a realização da submissão. Se faz necessário conhecer a estrutura do sistema para verificar se é possível implementar as rotinas notificação do sistema. Se faz necessário conhecer a estrutura do sistema para verificar se é II. CONSIDERAÇÕES FINAIS Ao longo do senvolvimento sse trabalho, po-se concluir que o processo revalidação requisito um sistema é uma etapa importante durante a migração plataformas softwares, pois é vital para se atingir os objetivos sejados. A utilização metodologias específicas para essa finalida ten a aumentar a qualida do processo, tornando-o mais rigoroso e com menor risco falhas. A metodologia senvolvida durante esse estudo, visa auxiliar o processo validação requisitos, a partir da execução teste com base em uma estrutura checklist. Desta forma, método senvolvido possibilitou que todas as especificações elencadas no documento requisitos fossem verificadas e validadas forma objetiva, eficiente e padronizada. Nesse sentido, através um conjunto questionamentos foi possível realizar a intificação problemas e/ou feitos. Portanto, a metodologia senvolvida e utilizada neste trabalho possui características que a torna

6 viável para ser aplicada em uma inspeção e validação requisitos. Ao concluir o trabalho, enxerga-se claramente as contribuições conquistadas como resultado: a checklist para validação dos requisitos, a documentação especificação requisitos, o manual instalação do SEER, a proposiçãoo um novo logotipo e a migração do website da revista para o formato nacional padrão SEER. Em especial, o manual, a documentação e a checklist pom ser úteis para outras pessoas interessadas em criarr revistas online, seguindo os passos para efetivar suas propostas no SEER. Como trabalhos futuros, ainda espera-se oficializar a revista em um enreço da Universida pública, a qual a RETEC está vinculada como um projeto extensão. Isso ainda não ocorreu por que se encontra em trâmite uma resolução para a formalização dos processos associados à criação e manutenção periódicos eletrônicos. Além disso, preten-se colocar em prática as sugestões elencadas no Quadro II para atenr todos os requisitos levantados durante o presentee trabalho, ntre outros que venham a surgir. Assim, intenciona-se disponibilizar publicamente, na Web, o manual instalação do SEER. REFERÊNCIAS [1] S. N. Ali; H. C. Young; N. M. Ali, Determining the quality of publications and research for tenure or promotion cisions: A preliminary checklist to assist. Library Review, Vol. 45, Iss: 1, pp [2] G. R. Alvarez, Usabilida da seção submissão do Sistema Eletrônico Editoração Revistas: Uma análise a partir da opinião dos autores cadastrados na revista em questão. Monografia Graduação em Biblioteconomia, UFRGS [3] Brasil. Guia Livre - Referência Migração para Software Livre. Software livre no governo do Brasil, Disponível em: < 3fv>. Acesso em: 01/12/2014. [4] L. S. A. Camargo, S. A. B. G. Vidotti. Arquitetura da informação para repositórios científicos digitais, Disponível em: < Acesso em: 03/12/2014. [5] G. A. Dias, J. B. Delfino, J. W. M. Silva, Open Journal System OJS: migrando um periódico científico eletrônico para um sistema automatizado gerência e publicação periódicos científicos eletrônicos. Inf. & Soc.: Est., João Pessoa, vol.17, nº2, p.75-82, [6] A. A. Eluan, Análise do Uso da Plataforma Open Journal System para o Processo Editoração Eletrônica: um estudo focado nos editores periódicos científicos eletrônicos acesso livre em Ciência da Informação e Biblioteconomia no Brasil. Dissertação Pós-Graduação em Ciência da Informação, UFSC [7] M. Ferreira, Introdução à preservação digital: conceitos, estratégias e atuais consensos. Escola Engenharia da Universida do Minho, Disponível em: < Acesso em: 02/01/2015. [8] A. G. C. Ferreira, Editoração Eletrônica Periódicos Científicos: O uso do SEER como ferramenta padronização para revistas brasileiras na Web. Monografia Graduação em Biblioteconomia, UFRGS, [9] S. M. Ferreira; W. A. S. Cabral; M. Mucheroni; J. Perez, Um Editor Conteúdos para o Software OJS/SEER: otimizando a atualização edições/fascículos revistas eletrônicas. X Encontro Nacional Pesquisa da ANCIB, [10] E. C. Genvigir; N. Sant anna; L. F Borrego Filho; M. Cereja Junior, Uma Abordagem para os Processos da Engenharia Requisitos. INPE Instituto Nacional Pesquisas Espaciais Disponível em: < Acesso em: 06/11/2014. [11] IBICT, Instituto Brasileiro Informação em Ciência e Tecnologia. Sistemas eletrônicos disseminação da informação e publicação revistas eletrônicas, Disponível em: < Acesso em: 05/ /11/2014. [12] International Standard. ISO/IEC 12207: Systems and software engineering - Software life cycle processes. IEEE Computer Society, Disponível em: < Acesso em: 09/ /11/2014. [13] C. H. Marcons; L. Sayão, Softwares livres para repositórios institucionais: alguns subsídios para a seleção. Salvador: Sistema Bibliotecas - UFBA-EDUFBA, Disponível em: < Acesso em: 05/11/2014. [14] R. F. Meirelles, Implementação da Revista Brasileira Saú e Produção Animal no Sistema Eletrônico Editoração Revistas SEER. Anais do VI CINFORM, Encontro Nacional Ciência da Informação [15] T. R. Mello, Periódicos Científicos: processo migração para a plataforma OJS. Monografia Graduação em Biblioteconomia, UFSC, [16] A. N. Oliveira; P. C. S. Charchar, Ferramenta Open Source (OJS) na Criação da Revista Eletrônica do Curso Sistemas Informação do IESAM. Sistemas Informação & Gestão Tecnologia, [17] R. S.. Pressman, Engenharia Software: Uma Abordagem Profissional - 7º. São Paulo: Makron Books, [18] A. Powell, Notes about possible technical criteria for evaluating institutional repository (IR) software, Disponível em: < Acesso em: 06/11/2014. [19] J. C. Ramalho; M. Ferreira; L. Faria, Boas práticas na migração repositórios: lições aprendidas com o CALM e o ARQBASE Disponível em: < Acesso em: 08/11/2014. [20] S. F. da Rocha, Fatoress que Influenciam a Interação entre e a Interface Periódicoss Científicos Eletrônicos: Um Estudo com Autores Artigos no Sistema Eletrônico Editoração Revistas (SEER). Dissertação Pós- Graduaçãoo em Ciência da Informação, UnB [21] R. A. da Silva, Migração e Integração Sistemas Legados Disponível em: < Acesso em: 01/12/2014. [22] I. Sommerville, Engenharia Software, 8ª Edição. São Paulo: Pearson- dos Addison Wesley [23] A. C. Tonini; M. M.. Carvalho; M. M. Spinola, Contribuição molos qualida e maturida na melhoria dos processos software. vol.18, n.2, pp ISSN , Diego Vieira Neves Graduado em Sistemas Informação pela Universida Feral do Mato Grosso/ Campus Rondonópolis. Brasil, (concluída em 2015). Soraia Silvaa Prietch Graduada em Ciência da Computação pela Universida Cuiabá - UNIC (concluída em 1999), Mestre em Ciência da Computação pela Universida Brasília - UnB (concluído em 2004) e Doutora pelo Programa Doutorado Interinstitucional (DINTER) entre a Escola Politécnica da USP e a UFMT (concluído em 2014). Des 2004 é docente com dicação exclusiva (Adjunto I), da Universida Feral Mato Grosso/ Campus Rondonópolis.