Engenharia de Requisitos - Parte III - Qualidade de Requisitos

Olá sejam bem-vindos ao canal engenharia de software com ênfase uml Eu sou professor Julian GES e eu já atuo na área de modelagem de software a vários anos eu tenho quatro livros publicados sobre o assunto e eu já ministrei diversas palestras e cursos técnicos utilizando a linguagem uml na aula de hoje eu vou dar continuidade ao tema sobre engenharia de requisitos dessa vez a abordando qualidade de requisitos Então vamos iniciar a nossa aula Então vamos falar sobre qualidade software com relação aos requisitos os requisitos eles são a base a partir da qual a qualidade de

um software é medida se não há conformidade com os requisitos então não há qualidade não importa o que o software faça ele pode ser muito bom pode ter diversas funcionalidades se ele não atende as necessidades do cliente não atende ao que foi solicitado ao que foi expressamente definido que o software precisava atender ele não tem qualidade Então para que ele os requisitos sirvam de Base a um produto de boa qualidade eles precisam individualmente e a especificação de requisitos como um todo ou seja a forma como eles foram documentados é satisfazer uma série de características de

qualidade que nós vamos ã abordar nessa aula então Aqui nós temos uma lista das características de um bom requisito um requisito ele precisa ser necessário apropriado não ambíguo ou preciso completo singular factível ou possível verificável correto conforme [Música] priorizá-lo então o requisito ele deve definir uma funcionalidade uma característica uma restrição ou um fator de qualidade que seja realmente necessário ao software Lembrando que fator de qualidade é um é um atributo que deve ser obedecido em geral pelo software como um todo ou por grande parte dele eh e exemplos disso seriam usabilidade desempenho portabilidade escalabilidade confiabilidade

esse tipo de coisa restrições São consistências Regras normas que precisam ser satisfeitas por uma determinada funcionalidade e uma funcionalidade é um serviço ou função que o software oferece aos seus usuários então um requisito ele precisa ser necessário se ele não é se ele não é necessário Não há necessidade de desenvolvê-lo não há motivo para desenvolvê-lo Ahã um requisito ele precisa ser apropriado a intenção específica e a quantidade de detalhe do requisito precisa ser descrita de forma apropriada no nível de abstração necessário assim é preciso evitar restrições desnecessárias sobre a arquitetura e entrar em detalhes da

solução porque isso é função da fase de projeto a fase de projeto deve definir como o problema será solucionado a fase de Aria de requisitos apenas identifica o problema um requisito ele precisa ser não ambíguo ou preciso e isso é uma característica muito importante de um requisito um requisito ambíguo ou seja passível de mais de uma interpretação ele pode levar ao fracasso de um projeto então um requisito ele precisa ser declarado de tal maneira que ele possa ter apenas uma única interpretação e essa descrição deve ser simples e fácil de entender não deve haver problemas

de interpretação do que o requisito eh do que precisa ser feito com relação à aquele requisito quando palavras termos técnicos siglas ou acrônimos podem ser interpretadas de maneira diferentes então deve-se elaborar um glossário onde cada um desses esses termos deve ser declarado eh de forma explícita e claramente Qual o seu significado e somente esse significado será aceito pelo projeto nenhum outro significado é aceito além do que está estabelecido no glossário isso para evitar ambiguidades e erros de interpretação por quê Porque as palavras a língua portuguesa a maioria dos idiomas como um todo eles costumam ser

muito ricos e uma mesma palavra o mesmo termo pode variar pode pode ter múltiplas interpretações dependendo do ambiente dependendo da área dependendo da região onde ele é utilizado então é muito importante Deixar claro o significado de cada termo para evitar ambiguidade para evitar erros de interpretação então erros de interpretação de dos requisitos eles podem ser extremamente graves em um projeto de software um requisito que for mal interpretado ele é um requisito errado ele não atende às necessidades das partes interessadas e isso resultará em um produto insatisfatório então requisitos não podem ser mal interpretados eles precisam

ter uma definição única e aceita por todas as partes vamos falar um pouco sobre uma outra característica de um bom requisito um requisito precisa ser completo então a descrição de o requisito precisa conter a informação necessária a compreensão do requisito sem que seja necessário consultar qualquer outra fonte de informação nenhum outro documento precisa ser consultado somente a especificação de requisitos um requisito ele precisa ser factível ou seja ele deve ser possível de ser atingido então um requisito ele deve poder ser implementado atendendo às restrições que foram impostas ao projeto que podem ser por exemplo orçamento

cronograma limitações tecnológicas com o nível de risco aceitável Então deve ser possível atender ao requisito dentro dessas restrições o requisito ele precisa ser singular um requisito ele deve declarar uma única funcionalidade característica restrição ou fator de de qualidade não o requisito não pode declarar mais de uma função personalidade ao mesmo tempo cada requisito é único é singular um requisito ele precisa ser verificável ele deve ser escrito e estruturado de tal forma que seja possível verificar se ele foi implementado de maneira efetiva dentro do que foi especificado e um requisito ele é verificável se ele atender

