ENGENHARIA DE REQUISITOS Introdução a Computação e Engenharia de Software Profa. Cynthia Pinheiro Contextualização Estudo realizado pelo Standish Group em 1995, envolvendo 350 companhias e 8.000 projetos de software concluiu que: 16,2% dos projetos são finalizados com sucesso, respeitando o escopo, tempo e custo previstos 52,7% dos projetos são considerados problemáticos: não cobrem todo o escopo, extrapolou o custo ou foi entregue com atrasos. 31,1% dos projetos fracassam, sendo cancelados durante o desenvolvimento. 1
Contextualização Da análise feita sobre os fatores críticos para o sucesso, foi constatado que 3 de 10 fatores referiam-se a Requisitos: Requisitos incompletos Falta de envolvimento do usuário Mudança de Requisitos e Especificações Requisitos Conclusão: Um trabalho mais criterioso na área de Requisitos é fundamental! Definição de Requisitos: Um requisito é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar para atingir os seus objetivos As descrições das funções e restrições são os requisitos do sistema Um requisito é uma propriedade que o software deve exibir para resolver algum problema no mundo real 2
Requisitos Importância dos Requisitos: Estabelecer uma base de concordância entre o cliente e a equipe de desenvolvimento sobre o que o software fará; Fornecer uma referência para a validação do produto final; Reduzir o custo de desenvolvimento Atenção: Embora o requisito seja definido pelo cliente, nem sempre o que o cliente quer é o que o negócio precisa. Cabe à equipe de consultores identificar a real necessidade do negócio. Definição de : Termo usado para descrever as atividades relacionadas à investigação e definição de escopo de um sistema de software. Processo sistemático de desenvolvimento de requisitos através de um processo cooperativo de análise onde os resultados das observações são codificados em uma variedade de formatos e a acurácia das observações é constantemente verificada. Processo de descobrir, analisar, documentar e verificar as funções e restrições do sistema. 3
Principais objetivos da : Estabelecer uma visão comum entre o cliente e a equipe de projeto em relação aos requisitos que serão atendidos pelo projeto de software; Registrar e acompanhar requisitos ao longo de todo o processo de desenvolvimento; Documentar e controlar os requisitos alocados; Manter planos, artefatos e atividades de software consistentes com os requisitos alocados. Atividades da Produção de Requisitos: Levantamento Registro Verificação Validação 4
Levantamento de Requisitos: Relaciona-se à obtenção dos requisitos de software. Analistas e Engenheiros de software trabalham com clientes e usuários finais para descobrir o problema a ser resolvido, os serviços do sistema, o desempenho necessário, restrições de hardware e outras informações. Existem algumas técnicas que apoiam as atividades de levantamento de requisitos: Entrevista Prototipação etc. Entrevista: Esta técnica resume-se em conversas com o usuário (entrevistado) para levantar os requisitos do sistema. Pode ser decomposta nas seguintes atividades: Ler material de suporte; Estabelecer os objetivos da entrevista; Decidir quem entrevistar; Preparar o entrevistado; Decidir os tipos de questões e a sua estrutura. 5
Prototipação: É uma versão inicial de um sistema para experimentação. Permite aos utilizadores identificar os pontos fortes e fracos do sistema por ser algo concreto que pode ser criticado. Tipos de protótipos: Descartáveis : ajudam o levantamento e desenvolvimento dos requisitos e suportam os requisitos mais difíceis de perceber; Evolutivos: ajudam o desenvolvimento rápido de uma versão inicial do sistema e suportam os requisitos bem definidos e conhecidos. Registro de Requisitos: Uma vez identificados e negociados, os requisitos devem ser documentados para que possam servir de base para o restante do processo de desenvolvimento. Entre os muitos problemas que enfrentamos na documentação de requisitos está administrar o grande volume de informações gerado. Os requisitos são documentados em um nível apropriado de detalhe: é produzido um documento de especificação de requisitos, de forma que todos os interessados possam entendê-lo. 6
Verificação de Requisitos: Esta atividade examina a especificação do software, de forma a assegurar que todos os requisitos foram definidos sem ambiguidades, inconsistências ou omissões. Detecta e corrige possíveis problemas ainda na fase de definição dos requisitos. Faz-se uso de revisões e inspeções de requisitos, este último sendo mais rigoroso e bem definido. Validação de Requisitos: A validação representa a atividade em que obtemos o aceite do cliente sob determinado artefato. Esta atividade significa aprovar junto ao cliente os requisitos que foram especificados. Pode parecer simples, mas esta atividade pode ser bastante dificultada pelo cliente ou mesmo por um processo de validação inadequado utilizado pela empresa. 7
Gerência de Requisitos: Requisitos são, por natureza, voláteis. Diversos fatores contribuem para isso: Mudanças externas no ambiente (mudanças de legislação, no mercado, no posicionamento estratégico da empresa) Erros incorridos no processo de requisitos, entre outros. Gerência de Requisitos: Tais alterações em requisitos precisam ser conduzidas de forma ordenada para que não se perca controle sobre o prazo e o custo do desenvolvimento. Denominamos a atividade de administrar os requisitos ao longo do tempo de Gerenciamento de Requisitos. 8
Gerência de Requisitos: Controle de Mudanças Gerência de Configuração Rastreabilidade Gerência da Qualidade de Requisitos Controle de Mudanças: Sugestão de passos a serem seguidos para um processo de controle de mudança: 1. Checar validade da solicitação de mudança; 2. Identificar os requisitos diretamente afetados pela mudança; 3. Identificar dependências entre requisitos para buscar aqueles que foram afetados indiretamente; 4. Assegurar com o solicitante a mudança a ser realizada; 5. Estimar custos da mudança; 6. Obter acordo com o usuário sobre o custo da mudança. Após essa análise pode-se aceitar ou rejeitar a mudança, conforme os impactos e custos que ela pode ter no sistema. 9
Gerência de Configuração: A Gerência de Configuração de software define critérios que permitem realizar modificações mantendo-se a consistência e a integridade do software com as especificações, através de um controle sistemático. Item de configuração: cada um dos elementos de informação que são criados durante o desenvolvimento de um software, ou que para este desenvolvimento sejam necessários, identificados de maneira única e cuja evolução é passível de rastreamento. Gerência de Configuração: Em cada fase do processo de desenvolvimento, um conjunto bem definido de itens de configuração deve ser estabelecido. A este conjunto é dado o nome de baseline, onde é guardada uma foto dos artefatos criados até aquele momento. 10
Rastreabilidade: É a habilidade de se acompanhar a vida de um requisito em ambas as direções do processo de software e durante todo o seu ciclo de vida. Por exemplo: partindo de requisitos e chegando a projeto ou, partindo de projeto e chegando a requisitos. Para implementar a rastreabilidade, usualmente é confeccionado em conjunto com a especificação de requisitos um artefato chamado Matriz de Rastreabilidade, cujo objetivo é mapear requisitos entre si. Garantia da Qualidade de Requisitos: Visa garantir os seguintes critérios de qualidade: Correção: um documento de requisitos é considerado correto se todos os requisitos representam algo que deve estar presente no sistema. Não ambiguidade: requisitos só podem ser interpretado por todos os envolvidos em um projeto de uma única maneira. 11
Garantia da Qualidade de Requisitos: Completude: requisitos descrevem absolutamente todas as demandas de interesse dos usuários. Consistência: nenhum subconjunto de requisitos entra em conflito com os demais requisitos do sistema. Verificabilidade: se existe uma forma efetiva, em termos de tempo e custo, para que pessoas ou ferramentas verifiquem se um sistema cumpre um dado requisito. Modificabilidade: um requisito é modificável quando seu estilo e estrutura é tal que as alterações podem ser realizadas de forma simples e consistente com os demais requisitos. Bibliografia Esta aula foi retirada dos seguintes livros/artigos: Introdução à. Edição 01 Engenharia de Software Magazine, págs. 46-52. Sommerville, I. Engenharia de Software. Addison Wesley Longman Publishing Co., 9ª Edição, 2011. 12