Baixe o app para aproveitar ainda mais
Prévia do material em texto
ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 1 Gerência de Requisitos Visão Geral ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 2 Objetivos da Gerência de Requisitos • Estabelecer e manter um acordo com o cliente sobre os requisitos para um projeto de software • Saber com que requisitos "estamos trabalhando" • Garantir que "estamos trabalhando" com um conjunto de requisitos acordados e aprovados pelas várias partes • Saber "como estão" os requisitos: quais estão aprovados, propostos, implementados, verificados, etc. • Tratar as mudanças nos requisitos de forma adequada ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 3 A Gerência de Requisitos na Engenharia de Requisitos (fonte: Software Requirements, K.E.Wiegers) ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 4 Relação entre Desenvolvimento e Gerência de Requisitos (fonte: Software Requirements, K.E.Wiegers) ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 5 Âmbito da Gerência de Requisitos (fonte: Software Requirements, K.E.Wiegers) fortemente ligado à gerência de configurações ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 6 Atividades da Gerência de Requisitos • Definir baselines de requisitos • Revisar propostas de mudanças de requisitos e avaliar o impacto provável de cada mudança antes da sua aprovação. • Incorporar as mudanças de requisitos aprovadas ao escopo do projeto de forma controlada. • Adequar os planos do projeto aos requisitos correntes ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 7 Atividades da Gerência de Requisitos • Renegociar compromissos e objetivos do projeto a partir da análise do impacto estimado das mudanças de requisitos. • Acompanhar e controlar a situação dos requisitos e da sua evolução ao longo do projeto. • Manter a rastreabilidade dos requisitos associando-os aos demais produtos de trabalho do projeto. ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 8 Boas práticas de Gerência de Requisitos • Controlar efetivamente as mudanças de requisitos: – Definir um processo de controle de alterações • para propor, analisar e resolver alterações – Estabelecer um comitê de controle de alterações • para receber alterações propostas, avaliá-las, decidir quais devem ser aceitas ou rejeitadas, e definir prioridades de implementação ou releases em que as alterações são incorporadas. – Analisar o impacto das alterações • Usar informação de rastreabilidade e dependências para determinar que partes terão de ser modificadas • Identificar as tarefas necessárias • Estimar o esforço necessário ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 9 Boas práticas de Gerência de Requisitos • Estabelecer uma baseline e versões de controle (drafts) dos documentos de requisitos – Baseline – requisitos acordados para uma determinada release – Usar identificadores de versões únicos (baselines ou drafts) – Solução mais robusta: colocar o documento de requisitos sob controle de versões usando ferramentas apropriadas de gerência de configurações ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 10 Boas práticas de Gerência de Requisitos • Manter um histórico das alterações aos requisitos – o quê, quando, por quem, porquê • Seguir o estado de cada requisito • Medir a volatilidade dos requisitos – medir em cada semana (ou outro período de tempo) a taxa de alterações propostas e aprovadas em relação ao número total de requisitos numa baseline – taxas elevados são mal sinal ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 11 Boas práticas de gerência de requisitos • Criar uma matriz de rastreabilidade – forward: para elementos de design, implementação e teste – backward: para requisitos de mais alto nível – Importante para analisar impacto de alterações, verificar a implementação e o teste, etc. • Usar uma ferramenta de gerência de requisitos – para manter uma base de dados de requisitos, com vários atributos (estado, fonte, prioridade, etc.), seguir o estado dos requisitos, e definir ligações de rastreabilidade. ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 12 Controle de alterações dos requisitos: Exemplo de ciclo de vida de um pedido de alteração (fonte: Software Requirements, K.E.Wiegers) ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 13 Acompanhamento do estado dos requisitos: definição dos estados possíveis O código que implementa o requisito foi projetado, escrito e os testes de unidade foram feitos. O requisito foi associado aos artefatos de projeto e de código pertinentes Implementado O requisito foi analisado, seu impacto foi estimado, os stakeholders chave aprovaram o requisito e concordaram com sua incorporação ao escopo do projeto ou release Aprovado O requisito foi solicitado por uma fonte autorizadaProposto DefiniçãoStatus Status Sugeridos para os requisitos ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 14 Acompanhamento do estado dos requisitos: definição dos estados possíveis O requisito foi proposto mas sua incorporação a uma nova release do produto não foi aprovada. O motivo de sua rejeição e o responsável pela decisão de rejeitá-lo foram registrados. Rejeitado O requisito anteriormente aprovado foi excluído da baseline. O motivo da sua exclusão e o responsável pela decisão de excluí-lo foram registrados. Excluído O correto funcionamento do requisito foi observado em teste de integração do produto. O requisito foi associado aos casos de teste pertinentes. O requisito é considerado atendido. Verificado DefiniçãoStatus Status Sugeridos para os requisitos (continuação) ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 15 Acompanhamento do estado dos requisitos: estatísticas (fonte: Software Requirements, K.E.Wiegers) ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 16 (fonte: Software Requirements, K.E.Wiegers) Rastreabilidade dos requisitos ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 17 • Exemplos – Caliber RM – comercial – Borland – DOORS – comercial - IBM Rational – QSSrequireit – comercial – Quality Sistem & Software – RequisitePro – comercial – IBM Rational – OSRMT – open source Ferramentas de gerência de requisitos: ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 18 Ferramentas de gerência de requisitos: Integração com outras ferramentas (fonte: Software Requirements, K.E.Wiegers) ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 19 Gerência de Requisitos Mudanças em Requisitos ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 20 Fatores de Mudança • Erros, conflitos e inconsistências em requisitos – A medida que os requisitos vão sendo analisados e implementados, erros e inconsistências vão sendo descobertos e precisam ser corrigidos. – Os problemas podem ser descobertos durante as atividades de análise e validação ou durante o processo de desenvolvimento. • Evolução do conhecimento do cliente ou usuário sobre o sistema – A medida que os requisitos são desenvolvidos, clientes e usuários desenvolvem uma melhor compreensão do que eles realmente precisam de um sistema. ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 21 Fatores de Mudança • Problemas na implementação de requisitos – Durante o processo de desenvolvimento pode-se chegara conclusão que a implementação de um requisito pode custar caro demais ou levar tempo demais. • Mudanças na prioridade dos requisitos por parte do cliente – As prioridades dos clientes mudam durante o desenvolvimento do sistema como resultado das mudanças do ambiente de negócio, o aparecimento de novos competidores, mudanças de pessoal, etc ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 22 Fatores de Mudança • Mudanças ambientais do sistema – O ambiente em que o sistema deve ser instalado pode mudar forçando os requisitos a mudarem para manter a compatibilidade • Mudanças organizacionais – A organização para a qual o sistema é desenvolvido pode sofrer mudanças na sus estrutura ou nos seus processos resultando em mudanças de requisitos. ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 23 Estabilidade de Requisitos • Alguns requisitos são mais estáveis do que outros – Requisitos relacionados com a essência do sistema e seu domínio de aplicação são mais estáveis do que requisitos relacionados com um tipo de instanciação particular do sistema para um cliente específico. • Classificação de requisitos voláteis – Requisitos mutáveis – Requisitos emergentes – Requisitos consequentes – Requisitos de compatibilidade ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 24 Requisitos Voláteis • Requisitos mutáveis – São aqueles que mudam devido a mudanças no ambiente em que o sistema opera. – Exemplo: requisitos de um sistema que calcula impostos de acordo com leis e normas que podem sofrer mudanças • Requisitos emergentes – Requisitos que não podem ser completamente definidos quando o sistema é especificado mas que aparecem à medida que o sistema vai sendo desenvolvido. – Exemplo: requisitos de informação que aparecem á medida que os clientes e usuários percebem o potencial do sistema. ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 25 Requisitos Voláteis • Requisitos consequentes – São aqueles baseados em premissas sobre como o sistema será usado e que podem mudar quando se percebe que as premissas estavam erradas. – Exemplo: perfil do usuário real diferente do perfil do usuário assumido gera mudanças em requisitos de usabilidade • Requisitos de compatibilidade – São aqueles que dependem de equipamentos ou processos específicos e que devem evoluir quando os equipamentos ou processos mudam. – Exemplo: um sistema de controle em uma estação de energia pode ser modificado em função de um novo tipo de informação que deverá aparecer no console. ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 26 Identificação de Requisitos • Um pré-requisito para o gerenciamento de requisitos é a identificação única de cada requisito • Possíveis métodos de identificação – Numeração relacionada com a seção do documento de requisitos. – Numeração automática em um banco de dados de requisitos. – Identificação simbólica baseada no tipo de requisito (uso de mnemônico) ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 27 “Armazenamento” de Requisitos • Centrada em documento – Requisitos são mantidos em um documento de requisitos – Vantagens • Todos os requisitos são colocados juntos no mesmo documento • Acesso ao documento é relativamente fácil • Produção de novas versões também é simples – Desvantagens • Dificuldade de manter rastreabilidade • Facilidades para busca de informações é limitada pelas facilidades suportadas por um processador de texto • Controle de mudanças limitado • Limitações no armazenamento de múltiplas versões do mesmo requisito ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 28 “Armazenamento” de Requisitos • Centrada em banco de dados – Requisitos são mantidos em uma ferramenta de gerência de requisitos baseada em banco de dados. – Vantagens • Flexibilidade e eficiência em consultas • Ligações entre requisitos e outros componentes é facilitada • Pode permitir controle de versões mais apropriado – Desvantagem • Ambiente mais complexo que exige melhor capacitação ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 29 Informações sobre Requisitos • Os dados que idealmente devem constar em um banco de dados de requisitos são: – Projeto vinculado e seus dados – Identificador do requisito – Descrição do requisito – Situação do requisito – Data de inclusão do requisito – Modificações feitas no requisito • Data da solicitação de modificação • Descrição da modificação • Responsável pela solicitação ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 30 Informações sobre Requisitos • Os dados que idealmente devem constar em um banco de dados de requisitos são: (continuação) – Modificações feitas no requisito (continuação) • Data da análise da solicitação • Resultado da análise • Data da aprovação da modificação • Responsável pela aprovação – Fonte do requisito (origem) – Requisitos relacionados – Artefatos de projeto e implementação relacionados – Comentários ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 31 Políticas para gerência de mudanças de requisitos • Para assegurar uma abordagem consistente para a mudança de requisitos, as organizações devem definir um conjunto de políticas de gerenciamento de mudanças que cubram: – Processo de requisição de mudanças e as informações exigidas para processar cada requisição. – Processo usado para analisar o impacto e custos da mudança. – Os elementos que formarão o grupo responsável por analisar as mudanças e aprová-las ou rejeitá-las (Change Control Board) – O software que será usado para suportar o processo de mudança (caso algum seja adotado). ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 32 Processos de gerência de mudança de requisitos • O processo de gerenciamento de mudanças de requisitos pode ser pensado como um processo de três estágios: Análise do problema e especificação da mudança solicitada Análise da mudança e dos seus custos Implementação da mudança Problema identificado Requisitos Revisados ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 33 Processo de análise de mudança de requisitos • Seis atividades básicas: 1. A validade da mudança solicitada é checada. 2. Os requisitos que são diretamente afetados pela mudança são identificados. 3. As informações de rastreabilidade são usadas para encontrar requisitos dependentes ou artefatos do projeto que podem ser afetados pela mudança. 4. As modificações concretas que devem ser feitas nos requisitos são propostas e validadas com os solicitantes. 5. Os custos da mudança são estimados (tempo, esforço e recursos necessários). ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 34 Processo de análise de mudança de requisitos 6. Negociações são feitas com os clientes para verificar se os custos estimados da mudança são aceitáveis. – Caso os clientes considerem os custos da mudança muito altos, pode ser necessário voltar ao passo 4 para propor mudanças alternativas. – Pode acontecer também uma modificação da solicitação de mudança de modo que todo o processo tenha que ser repetido. ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 35 • Uma solicitação de mudança pode ser rejeitada em três momentos no processo de gerência de mudanças de requisitos: – Se a solicitação é considerada inválida; • O grupo de controle de mudança considerou que o solicitante não entendeu um requisito e propôs uma mudança considerada desnecessária/irrelevante.– Se algum efeito colateral da implementação da mudança for considerado inaceitável pelo usuário. – Se o custo da mudança propriamente dita for alto demais ou se a mudança levar tempo demais para ser feita. Rejeição de mudanças ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 36 Atores no processo de mudança • Vários atores podem participar do processo de mudança de requisitos em seus diferentes estágios. • Um formulário de controle de mudanças muitas vezes é usado para ajudar a controlar a situação do processo e a sua documentação. • Neste caso o formulário é preenchido gradativamente à medida que as diferentes atividades vão sendo executadas. ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 37 Formato da Requisição de Mudança • A organização, forma e conteúdo de uma requisição de mudança pode variar: – de acordo com as características da empresa; – de acordo com os processos adotados; – de acordo com a características do projeto; – de acordo com a tecnologia usada. ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 38 Formato da Requisição de Mudança • Alguns conteúdos são obrigatórios: – Documentação de resultados de cada estágio da análise da mudança; – Registro das datas em que cada atividade começa e termina; – Registro dos responsáveis por cada atividade; – Registro da situação corrente da requisição; – Espaço para comentários relevantes. ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 39 Formato da Requisição de Mudança • Alguns conteúdos são obrigatórios: – Documentação de resultados de cada estágio da análise da mudança; – Registro das datas em que cada atividade começa e termina; – Registro dos responsáveis por cada atividade; – Registro da situação corrente da requisição; – Espaço para comentários relevantes. ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 40 Formato da Requisição de Mudança • Alguns conteúdos são obrigatórios: – Documentação de resultados de cada estágio da análise da mudança; – Registro das datas em que cada atividade começa e termina; – Registro dos responsáveis por cada atividade; – Registro da situação corrente da requisição; – Espaço para comentários relevantes. ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 41 Ferramentas para gerência de mudanças • Uso recomendado no caso de sistemas com escopo grande e/ou alta complexidade. • É interessante que as ferramentas sejam baseadas em banco de dados. • Alternativas de ferramentas: – Ferramentas especializadas em gerenciamento de requisitos; – Ferramentas CASE que suportam gerência de configuração. ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 42 Ferramentas para gerência de mudanças • Uso recomendado no caso de sistemas com escopo grande e/ou alta complexidade. • É interessante que as ferramentas sejam baseadas em banco de dados. • Alternativas de ferramentas: – Ferramentas especializadas em gerenciamento de requisitos; – Ferramentas CASE que suportam gerência de configuração. ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 43 Ferramentas para gerência de mudanças • Capacidades recomendadas: – Formulários eletrônicos de requisição de mudanças que permitam uso compartilhado pelos diferentes atores no processo. – Capacidade de armazenar e gerenciar estes formulários. – Controle de fluxo de trabalho (workflow) – Notificação eletrônica de atividades completadas aos interessados. – Integração com base de dados dos requisitos, de preferência com controle de versões de requisitos associada às mudanças. ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 44 Ferramentas para gerência de mudanças • Problemas com ferramentas de requisitos: – A maioria das ferramentas definem um modelo de processo de mudança rígido ao qual a organização precisa se adaptar. – Ferramentas especializadas robustas em geral são caras e difíceis de integrar com outras ferramentas usadas. – Ferramentas de uso geral como processadores de texto e gerenciadores de planilhas tem capacidade limitada para lidar com o gerenciamento de mudanças. ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 45 Rastreabilidade • Conceito relacionado com o estabelecimento dos impactos de uma mudança no sistema como um todos. • Impacto de mudança de um requisito: – durante os processos iniciais de elicitação, análise e negociação pode afetar outros requisitos. – durante a implementação da solução técnica pode afetar outros requisitos, os produtos de trabalho do desenho da solução e de sua implementação. – após o sistema estar em operação podem afetar além dos itens anteriores a forma como os stakeholders lidam com o sistema. ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 46 Rastreabilidade • Para estabelecer os requisitos são necessárias: – Informações sobre as dependências entre requisitos – Explicações sobre os requisitos: motivação, origem, responsável. – Informações sobre o encaminhamento da solução que atende os requisitos (implementação dos requisitos). • O conjunto dos itens anteriores é conhecido como informações de rastreabilidade, ou simplesmente rastreabilidade de requisitos. • A rastreabilidade pode ser classificada em: – Rastreabilidade backward-from – Rastreabilidade forward-from – Rastreabilidade backward-to – Rastreabilidade forward-to ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 47 Rastreabilidade • Rastreabilidade backward-from: – Vínculos dos requisitos para suas fontes (origens) que podem ser pessoas, documentos, etc. • Rastreabilidade forward-from: – Vínculos dos requisitos para os componentes do desenho e implementação do software. • Rastreabilidade backward-to: – Vínculos dos componentes do desenho e implementação do software para os requisitos. • Rastreabilidade forward-from: – Vínculos de outros documentos (precedentes ao documento de requisitos) para os requisitos. ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 48 Rastreabilidade Plano de negócio Documentos de Requisitos Especificação de Desenho Forward-to Backward-from Backward-from Forward-from ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 49 Rastreabilidade • Nem sempre é possível coletar todas as informações de rastreabilidade: – Políticas de rastreabilidade devem ser elaboradas para definir quais são as informações essenciais/prioritárias. – Na prática, as informações que se mostram mais importantes são aquelas que vinculam requisitos com outros requisitos, casos de uso com requisitos e requisitos com artefatos de projeto e implementação. Contudo é desejável vincular os requisitos às suas fontes. ERSS, Gestão de Requisitos, João Pascoal Faria, 5 de Janeiro de 2005 50 Rastreabilidade • Matrizes de Rastreabilidade Exemplo: R2R4 R5, R6R2 R3, R4R1 Depende deRequisito
Compartilhar