UNIDADE 4 - Verificacao, Validacao e Documentacao de Requisitos Ampli

Prévia do material em texto

Introdução
Olá, estudante! 
Nesta aula, você aprenderá a validar os requisitos especificados, buscando eventuais conflitos e analisando a consistência das funcionalidades levantadas. Aprenderá também sobre o processo de revisão da elicitação de requisitos, que garantirá o sucesso entre o resultado desejado para o produto e o que será obtido ao final do projeto. Como última etapa do aprendizado, você aprenderá a identificar e tratar eventuais ambiguidades relacionadas às funcionalidades levantadas. 
Lembre-se de que você é o responsável pelo seu aprendizado. Sempre busque o conhecimento através de fontes confiáveis e não se limite apenas ao visto em aula. 
Bons estudos! 
Conflitos e consistência de requisitos
Durante o processo inicial de escrita dos requisitos de uma aplicação, é comum que ocorram inconsistências e dubiedades, e que, ao longo do tempo, com a realização de novas entrevistas com o cliente, ocorram também ajustes e/ou correções nestas funcionalidades previamente escritas. 
Às vezes, pelo prazo curto para a entrega do projeto, que refletirá diretamente no encurtamento das fases de desenvolvimento, o analista de requisitos, em projetos que utilizam metodologias tradicionais, como cascata ou espiral, se preocupa apenas em escrever os documentos (artefatos da fase de especificação de requisitos), sem se preocupar em validar com o cliente se o seu desejo está, de forma eficaz, descrito no texto. 
O documento de especificação de requisitos, após concluído, será repassado à equipe de desenvolvimento, para que o processo de construção do produto seja iniciado, de modo que um erro no entendimento da funcionalidade poderá comprometer todo o sucesso do projeto. Então, a validação prévia deste documento, de modo a ajustar os pontos necessários e evitar retrabalhos ou o insucesso, é uma etapa crucial.  
A existência de diferentes interessados (stakeholders) no projeto, acarretando diferentes expectativas com o sistema que será desenvolvido, pode ter como consequência requisitos especificados de formas conflitantes. Pense, por exemplo, que um stakeholder visa obter o relatório do demonstrativo financeiro do último semestre, já que isso agregará valor ao produto, em sua visão. Por outro lado, um outro interessado deseja que os demonstrativos financeiros não sejam disponibilizados pelo sistema, por acreditar ser algo que se possa extrair de outra forma. Caso os dois requisitos (o de extração e o de não extração) sejam especificados, serão contraditórios. 
Deve caber, então, ao analista responsável pela fase de elicitação de requisitos, a validação destes em conjunto com o cliente (ou todas as partes interessadas), de modo a evitar que os requisitos sejam funcionalmente opostos.  
O cenário apresentado nos parágrafos anteriores, com dois requisitos sendo especificados de forma contraditória, representa o conceito de consistência dos requisitos. Quando há um conflito de interesse entre diversos interessados, pode acontecer de o quesito consistência ser quebrado, só sendo percebido o problema após a aplicação já estar em uso pelo cliente. 
Um outro ponto em que podem acontecer problemas relacionados à consistência de um requisito são as regras de validação. Muitas vezes, há a dependência entre requisitos funcionais diferentes no sistema, sendo que o resultado de uma funcionalidade pode ser pré-requisito para uma segunda funcionalidade. Caso haja remoção de uma pré-condição de um requisito que estava sendo validada por outro requisito, é importante que esta validação também seja removida, garantindo a consistência. 
Uma forma de identificar eventuais inconsistências na especificação dos requisitos é validando o documento de especificação de requisitos, junto ao detalhamento dos casos de uso do sistema, tendo em vista que a questão da completude de um requisito está atrelada à necessidade de especificação de todas as regras necessárias para que aquela funcionalidade possa ser codificada conforme as regras de negócio do cliente. 
Revisão da especificação de requisitos
Após as entrevistas de elicitação dos requisitos feitas na presença do cliente, o analista de requisitos terá um papel importante: validar se tudo que foi escrito está de acordo com as necessidades reais das partes interessadas pelo produto, da mesma forma que está escrita de forma clara, com todas as regras de validação necessárias e com o detalhamento técnico suficiente para a implementação pela equipe de desenvolvimento. 
É comum que o cliente, mesmo conhecendo bem seu negócio, tenha dificuldades em expressar, de forma clara e objetiva, seus interesses. Portanto, muitas vezes, em um primeiro momento, um requisito pode ser escrito de forma parcial, incompleta, tendo seus ajustes feitos ao longo do processo de validação, que pode contar com ferramentas visuais, como a prototipação das telas. 
Um protótipo é a representação de uma tela ou de todas as telas da aplicação, de modo a comportar seus campos, interações entre diferentes telas (mesmo de forma simulada), layout de cores e estilização, entre outros aspectos visuais que servirão de base para a construção do sistema final. Essas telas e as interações existentes (por exemplo, mensagens de validação de cadastros, regras de apresentação de campos etc.) podem ser validadas ou não pelo cliente, de modo a ajustar o que será implementado com as suas reais necessidades. 
Caso ajustes sejam detectados, os requisitos afetados serão reescritos, garantindo que a completude e a consistência deles se mantenham. É importante que se mantenha o histórico das alterações realizadas, para que as funcionalidades possam garantir suas rastreabilidades. 
Esta etapa deve ser a última antes que o documento de especificação de requisitos seja repassado ao time de desenvolvimento, para que se inicie o processo de construção do software. Dessa forma, a validação precisa acontecer de forma minuciosa, revisando critério por critério de validação, fluxos alternativos (se não deixou alguma opção alternativa de fora), se as especificações dos campos estão de acordo com o negócio, evitando que haja retrabalho após a entrega do projeto já pronto ao cliente. 
A importância do processo de validação de requisitos está relacionada ao custo de manutenção da aplicação. Quanto mais cedo no projeto uma falha for detectada, menor será o custo de seu ajuste, ficando o maior custo com manutenções corretivas feitas quando a aplicação já está em uso (produção). 
As etapas da fase de validação dos requisitos, conforme apresenta Sommerville (2011), são: 
· Verificação de validade: análise das funcionalidades em termos de utilidade para os stakeholders, já que os requisitos levantados podem não ser suficientes para atender a todas as expectativas e novos requisitos podem ser elucidados posteriormente. 
· Verificação de consistência: validação em relação às definições de cada requisito, que não podem ser contraditórias. 
· Verificação de completude: requisitos precisam estar completos, ou seja, com todas as regras de negócio envolvidas especificadas e detalhadas, de modo que sua implementação possa ser feita sem dúvidas. 
· Verificação de realismo: validação da viabilidade técnica, para que o requisito possa ser implementado, utilizando as tecnologias desejadas. 
· Verificabilidade: é a validação de que, após pronto e entregue, os requisitos da aplicação atenderão aos requisitos solicitados pelos interessados. 
· Revisões de requisitos: busca por erros de escrita ou inconsistências nas regras de negócio nos requisitos especificados. 
· Prototipação: desenvolvimento de um protótipo do sistema, para que o cliente possa validar as suas necessidades. 
· Geração de casos de teste: elaboração de cenários de testes para os requisitos especificados e seus critérios de validação, a fim de validar se as respostas esperadas são as de fato obtidas para cada funcionalidade.
Averiguação de requisitos ambíguos
A escrita, muitas vezes, leva a diferentes entendimentos por diferentes pessoas. Quando se trata de requisitos de uma aplicação, não é diferente.A depender da forma como um requisito é escrito no documento de especificação de requisitos, pode levar a ambiguidades de entendimento pela equipe de codificação e, consequentemente, o produto poderá apresentar divergências em termos do que era esperado pelo cliente. 
A elicitação de requisitos precisa ser feita de forma clara e com entendimento único por todos os envolvidos no projeto, evitando ambiguidades na escrita tanto do detalhamento dos requisitos quanto dos critérios de validação destes. 
Uma causa comum para a ambiguidade na definição de um requisito é a falha do entendimento (ou desconhecimento) do negócio que está sendo modelado. Se o cliente não tiver pleno conhecimento sobre as regras do seu negócio, ou tiver alguma dificuldade em expressar estas regras de modo que o analista de requisitos não consiga entender de forma clara, a ambiguidade poderá acontecer inevitavelmente. 
Para a validação dos requisitos, algumas técnicas podem ser utilizadas, tais quais apresentadas por Kawai (2005): 
· Checklists: planilhas com perguntas que devem ser direcionadas ao projeto que será analisado e de forma precisa, para que possam ser respondidas pelos avaliadores. 
· Leitura baseada em perspectiva: visa validar requisitos que estejam em linguagem natural. Esta técnica necessita que vários membros da equipe possam ler o documento de especificação de requisitos sob uma determinada perspectiva (testador, usuário final etc.), de modo que as funcionalidades possam ser analisadas em busca de falhas de entendimento ou especificação. 
· Técnica para construção de casos de uso e análise dos requisitos baseados em construção (TUCCA): através da identificação dos atores e de suas respectivas funcionalidades, construindo, assim, os casos de uso do sistema, será possível validar se os requisitos escritos estão, de fato, corretamente descritos e têm seus entendimentos plenos e completos. A partir dessa técnica, é possível identificar discrepâncias em termos do que é esperado e do que está especificado para uma funcionalidade, gerando um relatório de discrepâncias ao final do processo. 
As técnicas para validação dos requisitos conseguirão encontrar alguns problemas típicos da escrita das funcionalidades de uma aplicação, por exemplo: 
· Problemas relacionados com completude ou consistência dos requisitos. 
· Requisitos fora dos padrões de escrita adotados pela empresa que fará o desenvolvimento. 
· Conflitos de interesses e/ou ambiguidades nos requisitos especificados. 
· Erros técnicos no detalhamento das funcionalidades. 
É importante salientar que o documento que servirá de entrada para a fase de validação dos requisitos deve ser a versão final da especificação de requisitos, tendo em vista que esta versão já passou por uma etapa de validação inicial e é a que será entregue como artefato para a próxima fase do andamento do projeto. 
Os problemas detectados após a conclusão da fase de validação dos requisitos precisarão ser resolvidos mediante o acordo de ações corretivas, de modo que os documentos sejam ajustados, caso necessário, ou as funcionalidades já implementadas sejam readequadas, conforme a necessidade identificada.
Saiba mais
A ferramenta de código aberto RE-Tools executa todo o processo de especificação e gerenciamento de requisitos, disponível apenas para o sistema operacional Windows. 
A ferramenta Spider-CL auxilia no processo de elaboração de checklists para testar as funcionalidades de uma aplicação.
Referências
KAWAI, K. K. Diretrizes para elaboração de documento de requisitos com ênfase nos requisitos funcionais. 2005. Dissertação (Mestrado em Ciência da Computação) – Universidade Federal de São Carlos, São Carlos, 2005. Disponível em: https://repositorio.ufscar.br/bitstream/handle/ufscar/352/DissKKK.pdf?sequence=1&isAllowed=y. Acesso em: 16 jun. 2022.  
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo, SP: Pearson, 2011.
Introdução
Olá, estudante! 
Nesta aula, você aprenderá com mais detalhes como funciona o processo de validação dos requisitos, quais os métodos e as técnicas que poderão ser aplicados para auxiliar no processo de validação e a garantir que o documento de especificação de requisitos estará pronto para a próxima fase do processo de construção da aplicação: a fase de implementação.  
É importante que os requisitos levantados sejam revisados para se adequarem às reais necessidades do cliente, respeitando o custo e o prazo desejados para o projeto. 
Lembre-se de que você é o responsável pelo seu aprendizado. Sempre busque o conhecimento através de fontes confiáveis e não se limite apenas ao visto em aula. 
Bons estudos!  
Processos de validação de requisitos
Uma etapa crucial para o sucesso de um projeto de software é a validação dos requisitos, que terá por objetivo principal garantir que os requisitos especificados, da forma como estão escritos, atenderão às reais necessidades do cliente, além de serem tangíveis, ou seja, possíveis de serem codificados. 
A equipe que está envolvida com a construção do produto, constituída por desenvolvedores, arquitetos de software, analistas de requisitos, entre outros papéis importantes, deverá ler minuciosamente o documento de especificação de requisitos (ou as histórias de usuário, no caso da utilização de metodologias ágeis) em busca de eventuais inconsistências, ambiguidades ou requisitos que não sejam possíveis de serem codificados, devido às limitações técnicas das tecnologias envolvidas. 
Todo processo de validação dos requisitos deve contar também com a presença do cliente (ou de uma parte interessada que tenha sólidos conhecimentos do negócio), para que eventuais dúvidas possam ser sanadas. 
Um requisito é considerado validado quando suas regras estão totalmente especificadas, sem brechas para interpretações dúbias, com o detalhamento suficiente para que a equipe de desenvolvimento possa codificar o requisito apenas lendo o documento, sem a necessidade de consultas a fontes externas para esclarecimentos (o cliente, por exemplo). Todos os critérios de validação de um requisito servirão como base para testes de aceitação de primeiro nível (feito pelo desenvolvedor que construiu a funcionalidade) e de segundo nível (feito em conjunto com o cliente), já em ambiente de validação ou homologação (prévio ao ambiente de produção). 
Conforme Pressman e Maxim (2021), algumas questões são importantes para garantir o sucesso da fase de validação dos requisitos: 
1. Os requisitos atendem à expectativa quanto ao objetivo global do produto? 
2. O nível de abstração está coerente com o esperado para cada requisito, para a fase atual do projeto? 
3. A funcionalidade é considerada obrigatória para a aplicação, ou algo não essencial, como um recurso adicional? 
4. Os requisitos estão livres de ambiguidade? 
5. Cada requisito tem seu próprio ator, ou seja, quem disparará a funcionalidade? 
6. Existe algum conflito dentro do conjunto de requisitos levantados? 
7. Os requisitos são válidos tecnicamente? É possível implementá-los com as tecnologias envolvidas no produto? 
8. É possível testar o requisito após sua implementação? 
9. O requisito está descrito de forma a especificar sua funcionalidade e o comportamento que o sistema deve ter após a sua execução? 
10. O requisito está projetado para detalhar sua funcionalidade de forma progressiva, a depender da fase da construção do produto? 
11. O modelo de requisitos utilizado para escrita segue algum padrão especificado? Este padrão foi previamente validado pela equipe e está de acordo com a necessidade do cliente? 
Após responder a estas perguntas e a outras que surjam, eventualmente, ao longo do processo de levantamento dos requisitos e dos ajustes deles, será mais provável que o documento resultante esteja em conformidade com a necessidade do cliente, patrocinador do projeto. Sendo assim, a taxa de sucesso com a construção do produto será alta, o que não ocorreria caso esta fase de validação não acontecesse de forma suficiente. 
Métodos de validação de requisitos
Para realizar a fase de validaçãodos requisitos, é importante que seja utilizado algum método para guiar o processo. 
O processo de validação dos requisitos pode ser quebrado em pequenas fases, para garantir que o resultado do processo será condizente com o esperado pelo cliente: um documento de especificação de requisitos que reflita, de fato, os anseios das partes interessadas com a aplicação que será construída. 
Cada etapa do processo de validação revisará o documento de especificação de requisitos em busca de pontos de falha específicos, que poderão ser ajustados para dar continuidade ao processo de revisão do documento. 
Conforme Ayres (2021), existem seis tipos de revisão que compõem a fase de validação dos requisitos: 
· Revisão de especialista: nesta fase de revisão, uma pessoa especialista lerá os requisitos levantados e dará seu parecer acerca de inconsistências, ambiguidades e outros possíveis erros encontrados no documento. Além disso, proporá formas de correção dos problemas encontrados. 
· Inspeção dos requisitos: consiste em um trabalho cuidadoso em busca de erros nos requisitos levantados, que podem comprometer a aplicação que será construída. É feita por uma equipe, com diferentes papéis e funções, tais quais: 
· Organizador: controlará e planejará como o processo de inspeção acontecerá. 
· Moderador: moderará as reuniões da equipe, de modo a manter o foco no trabalho de inspeção. 
· Autor: precisa ter o conhecimento do negócio para explicar como as regras de cada requisito funcionam aos membros da equipe. Além disso, deverá detectar e corrigir eventuais erros de entendimento ou escrita que sejam encontrados. 
· Leitor: realizará a leitura dos requisitos para a equipe, de modo a manter a equipe focada no requisito em si, sem a necessidade de entendimento do que o autor quis dizer. 
· Inspetores: membros responsáveis pela detecção e pelo relato de problemas para os demais membros da equipe. 
· Secretário: responsável por organizar o resultado de cada reunião, assim como escrever sua ata. 
O processo de inspeção dos requisitos acontece em fases, conforme ilustrado na Figura 1. 
Fonte: elaborada pela autora.
A Figura 1 apresenta as fases de um processo de inspeção dos requisitos de uma aplicação. A primeira fase é o Planejamento, que determinará quais os objetivos a serem atingidos, como o processo será realizado e quais as funções de cada participante na equipe. Na fase de Visão geral, o autor apresentará, de forma detalhada, os requisitos à sua equipe, para que dúvidas possam ser esclarecidas. A fase de Detecção de falhas analisará os requisitos em busca de falhas, a fim de preparar um documento com os pontos encontrados, o qual servirá de entrada para a próxima fase. Por último, a fase de Coleta de falhas consolidará todos os pontos encontrados ao longo do processo, eliminando problemas que tenham sido apontados em duplicidade ou falsos positivos (pontos tidos como problemas, mas que, na verdade, não o são)
Técnicas de validação de requisitos
Para que as fases do processo de validação de requisitos sejam cumpridas de forma correta, ou que se tenha um maior proveito do processo como um todo, conseguindo mapear e tratar a maior quantidade de pontos possíveis de falha, é indicado que se apliquem técnicas. 
É importante que você, ao participar de uma equipe de validação de requisitos, tenha conhecimento destas técnicas, assim como os demais membros do time, pois a garantia de sucesso do produto que será construído e entregue dependerá de quão bem definidos foram seus requisitos. 
Uma das técnicas que podem ser utilizadas é a walkthrough, sendo caracterizada como uma inspeção simplificada. Nesta técnica, uma pessoa pode desempenhar diferentes papéis, tendo seu objetivo principal a identificação de falhas na escrita dos requisitos e no entendimento geral do negócio do produto. Ao final do processo, os membros do time devem ter o entendimento nivelado acerca da necessidade do cliente e do que está especificado. 
Uma outra técnica bastante utilizada é a PBR (validação baseada em perspectiva), na qual o documento de requisitos é lido com base na visão de uma das partes interessadas ou dos membros do time de desenvolvimento (como cliente, desenvolvedor, perspectiva de testes, entre outros, a depender do projeto). 
A PBR permite, além das perspectivas já mencionadas, a visão a partir de outras perspectivas, como a perspectiva de qualidade, que pode se dividir, conforme apresenta Ayres (2021), em: 
· Documentação: a documentação dos requisitos precisa estar seguindo o padrão acordado pelo time. 
· Conteúdo: traz a visão do conteúdo da funcionalidade, se condiz com o esperado para o requisito em questão. 
· Acordo: busca chegar a um acordo a respeito de todos os requisitos levantados com relação a todos os envolvidos no projeto, assegurando que não existem conflitos de interesses a serem resolvidos. 
A prototipação é uma outra técnica muito boa para que o cliente possa realizar a validação dos requisitos de modo visual, com protótipos funcionais de como o sistema deverá se comportar. Denominamos de protótipos funcionais as telas da aplicação, construídas de forma simples (como com a linguagem de marcação HTML), com a estilização necessária e pequenas interações com linguagem de script (como a Javascript). Estas interações podem incluir apresentação de mensagens após a execução de algum comando (clique em algum botão, por exemplo), alteração no fluxo das telas, entre outras ações visuais. 
Os protótipos, após a fase de validação ter sido concluída, serão repassados para a equipe de desenvolvimento, para que o sistema possa ser construído tendo as telas já validadas como base. 
A utilização de checklists também é uma forma importante de validação, já que a partir da criação de perguntas objetivas é possível identificar problemas de ambiguidade (clareza da escrita), falhas na escrita que possam deixar o requisito incompleto ou até nos critérios de validação, que podem não englobar todas as necessidades de validação da funcionalidade. 
As técnicas apresentadas podem ser utilizadas em conjunto, de modo que são complementares e auxiliam a identificar pontos que, eventualmente, possam ter passado desapercebidos pela equipe em alguma fase do processo de validação. 
Saiba mais
Para criação de protótipos funcionais, é possível utilizar a ferramenta gratuita Just in mind. 
A ferramenta gratuita Ninja Mock também é uma boa alternativa para a construção de protótipos para serem validados pelo cliente.
Referências
AYRES, F. B. Técnicas para Realizar a Validação de Requisitos no Contexto da Internet das Coisas (IoT). 2021. Monografia (Graduação em Engenharia da Computação) – Universidade de Brasília, Brasília, 2021. Disponível em: https://bdm.unb.br/bitstream/10483/29876/1/2021_FelipeBritoAyres_tcc.pdf. Acesso em: 22 jun. 2022. 
PRESSMAN, R.; MAXIM, B. R. Engenharia de software. 9. ed. Nova Iorque: McGraw Hill Education, 2021.
Introdução
Olá, estudante! 
Nesta aula, você aprenderá como o seu documento de especificação de requisitos deve ser escrito e estruturado, de modo a garantir que todas as informações sobre os requisitos estarão corretamente documentadas. Aprenderá também quais os documentos resultantes de cada etapa do levantamento de requisitos, desde as entrevistas iniciais até o documento revisado, pronto para a implementação. Uma boa documentação deve estar sempre atualizada e condizente com as necessidades do cliente. 
Lembre-se de que você é o responsável pelo seu aprendizado. Sempre busque o conhecimento através de fontes confiáveis e não se limite apenas ao visto em aula. 
Bons estudos! 
Estruturação do documento de requisitos
O documento de especificação de requisitos conterá toda a estrutura básica das funcionalidades de uma aplicação que será construída, sendo fundamental que sua escrita seja feita com clareza e objetividade, sem possibilidade de ambiguidades (todos os envolvidos precisarão ter exatamente o mesmo entendimento daquilo que está escrito). 
Este documento deverá conter um histórico de modificações, jáque, ao passar do tempo, é comum que alterações nos requisitos sejam feitas, seja para correção de alguma falha de escrita, inclusão ou exclusão de alguma regra de negócio ou fluxos alternativos. 
Para o primeiro capítulo do documento, é importante que informações básicas a respeito do projeto e da aplicação que será construída sejam fornecidas, como o propósito da aplicação, as convenções de termos adotados, a audiência e as sugestões de leitura do documento, o escopo do produto e, caso necessário, alguma referência técnica a respeito de conceitos e termos que serão utilizados. Toda essa parte dará o embasamento teórico à equipe envolvida a respeito das regras de negócio e do domínio da aplicação. 
O próximo capítulo do documento deve abordar conceitos acerca do produto que será construído, como sua perspectiva, funcionalidades, perfis de usuário e suas características, qual será o ambiente operacional, restrições de design e implementação, documentação do usuário, dependências e premissas. A documentação do usuário é um documento em separado, geralmente em formato de manual de utilização da aplicação, tendo em vista que deve ser escrito em linguagem mais próxima à natural, com a qual o usuário estará mais familiarizado.  
Os próximos capítulos deste documento devem abordar eventuais relacionamentos externos com outros sistemas, interfaces de comunicação (caso existam), requisitos de funcionamento, como performance, segurança, hardware, entre outras necessidades que a aplicação venha a ter. 
Por ser um documento voltado para a equipe técnica, com detalhes de implementação, ele deve ser mantido sempre atualizado, de modo que qualquer alteração deve ser registrada no documento, com o respectivo autor, data e conteúdo alterado, da mesma forma que, de preferência, deve ser armazenado em um repositório de documentos, evitando, assim, a impressão e, consequentemente, a defasagem. 
Apesar de ter a necessidade de validação pelos interessados no projeto, é recomendável a elaboração de um manual de usuário, separado deste documento, para o treinamento e a consulta do usuário final (que nem sempre é o patrocinador que encomendará a aplicação). 
Quando o sistema a ser construído envolver poucos interessados, com baixa complexidade e poucas funcionalidades, em um ambiente técnico bem definido e conhecido, o documento formal pode ser substituído por casos de uso, envolvendo os cenários de uso dos requisitos, seus atores e fluxos alternativos. Apenas o essencial para a equipe de desenvolvimento conseguir compreender as regras de negócio e implementar a aplicação, respeitando o prazo e o orçamento acordados com o cliente. 
Documentação da especificação de requisitos
O processo de especificação de requisitos deve ter sua documentação gerada e mantida, já que toda documentação gerada nesta fase será repassada para as fases seguintes como artefatos de entrada, dando subsídios para a construção do produto. 
O início do processo é feito através da realização de entrevistas com o cliente, podendo ser representado por diversas partes interessadas no projeto. Essas entrevistas iniciais servirão para elicitar os requisitos da aplicação, de modo que o cliente deverá, através delas, expressar como cada função no sistema deverá se comportar, quais resultados esperar a partir de quais entradas, entre outras questões importantes.  
A partir do histórico dos questionários aplicados ao longo das entrevistas, será possível realizar o refinamento inicial dos requisitos que deverão compor a aplicação, de modo a limitar o escopo, ou seja, a definir até que ponto a aplicação atenderá às necessidades do cliente. 
Após todas as funcionalidades terem sido identificadas, será necessário se reunir com o cliente mais algumas vezes, para que a priorização dos requisitos seja definida e as funcionalidades que agreguem mais valor ao cliente (e suas partes interessadas, de modo coletivo) possam receber o nível adequado de prioridade em sua implementação. 
Após o levantamento inicial dos requisitos, o projeto será continuado através da criação do documento de especificação de requisitos, que será uma compilação de todos os requisitos levantados através das entrevistas e rodadas de negociação com o cliente.  
Para que o projeto seja continuado e a aplicação seja construída, é necessário que a equipe elabore um termo de viabilidade técnica do projeto, que deverá ser assinado tanto pelo cliente quanto pelo analista de requisitos (ou alguém com perfil técnico), após a análise das funcionalidades solicitadas e da viabilidade técnica para a implementação utilizando as tecnologias envolvidas (linguagem de programação, ambiente tecnológico etc.). 
Com as funcionalidades já definidas, será necessário realizar uma validação destas, processo que pode ser feito através da elaboração de diagramas de caso de uso. Para cada ator do sistema (usuário com um determinado perfil, que fará interação com o sistema), será necessário mapear todas as funcionalidades com as quais este ator interagirá. Este passo será importante para o detalhamento, em momento futuro, de cada requisito. 
Tendo em vista que um mesmo requisito precise de vários níveis de detalhamento para que todos os interessados no projeto possam ter o mesmo entendimento a respeito da funcionalidade e seu comportamento, é necessário que a documentação de cada requisito englobe também diversos níveis de detalhamento. O diagrama de casos de uso é a visão mais macro, voltada para gestores e usuários não especialistas em TI. Já a descrição dos cenários de uso de um requisito, com um nível de detalhamento um pouco maior, será mais adequado para os usuários que dominem o negócio que está sendo modelado e em cima do qual a aplicação será construída. Para a equipe de desenvolvimento, será necessário um detalhamento maior do requisito, com detalhes técnicos (como quais campos, tabelas, tipos dos campos, entre outras informações técnicas relevantes). 
Ao final de todo o processo, todos os níveis de detalhamento e informações coletados deverão ser centralizados no documento de especificação de requisitos, que será repassado para a equipe de desenvolvimento após a validação e os ajustes necessários.
Documentação da especificação de requisitos
O processo de elicitação de requisitos deverá gerar, ao seu final, uma série de artefatos que comporão a documentação da aplicação que será construída.  
As entrevistas feitas com o cliente (ou seu representante) para detalhar quais as funcionalidades do sistema constituirão o documento de especificação de requisitos, da mesma forma que os diagramas gerados, que poderão ser de casos de uso e de sequência, para uma validação inicial dos requisitos que deverão compor a aplicação e, para um maior nível de detalhamento, diagramas de classe e da arquitetura do sistema. 
Durante a fase de elicitação dos requisitos, eventuais relacionamentos da aplicação com sistemas externos devem ser mapeados, o que pode auxiliar na geração de uma diagrama de arquitetura da aplicação, apresentando cada item da arquitetura física (servidores, equipamentos de rede que serão utilizados pela aplicação), como também da arquitetura lógica do sistema (como interfaces com outros sistemas e como o relacionamento com estas interfaces será feito a partir da aplicação que será construída). 
Outro documento importante que deverá ser construído como artefato da fase de elicitação dos requisitos é o modelo de entidade – relacionamento (DER), envolvendo as tabelas do banco de dados e seus relacionamentos. Nesta fase, os campos de cada tabela devem ser especificados pelo cliente, de acordo com seu negócio, assim como restrições de entrada de dados e outras informações importantes para a construção das tabelas e de toda a área do banco de dados que será destinada aos objetos da aplicação (o que denominamos esquema do banco de dados). 
Os requisitos não funcionais também precisarão ser especificados, de modo que todos os requisitos funcionais englobados, de forma transversal, por esta categoria de requisitos deverãoter, em suas regras de validação e em seus detalhamentos, o requisito não funcional envolvido. 
Os cenários de uso de cada funcionalidade deverão ser criados, ainda nesta fase, para que as partes interessadas (stakeholders) possam descrever, conforme suas percepções, como cada requisito deve se comportar na aplicação.  
Os analistas de sistema e engenheiros de software que estiverem envolvidos na equipe de construção do sistema devem, ao final do processo, analisar se as funcionalidades requisitadas pelo cliente são viáveis, gerando um termo de viabilidade e necessidade para a aplicação. O escopo da aplicação também precisa ser delimitado, já que será este marco que determinará quando o projeto chegou à sua conclusão.  
Outro artefato importante é a lista dos clientes, usuários e demais pessoas que participem do processo de levantamento de requisitos, já que estas pessoas serão os stakeholders da aplicação. 
Todos os documentos gerados durante a fase de elicitação dos requisitos precisam ser revisados por todos os envolvidos no projeto, para que encontrem eventuais pontos falhos, conforme suas respectivas percepções acerca do sistema. Um conceito que pode ter um significado para o setor de marketing, por exemplo, poderá ter um significado totalmente diferente para os usuários do setor de tecnologia, por isso a importância da validação por todos os envolvidos. 
Saiba mais
Pressman e Maxim apresentam um modelo de documento de especificação de requisitos, que pode ser acessado gratuitamente no Software Requirements Specification for <Project>
Um exemplo de documento de Especificação de Requisitos com dicas sobre o preenchimento pode ser encontrado.
Referências
AYRES, F. B. Técnicas para Realizar a Validação de Requisitos no Contexto da Internet das Coisas (IoT). 2021. Monografia (Graduação em Engenharia da Computação) – Universidade de Brasília, Brasília, 2021. Disponível em: https://bdm.unb.br/bitstream/10483/29876/1/2021_FelipeBritoAyres_tcc.pdf. Acesso em: 22 jun. 2022. 
PRESSMAN, R.; MAXIM, B. R. Engenharia de software. 9. ed. Nova Iorque: McGraw Hill Education, 2021.
Introdução
Olá, estudante! 
Nesta aula, você aprenderá como realizar os testes nos requisitos de uma aplicação, através da criação e do gerenciamento de um plano de testes.  
Aprenderá também técnicas que podem ser utilizadas para realizar a testagem de uma aplicação e seus requisitos, como o teste manual e o automatizado (incluindo algumas ferramentas que auxiliarão a criação de seus testes), e a como gerenciar os artefatos que possuem dependências entre si. 
Lembre-se de que você é o responsável pelo seu aprendizado. Sempre busque o conhecimento através de fontes confiáveis e não se limite apenas ao visto em aula. 
Bons estudos! 
Plano de testes de requisitos
Após o processo de elicitação de requisitos ter sido concluído, será necessário realizar testes para garantir que o resultado obtido com a funcionalidade equivale ao esperado para ela.  
A fase de testes é de extrema importância para garantir que o que está sendo entregue (a aplicação) está condizente com os requisitos acordados com o cliente, sendo necessário se fazer um planejamento do que será testado e como esses testes ocorrerão. 
Ao se criar os cenários de caso de uso para cada funcionalidade, são determinados os critérios de validação e as regras de negócio. Estes critérios, na fase de testes, servirão para definir como o requisito será validado, com suas premissas e seus resultados esperados.  
Todos os fluxos alternativos de um requisito também devem constar no plano de testes, de modo a cobrir todas as possibilidades previstas na documentação. 
O início do processo de testes, conforme apresentado por Sommerville (2011), é feito através dos testes unitários, realizados pelo próprio desenvolvedor que está responsável por implementar a funcionalidade. Ele deve executar seu teste local, sempre buscando comparar o resultado obtido (a resposta da aplicação) com o que se esperava obter. 
Após essa fase inicial, será necessário um teste de segundo nível, de preferência feito por outro desenvolvedor ou membro da equipe, para que sejam evitados vícios de testes, que acontecem quando uma pessoa está familiarizada demais com um código e uma funcionalidade e sempre utiliza o mesmo caminho para realizar o teste. Uma pessoa diferente, sem o conhecimento do código e da funcionalidade, realizará os testes de formas diferentes do desenvolvedor, podendo encontrar problemas que não foram identificados pelos testes unitários. 
A última etapa, então, será disponibilizar ao cliente um ambiente diferente do que foi feito o desenvolvimento, denominado ambiente de homologação, para os testes de aceitação. Nesta fase, o cliente deverá utilizar a funcionalidade, buscando aceitá-la ou rejeitá-la, conforme sua necessidade. 
O plano de testes, de forma prática, é composto por uma planilha, na qual devem ser detalhados as funcionalidades, os seus critérios de aceitação e os cenários para a realização de cada teste destes critérios, com as respectivas colunas de resultado esperado e resultado obtido, além de uma coluna de conclusão, que deverá ser preenchida com o resultado global do teste, ou seja, caso o resultado obtido não esteja condizente com o esperado, deve-se colocar nesta coluna qual foi a falha encontrada.  
A ordem dos testes também deve constar no plano de teste, já que uma funcionalidade pode depender de outras para conseguir ser testada. 
Todos os testes feitos com base no plano de testes deverão ter seus resultados documentados e o histórico armazenado, tendo em vista que, após as devidas correções e ajustes, será necessário executar todo o plano novamente, já que a correção de um bug pode ter inserido novos bugs em funcionalidades que já estavam validadas no sistema.
Técnicas de testes de requisitos
Para realizar os testes nas funcionalidades de uma aplicação, é possível utilizar técnicas que, além de auxiliar na organização e execução dos testes, serão úteis para registrar que o teste aconteceu e seu resultado. 
A primeira técnica é o teste manual, que deverá ser planejado e executado manualmente por um analista de testes ou pelo desenvolvedor da funcionalidade. Nesta técnica, uma planilha deve ser criada com a funcionalidade a ser testada, os critérios de validação, as ações (na aplicação) para que o teste possa ser executado e os resultados esperados e obtidos. Caso algum desvio de comportamento da aplicação seja percebido, deve-se coletar evidências, através de imagens de capturas de tela ou vídeos do passo a passo executado, para que uma tarefa de correção possa ser aberta para a equipe de desenvolvimento.  
Test Driven Development (TDD) 
Uma outra técnica bastante utilizada é a Test Driven Development (TDD – Desenvolvimento Baseado em Testes), na qual o caso de teste deve ser criado antes mesmo da implementação do requisito. Desta forma, caso alguma anormalidade no comportamento esperado pelo requisito seja encontrada, poderá ser detectada de forma rápida, sendo corrigida ainda na fase do desenvolvimento da funcionalidade. 
A implementação da funcionalidade, com a utilização desta técnica, também será beneficiada, já que será possível planejar o desenvolvimento, atentando-se aos detalhes dos critérios de aceitação e das regras de negócio. 
Um outro benefício desta técnica é que, ao escrever o teste antes do desenvolvimento do código, evita-se que o teste acabe sendo adaptado ao código, não refletindo exatamente o que deveria ser testado. O código será implementado para atender aos testes criados, não o contrário.  
Behavior Driven Development (BDD) 
Uma outra técnica utilizada para a execução de testes é a BDD (Desenvolvimento Baseado em Comportamento), que se caracteriza por ser uma evolução da TDD, já que moldará as funcionalidades da aplicação ao domínio do negócio do cliente. Assim como no TDD, os testes no BDD serão úteis no planejamento do desenvolvimento do código.  
A documentação dos requisitos será feita de forma dinâmica, uma vez que as regras de negócio eos testes serão escritos de forma antecipada à implementação destes, mantendo-se atualizada à medida que alterações ou ajustes vão sendo feitos na aplicação. Isso elimina o problema de defasagem na documentação, típico da utilização de metodologias tradicionais, que apenas documentam a funcionalidade após a sua codificação.  
Testes automatizados 
Equipes de teste de uma organização tendem a executar inúmeros testes diários, em diferentes projetos, dos mais diferentes domínios de aplicação. Desta forma, realizar todos os testes utilizando o método manual demandaria muito tempo e esforço, ainda correndo o risco de falhas devido ao esquecimento de determinadas regras ou à falta de atenção com todos os resultados obtidos nos testes. 
Para auxiliar o processo de desenvolvimento e execução dos testes, ferramentas de automação podem ser utilizadas, de modo que as principais funcionalidades da aplicação podem ter seus scripts de testes criados uma vez e executados inúmeras vezes. É possível, por exemplo, realizar testes de stress da aplicação, com a simulação de usuários simultâneos, testes em uma funcionalidade específica ou até em um conjunto de funcionalidades, o que se denomina suíte de testes.
Gerenciar as dependências entre os documentos de requisitos
A consistência dos requisitos é uma das características mais importantes no processo de elicitação de requisitos de uma aplicação. Dessa forma, é importante que não existam conflitos entre diferentes funcionalidades ou que os critérios de pré-requisitos de uma funcionalidade não sejam contraditórios com critérios de validação de um outro requisito da aplicação. 
Durante a fase de elicitação de requisitos, principalmente nos momentos iniciais, nos quais ainda estão acontecendo as primeiras entrevistas com o cliente para entendimento do negócio e de suas necessidades, é comum a geração de diferentes artefatos, sem necessariamente se fazer uma análise em busca de problemas de ambiguidade ou contradições. 
Na fase de validação dos requisitos, após suas diversas etapas em busca de contradições e ambiguidades, visando manter a consistência e a completude dos requisitos, o documento de especificação de requisitos passará por diversos ajustes, quando inconsistências serão detectadas e corrigidas. 
Um exemplo de inconsistência é quando, por exemplo, um caso de uso para um determinado ator no sistema apresentar uma funcionalidade que, no momento do detalhamento dos requisitos, não é apresentada na tabela. Então, caso os analistas tenham removido esta funcionalidade da tabela de detalhamento de requisitos, deverão também remover da apresentação no diagrama de caso de uso. Isso garantirá que a consistência do documento e dos requisitos será mantida. 
Outros artefatos gerados como resultado da fase de elicitação dos requisitos precisarão ser analisados e alterados, caso necessário, sempre que uma modificação seja feita em algum requisito, ou até quando uma nova funcionalidade é adicionada à aplicação. 
Uma forma de manter o controle dos documentos é através de repositórios de documentos, que guardarão cada versão da documentação gerada, mas é preciso que todos os documentos relacionados ao projeto sejam alterados, caso uma funcionalidade sofra modificações. Por isso, quanto mais documentos um projeto gerar, maior trabalho e mais probabilidade de falha na atualização existirá. 
As metodologias ágeis, por sua vez, prezam pela mínima documentação possível, enxugando todos os artefatos considerados desnecessários, como o próprio documento de especificação de requisitos, que se converte em histórias de usuário, com seus respectivos critérios de validação. Dessa forma, é necessário que as histórias sejam mantidas atualizadas, conforme as modificações, que são dinâmicas ao longo do projeto, aconteçam. 
Caso, por exemplo, uma nova tabela seja acrescentada no banco de dados da aplicação, será necessário atualizar o modelo de entidade relacionamento da aplicação, assim como os requisitos que se relacionam com a nova tabela inserida no modelo. Esta frequência de atualização, em projetos reais, não acontece com frequência, sendo comum a defasagem no modelo de entidade relacionamento do projeto e nos documentos auxiliares que detalham o atual estado do banco de dados. 
Uma questão importante que deve ser tratada ao longo de um projeto é a forma como mudanças acontecem e são solicitadas pelo cliente. É importante que a solicitação seja formalizada, através da abertura de chamados em um sistema específico para este fim, para que a solicitação seja documentada e atendida, alterando o comportamento do sistema.  
Caso um sistema de abertura de chamados não seja utilizado, será necessário especificar um modelo padronizado para requisições de mudança, que servirá de base para a execução do processo.
Saiba mais
Para utilizar a ferramenta de testes automatizados Katalon. 
Outra ferramenta de automação de testes, o Cypress.
Uma ferramenta gratuita para escrever e gerenciar casos de teste é a TestLink.
Referências
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo, SP: Pearson, 2011. 
Analisar, verificar, validar e documentar requisitos de software
Os requisitos de uma aplicação, sejam funcionais ou não funcionais, precisam passar por um longo processo de validação, até que possam ser considerados aptos ao desenvolvimento. Este processo incluirá, primordialmente, o cliente, principal interessado, para se certificar de que o processo de elicitação de requisitos, feito pelo analista de requisitos ou líder técnico, teve sucesso e reflete as reais necessidades do cliente. 
Os requisitos levantados para uma aplicação, em um primeiro momento, são escritos sem que sejam feitas validações, o que pode acarretar conflitos de funcionalidades (quando um requisito contradiz o outro), o que se denomina inconsistência, e regras de negócio incompletas ou com duplo entendimento (ambiguidade), o que invalidará a implementação da aplicação pela equipe de desenvolvimento. O objetivo da fase de validação é ajustar os requisitos para eliminar estas inconsistências e ambiguidades. 
Quando um projeto tem diferentes partes interessadas, conflitos de interesses podem acontecer no momento da priorização dos requisitos para codificação, necessitando que se chegue a um senso comum de quais as funcionalidades que melhor atenderão a todas as partes.  
O processo de revisão dos requisitos poderá indicar pontos falhos na implementação da aplicação, consequências de falhas no entendimento das regras de negócio ou na escrita dos requisitos. É importante que os problemas encontrados sejam corrigidos ainda nas etapas iniciais do projeto, tendo em vista que o custo e o prazo de entrega final podem ser impactados em detecções tardias.  
A fase de validação dos requisitos acontece em etapas, tais quais: 
· Verificação de validade. 
· Verificação de consistência. 
· Verificação de completude. 
· Verificação de realismo. 
· Verificabilidade. 
· Revisões dos requisitos. 
· Prototipação. 
· Geração de casos de teste. 
Para detectar ambiguidades, é possível que a equipe utilize checklists, a técnica de leitura baseada em perspectiva ou a técnica baseada em construção. Essas técnicas também podem ser utilizadas para validação dos requisitos junto ao cliente, principalmente a prototipação, que mostrará, de forma visual, como a aplicação final se apresentará aos seus usuários. 
Para completar o processo de validação dos requisitos de uma aplicação, testes são fundamentais, sejam eles manuais ou automatizados, garantindo que o resultado que foi acordado com o cliente para uma determinada funcionalidade será entregue pela aplicação. 
Um plano de testes pode ser criado para planejar quais as funcionalidades que serão testadas e como os testes ocorrerão, além de especificar quais os tipos de testes que uma aplicação precisará para garantir o pleno funcionamento de seus requisitos. 
Técnicas, como TDD (Desenvolvimento Baseado em Testes) e BDD (Desenvolvimento Baseado em Comportamento), podem ser utilizadas para evitar que partesdas funcionalidades não sejam englobadas nos testes necessários da aplicação. A TDD fala que a construção dos testes precisa ser feita antes da codificação de cada funcionalidade, fazendo com que a implementação tenha o teste como base, não o contrário. A BDD é uma evolução da TDD, construindo a aplicação com base no comportamento que ela deve apresentar, fazendo valer, ainda, a ideia de construção dos testes de forma antecipada ao desenvolvimento. 
Resumo visual
Fonte: elaborada pela autora.Fonte: elaborada pela autora.Fonte: elaborada pela autora.Fonte: elaborada pela autora.
Referências
PRESSMAN, R.; MAXIM, B. R. Engenharia de software. 9. ed. Nova Iorque: McGraw Hill Education, 2021.