Verificação e Validação de Requisitos - Introdução

Olá sejam bem-vindos ao canal engenheria de software com ênfase uml Eu sou professor Janes getes e eu já atuo na área de modelagem de software há vários anos eu tenho quatro livros publicados sobre o assunto e eu já ministrei diversas palestras de cursos técnicos sobre Model de software utilizando a linguagem uml Nesta aula eu pretendo dar continuidade ao tema sobre verificação e validação de software desta vez tratando sobre verificação e validação de requisitos eu não pretendo nessa aula abordar uma técnica específica de validação de verificação e validação de requisitos mas sim abordar as características gerais

desse tipo de verificação e validação e as características que as técnicas desse tipo devem possuir Então vamos iniciar o nosso conteúdo Então como falei essa vai ser uma aula introdutória sobre verificação e validação requisitos primeiramente Vamos retomar alguns conceitos uma especificação de requisitos ela é um documento que traduz descreve os requisitos as funcionalidades as necessidades das partes interessadas relativas a um determinado software partes interessadas são um conjunto de pessoas que têm interesse no desenvolvimento do software e ou serão afetados por ele então uma especificação de requisitos ela precisa ser Clara ou seja ela precisa ser

fácil de ler e não ser ambígua isto é não pode ser passível de mais de uma interpretação uma especificação de requisitos ela precisa ser consistente ou seja ela não pode ser não pode ter conflitos entre os requisitos os requisitos eles não podem se contradizer e ela precisa ser completa ou seja ela deve cir todos os requisitos e incluindo as restrições relacionadas aos requisitos a cada requisito específico e ao projeto como um todo entre outras características erros na especificação de requisitos costumam ser muito caros Principalmente quando eles forem descobertos em fases já avançados do desenvolvimento que

trarão um custo muito alto para corrigir esses erros mas em situações ainda piores quando o software já estiver concluído e instalado no cliente então o custo além de ser muito alto ele ainda traz um custo que não pode ser medido que é relativo à propaganda negativa da insatisfação do cliente então a verificação de requisitos é muito importante então eh a maioria das técnicas de verificação de requisitos são chamadas de inspeções ou revisões bom caso uma inspeção ela encontre erros ou anomalias na especificação falta de conformidade com padrões falhas incompletudes ambiguidades então é necessário executar novas

sessões de licitação provavelmente utilizando outras técnicas de licitação de requisitos Lembrando que elicitação de requisitos é uma fase onde se descobre os requisitos necessários ao software então no caso de teria sido encontrado erros ou anomalias a especificação de requisitos ela precisa ser corrigida refinada e atualizada já com relação à validação de requisitos Ela é bem mais complexa Como já foi falado em aulas anteriores a verificação ela basicamente tenta determinar se o software está sendo desenvolvido de acordo com o que foi planejado de acordo com o que foi solicitado então no caso de da verificação de

requisitos basicamente tenta-se determinar se o documento de requisitos ele está correto se ele não possui erro se ele não possui anomalia se ele não possui falhas eh já a validação de requisitos ela é muito muito mais profunda e muito mais complexa ela tenta determinar se os requisitos realmente traduzem as necessidades das partes interessadas e isso é muito mais difícil de determinar principalmente porque as partes interessadas muitas vezes não sabem se expressar corretamente não sabem traduzir as suas necessidades Elas têm um conjunto de desejos nebulosos que precisam ser traduzidos em requisitos Concretos e isso não é

fácil além de disso muitas vezes elas simplesmente não conseguem conceber as muitas das possibilidades que um software poderia trazer pra empresa então às vezes o engenheiro de requisitos ele precisa aplicar uma certa consultoria sugerir muita coisa ajudar as partes interessadas a ter ideias inovativas que ajudem a empresa a ser mais competitiva e a tornar o o trabalho dos usuários mais fácil e mais ágil então a varid implica examinar a especificação de requisitos e validar essa especificação juntamente com as partes interessadas em geral deve-se aplicar técnicas de licitação complementares para auxiliar a essa validação como por

