Técnica de Leitura Baseada em Cenários

Olá sejam bem-vindos ao canal engenharia de software com ênfase um ml Eu sou professor jis GS e eu já atua na área de modelagem de software há vários anos eu tenho quatro livos publicados sobre o assunto e eu já ministrei diversas palestras e cursos técnicos so modelagem de software utilizando a linguagem na aula de hoje eu dar sego ao tema de verificação e validação de software dessa vez abordando a técnica de leitura baseada em cenários Então vamos iniciar a nossa aula então a técnica de leitura baseada em cenários ela costuma ser aplicada principalmente mas não

somente em documentos de especificação de requisitos ela é aplicada para inspecionar documento de especificação de requisitos todavia ela pode ser utilizada para verificar outros tipos de artefatos como o nome já diz ela se baseia em cenários de de tal forma que esses cenários sirvam de guia para os revisores durante as inspeções e que permitam simular como o sistema se comportaria em determinadas situações em diversas situações Então como toda a técnica de exeção eh a técnica de leitura baseada em cenários ela tem por objetivo identificar problemas como por exemplo ambiguidades Ou seja quando algo É passivo

de mais uma interpretação omissões quando estão faltando informações inconsistências quando há conflitos ou informações se contradizem entre outros tipos de erros falhas ou anomalias então Eh quando se utilizam cenários como guia para inspeção isso força os avaliadores a assumirem um papel ativo de leitura porque muitas vezes é necessário e às vezes até recomendado que os inspetores eles escrevam cenários para inspeção E no momento que Eles seguem um ou mais cenários eh eles passam a adquirir uma percepção real do software descrito no documento de especificação de requisitos então já que os inspetores eles são forçados a

exercer um papel mais ativo então eles são obrigados a pensar mais profundamente sobre o software a analisar melhor a especificação de requisitos então uma vez que eles obtêm um entendimento mais profundo então Normalmente eles conseguem achar defeitos mais sutis defeitos mais implícitos defeitos mais escondidos ah então essa técnica ela pode fazer uso de perguntas e listas de verificação específicas para cada cenário ou conjunto de cenários que ajudam a descobrir os efeitos diferente da técnica de leitura baseada em listas de verificação que foi explicada na aula anterior Ah aqui cada lista de verificação costuma ser adaptada

para cada cenário ou conjunto de cenários que está sendo examinado enquanto que na técnica de leitura baseada em lista de verificação a lista de verificação em si era voltada para o artefato comum todo bom então dentro dessa técnica cada inspetor pode e é até mesmo recomendado que ele utilize um cenário diferente com responsabilidades diferentes então é preciso selecionar uma combinação de cenários que cubram todas as características todos os aspectos do documento sobre inspeção e e que ess cenários eles sejam o menos redundante possíveis entre si Ah então os cenários eles precisam ser definidos a partir

da de descrições parciais do sistema ou do e do comportamento Geral do software com relação à orientação de leitura a orientação de leitura foi ensinada em algumas aulas anteriores ela pode ser intuitiva não sistemática sistemática e altamente sistemática a a orientação de leitura da técnica de leitura baseada em cenários ela é sistemática por quê Porque ela segue um processo estruturado para revisar os requisitos os cenários eles podem ser descritos de maneira mais livre pode ser descritos de forma textual livre mas a análise desses cenários ela é guiada por etapas muito bem definidas e que precisam

ser executadas em uma sequência lógica Então quais são as características que tornam essa técnica de leitura sistemática bom existe um plane existe a execução desse do dos Passos definidos no planejamento existe uma orientação específica de como eh procurar por erros e é feita uma documentação dos erros encontrados e os erros são categorizados então isso são características de uma técnica sistemática então durante o planejamento o cenários eles são planejados e ou selecionados dependendo se os cenários já existem como por exemplo caso de uso ou se é preciso criar cenários para analisar a o documento de espação

de requisitos Então os cenários eles são planejados e selecionados tomando como base situações reais de uso do software durante a execução cada cenário é examinado de maneira consistente se tenta garantir que todos os requisitos relevantes para contexto do cenário em questão sejam revisados e ah com relação a orientação específica Como já foi falado os cenários eles podem ser mais textuais mais narrativos ou podem ser estruturados mas mesmo que eles se que eles possam ser narrativos então eles ainda assim eles serão acompanhados por um conjunto de perguntas direcionadas e ou listas de verificação então isso garante

