CENTRO DE CIÊNCIAS APLICADAS A EDUCAÇÃO
DEPARTAMENTO DE CIÊNCIAS EXATAS BACHARELADO EM SISTEMAS DE INFORMAÇÃO
NEEMIAS DE CARVALHO SILVA
DETERMINAÇÃO DOS REQUISITOS DE SOFTWARE A PARTIR DA CONVERSÃO DAS NECESSIDADES DE
SOFTWARE DOS USUÁRIOS DO DER/PB
RIO TINTO – PB 2015
DETERMINAÇÃO DOS REQUISITOS DE SOFTWARE A PARTIR DA CONVERSÃO DAS NECESSIDADES DE
SOFTWARE DOS USUÁRIOS DO DER/PB
Trabalho de Conclusão de Curso apresentado para obtenção do título de Bacharel à banca examinadora no Curso de Bacharelado em Sistemas de Informação do Centro de Ciências Aplicadas e Educação (CCAE), Campus IV da Universidade Federal da Paraíba.
Linha de Pesquisa: Engenharia de Software Orientador: Prof. Me. Jailson Ribeiro.de Oliveira.
RIO TINTO – PB 2015
Ficha catalográfica preparada pela Seção de Catalogação e Classificação da Biblioteca da UFPB
S586d Silva, Neemias de Carvalho.
Determinação dos requisitos de software a partir da conversão das necessidades de software dos usuários do DER/PB. / Neemias de Carvalho Silva. – Rio Tinto: [s.n.], 2015.
93f. : il.
Orientador(a): Prof. Msc. Jailson Ribeiro.de Oliveira.
Monografia (Graduação) – UFPB/CCAE.
1. Engenharia de software. 2. Software - desenvolvimento. 3. Sistemas de informação.
UFPB/BS-CCAE CDU: 004.4(043.2)
DETERMINAÇÃO DOS REQUISITOS DE SOFTWARE A PARTIR DA CONVERSÃO DAS NECESSIDADES DE
SOFTWARE DOS USUÁRIOS DO DER/PB
Trabalho de Conclusão de Curso submetido ao Curso de Bacharelado em Sistemas de Informação da Universidade Federal da Paraíba, Campus IV, como parte dos requisitos necessários para obtenção do grau de BACHAREL EM SISTEMAS DE INFORMAÇÃO, obtendo o conceito _____aprovado________ em defesa pública realizada no dia 09/11/2015, sob avaliação da banca examinadora a seguir:
Prof. Me. Jailson Ribeiro de Oliveira – Orientador UFPB/CT/DEP – Campus I
Prof. Dr. Joelson Nogueira de Carvalho – Examinador
UFPB/CCAE/DCX – Campus IV
Prof. Me. Ana Liz Souto Oliveira de Araújo – Examinador
UFPB/CCAE/DCX – Campus IV
RIO TINTO – PB 2015
Aos amigos, irmãos, colegas e professores, minha eterna gratidão por compartilhar comigo seus conhecimentos.
Primeiramente sou eternamente grato ao meu Deus, porque me deu paciência e conhecimento durante todo o processo de construção deste trabalho. Ele também guiou meus passos para tomar as medidas corretas nas horas certas. Na verdade este continua a guiar meus passos até a eternidade. Depois sou grato ao meu orientador, Professor Jailson, que me ajudou em coisas que não eram de sua obrigação, entretanto agiu com grande generosidade. O Professor Jailson me deu suporte durante todo o trabalho, e em nenhum momento ficou ausente. Agradeço, Professor, com toda minha sinceridade!
Também sou grato aos meus familiares, sobretudo aos meus pais, pois assistiram e sentiram comigo as minhas aflições e vitórias durante minha graduação. Para finalizar expresso minha gratidão aos demais professores, amigos e colegas (Principalmente Jorge Lima) que de alguma forma também me ajudaram neste trabalho. Um forte abraço para todos!
Conversão das Necessidades de Software dos Usuários do DER/PB. 2015. 93 f.
2015. Trabalho de Conclusão de Curso (Bacharelado em Sistemas de Informação).
UFPB/CCAE/DCX, Rio tinto – PB.
RESUMO
Os funcionários do Departamento de Estradas de Rodagens da Paraíba (DER-PB) têm demonstrado insatisfação com os softwares que usam. Em outras palavras, os softwares que funcionam no DER não estão atendendo as necessidades de seus usuários. Diante da potencial insatisfação, e tomando por base os modelos de Sommerville, Pressman, Delone, Doll e Laudon, foi criado um modelo para levantamento de necessidades e a transformação das mesmas em requisitos de software. Neste trabalho foi desenvolvido um estudo de caso com pesquisa em campo para descrever o mais fiel possível as necessidades dos usuários do DER-PB. Os principais resultados alcançados foram um conjunto de requisitos de usuários, os níveis de satisfação dos usuários do DER divididos em seis fatores e um modelo de resolução de problemas de software. Concluiu-se que é totalmente plausível a construção de requisitos de software por meio das exigências dos usuários, tanto na perspectiva de resposta às demandas dos usuários de software, quanto com foco nos resultados gerados pelos modelos de satisfação. Vale ressaltar também que os setores que possuem os softwares mais eficientes são os que têm mais impacto nos processos e resultados na repartição.
Palavra chave: Engenharia de software. Necessidades de usuários de software.
Requisitos de Software. Manutenabilidade. Engenharia de requisitos
2015. Trabalho de Conclusão de Curso (Bacharelado em Sistemas de Informação).
UFPB/CCAE/DCX, Rio tinto – PB.
ABSTRACT
Employees of the Departamento de Estradas e Rodagens da Paraiba (DER-PB) has shown dissatisfaction with the software they use. In other words, the software running on the DER-PB are not meeting the needs of its members. Faced with this dissatisfaction potential, and based in models of Sommerville, Pressman, Delone, Doll and Laudon, it has created a model for needs assessment and processing thereof in software requirements. In this work was developed a case study with field research to describe as faithful as possible the needs of DER-PB users. The main results were a group of users software requirements, the levels of satisfaction of DER members divided into six factors and a problem resolution model of software. It was concluded that is totally possible write software requirements through the users necessities produced, both in response to the demands of prospective software users, as focusing on results generated by the models of satisfaction. It is noteworthy also that the sectors that have the most efficient software are the ones that have more impact in the process and results of the public repartition.
Keywords: Software Engineering. Needs of software users. Software Requirements.
Maintainability. Requirements Engineering.
EUCS End-User Computing Satisfaction DER Departamento de Estradas de Rodagens SW Software
XP Extreme Programming PGP Pretty Good Privacy TI Tecnologia da Informação SAD Sistema de Apoio a Decisão DMP Divisão de Material de Patrimônio
ABNT Associação Brasileira de Normas Técnicas ISO International Organization for
Standardization
Figura 01 – Modelo EUCS para medição de satisfação 21 Figura 02 – As atividades em Sistemas de Informação 39 Figura 03 – Estrutura Organizacional do DER-PB 46
Figura 04 – Modelo de análise dos dados 48
Figura 05 – Diagrama de fluxo de processo da divisão de
fiscalização 80
Figura 06 – Diagrama de fluxo de processo da divisão de material
de patrimônio 80
Figura 07 – Diagrama de fluxo de processo da divisão de
programação de transporte 80
Figura 08 – Diagrama de fluxo de processo do setor de protocolo 80 Figura 09 – Diagrama de fluxo de processo do setor de protocolo. 81
Quadro 01 – Diferenças de requisitos de usuários e requisitos
de sistemas. 36
Quadro 02 – Variáveis da pesquisa 47
Quadro 03 – Necessidades dos usuários da Diretoria de
Administração 70
Quadro 04 – Necessidades dos usuários da Diretoria de
Manutenção 71
Quadro 05 – Necessidades dos usuários da Diretoria de
Transportes 72
Quadro 06 – Necessidades dos usuários da Diretoria
Superintendente 73
Quadro 07 – Necessidades dos usuários da Diretoria de
Planejamento 74
Quadro 08 – Necessidade e as tipologias de requisitos de
software da diretoria administrativa 76 Quadro 09 – Necessidade e as tipologias de requisitos de
software da diretoria de manutenção 77 Quadro 10 – Necessidade e as tipologias de requisitos de
software da diretoria de transportes 78 Quadro 11 – Necessidade e as tipologias de requisitos de
software da diretoria superintendente 78 Quadro 12 – Tipologias e requisitos de software comuns para
todos os sistemas 79
Quadro 13 – Objetivos alcançados do presente trabalho 84
Gráfico 01 – Nível de satisfação quanto ao conteúdo 51 Gráfico 02 – Nível de satisfação quanto à informação precisa 52 Gráfico 03 – Nível de satisfação quanto á informação
favorável 52
Gráfico 04 – Nível de satisfação quanto á relatório 53 Gráfico 05 – Nível de satisfação quanto á informação
suficiente 54
Gráfico 06 – Nível de satisfação quanto à exatidão 55 Gráfico 07 – Nível de satisfação quanto à exatidão do
software 56
Gráfico 08 – Nível de satisfação quanto à satisfação da
exatidão do software 57
Gráfico 09 – Nível de satisfação quanto ao formato 58 Gráfico 10 – Nível de satisfação quanto á resultados úteis 59 Gráfico 11 – Nível de satisfação quanto á informação clara 59 Gráfico 12 – Nível de satisfação quanto à facilidade no uso 60 Gráfico 13 – Nível de satisfação quanto à programa amigável 61 Gráfico 14 – Nível de satisfação quanto à programa simples 62 Gráfico 15 – Nível de satisfação quanto à informação na hora
certa 63
Gráfico 16 – Nível de satisfação quanto à informação pontual 64 Gráfico 17 – Nível de satisfação quanto à informação
atualizada 65
Gráfico 18 – Nível de satisfação quanto o impacto
organizacional e individual 65
Gráfico 19 – Nível de satisfação quanto à decisão individual 66 Gráfico 20 – Nível de satisfação quanto à decisão
organizacional 67
1 INTRODUÇÃO ... 15
1.1 DELIMITAÇÃO DO TEMA E FORMULAÇÃO DO PROBLEMA ... 15
1.2 OBJETIVOS ... 16
1.2.1 Objetivo geral ... 16
1.2.2 Objetivos específicos ... 16
1.3 JUSTIFICATIVAS ... 17
2 FUNDAMENTAÇÃO TEÓRICA ... 18
2.1 SATISFAÇÃO DO USUÁRIO ... 18
2.1.1 Modelo de medição de satisfação de usuário de delone-mclean ... 19
2.1.2 Modelo de medição de satisfação de usuário: end-user computing satisfaction (EUCS) ... 20
2.2 ANÁLISE DE REQUISITOS ... 22
2.2.1 Identificação do problema ... 22
2.2.2 Avaliação e síntese ... 24
2.2.3 Modelagem ... 25
2.2.4 Especificação de requisitos ... 26
2.2.5 Revisão da especificação ... 29
2.3 IDENTIFICANDO OS TIPOS DE REQUISITOS ... 31
2.3.1 Requisitos funcionais ... 32
2.3.2 Requisitos não funcionais ... 33
2.3.3 Requisitos de domínio ... 35
2.3.4 Requisitos de usuário ... 36
2.3.5 Requisitos de sistema ... 37
2.4 SISTEMAS DE INFORMAÇÃO PARA TOMADA DE DECISÃO ... 38
2.4.1 Sistema de informação ... 38
2.4.2 Modelos de sistemas de informação para resolução de problemas 40 3 PROCEDIMENTOS METODOLÓGICOS ... 43
3.1 MÉTODO DE ABORDAGEM ... 43
3.2 TIPO DE PESQUISA ... 43
3.3 AMBIENTE DA PESQUISA ... 44
3.4 SUJEITOS DA PESQUISA ... 44
3.7 TRATAMENTO DOS DADOS... 48
4 RESULTADOS ... 50
4.1 NÍVEL DE SATISFAÇÃO DOS USUÁRIOS DE SOFTWARE ... 50
4.1.1 Conteúdo ... 50
4.1.2 Exatidão ... 54
4.1.3 Formato ... 57
4.1.4 Facilidade no uso ... 60
4.1.5 Informação na hora certa ... 62
4.1.6 Impacto individual e organizacional ... 65
4.1.7 Perfil dos usuários pesquisados ... 67
4.2 NECESSIDADES DOS USUÁRIOS FINAIS DE SOFTWARE ... 68
4.3 REQUISITOS DO SOFTWARE ... 74
4.3.1 Diagramas ... 79
4.4 MODELO DE RESOLUÇÃO DE PROBLEMAS DE SOFTWARE... 81
4.4.1 Identificando funcionalidades e interfaces defasadas e inoperantes no software ... 82
4.4.2 Proposta de soluções para as funcionalidades ... 82
4.4.3 Avaliação das propostas ... 82
4.4.4 Implementação ... 83
5 CONCLUSÃO ... 84
5.1 CONSECUÇÃO DOS OBJETIVOS ... 84
5.2 RECOMENDAÇÃO PARA A EMPRESA ... 86
5.3 LIMITAÇÕES DA PESQUISA ... 86
5.4 SUGESTÕES DE PESQUISAS FUTURAS ... 87
REFERÊNCIAS ... 88
APÊNDICE A – QUESTIONÁRIO ESTRUTURADO E MEDIDOR DE SATISFAÇÃO DO USUÁRIO .... 89
APÊNDICE B – ENTREVISTA COM OS USUÁRIOS DO DER-PB ... 91
ANEXO 1 – SOLICITAÇÃO DO TRABALHO PELO DER-PB ... 93
1 INTRODUÇÃO
1.1 DELIMITAÇÃO DO TEMA E FORMULAÇÃO DO PROBLEMA A engenharia de software é uma área da computação que visa à criação de padrões para construção, manutenção e análise de projeto de softwares.
Atualmente as organizações estão contratando especialistas em engenharia de software com o objetivo de obter um produto que aumente sua eficiência nas atividades organizacionais.
Dentro da engenharia de software existem diversas áreas de conhecimento responsáveis por cada parte do projeto de software. Dentre elas existem os testes de software, manutenção de software, análise de requisitos, etc. A análise de requisitos é responsável por descrever as funções e delimitações que o software possuirá assim que for implementado (SOMMERVILLE, 2007). A descrição das funções e delimitações está ligada as necessidades dos usuários (funcionários de uma organização) que vão usar o software (QUEIROZ, 2001).
O Modelo de Delone & McLean (1992) mede o sucesso de um sistema de informação. Ele apresenta diversos elementos como a qualidade do software, da informação, satisfação ou atendimento das necessidades dos usuários, uso do software, e o que é bastante interessante, o impacto individual e organizacional. Estes dois últimos mostram que o uso e a satisfação do usuário são dependentes um do outro e que levam diretamente ao impacto individual e consequentemente ao impacto organizacional (PERINI, 2008).
Já o Modelo End-User Computing Satisfaction, ou apenas EUCS, mede especificamente a satisfação, ou atendimento das necessidades de usuários de software. O modelo, se comparado com o de Delone (1992), é mais fácil de ser usado, sobretudo em pesquisas acadêmicas. Escala do tipo Likert é usada para facilitar as respostas do questionário (PERINI, 2008).
Sendo EUCS um modelo mais fácil e usado para pesquisas acadêmicas, suas questões são utilizadas no presente trabalho. A adição do modelo de Delone (1992) complementa o modelo EUCS porque traz o elemento de impacto individual e organizacional. Já que a pesquisa é feita em uma
organização, é importante notarmos se o software está dando uma melhor compreensão do contexto para tomada decisão, tanto individual, quanto organizacional (PERINI, 2008).
O modelo de sistemas de informação é usado para identificar e resolver problemas de uma forma padronizada (LAUDON, 2010). O modelo é adaptável e totalmente viável para solucionar problemas de softwares defasados e usuários insatisfeitos em repartições governamentais.
O Departamento de Estradas de Rodagens da Paraíba (DER-PB) é um órgão fiscalizador que depende de softwares para supervisionar empresas de ônibus, terminais de passageiros, campos de pousos, veículos particulares, armazenar informações de centenas de funcionários, dentre outras atividades de interesse da sociedade. O fato é que, ao serem manuseados pelos funcionários, os softwares não estão satisfazendo as necessidades dos mesmos, ou seja, as funções dos softwares não estão suprindo o papel que o DER-PB precisa desempenhar. Diante destes problemas, o DER-PB está impossibilitado de executar com abrangência suas atividades organizacionais de fiscalização.
Neste contexto o estudo visa responder ao seguinte problema de pesquisa: Como transformar as necessidades dos usuários de programas do DER-PB em requisitos de software?
1.2 OBJETIVOS
Os objetivos funcionam como norteadores da pesquisa de modo a direcionar o planejamento, a execução e as análises de resultados.
1.2.1 OBJETIVO GERAL
Determinar a conversão das necessidades dos usuários de software do DER-PB em requisitos de software.
1.2.2 OBJETIVOS ESPECÍFICOS
Analisar o nível de satisfação dos usuários de software descrevendo o problema identificado, com base em Delone e Mclean (1992) e Doll (1988);
Levantar as áreas, atividades, fluxos operacionais, da organização e suas respectivas necessidades de software, com base em Sommerville (2007) e Pressman (2002);
Relacionar as necessidades dos usuários às tipologias de requisitos de software com base em Sommerville (2007) e Pressman (2002);
Propor a adoção de modelos para resolução de problemas de software com base em sistemas de informações. Estes modelos estão embasados em Laudon (2010).
1.3 JUSTIFICATIVAS
Como já foi dito anteriormente, o DER-PB é um órgão muito importante no cenário estadual porque fiscaliza terminais, rodovias, dentre outras coisas de interesse da sociedade. A repartição usa softwares para ajudar na fiscalização destes locais.
Para desenvolver estes softwares nunca foram usados padrões de projeto (como scrum, xp, ou modelos iterativos) e/ou pesquisas para descobrir quais funcionalidades satisfazem as necessidades dos funcionários, que são os usuários destes softwares. Em decorrência da falta de padrões para a construção dos softwares, os mesmos, hoje em dia, não possuem as funcionalidades suficientes para ajudar seus usuários a exercer as atividades, e consequentemente, impossibilita o DER-PB de fiscalizar, com total abrangência, os locais que atua.
Este trabalho vem propor a adoção de modelos para medir o real nível de satisfação dos usuários de software da repartição. Para suprir as necessidades dos usuários e, consequentemente, tornar eficiente a atuação de fiscalização do DER-PB, o trabalho propõe a atividade de análise de requisitos.
2 FUNDAMENTAÇÃO TEÓRICA
Para saber se os usuários de uma organização estão satisfeitos ou não com os softwares (SW) usados é necessário adotar modelos de medição de satisfação. O capítulo de fundamentação teórica explica dois, que são o Modelo de Delone (1992) e EUCS. Caso o analista de software (como é descrito a pessoa que tenta resolver os problemas de SW e satisfação de usuário) descobrir que estes softwares não estão satisfazendo as necessidades dos usuários da organização, ele propõe o levantamento destas necessidades e a sua transformação em requisitos de software. Um software que atende a necessidade dos usuários demonstra que possui qualidade.
Outra característica de um software com qualidade é ter seus requisitos bem definidos anteriormente, durante a elaboração do documento de requisitos.
Além destes requisitos de software que suprem as necessidades dos usuários, é importante que a organização adote um modelo para resolução de problemas dos softwares. Desta forma eles nunca ficarão defasados, e quando preciso, serão atualizados ou até mesmo substituídos.
2.1 SATISFAÇÃO DO USUÁRIO
Pfleeger (2004) apud Perini (2008) diz que o valor de um produto com qualidade depende do valor que o cliente está disposto a pagar por este produto. Segundo Côrtes (2001) apud Perini (2008), um dos atributos em sistemas de informação que contribuem para a qualidade de software é a satisfação do usuário. Ainda de acordo com o autor, a usabilidade, a funcionalidade, a confiabilidade e a interatividade são atributos de software avaliados com base no usuário. Os referidos pontos são avaliados por meio de questões que se aproximem dos atributos supracitados que, por sua vez, serão respondidos pelos usuários com o objetivo de medir estes pontos.
Queiroz (2001) diz que as organizações nacionais e internacionais de padronização estão associando o termo qualidade com o atendimento de necessidades do usuário. Segundo o padrão 8402 (ABNT) apud Queiroz (2001), a qualidade de um produto (software, dentre outros) é medida de acordo com a sua capacidade de suprir as necessidades do usuário, sejam elas explícitas ou implícitas. O termo qualidade, na perspectiva do usuário,
significa o compromisso com suas necessidades individuais, ou seja, a qualidade do software vai variar de acordo com a visão de que cada usuário tem sobre ele. Costa (2008) diz que é impossível estudar um a um todos os usuários, por isso faz-se necessário o estudo de pequenos grupos de usuários.
Lembrando que tais necessidades só serão supridas caso forem bem definidas (QUEIROZ, 2001).
Algo que reflete nas necessidades dos usuários são os requisitos (SOMMERVILLE, 2007). A realização destas necessidades exige a produção de requisitos. Para produzir requisitos de uma forma clara é executada uma atividade na engenharia de software chamada análise de requisitos (QUEIROZ, 2001), algo que será explicado nos próximos tópicos deste capítulo. O padrão 9000 (ISO) apud Queiroz (2001) diz respeito à garantia da qualidade de um produto/software sob o ponto de vista do preenchimento de um conjunto de requisitos pré-definidos. A satisfação do usuário também está ligada aos requisitos. Características ou atributos de um software, que contribuem para a satisfação de usuário são um misto de requisitos, tanto funcionais como não funcionais (QUEIROZ, 2001).
Em relação ao sistema de gestão da qualidade, o padrão (ISO 9001:2008) diz que a análise de dados de uma empresa deve proporcionar informações como satisfação do cliente e conformidade com requisitos do produto. Deve sempre existir o objetivo de melhorar e aperfeiçoar os softwares.
2.1.1 MODELO DE MEDIÇÃO DE SATISFAÇÃO DE USUÁRIO DE DELONE- MCLEAN
Perini (2008) enfoca satisfação de usuário como um componente importante para o sucesso de sistemas de informação. Um modelo de sucesso de sistemas de informação bastante utilizado é o de William H. Delone e Ephraim R. McLean. De acordo com Perini (2008) o Modelo de Delone e Mclean (1992) enfatiza que a qualidade do software afeta a satisfação do usuário. Para se medir a satisfação do usuário, o Modelo de Delone e McLean (1992) avalia a facilidade de uso, se o software é satisfatório ou frustrante, se o software é adequado, se é flexível, se o usuário é estimulado a utilizar o software e o que o usuário acha do software (PERINI, 2008).
Um dos elementos do Modelo de DeLonee McLean (1992) é o impacto individual. Um software de qualidade impacta de forma positiva e individualmente, possibilitando ao usuário: uma melhor compreensão do contexto para melhorar sua tomada de decisão; a produção de mudanças em suas atividades; a mudança em sua percepção para tomadas de decisões. Por sua vez, o impacto individual pode levar ao impacto organizacional, que é uma mudança positiva em toda a organização (PERINI, 2008).
Para se comprovar a veracidade do Modelo de Delone e Mclean (1992), este foi executado por Livari (2005) apud Perini (2008). O teste foi realizado em um órgão da prefeitura de Oulu, na Finlândia, composto por 7500 funcionários.
Foram propostas hipóteses para verificar a afirmação de que a qualidade do software (...) está positivamente associada com a satisfação do usuário. Duas dessas hipóteses são: assume que quanto melhor for a qualidade do software percebida pelos usuários, mais satisfeito eles estarão com o software. A outra é: prediz que quanto melhor a qualidade do software, mais o software é usado.
Perini disse que os caminhos da qualidade do software até a satisfação do usuário e da satisfação do usuário para o impacto individual aconteceram como previa o Modelo de Delone-McLean (1992) (PERINI, 2008).
2.1.2 MODELO DE MEDIÇÃO DE SATISFAÇÃO DE USUÁRIO: END-USER COMPUTING SATISFACTION (EUCS)
Queiroz (2001) não fala sobre o modelo de Eusc, porém ele afirma que um dos estimadores para medir o grau de iteração de usuário com o software, ou com qualquer outro produto, tem sido a satisfação do usuário. Explicando melhor esta preferência pelo estimador satisfação, quanto maior for a satisfação do usuário pelo software, maior será o grau de iteração deste usuário com este software.
O modelo Eusc (no português, satisfação de usuários finais de computação) foi desenvolvido para medir a satisfação do usuário em relação ao software avaliado. Para se construir este modelo, Doll e Torkzadeh (1988) revisaram trabalhos anteriores sobre satisfação de usuário com o objetivo de formar um modelo próprio deles. O resultado foi um modelo com 31 (trinta e um) itens para medir o fator percepção do usuário, e mais tarde seriam
acrescentados mais sete itens para medir o fator facilidade de uso. Com isso obtiveram incialmente um modelo composto por 40 itens usando a escala de Likert composta pelos seguintes pontos: 1 – quase nunca; 2 – algumas vezes;
3 – metade das vezes; 4 – a maioria das vezes; 5 – quase sempre, além de dois fatores que eram facilidade de uso e percepção (PERINI, 2008).
Para testar este novo modelo foram selecionadas cinco empresas, sendo estas um órgão do governo, uma fábrica, dois hospitais e uma universidade. As instruções pediam que os usuários circulassem os pontos da escala de likert; com isso foram coletas as respostas de noventa e seis usuários de cada empresa. Os pesquisadores analisaram as perguntas e respostas procurando retirar imprecisões, ambiguidades, mesclar perguntas parecidas, dentre outros ajustes.
No final do refinamento, os pesquisadores obtiveram um modelo composto por 12 itens agrupados em cinco fatores (conteúdo, exatidão, formato, usabilidade, informação na hora certa) fatores estes iriam facilitar a compreensão dos pesquisadores em relação aos resultados coletados (PERINI, 2008). Para uma melhor compreensão do Modelo, observe a Figura 01:
Figura 01 - Modelo EUCS para medição de satisfação de usuário.
Fonte: Perini (2008)
As doze questões da Figura 01 são importantes para identificar se os usuários estão satisfeitos ou não com o software o nível de satisfação pode variar entre os cinco fatores.
Na análise de satisfação dos usuários do DER-PB (Departamento de Estradas de Rodagens da Paraíba), os modelos de Doll (1988) e Delone (1992) são combinados. As questões do Modelo de Delone são inseridas entre os cinco fatores do modelo EUCS. As respostas das questões são examinadas com o objetivo de identificar o impacto individual ou até mesmo o organizacional.
2.2 ANÁLISE DE REQUISITOS
A análise de requisitos é uma das áreas mais importantes da engenharia de software. Por meio dela, segundo Pressman (2002), as funções, o desempenho, interface, dentre outros elementos do software são especificados. Para facilitar a análise de requisitos existem cinco áreas de esforço. Estas são a identificação do problema a ser resolvido pelo software (primeiro contato do engenheiro com o cliente), avaliação e síntese de soluções deste problema, a modelagem para melhor compreensão, a especificação do software, e a revisão desta especificação. Este trabalho é feito por meio do engenheiro de software e o cliente, com o objetivo de chegar a uma documentação consistente e fiel ao que foi solicitado. De acordo com Pressman (2002), a especificação de requisitos proporciona ao engenheiro de software e ao cliente os critérios para avaliar a qualidade assim que o software for construído.
2.2.1 IDENTIFICAÇÃO DO PROBLEMA
Deve ser estabelecida uma comunicação entre o futuro usuário (cliente) do produto e o engenheiro de software com o propósito de identificar problemas nos processos, nas atividades, dentre outros pontos da organização. Estes problemas podem ser receptivos a uma solução baseada em computador. É normal que esta comunicação entre engenheiro e futuro usuário possua ruídos, que segundo Pressman (2002) significa uma má interpretação das informações, omissão, etc. Estes ruídos ocorrem quando informações fornecidas de clientes entram em conflito, e funções e o
desempenho entram em contradição com restrições impostas por elementos do software (PRESSMAN, 2002). Para evitar estes ruídos, técnicas de comunicação são usadas.
Uma primeira entrevista entre cliente e engenheiro de software é feita, porém este encontro sempre é constrangedor. Nenhum dos dois sabe o que dizer, tem medo de serem mal interpretados, querem que a entrevista acabe logo, mas que seja bem sucedida. Pressman (2002) aconselha que, para uma compreensão básica dos problemas, o engenheiro de software faça perguntas de livre contexto, do tipo: Quem está por trás do pedido deste trabalho? Quem usará a solução? Qual o benefício econômico de uma solução bem sucedida?
Há outra fonte para a solução exigida? Estas questões se concentram no cliente, nas metas globais e nos benefícios (PRESSMAN, 2002).
A segunda bateria de perguntas capacita o analista a entender melhor o problema. São estas algumas perguntas: Qual problema(s) essa solução resolverá? Como você caracteriza um “bom” resultado (saída) que seria gerado por uma solução bem-sucedida? Esta segunda parte também ajuda o cliente poder se expressar sobre uma possível solução. A terceira e última concentra- se na efetividade do encontro, também chamadas de metaperguntas, propõem as seguintes questões: Você é a pessoa certa para responder a essas perguntas? Suas respostas são oficiais? Minhas perguntas são pertinentes ao problema que você tem?. Todas estas perguntas (e muitas outras) levantadas desde o primeiro parágrafo deste tópico são feitas para “quebrar o gelo” entre os indivíduos, cliente e engenheiro de software, realizando assim uma análise dos problemas bem-sucedida (PRESSMAN, 2002).
Sommerville (2007) diz que antes de qualquer coisa deve ser feito um estudo de viabilidade, este estudo consiste em saber se o novo software será ou não útil para a organização. Perguntas são feitas para os clientes e gerentes de departamento com o intuito de saber se um software novo é viável ou se um já existente resolveria o problema, são elas: O software contribui para os objetivos gerais da empresa? Quais são os problemas com os processos atuais? Como o novo software ajudaria a reduzir esses problemas? Como a
organização se comportaria se esse software não fosse implementado?
(SOMMERVILLE, 2007).
2.2.2 AVALIAÇÃO E SÍNTESE
A segunda fase, a de avaliação e síntese, é a que requer mais esforço durante a análise. Algumas tarefas a seguir servem para descrever o problema de tal forma que uma abordagem ou solução global para o software pode ser sintetizada: Monitoração do comportamento do software no contexto dos eventos que afetam-no, avaliação do fluxo e conteúdo da informação, descobrimento de restrições do projeto, elaboração e definição das funções do software. Assim como na primeira fase, identificação do problema (2.1), a fase de avaliação e síntese também está sujeita a problemas, como conflitos entre informações e conflitos entre funções e restrições de software (PRESSMAN, 2002).
Para esclarecer melhor o objetivo desta fase, Pressman (2002) dá um exemplo de uma empresa fornecedora de autopeças. O engenheiro descobriu uma série de problemas na empresa envolvendo, incapacidade de obter o status de um componente rapidamente, turno de dois a três dias para atualizar um arquivo de cartões e múltiplas reencomendas ao mesmo vendedor, porque não há formas de associar vendedores com componentes. Logo que os problemas são identificados, o engenheiro determina as informações que serão produzidas pelo software (por exemplo, um relatório diário de quais peças foram requisitadas no estoque e quantas unidades daquela peça ainda existem no estoque) e fornecidas (por exemplo, os funcionários do setor de estoque registrarão o número de identificação de cada peça quando elas saírem do estoque). Em outras palavras, informações de entrada e saída. Agora que avaliou, determinou e descobriu, o engenheiro começa a sintetizar soluções para o software. Por exemplo, um software on-line baseado em terminal resolverá uma grande parte destes problemas? Um software de gerenciamento poderia ser uma boa ideia para estes problemas identificados? Este processo de avaliação e síntese prossegue até o cliente e engenheiro chegar a uma informação do software consistente ao ponto de poderem passar para as próximas fases (PRESSMAN, 2002).
Sommerville coloca a segunda fase como a etapa de elicitação de requisitos, onde o engenheiro trabalha com o cliente (seja ele usuário final ou algum stakeholder que não usa o software diretamente), com o propósito de aprender sobre o domínio da informação (domínio dos eventos/controles, comportamentos do software, dados), restrições de hardware na organização, etc. Entrevistas também são úteis, já que por meio delas o cliente dá informações sobre problemas que ele enfrenta com uso do software antigo, e informa o que seria importante o novo software possuir. Para deixar mais claro a ideia de Sommerville, ele mostra um espiral que representa um modelo de análise de requisitos genérico, este é composto por: classificação, priorização, documentação e obtenção de requisitos. Estas atividades serão executadas de forma intercalada de modo que o processo progrida da parte interna da espiral para a parte externa (SOMMERVILLE, 2007).
2.2.3 MODELAGEM
Modelos são criados com o propósito de compreender no software o processamento funcional, fluxo de dados e de controle, comportamento das operações e o conteúdo da informação (PRESSMAN, 2002). Já de acordo com (SOMMERVILLE, 2007), modelos servem para fazer representações gráficas com o intuito de mostrar processos de negócios, também servem para descrever problemas a serem resolvidos e softwares a serem desenvolvidos.
Em outras palavras, uma forma mais compreensível do que as detalhadas descrições do projeto.
Modelos devem ser capazes de modelar as informações que os softwares transformam, funções ou subfunções que permitem que estas transformações ocorram, além do comportamento do software quando estas transformações estão acontecendo. Eles se concentram naquilo que o software deve fazer e não como ele faz. Os modelos ajudam o analista a entender o software, facilitando assim a análise de requisitos. Eles tornam-se o ponto focal para revisão do software, sendo o ponto principal para a plenitude, consistência e precisão da especificação de software. Resumindo o parágrafo, a área de modelagem é a base para o projeto de software, fornecendo ao engenheiro uma ideia do software a qual pode ser descrita em um contexto de implementação (PRESSMAN, 2002).
Sommerville (2007) explica sobre modelos de software. Existem três diferentes perspectivas representadas pelo software por meio de diferentes modelos.
Externa, onde você decide sobre os limites do software. Isso significa que você vai trabalhar com os stakeholders com o objetivo de distinguir o que é software e o que é o ambiente do software. Você deve tomar decisões para limitar os custos do projeto e verificar o tempo necessário para análise;
Comportamental é o que modela o comportamento global do software.
Ele está dividido em dois tipos, estes são o modelo de máquina que modela como o software reage a eventos e o modelo de fluxo de dados que modela o processamento de dados no software;
Estrutural, onde a arquitetura do software ou a estrutura dos dados é modelada. Nesta perspectiva é definida a forma lógica dos dados processados pelo software, também algumas vezes chamada de modelos semânticos de dados.
2.2.4 ESPECIFICAÇÃO DE REQUISITOS
A especificação de requisitos de software é produzida no auge da tarefa de análise. As funções e recursos do software são refinados assim que a descrição, restrições, critérios de validação e dados pertinentes do software são estabelecidos. A especificação também pode ser vista como um processo de representação. Para obter uma especificação bem feita, Pressman (2002) sugere oito princípios, que serão descritos nos parágrafos seguintes:
O primeiro princípio diz que devemos separar funcionalidade de implementação, ou seja, a especificação irá descrever aquilo que é desejado (funções) e não como tem que ser realizado ou implementado. Para representar melhor este princípio, Pressman mostra as funções matemáticas (adotadas pela especificação): dado um conjunto de valores na entrada, mostre o resultado na saída. Os resultados obtidos na função foram expressos numa forma o que e não como;
O princípio dois diz que uma linguagem de especificação de softwares orientada ao processo é exigida. As mudanças de um ambiente dinâmico afetam o comportamento das entidades que se relacionam com este ambiente. A forma adotada para se monitorar este comportamento é por meio
da descrição orientada a processos. Por meio dela, a especificação o que será conseguida ao ser criado um modelo de comportamento baseado nos vários estímulos e respostas do ambiente. Hoje em dia, este modelo tem sido requisitado apenas em situações complexas que precisaram ser especificadas;
No terceiro princípio, o autor diz que a especificação deve abranger o sistema do qual o software é um componente. Um sistema é formado por vários componentes que se interagem. O comportamento de um determinado componente só será definido caso: ele esteja dentro do contexto do sistema e que haja interação entre todos os componentes deste sistema. Um sistema pode ser modelado como uma coleção de objetos (passivos e ativos) que se relacionam. Nas relações dos softwares ocorrem mudanças. Estas relações proporcionam estímulos, aos quais os objetos ativos reagem. As respostas podem provocar mais mudanças ainda, produzindo assim estímulos adicionais aos quais os agentes poderiam reagir;
O quarto princípio diz que o ambiente em que o software opera também deve ser especificado. Este deve ser reconhecido como um software composto de objetos interagentes (passivos e ativos). A diferença entre o ambiente e o software que opera nele (também pode ser chamado de agente) é o esforço seguinte do projeto (implementação) que será executado com base na especificação do software (e não do ambiente). A especificação do software é representada como um panorama de uma coleção, esta é altamente interligada por agentes que reagem a estímulos do ambiente. Estas ações do agente são necessárias para alcançar as metas do software. Pressman diz que esta interligação de agentes (dependência) viola o princípio da separalidade, ou em outras palavras, o isolamento de outras partes do software e do ambiente. No entanto, este é um princípio do projeto e não da especificação.
Enquanto o projeto se preocupa em decompor a especificação em partes quase separáveis, a especificação se preocupa em retratar de uma forma precisa o ambiente e seu software. Esta retratação é feita por meio das exigências solicitadas anteriormente por usuários, e que para obter êxito precisa ser feita de forma interativa;
O princípio cinco diz que uma especificação deve expressar um modelo cognitivo em vez de um modelo de projeto ou implementação. A seguir, alguns pontos que devem ser obedecidos de acordo com este princípio:
A especificação deve descrever um software da forma como ele é percebido pela comunidade de usuários;
Os objetos que manipula devem corresponder aos objetos desse domínio;
Os agentes devem modelar as pessoas, organizações e equipamentos desse domínio;
As ações que a especificação executa devem modelar aquelas que ocorrem de fato no domínio;
A especificação deve ter a possibilidade de incorporar as regras ou leis que regem os objetos de domínio.
Leis proscrevem estados do software (como, por exemplo, os objetos devem se somar quando o contador bater a marca de cem) e, desta forma, limitam o comportamento dos agentes ou mostram a necessidade de se adicionar novas regras para evitar o surgimento destes estados. Outras leis descrevem como os objetos reagem quando sofre uma ação, estas são uma parte inerente da especificação do software (PRESSMAN, 2002).
O sexto princípio diz que uma especificação deve ser formal e consistente o bastante para determinar se a proposta da implementação do software é satisfatória ou não. Em outras palavras, os resultados obtidos a partir de dados aleatoriamente escolhidos devem ser validados por meio da especificação. Mesmo que não seja uma especificação completa do “como”, esta deve agir como um gerador de possíveis comportamentos entre os quais deve estar a implementação proposta. Por isso, em um contexto mais amplo, a especificação deve ser operacional;
O sétimo princípio diz que a especificação não deve ser totalmente completa já que o ambiente em que ela está inserida é demasiadamente complexo para isso. Lembrando que uma especificação é um modelo, algo que retrata o real ou o que foi imaginado, uma abstração, e por isso será incompleta e sem necessidade de inteireza em sua operacionalidade;
O oitavo e último princípio diz que a especificação não deve ser um objeto estático, como ficou entendido nos princípios anteriores, mas sim um objeto dinâmico sujeito a modificações. Estas modificações ocorrem em três atividades diferentes e principais: formulação, quando uma especificação é
inicialmente construída; desenvolvimento, quando a especificação é elaborada iterativamente; finalmente quando requisitos funcionais adicionais são inseridos. O ideal é que a informação seja facilmente localizada e que apenas uma peça ou requisito necessite ser modificado em caso de mudança da informação. Ao mesmo tempo a especificação precisa ser fracamente acoplada, para que um novo requisito, informação ou peça seja facilmente adicionado ou removido, reajustando automaticamente a estrutura.
No auge da tarefa de análise de requisitos, a especificação de requisitos de software é produzida. A especificação mostra o tipo de requisito, se é um requisito funcional ou não funcional, e para qual destinatário ele será direcionado (para o software, para o usuário, ou para o design da aplicação).
Nela consta a identificação do requisito, sua descrição, restrições, diagramas de apoio, prioridades, etc. No documento de especificação também é mostrado um modelo do fluxo de informação para uma melhor compreensão do ambiente em que o software está inserido. Enfim, todas as informações disponíveis são descritas adequadamente no documento a fim de obter um documento expressado claramente.
2.2.5 REVISÃO DA ESPECIFICAÇÃO
Segundo Pressman (2002), a revisão da especificação é realizada pelo engenheiro de software e o cliente. Primeiramente a revisão examina a especificação em nível macroscópico, ou seja, de um modo superficial. Nesta fase ela tenta garantir que a especificação esteja completa, consistente e precisa. Algumas questões a seguir são consideradas:
O fluxo de processo do ambiente está de acordo com o que o cliente descreveu?
Os diagramas são claros? Cada um pode sustentar-se sozinho, sem textos complementares?
As prioridades (obrigatório, importante e desejável) dos requisitos estão conforme o nível de importância dos requisitos?
As funções importantes permanecem dentro do escopo e cada uma foi adequadamente descrita?
As restrições de projeto são realísticas?
Existem inconsistências, omissões e/ou redundâncias?
O contato com o cliente é completo?
As descrições estão representando bem cada requisito?
As descrições funcionais estão representando bem os problemas a serem solucionados pelo software?
Ainda de acordo com Pressman (2002), para alcançar respostas às questões apresentadas acima, a revisão pode focalizar um nível detalhado (diferente de macroscópico). Por meio da revisão tentamos descobrir problemas ocultos no conteúdo da especificação. A seguir são sugeridas diretrizes para uma revisão de especificação detalhada com o objetivo de encontrar estes problemas ocultos:
Ter atenção com conectivos persuasivos, como por exemplo,
“certamente”, “claramente”, “segue-se que”. É importante ter noção do por que estes conectivos estão presentes;
Evite termos e verbos vagos. Esclareça-os. “Frequentemente” e “Na maior parte” são exemplos de verbos vagos. “Manuseados” e “Rejeitados” são exemplos de verbos vagos;
Quando apresentadas listas incompletas, onde no final aparecem os termos “etc”, “assim por diante”, “tal como”, certifique-se de que estas listas estão compreendidas;
Esteja certo de que as sentenças não dão nenhuma margem para ambiguidade (por exemplo: “As variáveis guardam números”. Números inteiros? Reais? Hexadecimais?);
Também se certifique de que os pronomes não dão margem para ambiguidade (por exemplo: “o módulo I/O comunica-se com o módulo de validação de dados e seu sinal de controle está ligado”. Qual sinal de controle?);
Procure palavras que impliquem certeza, como por exemplo, “sempre”,
“cada”, “todos”, “nenhum”;
Verifique se os gráficos apresentados vêm acompanhados de descrições.
Segundo Pressman (2002), após a conclusão da revisão, cliente e engenheiro assina o documento de requisitos, como se fosse um contrato.
Novas alterações podem ocorrer após a assinatura do documento, porém o cliente deve ter ciência de que isso aumentará o custo e o escopo do documento de requisitos.
No decorrer da especificação podem ocorrer vários tipos de problemas (incoerência, ambiguidade, inconsistência), por isso existem ferramentas que auxiliam na produção da especificação de requisitos. Mesmo com o esforço da revisão, nem todos os problemas são encontrados na especificação, sendo assim necessário o uso de ferramentas especialistas que garantem precisão (PRESSMAN, 2002).
No presente trabalho, a atividade de revisão de especificação serve para garantir um documento fiel, preciso e consistente. Sendo este um documento de análise de requisitos não muito grande, as chances de erros não percebidos são mínimas. Já que se trata de uma monografia, o tempo para coleta de dados, produção do documento de requisitos e revisão é grande o bastante para fazer um projeto completo.
2.3 IDENTIFICANDO OS TIPOS DE REQUISITOS
Depois de levantar as necessidades dos usuários e especificar os requisitos do software, o importante agora é entender melhor o que são requisitos, sua importância e como eles estão classificados. Segundo Sommerville (2007) os requisitos de um software são descrições dos serviços fornecidos e restrições operacionais. Ainda de acordo com o autor, o termo requisito não é usado de maneira consistente na indústria de software. Um requisito pode ser uma declaração abstrata de algum serviço do software, como também pode ser uma descrição detalhada de alto nível de alguma função do software. Os requisitos também especificam interfaces quando se trata de um software novo que vai trabalhar ao lado de um software já existente. A interface do programa existente precisa ser descrita para uma melhor compreensão dos desenvolvedores (SOMMERVILLE, 2007).
Como já foi dito no tópico passado (2.2), alguns problemas ocorrem no decorrer do processo de análise de requisitos. Estes problemas são resultantes
da falta de uma clara separação entre os diferentes níveis de descrição dos requisitos. Existem duas formas de declaração de requisitos:
Requisitos de usuário, que são uma forma superficial de se entender o programa. Quais serviços são esperados e quais restrições o programa deve ter. Estes requisitos são direcionados para usuários que não estão interessados na parte de implementação do programa, e sim no que o programa oferece;
Requisitos do sistema expressam uma perspectiva detalhada do programa, e do que será implementado. Estes requisitos estão direcionados para os desenvolvedores ou analistas de sistema.
Os requisitos de usuário e de sistema estão classificados em requisitos funcionais, não funcionais e de domínio. Requisitos funcionais declaram os serviços que o programa deve oferecer, orientam o comportamento do programa em determinadas situações e mostra como este deve agir com diferentes tipos de entrada. Já os requisitos não funcionais estabelecem restrições de funções do programa e dos serviços e processos no desenvolvimento. Também descrevem o desempenho, eficiência e segurança esperada pelo programa. Os requisitos de domínio expressam o domínio da aplicação do programa. Eles descrevem características e restrições exclusivas deste domínio. Requisitos de domínio podem ser tanto requisitos funcionais com não funcionais (SOMMERVILLE, 2007).
2.3.1 REQUISITOS FUNCIONAIS
Lembrando-se do que foi dito anteriormente, requisitos funcionais descrevem de uma forma detalhada o que um programa deve conceder ou quais funções ele oferecerá. Para serem produzidos, eles dependem das informações que mostram o tipo de software que será construído ou modificado. O cliente descreve as necessidades, ou informações, da organização que precisam ser supridas pelo software (SOMMERVILLE, 2007).
De acordo com Sommerville (2007), os requisitos funcionais podem ser escritos de formas e níveis de detalhamento diferentes. Por exemplo, requisitos funcionais de um programa A podem ser expressos de um modo que são compreendidos pelo usuário (o usuário deve ser capaz de fazer uma busca no
catálogo de produtos à venda) como também podem descrever algo em um nível mais técnico (para cada produto a venda, o programa deve alocar um único identificador ORDER_ID). Caso esses requisitos sejam especificados de forma imprecisa, isto pode acarretar problemas de interpretação por parte dos desenvolvedores. O desenvolvedor pode interpretar o requisito de uma forma, sendo que o usuário queria outra coisa. Por exemplo, o requisito diz que o programa A deve fornecer telas amigáveis que ajudem o usuário a operá-lo; o desenvolvedor ao ler o requisito fica livre para implementar qualquer tela, podendo assim até simplificar seu trabalho. Claro que, frequentemente, não é isso que o cliente deseja. Novos requisitos precisam ser definidos e mudanças devem ser feitas na atividade de análise, a fim de chegar naquilo que o cliente realmente quer (SOMMERVILLE, 2007).
A especificação dos requisitos funcionais deve ser algo completo e consistente. Completo porque tudo aquilo que o usuário deseja deve estar descrito no documento de requisitos. Consistente porque o documento não deve descrever requisitos que entram em contradição. Em outras palavras, deve ser algo fácil de ser interpretado pelos diferentes tipos de usuários.
2.3.2 REQUISITOS NÃO FUNCIONAIS
Os requisitos não funcionais estão preocupados com as propriedades emergentes do programa, como por exemplo, confiabilidade, tempo de resposta e espaço de armazenamento. Outros exemplos de propriedades emergentes do programa que os requisitos não funcionais também podem especificar são desempenho, proteção e disponibilidade. Estes requisitos são considerados mais importantes do que os requisitos funcionais individuais, pois enquanto que os usuários podem contornar funções do programa que não atendem as suas necessidades, falhas ou erros devido ao não atendimento dos requisitos não funcionais podem tornar o programa inútil (SOMMERVILLE, 2007).
De acordo com Sommerville (2007), os requisitos não funcionais surgem logicamente devido às necessidades dos usuários. Além deste, outros motivos são, às restrições de orçamento, políticas da organização, operação com outros programas (fatores externos), regulamentos e legislações. Para atender
a estes pontos supracitados, os requisitos não funcionais se dividem basicamente em três tipos:
Requisitos de produto. Estes descrevem o comportamento do programa.
Como por exemplo, seu comportamento referindo-se a rapidez e memória, confiabilidade referindo-se a taxa aceitável de falhas, portabilidade referindo-se a sua compatibilidade em diferentes plataformas e usabilidade referindo-se ao seu fácil uso;
Requisitos organizacionais. Definem políticas de procedimento dos clientes e desenvolvedores. Padrões de processos, ou seja, que o programa deve ser desenvolvido de acordo com um determinado processo padrão da organização. Ele dita quais linguagens serão usadas na implementação do programa e também quando a documentação do programa será entregue;
Requisitos externos. Abrangem todos os requisitos que estão relacionados com o programa exteriormente. Atributos de requisitos externos são interoperabilidade, que significa a capacidade de interagir com outros programas de outras organizações; legalidade, que conduz o programa a estar conforme as legislações, regras e leis dos requisitos legais.
O ponto negativo de se especificar requisitos não funcionais é que suas metas, frequentemente, ficam muito vagas ao ponto de não poderem ser testáveis. Para que seja possível testar os requisitos não funcionais é necessário escrevê-los quantitativamente. Como por exemplo, “os usuários devem receber informações dos preços dos produtos em até no máximo 2 minutos”; “o sistema deve suportar 500 usuários acessando simultaneamente”.
É aconselhável medir a capacidade do sistema por meio de números, dados e valores.
Para compreensão dos desenvolvedores e clientes é importante que os requisitos sejam descritos detalhadamente, e não apenas de uma forma geral.
Como por exemplo, em um requisito não funcional de segurança, é incorreto dizer que “o sistema terá segurança total dos dados”, o correto seria dizer que
“o sistema deve possuir tecnologia de encriptação e descriptografia de dados por meio do PGP”. A ideia é que eles sejam detalhados o bastante para serem entendidos, implementados e subsequentemente testados.
2.3.3 REQUISITOS DE DOMÍNIO
Segundo Sommerville (2007), os requisitos de domínio são originados do domínio da informação do programa, ou seja, são os requisitos que especificam exclusivamente a especialização do programa. Como por exemplo, os requisitos de domínio são responsáveis por descrever cálculos, procedimentos ou processos característicos do programa A que funciona na universidade X.
Os requisitos de domínio são importantes porque refletem os fundamentos do domínio da aplicação, eles podem ser tanto funcionais como não funcionais. A seguir alguns exemplos de requisitos de domínio:
O programa deve acrescentar 0,5% da média fina – na média geral dos alunos que não possuem falta;
O programa deve calcular quanto o aluno precisa para passar na final.
Isto deve ser feito assim que o aluno receber o status de final.
O primeiro requisito diz que caso o aluno não possua faltas em seu histórico do ano letivo, é acrescentado 0,5% de sua nota final em cima da sua média geral. Este acréscimo na média faz parte do regulamento da universidade X para alunos não faltosos. O segundo requisito mostra que, o aluno ao saber que vai para final, o programa deve calcular automaticamente o quanto ele precisa para passar. Em um caso como esse é importante que o desenvolvedor saiba fazer estes cálculos de prova final, por que caso o contrário, o programa não será concluído (SOMMERVILLE, 2007).
O ponto negativo em especificar requisitos de domínio é que nem sempre o desenvolvedor sabe implementar o domínio da informação. Os especialistas de domínio podem deixar determinadas informações fora de um requisito, simplesmente por serem obvias para eles. Por outro lado, pode não ser óbvias para os desenvolvedores do programa, podendo eles implementar o requisito de forma equivocada (SOMMERVILLE, 2007). É importante que haja um sincronismo entre o desenvolvedor do programa e o especialista de domínio, com o objetivo de produzir requisitos de domínio corretos.
2.3.4 REQUISITOS DE USUÁRIO
Os requisitos de usuários explicam de uma forma abstrata o programa para compreensão dos usuários que não tem conhecimento técnico. Nos requisitos de usuários não é permitido o uso de termos técnicos, jargões da informática, notações estruturadas ou requisitos referentes à implementação do programa. Os requisitos de usuário podem ser requisitos funcionais e não funcionais. Estes requisitos devem ser descritos em linguagens simples, explicados por meio de tabelas, gráficos ou diagramas (SOMMERVILLE, 2007).
Por causa da explicação simplista dos requisitos, vários problemas podem surgir:
Falta de clareza. É impossível desenvolver uma linguagem precisa e sem ambiguidades sem tornar o documento extenso e difícil de ler;
Confusão de requisitos. Requisitos funcionais, não funcionais, objetivos do programa estão em diferentes planos no documento;
Fusão de requisitos. Um requisito pode acabar possuindo mais de uma função, quando na verdade era para existir vários requisitos.
Ao escrever os requisitos de usuário é importante separa-los dos requisitos detalhados, caso contrário, isso pode levar os usuários não técnicos a se sobrecarregarem com os detalhes das informações, informações estas importantes apenas para os desenvolvedores. Também é importante que os requisitos de usuário não possuam muitas informações, pois pode restringir o desenvolvedor do programa de propor novas soluções. É importante salientar que estes requisitos são importantes apenas para focar nos recursos principais a serem desenvolvidos (SOMMERVILLE, 2007). Para melhor compreensão do leitor, é apresentado um exemplo no Quadro 01:
Requisito de usuário O programa deve fornecer todos os trabalhos do aluno assim que ele concluir o ano letivo.
Justificativa lógica: A entrega dos trabalhos é importante porque, caso aluno encontre algum equívoco em sua nota, o professor corrigirá a prova novamente e desta vez colocará a nota real do aluno.
Requisito de sistema O programa deve fazer um backup do log do
aluno contidas no database.
Quadro 01 – Diferenças de requisitos de usuários e requisitos de sistema Fonte: Adaptado de Sommerville (2007)
Os requisitos são descritos separadamente, por isso caso o usuário que não tenha conhecimento técnico queira entender a descrição, não terá problemas com jargões técnicos. Os demais que são detalhados, se referindo ao requisito de sistema apresentado, ficarão a disposição dos desenvolvedores. Segundo Sommerville (2007), é importante adicionar aos requisitos de usuário uma justificativa lógica. Esta justificativa deve esclarecer o porquê daquele requisito está inserido no documento.
Por fim, Sommerville (2007) propõe algumas recomendações para evitar mal-entendidos ao se escrever requisitos de usuário. Primeiramente é importante que seja criado um padrão para a criação de todos estes requisitos;
em segundo lugar, é interessante fazer uma distinção entre requisitos obrigatórios e desejáveis. Obrigatórios são requisitos que o programa deve ter e são seguidos da palavra “deve”. Já os requisitos desejáveis não são importantes, porém complementares, para o funcionamento do software. Os requisitos desejáveis são seguidos da palavra “pode”; use destaques no texto para enfatizar palavras e, como já foi dito anteriormente, não use jamais jargões de informática.
2.3.5 REQUISITOS DE SISTEMA
Diferente dos requisitos de usuários, os requisitos de sistema são versões com descrição mais ampla e detalhada. São usados pelos engenheiros de software como base para iniciar o projeto de desenvolvimento. Podem fazer parte do contrato para a construção do programa, e por isso, devem descrever completa e consistentemente todo o programa. Apesar de descrever o programa completamente, eles apenas devem mostrar o comportamento externo e as restrições (SOMMERVILLE, 2007).
Os requisitos de sistema não devem mostrar como o programa é implementado ou como pode ser projetado, porém é impossível que no desenvolvimento de um programa complexo, todas as informações, internas ou externas, sejam excluídas. Como por exemplo, uma arquitetura inicial do