exemplo utilizar protótipos e essa validação não pode ser feita simplesmente com os clientes que são os que pagam pelo produto são chamados usuários terciários mas também e principalmente Sobretudo com os usuários chave que são partes interessadas que possuem bastante conhecimento sobre determinado setor ou processo e com as com os usuários finais que são as pessoas que realmente utilizarão o software ã bom ah a a verificação de requisitos ela é especificamente uma das fases da engenharia de requisitos a engenheria de requisitos é um processo pelo qual se tenta identificar os requisitos transformar os requisitos em eh

requisitos de sistema ou seja requisitos mais detalhados documentar esses requisitos ou seja especificá-los e verificar e validar esses requisitos para determinar se eles estão corretos E se eles atendem as necessidades dos clientes bom embora a verificação de requisitos ela seja a quarta fase da engenharia de requisitos ela pode e deve muitas vezes ser executada em conjunto paralelamente com as outras fases então h no momento que os documentos que os requisitos são elicitados já se pode aplicar uma certa verificação de requisitos uma certa validação de requisitos já se pode determinar se eles estão corretos já se

pode até um certo ponto já se pode tentar validar esses requisitos durante a análise de requisitos uma das funções da análise é justamente determinar se não há ambiguidade se não há conflito se não há anomalia os requisitos Ou seja já é feita uma verificação da análise além de compreender os requisitos e transformar eles em requisitos de sistema ou seja requisitos mais detalhados e ao produzir a especificação de requisitos já se pode verificar esses essa especificação para ver se ela está Clara correta completa Ahã então a validação de requisitos ela pode ocorrer assim que os requisitos

tenham sido elicitados ela pode ser executada em paralelo com em conjunto com a análise de requisitos já a verificação de requisitos é ela pode ser aplicada assim que haja alguma documentação de requisitos não necessariamente completa a validação e verificação elas podem na medida do possível H ocorrer também em paralelo ã a validação de requisitos ela pode ser apoiada por outras técnicas de elicitação Como por exemplo o a o uso de protótipos protótipos eles ajudam muito na comunicação com as partes interessadas eh uma vez que eles são gráficos que eles são visuais eles auxiliam a a

facilitar a a a compreensão das partes interessadas sobre o que foi entendido pela equipe Então os protótipos eles auxiliam a demonstrar como os conceitos e os comportamentos do software Foram compreendidos pela equipe Qual é o padrão de interface pretendido para o software Como será a interação do software com os usuários De que maneira as informações serão inseridas e recuperadas no sistema entre outras possibilidades ah então ah em resumo ao verificarmos os requisitos nós tentamos determinar se os requisitos foram compreendidos corretamente e se a especificação de requisitos não possui anomalias anomalias são erros ambiguidades conflitos falhas

incomple audes esse tipo de coisa já ao validarmos requisitos nós tentamos determinar se as partes interessadas estão em sintonia com a equipe se o que a equipe entendeu é realmente o que as partes interessadas quiseram dizer se o conhecimento transmitido pelas partes interessadas foi traduzido corretamente pela equipe foi compreendido corretamente pela equipe e também a validação de requisitos tenta determinar se o que foi H compreendido pela equipe traduz corretamente o que as partes interessadas realmente desejam e precisam E como eu falei isso não é uma tarefa uma tarefa fácil não é uma tarefa simples exige

bastante Tato exige bastante experiência exige muita conversa com as partes interessadas então ah o engenheiro de requisitos muitas vezes precisa h sugerir muitas funções que melhorem a o funcionamento da da empresa como um todo que torna ela mais competitiva bom existem vários tipos de verificação de requisitos entre eles existe o o a verificação de varidade de consistência de completude de Realismo de D ambiguidade de verificabilidade de rastreabilidade e de modificabilidade entre outros nós vamos falar um pouquinho sobre cada um deles então com relação à verificação de validade ela tenta determinar se cada funcionalidade está dentro