que o processo de inspeção seja orientado para a detecção de um conjunto de erros bem identificados um conjunto de erros específicos com relação à documentação ah essa técnica de essa técnica de leitura determina o registro das observações e resultados incluindo os erros que foram encontrados de maneira formal os erros devem ser categorizados de acordo com o seu tipo então ã mesmo que haja uma certa flexibilidade na construção dos cenários a técnica em si é uma abordagem controlada estruturada e isso caracteriza uma técnica sistemática vamos falar a um pouco sobre a responsabilidade do Inspetor aqui eu

coloquei uma figurinha do homem-aranha com o Dogma a máxima mais comum que ele costuma utilizar que é com grandes poderes vem grandes responsabilidades bom com relação à responsabilidade do Inspetor ela é específica por quê Porque é muito comum que cada inspetor examine um artefato considerando um cenário o conjunto de cenários diferentes porém com relação à responsabilidade da equipe ela é Idêntica porque todos os inspetores usam a mesma técnica de leitura falando um pouco sobre os cenários os cenários eles podem ser de texto livre ou seja descrições textuais em formato específico Ou eles podem ser estruturados

ou seja como por exemplo cenários de caso de uso Ah eu vou explicar as vantagens de utilizar cenários de texto e cenários estruturados Então as vantagens de usar cenários de texto não estruturados as vantagens são flexibilidade adaptabilidade facilidade de criação foco nos problemas envolvimento das partes interessadas comunicação Clara e melhor cobertura de requisitos não funcionais vamos falar um pouquinho sobre cada uma dessas vantagens com relação à flexibilidade então h quando se trabalha com cenários de texto mais livre ou menos estruturado Então os revisores eles podem focar em aspectos específicos dos requisitos sem se restringir eh

por um formato mais rígido porque casos de uso costumam ser mais estruturados seguem um formato ato que deve ser obedecido e isso é bastante útil quando se deseja explorar áreas do software que não estão claramente definidas ou que simplesmente não foram cobertas pelos casos de uso com relação à adaptabilidade cenários de texto mais simples eles podem ser ajustados com mais facilidade do que caso de uso ah então essa adaptabilidade permite que eles sejam ajustados para focar em situações específicas ou a novas percepções que são descobertas durante o processo de revisão com relação à facilidade de

criação ah escrever cenários utilizando um formato mais livre costuma ser mais rápido e exigir menos esforço e isso pode ser vantajoso em situações que o tempo é limitado quando se deseja envolver partes interessadas que H estão pouco familiarizados ou não estão familiarizados com técnicas formais de modelagem então escrever um texto mais livre eh permite que elas eh se envolvam melhor no processo entendam melhor o processo ou em em situações que os casos de usos relacionados à aquela situação específica não existem não foram produzidos ah Uma Outra vantagem é F os problemas os cenários informais eles

podem ser direcionados para áreas onde se suspeita que haja problemas Ah então Eh se permite uma inspeção mais focada Ainda há o melhor envolvimento das partes interessadas e uma comunicação mais clara com relação ao envolvimento das partes interessadas eh trabalhar com cenários de texto livre eh facilita mais a participação das partes interessadas Porque como já foi falado antes ã pessoas não familiarizadas com formatos formais como usuários finais ou representantes de negócio podem ter uma certa dificuldade em entender em caso de uso então elas têm mais facilidade em cenários de texto livre e a comunicação Clara

é que as descrições narrativas elas podem ser mais fácil entender e discutir por esse tipo de usuário ah ainda com relação à melhor cobertura de requisitos não funcionais ah caso de uso normalmente se concentram principalmente em requisitos funcionais requisitos não funcionais podem ser citados também podem ser comentados mas maior enfoque está no requisito funcional um caso de uso sempre descreve cenários sempre não mas na maioria das vezes descreve cenários relativos a uma funcionalidade a um a um requisito funcional específico então uma abordagem textual mais simples pode permitir a cobertura com mais profundidade de alguns requisitos