as seguintes condições Deve existir ti um processo finito para verificá-lo com um custo compensador Ou seja a verificação não pode levar tempo demais nem custar caro demais que possa ser executado por uma pessoa ou máquina e que comprove que o produto final está de acordo com o requisito que foi solicitado o requisito ele precisa ser correto o requisito ele deve representar uma necessidade real do produto a ser construído e deve ser descrito corretamente é necessário garantir que o requisito em questão realmente pertence ao software a ser desenvolvido ou se ele está fora do escopo e

deve ser descartado isso pode ser facilitado por meio de priorização de requisitos priorização de requisitos ajuda a determinar quando o requisito está fora do escopo H por exemplo eu posso utilizar uma técnica de priorização como a a técnica Moscou que estabelece os requisitos essenciais desejáveis ou opcionais e que não devem ser desenvolvidos ou seja os requisitos que estão fora do escopo é importante identificar os requisitos que estão fora do escopo Logo no início para não dar falsas esperanças para os clientes já dizer Logo no início esse requisito não será desenvolvido porque não faz parte do

escopo desse software ele faz parte de um outro sistema um requisito ele precisa ser conforme e significa que cada requisito precisa estar de acordo com o padrão e estilo de de escrita da especificação de requisitos que foi adotado então eu não devo escrever um requisito utilizando um padrão um estilo de escrita diferente eu devo utilizar o padrão adotado pela empresa de desenvolvimento pela equipe de desenvolvimento como eh estabelecido um requisito ele precisa ser priorizado como já falei é importante priorizar os requisitos existem diversos critérios que podem ser considerados então eh a priorização de requisitos ajuda

a determinar quais os requisitos devem ser enfocados primeiro implementados primeiro e também quais requisitos podem ser descartados se houver problemas de orçamento de cronograma se a equipe perder membros por exemplo qualquer outro risco que possa afetar o desenvolvimento do software como eu falei existe uma técnica Moscou que ela estabelece quais os requisitos essenciais Quais são os desejáveis Quais são os opcionais e quais estão fora do escopo os requisitos eh essenciais como o nome já dis são os requisitos que precisam ser desenvolvidos impreterivelmente são requisitos que ajudam a determinar o MVP o mínimo produto viável ou

seja o mínimo que o software deve atender para agregar valor ao usuário então em situações em que podem haver pode ocorrer riscos estabelecer quais os requisitos mais importantes ajuda a a atender minimamente o cliente e também por uma questão de negociação às vezes há grandes mudanças nos requisitos ou há grandes mudanças na no enfoque da empresa ou há grandes cortes orçamentários ou o cronograma precisa ser adiantado n riscos podem ocorrer então isso ajuda a negociar com o cliente eles podde nós podemos chegar a dizer olha com essas mudanças nós não conseguimos atender todos os requisitos

mas nós conseguimos atender aos requisitos essenciais Então pelo menos o mínimo produto viável vocês terão para começar a trabalhar os outros requisitos podem ser atendidos em uma segunda versão também pode se estabelecer de acordo com essa priorização determinar quais requisitos podem ser cortados eu posso dizer bom por exemplo já que houve essas mudança os requisitos opcionais poderão não ser desenvolvidos ou alguns dos requisitos desejáveis precisaram ser abandonados esse tipo de coisa Ahã Então os requisitos eles podem ser priorizados de acordo com sua estabilidade Ou seja a probabilidade que o requisito V sofrer modificações durante o

projeto então existem requisitos que são bastante instáveis e isso pode ser problemático de acordo com a sua importância para o cliente então por exemplo utilizando a a técnica Moscou ã de acordo com a sua complexidade esse último item é bastante complicado não é muito fácil estimar a complexidade de um requisito às vezes eh um requisito ele precisa ser rastreável basicamente eh a rastreabilidade me permite determinar a origem de cada requisito e o impacto de sua mudança eh existem dois tipos de rastreabilidade a rastreabilidade para a frente e rastreabilidade para trás a rastreabilidade para trás ela

permite determinar a origem do requisito isso ou seja verificar quem solicitou o requisito quando a solicitação foi feita por que o o requisito foi solicitado o que se tencionava obter por meio daquele requisito isso é importante para determinar se o requisito ele é ind válido ou se ele deixou de ter validade e pode ser descartado como eu falei os requisitos pode sofrer mudanças ao longo do projeto Às vezes pode ser útil determinar se o requisito ainda não desenvolvido ainda é válido ah existe a rastreabilidade para a frente que ela determina o impacto da modificação do

requisito em termos de quais artefatos ou seja artefato é basicamente qualquer produto desenvolvido durante o ciclo de vida do do sistema durante o processo de desenvolvimento do software então artefatos podem ser especificação de requisitos podem ser modelos de projeto podem ser eh testes de software pode ser código qualquer coisa que foi desenvolvida então a rastreabilidade paraa frente ela estabelece quais artefatos podem sofrer Impacto podem ser afetados pela modificação de requisito e isso permite avaliar o impacto dessa modificação e se essa modificação ela se justifica levando em consideração o custo e o tempo que se levará