do escopo do software o escopo do software determina o que faz parte do software e o que está fora das suas fronteiras está fora dos seus limites que não deve ser implementado pelo software um software só deve implementar o que realmente faz parte do seu escopo então a verificação de validade determina se a se uma funcionalidade está dentro do escopo do software e se ela é realmente necessária não se deve desenvolver nada que não seja realmente necessário para o software ainda ela tenta determinar se há necessidade de funcionalidades adicionais ou se as funcionalidades elas precisam

ser modificadas de alguma maneira com relação à verificação de consistência Então os requisitos no documento de especificação eles não podem entrar em conflito ou seja os não pode acontecer de um de um requisito dizer uma coisa e outro requisito dizer o contrário Então não podem haver restrições que sejam contraditórias entre si ou sejam tão diferentes que ah cancelem uma a outra então eh a verificação de consistência éa como o nome já disz tenta determinar se o software está consistente em termos de não existirem conflitos entre os requisitos ou ou entre suas restrições já com relação

à verificação de completude tenta se tenta determinar se o documento de especificação ele está completo ou seja se há requisitos que definam todas as funcionalidades necessárias ao software e se as restrições pretendidas para as funcionalidades estão completas restrições dizem respeito à regras de negócio que uma funcionalidade deve obedecer a possíveis consistências possíveis validações que devem ser realizadas quando do funcionamento de uma funcionalidade e também se a as restrições relativas ao projeto como um todo estão eh definidas Então esse tipo de restrição relacionado ao projeto H diz respeito a cronograma orçamento tecnologias que devem ser utilizadas

processos de desenvolvimento que serão aplicados esse tipo de coisa já com relação a a verificação de Realismo se tenta determinar considerando a tecnologia disponível o orçamento estabelecido o cronograma estabelecido e o nível de conhecimento da equipe se realmente os requisitos solicitados podem ser implementados às vezes não é possível levando em consideração esse tipo de restrição e nós temos a verificação de não ambiguidade a verificação de de não ambiguidade tenta determinar se os requisitos se o documento de requisitos como um todo não é ambíguo ou seja se a descrição de cada requisito ela é passível de

uma e apenas uma interpretação ambiguidade é um problema muito grave para a engenharia de requisitos um documento de requisitos que esteja ambíguo pode e muitas vezes vai levar ao fracasso do Projeto vai levar a incompreensão do que realmente os clientes quiseram dizer então o software vai ser desenvolvido de forma errônea por melhor que ser desenvolvido não vai atender as necessidades do cliente ah ambiguidade é algo muito perigoso uma vez que os termos eles podem ser interpretados de múltiplas maneiras Principalmente quando se tratam de áreas diferentes aqui eu até coloquei uma figurinha que tenta ilustrar isso

ela pode ser por um ângulo ela pode ser vista como um coelho sobre outro ângulo ela pode ser um pato Então por essa questão ão de ambiguidade ser muito grave é necessário que haja um glossário esse glossário ele deve conter cada termo utilizado na especificação de requisitos principalmente os termos técnicos mas não somente eles e esses termos eles devem ser devem ter uma única interpretação cada termo deve ser descrito de forma Clara e essa descrição é a única interpretação aceita para aquele termo dentro do contexto daquele produto da aquele software eh com relação à verificação

de verificabilidade tenta se determinar se o documento ele é verificável ou seja E para isso aliás é preciso que cada requisito possua um processo viável Considerando o tempo que se leva para verificar o requisito e o custo desse desse processo então H esse processo ele deve garantir que que o software atende ao requisito em questão então o documento é verificável se é possível garantir que o software atende ao requisito em questão dentro de um tempo razoável e há um custo viável ainda com relação a à verificação de rastreabilidade um documento ele é rastreável se eu