não funcionais necessários a um cenário específico ou ao sistema como um todo o que é aliás mais comum agora vou falar sobre as vantagens de utilizar cenários de caso de uso caso de uso eles permitem criar vários cenários como cenário principal cenários alternativos e cenários de sessão para um determinado requisito funcional Então as principais vantagens são foco no comportamento real do sistema clareza e objetividade cobertura abrangente de funcionalidades maior facilidade para detectar omissões e inconsistências maior alinhamento com as necessidades das partes interessadas melhor identificação de falhas de usabilidade e maior testabilidade dos requisitos vamos falar

pouquinho sobre o foco no comportamento real do sistema essa é a primeira parte então como já foi falado caso de uso descreve o comportamento funcional do software em interações reais ou seja o comportamento de requisitos funcionais Ah ele permite a que a revisão seja feita com base no uso prático do sistema que já foi analisado e descrito por meio de caso de uso e garante que os requisitos eles capturam cor as funcionalidades necessárias ainda ao se verificar cenários de caso de uso o inspetor avalia como o sistema realmente se comporta diante de interações específicas com

o usuário isso torna a validação mais realista mais próxima de uma de situações reais e contextualizada com relação à clareza e objetividade essa é a primeira parte então os cenários de casos de uso eles são em geral estruturados e melhor detalhados do que cenários de caso de uso cenários de texto Livre e eles contêm diversas informações como por exemplo pré-condições pós condições ações de ator ações de sistema regras de negócio entre outras e isso permite ah a identificação de erros inconsistências ou lacunas com maior facilidade do que eh cenários de texto Livre ainda falando sobre

clareza e objetividade cada caso de uso tem um fluxo definido ah por vezes tem mais de um fluxo isso torna o processo de leitura mais objetivo e organizado e também fornece um contexto Claro paraos revisores sobre como o sistema deverá funcionar ah relação a cobertura abrangente de funcionalidades através de cenários de caso de uso eu posso cobrir diversos fluxos possíveis relativos ao software ou ao requisito funcional específico Eh esses fluxos eles são representados por cenários principais alternativos e Deão obviamente os cenários alternativos de excepção não são obrigatórios em todo caso de uso mas costumam existir

e costumam ser úteis mas pelo menos o cenário principal Deve existir então ã isso permite uma verificação mais completa e garante que todos os requisitos críticos foram adequadamente representados ainda falando sobre a cobertura ah cenários alternativos de exceção eles auxiliam que seja verificado se o software realmente lida de forma adequada com situações imprevistas ou fora do fluxo normal com relação à maior facilidade para detectar omissões e distâncias trabalhando com cenários de caso de uso é é mais fácil identificar requisitos faltantes ou incompletos porque a técnica ela força uma análise do comportamento completo do software em

situações reais Ah também permite o maior alento com as necessidades das partes interessadas os casos uso eles são criados para representar as interações do usuários finais com software e isso permite determinar se os requisitos estão alinhados com as expectativas e necessidades das partes interessadas e isso garante que o software seja funcional e útil então a perspectiva do do usuário é um aspecto essencial que precisa ser verificado durante a inspeção e isso é feito por meio da validação de como o software suportará as ações e decisões dos usuários e quais as suas respostas Ah também trabalhar

com cenários de caso de uso permite uma melhor identificação de falhas de usabilidade uma vez que caso de uso eles prescrevem Como será a interação entre os usuários e o software então é mais fácil detectar problemas de usabilidade e de fluxos confusos ou mal definidos e isso permite que os requisitos sejam ajustados para eh cobrir essas lacunas maior testabilidade dos requisitos os casos de uso como eles descrevem cenários tanto principais como alternativos como deceção os cenários são descritos passo a passo Isso facilita a a a concepção de testes para verificar esses cenários então facilita mais

que os requisitos eles sejam validados Ou seja que se determ se eles foram realmente desenvolvidos de acordo com o que foi especificado e uma vez que eu tenho requisitos testáveis eles são mais fáceis de implementar e verificar durante o desenvolvimento bom ah falar um pouquinho sobre as etapas da técnica de leitura baseada em cenário as etapas principais são identificação dos cenários principais definição de objetivos claros para cada cenário simulação do uso do software e documenta dos problemas encontrados vamos falar sobre cada uma delas com relação à identificação dos cenários principais então nessa etapa os cenários