para modificar o requisito e comparar isso com o benefício que essa mudança iria trazer efetivamente e ela também garante que todas as atualizações que H deverão ser deverão ser efetivadas a partir da alteração do requisito realmente ocorram então isso evitaria deixar a documentação ou o código do produto inconsistente Porque no momento que um requisito foi modificado o projeto ou a a parte do projeto que foi afetada por ele deve ser atualizada e agora vamos falar sobre as características de uma boa especificação de requisitos existe o requisito e existe a especificação de requisitos a especificação de

requisitos engloba o o conjunto total de requisitos e é basicamente um documento que descreve e organiza esses requisitos de acordo com um determinado padrão ã então de forma a servir de base para um produto de boa qualidade a a especificação de requisitos ela precisa satisfazer várias qualidades eh que nós vamos falar Eh então uma especificação de requisitos ela deve ser compreensível factível ou possível completa consistente e validá alguns dessas características se confundem um pouco com as características de um bom requisito as as duas coisas estão pouco interrelacionadas mas vamos falar então uma especificação de requisitos

ela deve ser compreensível ou seja a especificação ela precisa ser escrita de tal maneira que eu consiga entendê-la de forma Clara que eu consiga perceber Qual é o comportamento esperado do software pelas partes interessadas Ah uma especificação de requisitos ela precisa ser factível ou possível então isso é uma característica também de dos requisitos individualmente mas basicamente o conjunto de requisitos representado na especificação precisa ser passível de ser implementado levando em consideração restrições impostas ao projeto tais como cronograma custos limitações tecnológicas nível de expertise da equipe esse tipo de coisa e a um nível de risco

aceitável ainda uma boa especificação de requisitos ela precisa ser completa então a especificação de requisitos ela deve ser suficiente para descrever as funcionalidades características restrições fatores de qualidade sem que seja necessário consultar outra fonte de informação Ah todas as informações necessárias sobre os requisitos de software devem estar contidas na especificação Isso inclui as ostas para todas as entradas possíveis sejam elas válidas ou inválidas em todas as situações possíveis Nem sempre é possível conseguir representar todas as entradas mas é o ideal um glossário definindo a única interpretação aceita para cada termo técnico sigla unidade medida referências

a todos os diagramas figuras e tabelas contidos na especificação e a especificação ela deve também refletir todas as decisões de especificação que foram tomadas não conter pendências também não devem ser aceitos comentários de algo que ainda precisa ser melhorado que ainda precisa ser estabelecido que ainda precisa ser resolvido isso obviamente determina que o documento está incompleto não foi finalizado Ah uma boa especificação de requisitos ela precisa ser consistente então cada requisito da especificação precisa ser único e não estar em conflito ou se sobrepor a outro requisito do documento Ah ainda com relação à consistência as

unidades e sistemas de medida devem ser as mesmas em toda a especificação e a terminologia empregada como termos expressões e siglas devem ter um único significado e uma única interpretação em toda especificação aqui entra também a questão de ambiguidade se uma terminologia poder ser interpretada de mais de uma maneira Isso é um problema grave paraa especificação de requisitos Existem três tipos comuns de conflitos entre requisitos de acordo com summerville ah conflitos entre características de objetos do mundo real como formatos de relatórios formatos utilizando padrões diferentes com cabeçário diferentes cores padrões de interface Então e o

momento se usa uma cor e outro momento se usa outra e o momento se usa um padrão de interface no outro momento se usar outro isso é um conflito a inconsistência um outro conflito é o conflito lógico ou temporal entre as ações que pode acontecer de que um requisito diz que a ação a deve ser realizada antes da b e um outro requisito diz exatamente o contrário e tem o também ah o conflito de uso de termos diferentes para designar um mesmo objeto mundo real como por exemplo aviso e mensagem e ainda uma especificação de

requisitos ela precisa ser validá então deve ser possível dentro de um tempo e de um custo aceitável estabelecer se o conjunto de requisitos Eles foram efetivamente implementados de acordo com o que foi especificado se o resultado realmente satisfaz as necessidades das partes interessadas então para isso é preciso considerar diversas restrições estabelecidas tais como restrições de qualidade essencialmente atendimento a requisitos não funcionais requisitos não funcionais de produto Como foi como foram ensinados na aula anterior restrições orçamentárias restrições de cronograma restrições técnicas restrições legais restrições regulatórias e Essas duas últimas as legais regulatórias elas podem eh estar

contida totalmente ou em grande parte nas regras de negócio as regras de negócio foram explicadas no no vídeo anterior e basicamente estabelece normas que devem ser seguidas por uma ou todas as funcionalidades do software então nós terminamos mais essa aula sobre engenharia de requisitos eu espero que esse vídeo tenha sido útil se vocês gostaram do vídeo eu peço que vocês curtam esse vídeo compartilhem com quem possa ter interesse e se ainda não estão inscritos eu peço que vocês se inscrevam nesse canal eu agradeço a atenção de vocês nós nos vemos nas próximas aulas