consigo determinar a origem de cada de cada requisito Ou seja que qu pediu por pediu quando pediu e essa origem ela deve ser Clara e devidamente justificada isso é útil para determinar se é se um determinado requisito ainda é válido porque os requisitos podem mudar ao longo do projeto então o requisito que era válido no Ino do projeto ele pode deixar de ser Válido por algum motivo e eu ten que determinar Quem foi responsável por solicitar aquele requisito também isso é chamado aliás isso é chamado de rastreabilidade para trás agora Ah para um documento ser

rastreável é preciso também determinar o impacto da mudança em um determinado requisito quais artefatos serão impactados pela mudança desse requisito isso é chamado rastreabilidade para frente e tem também a verificação de modificabilidade um documento de especificação de requisitos ele é modificável se eu posso modificar esse documento de maneira fácil completa e consistente ou seja a modificação ela não causa ambiguidades não causa conflitos não causa inconsistências ao meu documento Ahã falando um pouquinho sobre as técnicas de verificação e validação de requisitos as técnicas de de verificação e validação de requisitos mais conhecidas ou ainda os grupos

de técnicas de verificação e validação de requisitos mais conhecidos são revisões ou inspeções de requisitos alguns autores fazem diferença entre revisões e inspeções Mas na minha opinião elas são praticamente a mesma coisa talvez com nível de ã critério mais profundo Entre uma e outra então nas revisões ou inspeções requisitos os requisitos eles são analisados sistematicamente por uma equipe de revisores e essa equipe ela busca por erros anomalias falhas inconsistências falta de padronizações na especificação uma outra técnica já mais voltada para validação de requisitos Como já foi falado é a prototipação onde tenta-se demonstrar eh por

meio de protótipos O que foi compreendido do software Qual é o comportamento que se pretende para cada requisito Qual é o padrão de interface que vai ser utilizado esse tipo de coisa então isso é para tentar garantir que H os requisitos realmente atendem as necessidades dos usuários das partes interessadas e se os requisitos foram compreendidos corretamente e nós temos a geração de casos de Test onde se tenta produzir testes para validar para validar e verificar os requisitos existem técnicas de desenvolvimento como a tdd a test Dri and development que produzem testes antes do código ser

realmente desenvolvido então quando os testes eles são concebidos como parte do processo de validação eles ajudam muitas vezes a encontrar erros e problemas requisitos ã basicamente a filosofia é que se for difícil ou impossível projetar um teste então aquele requisito Muito provavelmente vai ser difícil de implementar e deve ser revisto ah com relação ainda às validações requisitos Então a partir dos requisitos elicitados eu devo validar os requisitos com as partes interessadas por meio de técnicas como prototipação e eu tenho que garantir que os requisitos estão rastreáveis ou seja determinar a origem desses requisitos E qual

vai ser o impacto da mudança desses requisitos Ah já com relação às verificações de requisitos a partir da descrição dos requisitos deve-se verificar se existem conflitos entre os requisitos se um requisito contradiz outro por exemplo se os requisitos estão consistentes se os requisitos estão completos se existem possíveis ambiguidades dos requisitos os resultados obtidos pela pelas técnicas de verificação e validação de requisitos costumam ser um glossário de termos para evitar ambiguidade requisitos rastreáveis para determinar quem pediu porque pediu quando pediu E qual vai ser o impacto da mudança dos requisitos nos artefatos nos outros artefatos do

projeto Lembrando que artefato é qualquer documento que foi que é produzido durante o processo de desenvolvimento de software pode ser documento e requisitos pode ser H modelos arquiteturais modelos de projeto testes casos de testes resultados de testes e código propriamente dito Ah também a verificação e validação dos requisitos produz uma especificação de requisitos corrigida atualizada e correta e também ela pode conter resultados dos casos de testes então nós terminamos mais essa aula sobre verificação e validação eu espero que essa aula tenha sido considerada útil válida Então se vocês eh consideraram essa aula útil eu peço

que vocês curtam esse vídeo eh compartilhem com quem possa se interessar pelo assunto e se ainda não estão inscritos eu peço que se inscrevam nesse canal obrigado pela atenção