que cobrem os principais fluxos de uso do software eles são selecionados deve-se incluir também os cenários alternativos de deceção além dos cenários principais durante a etapa da da definição de objetivos claros para cada o nome já diz se determina Qual é o objetivo da do que vai ser inspecionado em cada cenário então H exemplos são se as informações a serem fornecidas estão corretas se as saídas estão de acordo com o esperado se as regras de negócio consistências e validações estão corretas e completas então para isso pode-se e é até recomendado que se criem listas de

verificação específicas para cada cenário ou para o software como todo com relação à etapa de simulação de uso do software os revisores eles percorrem os cenários tentando determinar se os requisitos e a documentação realmente suportam adequadamente o comportamento esperado Ah para aquele caso de uso e Ah para aquele caso de uso ou para aquele cenário obviamente h e depois durante a etapa de documentação dos problemas encontrados Como já diz né todos os problemas que foram encontrados como por exemplo inconsistências ambiguidades omissões erros de usabilidade e outras possíveis anomalias são registradas Para que sejam corrigidas posteriormente

agora nós nós vamos fazer um exemplo de aplicação dessa técnica Aqui nós temos um trecho do documento de especificação de requisitos para o sistema de controle de encomendas enfocando o requisito de estar encomenda onde um cliente ele solicita que uma encomenda seja enviada para um destinatário então Aqui nós temos a descrição do requisito o sistema deve permitir que clientes postem encomendas nas diversas filiais da empresa de forma que elas possam ser enviadas para qualquer parte do mundo para isso é preciso informar os dados tanto do cliente como do destinatário bem como o conteúdo da encomenda

suas dimensões ou seja altura e largura e peso o software deve calcular o preço do envio e se o cliente estiver de acordo com o valor a encomenda deve ser colocada no estia para análise empacotamento etiquetação e Despacho o pagamento deve ser registrado e o sistema deve emitir o recibo e o código de rastreamento da encomenda não podem ser aceit os itens proibidos pela empresa como líquidos produtos perecíveis produtos frágeis produtos que contém animais ou vegetais vivos ou sementes ou ainda não são aceitos itens ilegais como drogas ou armas nesse último caso a encomenda deve

ficar retida e a polícia deve ser convocada bom ah agora nós vamos examinar uma lista de verificação complementar que foi produzida para esse caso de uso então primeiro nós temos a etapa de verificação da estrutur do caso de uso as perguntas a serem feitas o título e a identificação do caso de uso estão claros e corretos o possível erro que pode ser encontrado caso essa pergunta não seja a resposta a essa pergunta não seja verdadeira são omissão ou ou ambiguidade outra pergunta os atores principais e secundários estão claramente especificados e TM seus papéis descritos possíveis

erros omissão ambiguidade ou informação incorreta as pré-condições e pós condições quando necessárias estão claramente definidas possíveis erros omissão ou ambiguidade com relação à verificação do cenário principal perguntas o fluxo principal está completo e descreve todas as ações esperadas do ator do sistema possíveis erros omissão ou informação incorreta as ações do ator e do sistema estão Claras e sem ambiguidade possíveis erros ambiguidade ou imprecisão todos os dados essenciais são solicitados alguma necessária ao correto funcionamento do processo está faltando possível erro omissão o processo valida corretamente os dados de entrada possível erro validação com relação às regras

de negócio e outras possíveis validações e consistências que precisam ser realizadas as regras de negócio relevantes estão descritas no cenário principal possíveis erros omissão ou informação incorreta as validações como o peso da encomenda ou itens proibidos estão descritas claramente são coerentes possíveis erros omissão informação incorreta informação incompleta ou ambiguidade eu chamo atenção que essa pergunta é bem específica para o cenário em questão ela não poderia ser aproveitada na maioria dos outros cenários então destacando a diferença entre a técnica de leitura baseada em cenário e a técnica de leitura baseada em lista de verificação a técnica

de leitura baseada em cenário também usa listas de verificação mas são listas de verificação específicas para cada cenário outra pergunta o sistema trata as entradas e dados corretamente validando os conforme necessário possíveis erros comissão informação incorreta ou inconsistência ah com relação à verificação dos cenários alternativos os cenários alternativos estão claramente descritos e cobrem as situações específicas que desviam do fluxo principal possíveis erros omissão ou informação incorreta as condições que levam o cenário alternativa estão claramente identificadas possível erro omissão ou ambiguidade o cenário alternativo descreve corretamente as ações do ator e do sistema de forma Clara

