Aula 13

Prévia do material em texto

Engenharia de Requisitos
Ementa
Introdução à Engenharia de Software;
Desenvolvimento Ágil;
Engenharia de Requisitos;
UML;
Tarefas da Engenharia de Requisitos
Concepção;
Levantamento;
Elaboração;
Negociação;
Especificação;
Validação;
Gestão;
Levantamento
Parece simples: pergunte ao cliente, aos usuários e demais interessados quais são os objetivos do sistema, o que precisa ser conseguido, como o sistema se encaixa nas necessidades do negócio e como o sistema será usado no dia-a-dia;
Porém, muitos problemas podem ser encontrados nessa simples conversa:
Problemas de escopo: o limite do sistema é mal definido ou o cliente especifica detalhes técnicos desnecessários que podem confundir, em vez de esclarecer os objetivos globais do sistema;
Levantamento
Problemas de entendimento: os clientes não estão completamente certos do que é necessário, têm pouca compreensão das capacidades e limitações de seu ambiente computacional, não têm pleno entendimento do domínio do problema, têm dificuldade de informar as necessidades ao engenheiro de software, omitem informações que acreditam ser óbvias, especificam requisitos conflitantes com as necessidades de outros clientes ou especificam requisitos ambíguos;
Problemas de volatilidade: os requisitos mudam ao longo do tempo;
Levantamento
Além desses problemas, outros podem surgir, como:
Pode ser difícil compreender e coletar informações quando existem muitos termos desconhecidos, manuais técnicos, etc.;
Pessoas que entendem o problema podem ser muito ocupadas e não ter tempo para levantar os requisitos e entender o sistema junto ao analista;
Políticas organizacionais pode influenciar nos requisitos de um sistema;
Levantamento
Porém, devemos ainda levar em conta diversos fatores como necessidades dos usuários e clientes, informações de domínio, sistemas existentes, regulamentos, leis, etc.;
Dois tipos de documentos são normalmente produzidos após o levantamento:
Documento de Requisitos: contém uma lista dos requisitos de usuário identificados;
Documento de Especificação de Requisitos: registra os requisitos de sistema e os vários diagramas resultantes do trabalho de análise;
Levantamento
Algumas características que devem ser coletadas segundo a natureza do produto a ser criado:
Funcionalidade: o que o software deverá fazer?
Interfaces externas: como o software interage com as pessoas, com o hardware, com outros sistemas e com outros produtos?
Desempenho: qual a velocidade de processamento, tempo de resposta e outros parâmetros de desempenho requeridos?
Outros atributos: quais as considerações sobre portabilidade, manutenibilidade e confiabilidade devem ser observadas?
Restrições: existem padrões e outros limites a serem obedecidos, como linguagem de programação, ambientes de operação, limites de recursos?
Técnicas para Levantamento de Requisitos
Dentre as principais técnicas para levantamento de requisitos, podemos citar:
Entrevistas;
Questionários;
Observação;
Análise de documentos;
Cenários;
Prototipagem;
Dinâmicas de Grupo;
Técnicas - Entrevistas
Técnica amplamente utilizada, que consiste em conversas direcionadas com um propósito específico e com formato “pergunta-resposta”;
Seu objetivo é descobrir problemas a serem tratados, levantar procedimentos importantes e saber a opinião e as expectativas do entrevistado sobre o sistema;
Técnicas - Questionários
O uso de questionários possibilita ao analista obter informações como postura, crenças, comportamentos e características de várias pessoas que serão afetadas pelo sistema;
Técnicas - Observação
Consiste em observar o comportamento e o ambiente dos indivíduos de vários níveis organizacionais;
Utilizando-se essa técnica, é possível capturar o que realmente é feito e qual tipo de suporte computacional é realmente necessário;
Ajuda a confirmar ou refutar informações obtidas com outras técnicas e ajuda a identificar tarefas que podem ser automatizadas e que não foram identificadas pelos interessados;
Técnicas - Análise de Documentos
Pela análise de documentos existentes na organização, analistas capturam informações e detalhes difíceis de conseguir por entrevista e observação;
Documentos revelam um histórico da organização e sua direção;
Técnicas - Cenários
Com o uso desta técnica, um cenário de interação entre o usuário final e o sistema é montado e o usuário simula sua interação com o sistema nesse cenário, explicando ao analista o que ele está fazendo e de que informações ele precisa para realizar a tarefa descrita no cenário;
O uso de cenários ajuda a entender requisitos, a expor o leque de possíveis interações e a revelar facilidades requeridas;
Técnicas - Prototipagem
Um protótipo é uma versão preliminar do sistema, muitas vezes não operacional e descartável, que é apresentada ao usuário para capturar informações específicas sobre seus requisitos de informação, observar reações iniciais e obter sugestões, inovações e informações para estabelecer prioridades e redirecionar planos;
Técnicas - Dinâmicas de grupo
Técnicas de levantamento de requisitos como Brainstorming e JAD (Joint Application Development) ajudam a levantar requisitos;
No Brainstormming, stakeholders engajam-se em uma discussão informal para rapidamente gerarem o maior número possível de ideias;
No JAD, interessados e analistas se reúnem para discutir problemas a serem solucionados e soluções possíveis;
A principal diferença entre JAD e Brainstorming é que, em JAD, tipicamente os objetivos do sistema já foram estabelecidos antes dos interessados participarem. Além disso, sessões JAD são normalmente bem estruturadas, com passos, ações e papéis de participantes definidos;
Elaboração
As informações obtidas na concepção e levantamento são expandidas e refinadas;
Enfoca o desenvolvimento de um modelo técnico refinado das funções, características e restrições do software;
É uma ação de modelagem de análise, composta de várias tarefas de modelagem e refinamento;
É guiada pela criação de refinamento de cenários do usuário que descrevem como o usuário final e outros atores vão interagir com o sistema;
Uma variedade de diagramas UML suplementares é produzida;
Elaboração
Nessa fase é obrigatória a presença de usuários chave para auxiliar o processo. O usuário chave é aquele indicado pelo cliente como a pessoa capacitada a definir requisitos do produto;
Se for um novo produto, usuários e desenvolvedores devem trabalhar em conjunto;
O acompanhamento do usuário auxilia o desenvolvedor a coletar informações válidas e o desenvolvedor ajuda o usuário a compreender melhor o processo onde o software será aplicado;
Esta fase se mistura a Análise de Requisitos em outras bibliografias;
Elaboração
Quando um software vai fazer parte de um sistema maior, é aconselhável que todas as equipes envolvidas no sistema participem:
Equipe de desenvolvimento de hardware;
Equipes de redes e banco de dados;
Especialistas da área da aplicação;
Pessoas de marketing, área administrativa e financeira;
Elaboração
Alguns limites devem ser impostos na elaboração dos requisitos:
Decisões sobre design e implementação;
Custos;
Cronogramas de entregas;
Relatórios requeridos;
Métodos requeridos de desenvolvimento;
Procedimentos de controle de qualidade;
Elaboração
Em essência, é uma atividade de modelagem;
A modelagem é dita conceitual, pois se preocupa com o domínio do problema e não com soluções técnicas para o mesmo;
Os modelos são elaborados para se obter uma compreensão maior acerca do sistema a ser desenvolvido e para especificá-lo;
Eles ajudam o analista a entender a informação, a função e o comportamento do sistema;
Tornam-se o ponto focal para a revisão e portanto, a chave para a determinação da consistência da especificação;
Elaboração
Tipicamente, duas perspectivas são consideradas:
Perspectiva estrutural: busca modelar os conceitos, propriedades e relações do domínio que são relevantes para o sistema em desenvolvimento;
Provê uma visão estática das informações que o sistema necessita tratar e, portanto, refere-se às representações que o sistema terá de prover para abstrair entidades domundo real;
Diagramas de classes são usados para modelar esta perspectiva;
Elaboração
Perspectiva comportamental: visa modelar o comportamento geral do sistema, de suas funcionalidades ou de uma entidade específica ao longo do tempo;
Provê uma visão do comportamento do sistema ou de uma parcela do sistema;
Diagramas de casos de uso, diagramas de atividades, diagramas de estados e diagramas de interação são usados para modelar essa visão;
Negociação
Normalmente, clientes pedem mais do que pode ser conseguido, levando em conta os recursos limitados do negócio. O engenheiro de requisitos precisa conciliar os conflitos através da negociação;
Clientes, usuários e outros interessados são solicitados a ordenar os requisitos e priorizá-los. Os riscos são identificados, estimativas de esforço são feitas e usadas para avaliar o impacto de cada requisito no custo do projeto e no prazo de entrega;
O objetivo é satisfazer a todas as partes da melhor forma possível;
Negociação
A maior parte da negociação é utilizada para resolver conflitos de requisitos;
Se discussões informais não forem suficientes para resolver os problemas, devem ser realizadas reuniões de negociação que envolvem:
Discussão: os requisitos que apresentam problemas são discutidos e os interessados presentes opinam sobre eles;
Priorização: requisitos são priorizados para identificar requisitos críticos e ajudar nas decisões e planejamento;
Concordância: soluções para os problemas são identificadas, mudanças são feitas e um acordo sobre o conjunto de requisitos é acertado;
Especificação
É o produto de trabalho final produzido pelo engenheiro de requisitos;
Serve como fundamento das atividades de engenharia de software que virão a seguir;
Descreve a função e o desempenho de um sistema baseado em computador e as restrições que governarão o seu desenvolvimento;
É uma atividade de registro e oficialização dos resultados da engenharia de requisitos;
É equivalente à fase de documentação em outras bibliografias;
Especificação
Uma boa especificação fornece muitos benefícios:
Facilita a comunicação dos requisitos;
Reduz o esforço de desenvolvimento, pois sua preparação força usuários e clientes a considerar os requisitos atentamente, evitando retrabalho nas fases posteriores;
Fornece uma base realística para estimativas;
Fornece uma base para verificação e validação;
Facilita a transferência do software para novos usuários e/ou máquinas;
Serve como base para futuras manutenções ou incremento de novas funcionalidades;
Especificação
Diretrizes para melhorar a estrutura e organização da documentação de requisitos:
Definir um modelo de documento para cada tipo de documento a ser considerado, definindo um padrão de estrutura para o documento;
Explicar como cada classe de leitores deve usar os diferentes tipos de documentos;
Incluir uma seção explicando por que o software é necessário e como irá contribuir para os objetivos gerais de negócio da organização;
Definir termos especializados em um glossário;
Organizar o layout do documento para facilitar a leitura;
Documentar também as regras do negócio e definir ligações entre os requisitos e as regras correspondentes;
Especificação
Auxiliar os leitores a encontrar a informação, incluindo recursos tais como listas de conteúdo e índices, e organizando os requisitos em capítulos, seções e subseções identificadas;
Identificar as fontes dos requisitos de modo a manter dados da origem do requisito, de modo que, quando alguma mudança for solicitada, seja possível saber com quem essa mudança deve ser discutida e avaliada;
Criar um identificador único para cada requisito, de modo a facilitar a rastreabilidade e o controle de mudanças;
Tornar o documento fácil de alterar;
Validação
Os produtos de trabalho resultantes são avaliados quanto à qualidade na validação;
Examina a especificação para garantir que todos os requisitos estão declarados sem ambiguidade, que as inconsistências, omissões e erros foram detectados e corrigidos e os produtos de trabalho estão de acordo com as normas do processo, projeto e produto;
Deve ser iniciada o quanto antes no processo de desenvolvimento de software, pois quanto mais tarde os defeitos são encontrados, maiores os custos associados à sua correção;
Qualidade dos Requisitos
Os requisitos devem servir para ajudar a garantir o mínimo de qualidade possível, portanto, devem ser:
Corretos;
Precisos;
Completos;
Consistentes;
Priorizados;
Verificáveis;
Modificáveis;
Rastreáveis;
Qualidade dos Requisitos - Corretos
Corretos: todo requisito presente realmente é um requisito do produto a ser construído;
O cuidado com a qualidade deve ser muito observada durante o processo de construção do produto;
A verificação da validade de um requisito é feita pela checagem da coerência. Verifique se tudo o que foi relatado é realmente necessário e vai funcionar como se está pensando;
Este processo é contínuo e deve ser realizado por todo o processo de construção. Nunca deixe para o final;
Qualidade dos Requisitos - Precisos
Precisos: a precisão visa o conceito de que para um requisito ser preciso deve-se ter uma única interpretação sobre suas características coletadas, não havendo ambiguidades;
Deve ser compreensível por todo seu público alvo e também ser suficiente para o desenho dos testes de aceitação;
Considera-se um requisito preciso quando esse já foi autorizado na fase de correção;
Revisões técnicas e uso de notações e ferramentas de análise ajudam a garantir a precisão dos requisitos;
Qualidade dos Requisitos - Completos
Completos: todo requisito presente reflete todas as decisões de especificação que foram tomadas;
O requisito pode ser considerado completo depois que passou pelas fases de correção e precisão e não deixou nenhuma pendência;
Uma especificação de requisitos completa possui todos os requisitos significativos relativos a funcionalidade, desempenho, restrições de desenho, atributos e interfaces externas;
Deve-se definir as respostas do software para todas as entradas possíveis, válidas e inválidas, em todas as situações existentes;
Qualidade dos Requisitos - Completos
Completos: possui um glossário de todos os termos técnicos e unidades de medida, assim como referência completas a todos os diagramas, figuras, tabelas, etc.;
Se o requisito possui tudo o que foi comentado até agora, ele está pronto para ser implementado;
Qualidade dos Requisitos - Consistentes
Consistentes: Não há conflito entre nenhum dos subconjuntos de requisitos presentes. Entre os conflitos possíveis estão:
Conflito entre características de objetos do mundo real, como por exemplo, formatos de relatórios ou cores de sinalização;
Conflito lógico ou temporal entre ações, como por exemplo, um requisito diz que a ação A deve ser realizada antes da ação B e outro requisito diz o contrário;
Uso de termos diferentes para o mesmo objeto do mundo real, como por exemplo, Lembretes x Mensagens;
Qualidade dos Requisitos - Priorizados
Priorizados: todo requisito presente é classificado de acordo com a sua importância, estabilidade e complexidade;
A priorização classifica os requisitos de acordo com um dos seguintes graus (outros graus podem existir):
Requisito essencial: requisito que se não atendido, o produto é inaceitável;
Requisito desejável: requisito que se atendido, aumenta o valor do produto;
Requisito opcional: requisito a ser cumprido se houver disponibilidade de prazo e orçamento;
Qualidade dos Requisitos - Verificáveis
Verificáveis: todo requisito presente é verificável;
Os requisitos de um produto são verificáveis se existir um processo finito, com custo compensador, que possa ser executado por uma pessoa ou máquina;
No geral, um requisito é verificável se esse não é ambíguo e pode ser realizado;
Qualidade dos Requisitos - Modificáveis
Modificáveis: sua estrutura e estilo permitem a mudança de qualquer requisito, de forma fácil, completa e consistente;
Esse processo é válido se os requisitos estipulados podem sofrer mudanças.
A modificabilidade geralmente requer:
Organização coerente, com índices e referências cruzadas;Ausência de redundâncias entre requisitos;
Definição separada de cada requisito;
Qualidade dos Requisitos - Rastreáveis
Rastreáveis: todo requisito presente permite a fácil determinação dos antecedentes e consequências de todos os requisitos;
Dois tipos de rastreabilidade devem ser observados:
Rastreabilidade para trás: deve ser possível localizar a origem de cada requisito. Deve-se saber o motivo da existência de cada requisito;
Rastreabilidade para frente: deve ser possível localizar quais os resultados do desenvolvimento que serão afetados por cada requisito;
Qualidade de Requisitos
A falta de qualidade ao se levantar os requisitos podem resultar em problemas como:
Produtos inconsistentes;
Produto final com custo maior do que o esperado;
Software instável e com altos custos de manutenção;
Clientes insatisfeitos;
Qualidade de Requisitos
Por outro lado, requisitos bem levantados e com qualidade trazem diversos benefícios:
Menor quantidade de defeitos nos requisitos;
Redução de retrabalho;
Desenvolvimento de menos características desnecessárias;
Diminuição dos custos;
Desenvolvimento mais rápido;
Menos problemas de comunicação;
Alterações de escopo reduzidas;
Estimativas de prazo e custo mais confiáveis;
Maior satisfação dos clientes e membros da equipe;
Gestão
É um conjunto de atividades que ajudam a equipe de projeto a identificar, controlar e rastrear requisitos e modificações de requisitos em qualquer época, à medida que o projeto prossegue;
Os requisitos são identificados e tabelas de rastreamento são desenvolvidas, para relacionar os requisitos identificados a um ou mais aspectos do sistema e de seu ambiente;
Gestão
Seus principais objetivos são:
Gerenciar alterações nos requisitos acordados;
Gerenciar relacionamentos entre requisitos;
Gerenciar dependências entre requisitos e outros documentos produzidos durante o processo de software;
Inclui as atividades de:
Controle de mudanças;
Controle de versão;
Acompanhamento do estado dos requisitos;
Rastreamento dos requisitos;