possível erro omissão ou ambiguidade ah com relação às regras de negócio e validações no cenário alternativo as as regras de negócio aplicáveis ao cenário alternativo estão descritas e são consistentes com fluxo possíveis erros omissão ou inconsistência as validações necessárias para o cenário alternativo estão adequadas possíveis erros omissão ou informação incorreta ah com relação ao fluxo e coerência com o cenário principal o cenário alternativa mantém consistência com fluxo principal possível erro inconsistência as as transições entre o fluxo principal e o alternativo estão bem definidas possíveis erros omissão ou inconsistência ah com relação à verificação do cenário

de sessão essa é a primeira parte todos os cenários de sessão foram contemplados possível erro omissão os cenários de exceção estão bem identificados e descrevem claramente as condições que levam uma exceção possíveis erros omissão ou ambiguidade o sistema trata corretamente as condições de erro como itens roubados ou Ilegais possíveis erros omissão ou informação incorreta ainda com relação à verificação do cenário de sessão erros de processamento falhas de sistema ou entrada de dados incorretos estão cobertas possível erro omissão o sistema oferece informação Clara para o usuário quando ocorre um erro possíveis erros omissão ou ambiguidade as

mensagens de er estão descritas elas são Claras e fornecem instruções suficientes para que o usuário possa corrigir o problema possíveis erros omissão ou ambiguidade com relação aos ao tratamento de exceções o tratamento de erros e exceções está bem descrito incluindo a ação do ator e do sistema possíveis erros omissão ou ambiguidade as exceções são tratadas de forma Clara e sem ambiguidade incluindo ações corretivas notificações e mensagens de erro possíveis erros omissão ou informação incorreta com relação à consistência e integração o cenário de excessão está consistente com as regras de negócio e o fluxo principal possíveis

erros inconsistência ou omissão o fluxo de excessão leva a um resultado coerente com o restante do processo possível erro inconsistência com relação à verificação de aderência aos requisitos perguntas o caso de uso está em conformidade com a descrição do requisito funcional possível erro inconsistência todas as demandas dos requisit do requisito foram cobertas no fluxo principal ou nos cenários alternativos possível erro omissão possíveis requisitos não funcionais como desempenho proteção escalabilidade ou usabilidade são mencionados e cobertos pelo caso de uso possível erro omissão e Aqui nós temos eh os cenários representados por caso de uso para o

processo de postagem de encomenda então Aqui nós temos a primeira parte que é a estrutura principal do caso de uso a identificação do caso de uso é o c01 O código dele e a descrição postar encomenda o resumo ele descreve que este caso de uso estabelece as etapas percorridas por um atendente para receber um pedido de encomenda e encaminhá-la para entrega o ator principal atendente os atores secundários são cliente pré-condições o atendente precisa estar logado pós condições deve-se entregar um recibo ao cliente com relação ao cenário principal ações do ator e esse cenário é dividido

em ações do ator e ações do sistema ã iniciando com uma ação do ator primeiramente o atendente irá selecionar a opção enviar encomenda sempre as ações do ator costumam trabalhar com o ator principal e a resposta do sistema é a apresentar o formulário solicitando os dados do cliente do destinatário sobre o conteúdo e medidas e peso da encomenda o ator então ele informa os dados do remetente do destinatário e ele informa as medidas e o peso da encomenda e confirma a as informações o sistema em resposta irá calcular o valor de envio da encomenda continuando

o atendente irá colocar encomenda na esteira de análise e empacotamento e o sistema em resposta irá escanear a encomenda em busca de itens Ilegais proibidos procurados ou não aceitos pelos países de origem e destino o sistema irá embalar e etiquetar a encomenda irá despachar a encomenda o atendente irá registrar o pagamento da encomenda e vai confirmar esse pagamento o sistema em resposta registrará o pagamento e emitirá e emitir um comprovante e um có cóigo de rastreamento a ser entregue para o cliente regras de negócio restrições e validações que precisam ser verificadas primeiro não são aceitos

itens líquidos perecíveis frágeis vivos ou sementes segundo não podem ser aceitos itens proibidos do país de destino terceiro deve-se procurar por itens roubados ou Ilegais Aqui nós temos um cenário alternativo que leva em consideração que se recebeu a existência de Um item roubado ou ilegal na encomenda o cenário também é dividido em ações de ator e ações do sistema Então por ações do sistema o o software ele contacta a polícia mais próxima informando a descoberta de itens roubados ou Ilegais dentro da encomenda eh fotografa o cliente sem que ele perceba e informa o atendente do

ocorrido já o cenário de sessão se refere a item proibido ou não aceito pela empresa também é dividido em ações do ator e a do sistema então o sistema informa que a encomenda não pode ser aceita devido ao item ser proibido ou não ser aceito pela empresa e recusa encomenda bom agora nós vamos analisar os resultados da inspeção com relação à verificação da estrutura do caso de uso com relação aos atores secundários o ator secundário cliente ele está mencionado porém não há uma descrição detalhada do papel que ele exerce durante o processo ã em geral

se presume que o ator secundário ele somente fornece informações Mas isso é uma presunção Então não fica claro de que maneira ele interage com o processo ou interage com o ator atendente então talvez fosse útil esclarecer melhor o o envolvimento do ator cliente nas etapas específicas em que ele fornece dados ou realiza o pagamento então o erro encontrado aqui foi o de omissão ã a ainda com relação à verificação da estrutura do caso de uso com relação às pré-condições a precondição o atendente precisa estar logado está presente todavia poderia ser adicionado o hardware de rastreamento

deve estar operacional é uma pré-condição para que seja postado uma uma encomenda que não foi prevista então o erro encontrado é o de omissão ainda com relação à estrutura do caso de uso com relação a pós condições a pós condição entregar receba ao cliente ela é Clara e específica porém não foi coberta a a pós condição de que seja emitido o código de rastreamento que é o que tá descrito no no requisito é necessário que o cliente Receba um código de adestramento após o ao final desse processo E isso não foi coberto portanto esse o

erro encontrado é de omissão com relação à verificação do cenário principal o cenário principal ele cobre todas as etapas principais desde a entrada dos dados até o pagamento e emissão do recibo porém não existem detalhes sobre como o sistema cobre algumas validações de dados por exemplo quando há medidas incorretas da encomenda o peso a altura o comprimento foram informados de maneira errada então o erro encontrado aqui é o de incompletude ainda com relação ao cenário principal as ações do ator do sistema estão descritas de forma Clara porém o subprocesso de escaneamento e busca de itens

Ilegais ele possui pouco detalhamento apenas se diz que o sistema deve escanear mas não há informações de como isso será feito ou por exemplo qual tecnologia eh será utilizada nesse subprocesso então o er contrado é de incompletude e omissão ainda com relação ao cenário principal os dados a sero informados eles estão claramente listados como por exemplo que é necessário informar os dados remetente do destinatário informar os dados relativos à medidas e pesos da encomenda porém não se especificou limites de peso e dimensões máximas das encomendas não está claro qual é o peso máximo que é

aceito Qual o tamanho máximo para uma encomenda então o erro encontrado é o de omissão com relação à verificação do cenário alternativo o cenário alternativo item roubado ou ilegal está bem descrito mas não estão detalhados os passos de como a encomenda ficaria retida então o erro encontrado é de omissão com relação à verificação do cenário de sessão o cenário de sessão item proibido ou não aceito pela empresa ele está bem descrito com etapas bem Claras todavia não está descrito O que acontece após a recusa do pedido então a fica uma dúvida o sistema ele deve

registrar a tentativa de envio de item proibido isso pode ser útil Por uma questão de dados analíticos futuros para emissão de relatórios de tentativas de envio de item proibido ã talvez por desinformação dos clientes por exemplo então o erro encontrado é o de omissão ainda com relação cenário de sessão o caso de uso el cobre cenários de erro relacionados a itens proibidos mas não há detalhes sobre erros eh relativos a outras etapas ou situações como H falhas na esteira ou hard ou falhas do hardware de rastreamento ou escaneamento ã problemas relativos ao pagamento ou dados

ou situações em que o o cliente forneça dados incorretos então aqui o er encontrá foi o de omissão com relação à verificação das regras de negócio as regras de negócio elas estão mencionadas contudo há poucos detalhes sobre como essas regras devem ser implementadas como o sistema verifica se o item é proibido isso não foi descrito então poderia haver mais detalhes sobre as validações automáticas que devem ser realizadas durante o processo de entrada de dados então por exemplo como se poderia ter informações como como que permitissem determinar se o peso ou as dimensões da encomenda são

válidas então o erro encontrado aqui é o de omissão com relação à verificação da Integração com outros processos bom não existe menção explícita de como o sistema irá interagir com outros softwares Como por exemplo o sistema de rastreamento de encomendas ou o sistema de pagamento então o reencontrado foi o de omissão ah relação à verificação de dependências existem dependências a as existe dependência de conexão com o sistema de rastreamento e com a base de dados de itens Ilegais ou procurados mas as dependências elas não estão claramente descritas então o er encontrado foi o de omissão

com relação à à verificação de requisitos não funcionais eles não são mencionados Ah não se sabe por exemplo questões como desempenho usabilidade proteção não se sabe como elas devem ser atendidas Então não é descrito por exemplo quanto tempo processo deve durar Qual é o tempo de resposta para cada ação do do atendente por exemplo Ah não é definido qu amigável a interface deve ser eh e também não se não não é descrito como os dados do cliente e do destinatário deverão ser protegidos porque eles são particulares eles não podem se se tornar disponíveis para qualquer

pessoa então o erro encontrado é o de omissão agora vamos falar um pouquinho sobre as vantagens das da da técnica de leitura baseada em cenários o contexto é mais realista existe uma maior facilidade de detecção de opções maior facilidade de detecção de inconsistências e facilidade de comunicação com as partes interessadas vamos falar um pouquinho sobre cada uma dessas vantagens Ah o contexto é mais realista então cenários realistas eles ajudam a validar se o software realmente atende aos requisitos E se ele cobre as diversas situações possíveis como fluxo principal fluxos alternativos fluxos de exceção existe uma

maior facilidade de detecção de omissões ah A análise dos dos cenários pode permitir que sejam revelados requisitos que não foram mencionados estão ausentes ou que estão mal descritos já uma vez que os requisitos eles simulam a utilização do software por meio desse cenários e existe uma maior facilidade de detecção de inconsistências então uma vez que são examinados cenários completos passo a passo então fica mais fácil identificar inconsistências entre os requisitos ou problemas de interação entre as funcionalidades há também uma fa de comunicação com as partes interessadas mesmo se tratando de cenários de caso de uso

porque cenários são mais fáceis de entender e discutir então a comunicação é mais clara entre as partes interessadas agora nós temos as desvantagens Então essa técnica pode demandar um tempo bastante longo ela é muito dependente da qualidade dos cenários e pode ocorrer um foco limitado a casos específicos com relação a a demanda de tempo longa ah analisar os cenários pode ser bastante demorado principalmente se for necessário criar muitos dos cenários antes se não é possível aproveitar casos de uso que já estão definidos na especificação de requisitos ou esses casos de uso estão mal feitos por

exemplo e também eh pode ocorrer situações em que o número de cenários que é necessário para cumprir todas as facetas possíveis por muito grande então isso vai deixar o processo bastante longo também há o problema da dependência de qualidade cenários essa técnica ela precisa que os cenários estejam bem construídos bem definidos senão a a eficácia da técnica vai ser muito prejudicada Então os resultados de uma inspeção que se baseia em cenários mal definidos ou cenários reais vai ser fraca e com relação ao foco limitado a casos específicos a equipe ela pode eventualmente se concentrar em

alguns cenários específicos e deixar de identificar problemas maiores mais amplos ou sistêmicos ou seja relativos ao sistema como um todo no documento de especificação de requisitos ou no artefato ou em outro artefato que este sendo examinado e nós concluímos mais essa aula eu espero que vocês tenham considerado essa aula válida espero que vocês tenham gostado se vocês gostaram dessa aula eu peço que vocês curtam esse vídeo compartilh com quem possa ter interesse e se ainda não estão inscritos eu peço que se inscrevam no canal obrigado pela atenção nós nos veremos em outros vídeos futuros