,PSODQWDomRGHXP 3URFHVVR GH *HVWmR GH 5HTXLVLWRV VHJXLQGRR R &00, 0, Instrutora: Claudia Hazan claudinhah@yahoo.com Agenda Motivações para Engenharia de Requisitos (ER) Processo de Requisitos Visão Geral da Gestão de Requisitos Medições para Gestão de Requisitos Introdução ao Modelo CMMI Melhores Práticas para Gestão de Requisitos 2-1
Motivações para ER A indústria de software continua lidando com projetos mal sucedidos. O CHAOS Report de 2003 apresentou as seguintes estatísticas: 34% dos projetos são bem sucedidos; 15% dos projetos foram cancelados; 43% é o erro médio em relação ao orçamento do projeto daqueles que foram completados; 52% das características (requisitos não funcionais) e funcionalidades são entregues no produto. Problemas Os principais problemas que afetam os projetos de software não são tecnológicos. A principal preocupação da indústria referese à previsibilidade de prazo e de custo dos projetos. A causa destes raiz dos problemas está associada a Requisitos. Funcionalidades, Atributos da Qualidade Prazo Custo 2-2
Motivações para ER Dificuldades : Previsibilidade de Prazo Previsibilidade de Custo Requisitos ER e a Indústria Os dois principais fatores que contribuem para falhas de projetos de desenvolvimento de software em atender seus orçamentos e cronograma são problemas de requisitos. 1. Especificação de requisitos inadequada (4.5) 2. Mudanças em requisitos (4.3) SEI National Software Capacity Study, 1990 2-3
Mitos & Paradigmas - ER FORMALIZAÇÃO Antes do Processo de Gestão de Requisitos : Quem definiu isso? Vou tentar me lembrar... Depois do Processo de Gestão de Requisitos : Quem definiu isso? Foi a área de negócio X no dia 10 de Janeiro, segundo consta aqui nesta ata... Mitos & Paradigmas - ER GERENCIAMENTO Antes: Como pode o usuário estar bravo com a mudança de prazo se estamos fazendo tudo o que ele quer? Depois: Informe ao usuário que os novos requisitos acarretarão um desvio de 20 % no prazo e 5% no custo. 2-4
Motivações para ER mais números... 70 a 85% dos erros encontrados em sistemas de software podem ser rastreados para problemas de requisitos. (Barry Boehm, 1981) 70 % dos problemas de sistemas são de especificações, pois apenas 60 % das informações formais e informais estão documentadas. (Quality Assurance Institute) O custo relativo de corrigir problemas detectados após a fase de testes é de 50 a 100 vezes maior que o custo de correção de problemas detectados na fase de especificação de requisitos. (Shemer, 1987) Para Refletir... MUDANÇAS Será que precisamos mudar a maneira de desenvolver soluções de software e de relacionamento com nossos clientes? 2-5
Processo de Requisitos Requisitos Engenharia de Requisitos Gerenciamento de Requisitos Definem o que é solicitado ao sistema fazer e com quais limitações ele é requisitado a operar. Propõe métodos, técnicas e ferramentas que auxiliam o processo de descoberta, documentação e gestão dos requisitos que o software deve atender. Gerenciar as mudanças que ocorrem nos requisitos já acordados; Gerenciar relacionamentos entre os requisitos; Gerenciar as dependências entre os documentos de requisitos e outros documentos produzidos durante o processo de engenharia de software; Processo de Requisitos Condição ou capacitação que deve ser contemplada pelo software, necessitada pelo usuário para resolver um problema ou alcançar um objetivo O conjunto de todos os requisitos formam a base para o posterior desenvolvimento do sistema [IEEE] 2-6
Processo de Requisitos Tipos de Requisitos Documento de Requisitos Requisitos Funcionais Requisitos Não-Funcionais Descreve os serviços providos. Define limitações no sistema e no processo de desenvolvimento Processo de Requisitos Requisitos Funcionais Os requisitos funcionais são a descrição das diversas operações que clientes e usuários querem, ou precisam, que sejam realizadas pelo sistema. Exemplos: - o software deve possibilitar o cálculo dos gastos diários, semanais, mensais e anuais com pessoal; - o software deve emitir relatórios de compras a cada quinze dias; - os usuários devem poder obter o número de aprovações, reprovações e trancamentos em todas as disciplinas por um determinado período de tempo; 2-7
Processo de Requisitos Requisitos Não Funcionais Os Requisitos Não Funcionais (RNFs) são restrições ou atributos de qualidade de um software ou de um processo de desenvolvimento de software. É necessário que estes requisitos sejam considerados na fase inicial do processo de desenvolvimento de software. Exemplos: - a base de dados deve ser protegida, para acesso, apenas, de usuários autorizados; - o tempo de resposta não deve ultrapassar 30 segundos; - o software deve ser operacionalizado no sistema Linux; Requisitos Não Funcionais 2-8
Processo de Requisitos Requisitos não Funcionais - São críticos para o sucesso de sistemas de software; diretamente relacionados com a satisfação dos usuários. O sistema executa todas as funcionalidades desejadas, mas é muito difícil de usar e demora muito para executar operações simples! Processo de Requisitos Tipos de Requisitos Não Funcionais Acurácia Precisão Confiabilidade Desempenho Rentabilidade Manutenibilidade Disponibilidade Recuperabilidade Segurança Inversos Não Técnicos Restrições de Projeto e Implementação Requisitos Gerenciais Usabilidade Critérios de Aceite 2-9
Processo de Requisitos Definições para Engenharia de Requisitos Definição Genérica: O processo de Engenharia de Requisitos é um conjunto estruturado de atividades o qual são seguidas para derivar, validar e manter um documento de requisitos de um sistema. Estabelecer o que o cliente requer de um sistema de software. Definição da IEEE: Processo de aquisição, refinamento e verificação das necessidades do cliente, com o objetivo de obter uma especificação correta e completa dos requisitos. Processo de Requisitos O primeiro passo antes de se fazer qualquer coisa na vida é saber e compreender o que deve ser feito, sendo que este passo é chamado de Engenharia de Requisitos. O produto obtido deste processo denomina-se requisitos. A ER que constitui de uma seqüência de descobertas e refinamentos e documentação de requisitos é essencial para o sucesso do projeto de software. A Engenharia de Requisitos organiza a base para a construção do software. 2-10
Processo de Requisitos O objetivo principal é desenvolver produtos de qualidade que satisfaçam às reais necessidades dos clientes dentro do prazo e do orçamento. Para refletir As conseqüências da falta de um processo de requisitos efetivo têm sido a produção de documentos de requisitos que não refletem as necessidades reais dos clientes. Os requisitos constituem a base para o desenvolvimento do projeto de software. Então, requisitos de má qualidade geram produtos de software com qualidade inadequada. A análise final da qualidade de um software é determinada pelo atendimento aos requisitos dos stakeholders. O documento de requisitos de software constitui a base para as estimativas de tamanho, esforço, cronograma, e custo. Assim, quando as estimativas de tamanho, prazo e custo são geradas a partir de requisitos incompletos, omissos ou inconsistentes, estas não possuirão acurácia adequada. 2-11
Processo de Requisitos Elicitação Modelagem Análise G e r ê n c i a Validação Verificação Processo de Requisitos Elicitação de Requisitos Elicitação de requisitos é o processo responsável por descobrir informações, compreender os fatos descobertos e adquirir conhecimentos. Elicitação de requisitos refere-se ao processo de extração de informação sobre a funcionalidade requisitada e outras propriedades do sistema de diversas fontes, incluindo usuários potenciais. 2-12
Processo de Requisitos Problemas na Elicitação de Requisitos Conhecimento parcial ou incorreto do domínio da aplicação. Diferentes pontos de vista dos usuários Requisitos oscilantes (variam com o tempo devido a alterações internas ou externas a empresa) e conflitantes (possuem inconsistências) Falhas na comunicação e na coordenação de atividades. Falta de documentação formal (memória e anotações feitas em rascunho) Pressões de tempo Culturas distintas dificultam a comunicação (diferenças culturais Engenheiros de Software e usuários) Processo de Requisitos FAZ FAZ COLETA DE FATOS USA USA USA FAZ IDENTIFIC. DE FONTES DE INFO. PESSOAL DEPENDE DE COMUNICAÇÃO MÉTODOS FERRAMENTAS PONTOS DE VISTA Notas de Aula, Julio Leite (PUC-Rio) 2-13
Processo de Requisitos Modelagem de Requisitos A modelagem consiste da representação e da organização do conhecimento adquirido durante a fase de elicitação de requisitos. Os modelos utilizados para representação devem ter uma semântica bem definida. Os modelos de requisitos facilitam a comunicação entre os desenvolvedores do projeto de software. Processo de Requisitos Exemplos de Modelos de Requisitos Diagramas de Fluxo de Dados 2-14
Processo de Requisitos Exemplos de Modelos de Requisitos Casos de Uso Abrir Conta Cliente Depositar Fundos Retirar Fundos Fechar Conta Processo de Requisitos Técnicas para Elicitação de Requisitos Cenários restrição restrição exceção restrição CONTEXTO 1 CENÁRIO 1 1 EPISÓDIO 1 (0,1) 1 tem expresso através N 1 1 tem 1 engatilha N RECURSO N tem envolve satisfaz 1 OBJETIVO ATOR N 2-15
Processo de Requisitos FAZ FAZ ORGANIZAÇÃO USA USA USA FAZ ARMAZENAMENTO PESSOAL DEPENDE DE REPRESENTAÇÃO MÉTODOS FERRAMENTAS PONTOS DE VISTA Notas de Aula, Julio Leite (PUC-Rio) Processo de Requisitos Análise de Requisitos Antes de efetuar a análise precisa-se identificar as partes do modelo. Essa identificação relaciona-se tanto com a modelagem (armazenamento, organização) como com a elicitação (identificação das fontes de informação). As principais atividades da análise são: Verificação Validação 2-16
Processo de Requisitos Verificação & Validação (V&V) Verificação Nós estamos construindo certo o produto? (em relação a artefatos) Validação Nós estamos construindo o produto certo? (em relação a intenção) ENTRE MODELOS ENTRE O UdI E UM MODELO Processo de Requisitos FAZ FAZ IDENTIFICAÇÃO DE PARTES USA USA USA FAZ VALIDAÇÃO PESSOAL DEPENDE DE VERIFICAÇÃO MÉTODOS FERRAMENTAS PONTOS DE VISTA Notas de Aula, Julio Leite (PUC-Rio) 2-17
Processo de Requisitos Gerência de Requisitos Mudanças nos requisitos ocorrem durante todo o tempo; Mesmo durante a elicitação, modelagem e/ou análise, eles podem estar mudando; As mudanças nos requisitos são inevitáveis, e não significa que o processo de engenharia de requisitos adotado tenha sido falho; Processo de Requisitos Gerência de Requisitos Mudanças resultam de uma combinação de fatores, tais como: Inconsistências, conflitos e falhas nos requisitos; Evolução do conhecimento do usuário sobre o sistema em desenvolvimento; Problemas de custos, cronogramas ou técnicos; Mudanças na prioridade do cliente; Mudanças ambientais (ex :legislação); Mudanças organizacionais. 2-18
Processo de Requisitos Gerência de Requisitos Elicitação Modelagem Análise G e r ê n c i a A Gerência de Requisitos é um processo que se desenvolve em paralelo à Elicitação, Modelagem e Análise de Requisitos. Validação Verificação Visão Geral da Gestão de Requisitos Os requisitos tendem a ser extremamente voláteis. Muitas vezes o usuário não tem uma idéia muito clara do que quer do início do projeto. Esta é uma das principais razões pelas quais o produto final demora muito para ficar pronto, além de quase sempre não atender o usuário. Novos requisitos surgem e há alterações nos requisitos em todos os estágios do processo de desenvolvimento, causando problemas para os desenvolvedores. Por isso, os requisitos devem ser documentados e controlados. 2-19
Visão Geral da Gestão de Requisitos Objetivos da Gestão de Requisitos As principais preocupações da gestão de requisitos são as seguintes: * Gerenciar mudanças nos requisitos acordados; * Gerenciar os relacionamentos entre os requisitos; * Gerenciar as dependências entre o documento de requisitos e outros documentos produzidos ao longo do processo. Visão Geral da Gestão de Requisitos A Gestão de Requisitos trata dois aspectos importantes: Estabilidade Rastreabilidade 2-20
Visão Geral da Gestão de Requisitos Estabilidade de Requisitos A indústria tem mostrado que a instabilidade dos requisitos contribui fortemente para o risco de Pressão Excessiva do Cronograma e não aceitação do produto final. Mudanças em requisitos ocorrem enquanto os requisitos estão sendo elicitados, analisados e após o sistema ter entrado em produção. Visão Geral da Gestão de Requisitos Fator de mudança Descrição Erros em requisitos, Conforme os requisitos são analisados e implementados, erros e conflitos e inconsistências surgem e devem ser corrigidas. inconsistências Evolução do Conforme os requisitos são desenvolvidos, clientes e usuários conhecimento do cliente finais desenvolvem uma melhor compreensão do que desejam. Problemas podem ser encontrados na implementação dos Problemas técnicos, de requisitos. Pode ser muito caro ou tomar muito tempo custo ou cronograma implementar certos requisitos. Mudanças nas prioridades do cliente Mudanças de ambiente Mudanças organizacionais Estabilidade de Requisitos As prioridades do cliente podem mudar durante o desenvolvimento do sistema como resultado de mudanças no ambiente de negócios. O ambiente no qual o sistema será instalado pode mudar de tal forma que os requisitos tenham que mudar para manter compatibilidade. A Organização que pretende usar o sistema pode mudar sua estrutura e processos, resultando em novos requisitos de sistema. 2-21
Visão Geral da Gestão de Requisitos Estabilidade de Requisitos Embora a mudança seja inevitável, é usual o caso em que alguns requisitos são mais estáveis que outros. Requisitos estáveis são concebidos com a essência de um sistema e domínio da aplicação, e mudam mais lentamente que requisitos voláteis. Os requisitos voláteis são específicos para a instanciação de um sistema em um ambiente particular e para um cliente particular. Visão Geral da Gestão de Requisitos Estabilidade de Requisitos É uma boa prática de gerenciamento de requisitos tentar antecipar mudanças de requisitos, o que envolve classificar os requisitos para identificar os mais voláteis e predizer possíveis mudanças. Isto fornece informação aos desenvolvedores do sistema e pode ajudá-los a projetar o sistema de tal forma que os requisitos sejam implementados com (relativa) independência de componentes, para tentar minimizar a influência destas mudanças no restante do sistema. 2-22
Visão Geral da Gestão de Requisitos Rastreabilidade de Requisitos Um requisito é rastreável se for possível identificar quem solicitou o requisito, porque o requisito existe, quais os requisitos relacionados e como os requisitos se relacionam a outras informações como design, implementações e documentos do usuário. O Rastreamento de Requisitos é um fator importante para prover com integridade uma documentação completa dos requisitos, assim como ajudar no processo de gestão de mudanças nesses requisitos. Visão Geral da Gestão de Requisitos Rastreabilidade de Requisitos Existem dois tipos de rastreamento de requisitos: Pré-rastreamento está relacionado a alguns aspectos da vida do requisito antes da sua inclusão na especificação dos requisitos. Pós-rastreamento está relacionado a alguns aspectos da vida do requisito após a sua inclusão na especificação dos requisitos. 2-23
Visão Geral da Gestão de Requisitos Rastreabilidade de Requisitos Pré Rastreabilidadade - ER Pós Rastreabilidadade - ER Especificação de Requisitos (S0) (S1) (Sn) Visão Geral da Gestão de Requisitos Rastreabilidade de Requisitos O processo de desenvolvimento deve produzir requisitos rastreáveis, isto é capazes de serem rastreados para a sua origem. Assim, a rastreabilidade de requisitos pode ser vista como a habilidade de acompanhar e descrever a vida de um requisito, em ambas as direções; prérastreabilidade documenta a movimentação e o contexto a partir do qual emergem os requisitos (origem dos requisitos); pós-rastreabilidade está relacionada ao refinamento, desdobramento e uso do requisito, vinculando os requisitos ao design do sistema e a sua implementação. 2-24
Visão Geral da Gestão de Requisitos Matriz de Rastreabilidade Visão Geral da Gestão de Requisitos Rastreabilidade e Relacionamento 2-25
Visão Geral da Gestão de Requisitos Tabela de Relacionamento/Rastreabilidade Depende de R1 R2 R3 R4 R5 R6 R1 X X R2 X X R3 X X R4 X R5 X R6 Onde: Linha: é dependente de Coluna: depende de Visão Geral da Gestão de Requisitos Lista de Relacionamento/Rastreabilidade R1 R2 R3 R4 R5 Requisito R3, R4 R5, R6 R4, R5 R2 R6 Depende de Vantagem: é mais compacta que a tabela Desvantagem: necessidade de duas listas lista depende de e lista é dependente de 2-26
Visão Geral da Gestão de Requisitos Ferramentas As ferramentas de gestão de requisitos podem fornecer facilidades como: Um sistema de banco de dados para armazenamento de requisitos ; Análise de documento e facilidades de geração para ajudar a construir um banco de dados de requisitos e auxiliar na criação dos documentos de requisitos ; Facilidades de gerenciamento de mudanças que ajudam a garantir que as mudanças foram avaliadas e tratadas corretamente; Facilidades de rastreabilidade que auxiliam os engenheiros de requisitos a encontrar dependências entre requisitos Visão Geral da Gestão de Requisitos Política de Rastreabilidade de Requisitos A política de rastreabilidade, dentre outras informações deve incluir: A informação de rastreabilidade que será mantida; As técnicas e ferramentas, como as matrizes de rastreabilidade, que serão utilizadas para manter a rastreabilidade; Uma descrição dos pontos em que a informação de rastreabilidade deverá ser coletada durante a execução dos processos de engenharia de requisitos e desenvolvimento de sistemas. Os papéis das pessoas responsáveis pela manutenção da informação de rastreabilidade também devem ser definidos; O processo usado para garantir que a informação de rastreabilidade seja atualizada depois que a alteração for realizada. 2-27
Visão Geral da Gestão de Requisitos Gerenciamento de Alterações de Requisitos O gerenciamento de alterações envolve métodos, procedimentos e padrões que são usados para gerenciar as alterações dos requisitos do sistema. Este gerenciamento garante que sejam coletadas todas as informações relacionadas aos envolvidos na alteração, além de ser realizada, para cada alteração proposta, uma avaliação de custos e benefícios. Esta avaliação é denominada de Análise de Impacto da Mudança. Visão Geral da Gestão de Requisitos Gerenciamento de Alterações de Requisitos A Organização deve definir uma política de gestão de requisitos, considerando, dentre outros, os seguintes aspectos sobre o gerenciamento das alterações: O processo de solicitação de alteração e a informação requerida para processar cada solicitação de alteração; O processo usado para analisar o impacto e custos da alteração e informações de rastreabilidade associadas; O grupo da organização que considera formalmente as solicitações de alteração. A ferramenta de suporte (caso exista) para o controle do processo de alterações. 2-28
Visão Geral da Gestão de Requisitos Gerenciamento de Alterações de Requisitos O processo de gerenciamento de alterações de requisitos consiste em um conjunto de atividades para documentação, relato, análise, avaliação de custo e implementação das alterações no conjunto de requisitos do sistema. Problema Identificado Análise do problema e Especificação da alteração( 1 ) Análise e Avaliação de custo da solução ( 2 ) Implementação da alteração ( 3 ) Requisitos Revisados Visão Geral da Gestão de Requisitos Gerenciamento de Alterações de Requisitos Análise e Avaliação do Custo da Solução 2-29
Visão Geral da Gestão de Requisitos Gerenciamento de Alterações de Requisitos Análise e Avaliação da Alteração A solicitação de alteração pode ser rejeitada: Se a solicitação de alteração for inválida: isto normalmente ocorre quando o cliente tem uma interpretação incorreta sobre alguns dos requisitos e propõe uma alteração que não é necessária; Se a solicitação de alteração tem como conseqüência alterações que sejam inaceitáveis pelos stakeholders. Se o custo de implementação da alteração for muito alto ou demorar muito. Visão Geral da Gestão de Requisitos Gerenciamento de Alterações de Requisitos Uma parte crítica do gerenciamento de alterações é a avaliação do impacto da mudança no resto do sistema. Se a mudança é proposta enquanto os requisitos estão sendo desenvolvidos, deve ser identificado como a alteração afeta outros requisitos. Se a alteração é proposta enquanto o sistema está em implementação, o impacto de alteração envolve verificar como a alteração afeta os requisitos, o design e implementação. Se a alteração é proposta depois que o sistema foi colocado em operação, deve haver também uma verificação adicional a fim de identificar como todos os stakeholders podem ser afetados pela alteração. 2-30
Visão Geral da Gestão de Requisitos - Exercício 1 Descreva como as medições de requisitos podem auxiliar no planejamento e acompanhamento de projetos de software. Por que as medições de requisitos podem ajudar na justificativa de desvio de cronograma gerados por mudanças de requisitos? Medições para Gestão de Requisitos Definição de Indicadores São formas de representação quantificáveis de características de produtos e processos utilizados para acompanhar e melhorar os resultados ao longo do tempo 2-31
Medições para Gestão de Requisitos Indicadores de Estabilidade Requisitos estáveis e sem ambigüidade constituem a base para construção do software Medições para Gestão de Requisitos GOAL: Controlar as Mudanças nos Requisitos QUESTIONS Qual % de novos requisitos no período? Qual o % de requisitos alterados no período? Qual o % de requisitos excluídos no período? METRICS nº de requisitos novos/nº requisitos alocados requisitos novos (PFs)/ requisitos alocados (PFs) nº de requisitos alterados/nº requisitos alocados requisitos alterados (PF)/ requisitos alocados(pf) nº de requisitos excluídos/nº requisitos alocados requisitos excluídos (PF)/requisitos alocados(pf) 2-32
Medições para Gestão de Requisitos Indicador de Mudanças de Requisitos Afere o grau de mudanças para a baseline de requisitos Fornece o impacto da mudança no tamanho da baseline sob o ponto de vista funcional Utiliza a métrica de Pontos de Função para normalização IMR = (RA + RI + RE)/RB Medições para Gestão de Requisitos 2-33
Medições para Gestão de Requisitos Indicadores de Rastreabilidade Espaço do Problema Rastreabilidade Necessidades Propriedades RFs & RNFs Documento de Requisitos de Software Problema Espaço da Solução Produto a ser construído Procedimentos de Teste Design Documentos do usuário Medições para Gestão de Requisitos GOAL: Controlar a aderência dos artefatos com os requisitos deles nos vários níveis de especificação do produto QUESTIONS Qual % de requisitos rastreáveis até sua origem? Qual o percentual de requisitos rastreáveis para o próximo nível? Qual o impacto operacional dos req. modificados? METRICS nº de requisitos rastreáveis para a origem nº requisitos rastreáveis para a sua origem / nº total de requisitos alocados nº de requisitos rastreáveis para a próxima atividade nº requisitos rastreáveis a próxima atividade / nº total de requisitos alocados nº de requisitos impactados/ nº requisitos alocados requisitos impactados (PF)/ requisitos alocados(pf) 2-34
Medições para Gestão de Requisitos Indicador de Requisitos Rastreáveis Fornece um indicativo dos requisitos rastreáveis contidos na baseline de requisitos de software Mede o % de requisitos que podem ser rastreados entre dois níveis adjacentes de especificação Fonte de Dados: Matriz de Rastreabilidade IRR = RR/RA Medições para Gestão de Requisitos Matriz de Rastreabilidade 2-35
Medições para Gestão de Requisitos Introdução ao Modelo CMMI Modelo CMMI Nível de Maturidade 1 Inicial 2 Gerenciado 3 Definido Representação por estágios 4 Gerenciado Quantitativamente 5 Otimização 2-36
Introdução ao Modelo CMMI Áreas de Processo (PA) Gerência de Requisitos Planejamento do Projeto Monitoração e Controle do Projeto Gerência de Acordos com Fornecedores Medição e Análise Garantia da Qualidade do Processo e do Produto Gerência de Configuração Introdução ao Modelo CMMI Estrutura Níveis de Maturidade Área de Processo 1 Área de Processo 2 Área de Processo n Objetivos Específicos Objetivos Genéricos Características Comuns Compromisso para realizar Habilidade para executar Diretrizes para implementação Verificação da implementação Práticas Específicas Práticas Genéricas 2-37
A Gestão de Requisitos visa estabelecer um entendimento comum entre o cliente e o fornecedor quanto aos requisitos que serão atendidos no projeto de software. A Gestão de Requisitos é um processo para estabelecimento e manutenção de um acordo formal entre clientes/usuários e a equipe do projeto sobre os requisitos e suas mudanças ao longo do projeto. O Objetivo Comunidade de Clientes/Usuários Produto a ser construído Verificação /Validação de Requisitos Objetivo Substituto Requisitos 2-38
O propósito da Gestão de Requisitos é gerenciar os requisitos dos produtos do projeto e componentes do produto e identificar inconsistências entre os requisitos e o plano do projeto e artefatos. Acordo Comum: Os requisitos são revisados com os fornecedores de requisitos para resolver questões para evitar o não entendimento. Isto ocorre antes que os requisitos sejam incorporados ao plano do projeto. Rastreabilidade: Deve-se documentar as mudanças de requisitos e manter a rastreabilidade bidirecional entre requisitos - todos produtos e componente do produto requisitos. Objetivos Específicos - Specific Goals (SG) & Práticas Específicas Specific Practices (SP) SG 1 Gerenciar Requisitos SP 1.1 Obter um Entendimento dos Requisitos SP 1.2 Obter Comprometimento com Requisitos SP 1.3 Gerenciar Mudanças de Requisitos SP 1.4 Manter Rastreabilidade Bidirecional de Requisitos SP 1.5 Identificar Inconsistências entre Artefatos do Projeto e Requisitos 2-39
Objetivos Genéricos - Generic Goals (GG) & Práticas Genéricas Generic Practices (GP) GG 2 Institucionalizar o Processo Gerenciado GP 2.1 (CO 1) Estabelecer uma Política Organizacional GP 2.2 (AB1) Planejar o Processo GP 2.3 (AB2) Fornecer Recursos GP 2.4 (AB3) Associar Responsabilidades GP 2.5 (AB 4) Treinar Pessoas GP 2.6 (DI1) Gerenciar Configurações GP 2.7 (DI2) Identificar e Envolver Stakeholders GP 2.8 (DI3) Monitorar e Controlar o Processo GP 2.9 (VI1) Avaliar Objetivamente a Aderência GP 2.10 (VI2) Revisar Status com a Alta-Administração Objetivos Genéricos - Generic Goals (GG) & Práticas Genéricas Generic Practices (GP) GG 3 Institucionalizar o Processo Definido GP 3.1 Estabelecer um Processo Definido GP 3.2 Coletar Informação de Melhoria 2-40
SG 1 Gerenciar Requisitos Requisitos são gerenciados e inconsistências com planos de projeto e outros artefatos são identificadas. O projeto deve manter um conjunto de requisitos atual e aprovado, fazendo o seguinte: Gerenciando todas as mudanças de requisitos; Mantendo o relacionamento entre os requisitos, os planos de projetos e outros artefatos; Identificando inconsistências entre os requisitos, os planos de projetos e outros artefatos; Implementando ações corretivas. SP 1.1 Obter um entendimento dos Requisitos Desenvolver um entendimento do significado dos requisitos com os fornecedores de requisitos Note que é fundamental: - Estabelecer critérios para designar canais apropriados ou fontes oficiais dos quais são recebidos os requisitos. - Conduzir análise dos requisitos com o fornecedor de requisitos para garantir um entendimento compatível e compartilhado do significado dos requisitos. O resultado desta análise e diálogo é um conjunto de requisitos acordado. 2-41
SP 1.1 Obter um entendimento dos Requisitos Artefatos Típicos Lista de Critérios para identificar fornecedores de requisitos apropriados Critérios para avaliação e aceite de requisitos Resultados de análise utilizando os critérios Um conjunto de requisitos acordados SP 1.1 Obter um entendimento dos Requisitos Subpráticas Estabelecer critérios para identificar fornecedores de requisitos apropriados; Estabelecer critérios objetivos para o aceite de requisitos; A falta de um critério de aceite pode resultar em verificação inadequada, retrabalho custoso e/ou rejeição do cliente. Analisar os requisitos para garantir que estes satisfaçam os critérios estabelecidos; Buscar um entendimento dos requisitos com os fornecedores de requisitos e obter o compromisso dos participantes do projeto com os requisitos acordados. 2-42
SP 1.2 Obter Comprometimento com Requisitos Obter o comprometimento dos participantes do projeto com os requisitos acordados. Esta prática lida com acordo e compromissos entre aqueles que executam as atividades necessárias para implementar os requisitos. Os requisitos evoluem ao longo do projeto. Assim, deve-se garantir que as equipes do projeto se comprometam com os requisitos aprovados atuais e as mudanças resultantes nos planos de projeto, atividades e artefatos. SP 1.2 Obter Comprometimento com Requisitos Artefatos Típicos Avaliações de impacto de requisitos Comprometimento documentado com os requisitos e com as mudanças de requisitos 2-43
SP 1.2 Obter Comprometimento com Requisitos Subpráticas Avaliar o impacto dos requisitos nos compromissos existentes; Negociar e registrar os compromissos. As mudanças nos compromissos existentes devem ser negociadas pelos participantes do projeto antes que estes se comprometam com os requisitos ou mudanças de requisitos. SP 1.3 Gerenciar Mudanças de Requisitos Gerenciar as mudanças de requisitos, conforme estes evoluam no decorrer do projeto. É fundamental gerenciar mudanças de requisitos com eficiência e eficácia. Para uma análise de impacto das mudanças, é necessário que a fonte de cada requisito seja conhecida e a razão para cada mudança documentada. 2-44
SP 1.3 Gerenciar Mudanças de Requisitos Artefatos Típicos Status dos Requisitos Base de Dados de Requisitos (baselines) Base de Dados com Decisões de Requisitos SP 1.3 Gerenciar Mudanças de Requisitos Subpráticas Capturar todos os requisitos e mudanças de requisitos do projeto; Manter o histórico das mudanças de requisitos com a razão das mudanças. A manutenção do histórico das mudanças ajuda a acompanhar requisitos voláteis; Avaliar o impacto das mudanças de requisitos com a visão dos stakeholders relevantes; Tornar os dados dos requisitos e das mudanças disponíveis para o projeto. 2-45
SP 1.4 Manter Rastreabilidade Bidirecional de Requisitos Manter rastreabilidade bidirecional entre os requisitos e os planos de projeto e demais artefatos. O propósito é manter a rastreabilidade bidirecional de requisitos em cada nível de decomposição do produto. A rastreabilidade pode ser estabelecida da fonte dos requisitos para o nível mais baixo dos requisitos e do nível mais baixo dos requisitos para sua fonte. A rastreabilidade é necessária na condução da avaliação de impacto das mudanças de requisitos nos planos do projeto, atividades e demais artefatos. SP 1.4 Manter Rastreabilidade Bidirecional de Requisitos Artefatos Típicos Matriz de Rastreabilidade de Requisitos Sistema de Acompanhamento de Requisitos 2-46
SP 1.4 Manter Rastreabilidade Bidirecional de Requisitos Subpráticas Manter a rastreabilidade de requisitos para assegurar que a fonte dos requisitos (derivados) de mais baixo nível seja documentada; Manter a rastreabilidade de um requisito para seus requisitos derivados assim como para suas funções, objetos, pessoas, processos e artefatos alocados; Manter a rastreabilidade horizontal (relacionamento) de função para função e entre interfaces; Gerar a matriz de rastreabilidade de requisitos. SP 1.5 Identificar Inconsistências entre Artefatos do Projeto e Requisitos Identificar inconsistências entre os planos do projeto e demais artefatos e os requisitos. É necessário encontrar inconsistências entre os requisitos e os planos do projeto e demais artefatos e então, iniciar a implementação de ações corretivas para solucioná-las. 2-47
SP 1.5 Identificar Inconsistências entre Artefatos do Projeto e Requisitos Artefatos Típicos Documentações de inconsistências, incluindo fontes, condições e razões Ações Corretivas SP 1.5 Identificar Inconsistências entre Artefatos do Projeto e Requisitos Subpráticas Rever os planos, atividades e artefatos do projeto para assegurar a consistência com os requisitos e as mudanças realizadas neles; Identificar a fonte da inconsistência e a razão; Identificar mudanças que necessitam ser feitas nos planos e demais artefatos resultantes das mudanças na baseline de requisitos; Iniciar ações corretivas. 2-48
GG 2 Institucionalizar o Processo Gerenciado O processo é institucionalizado como um processo gerenciado. GP 2.1 COMPROMISSO 1 Estabelecer uma Política Organizacional Estabelecer e manter uma política organizacional para planejamento e execução do processo de gestão de requisitos. Esta política estabelece as expectativas organizacionais para gestão de requisitos e identificação das inconsistências entre os requisitos e os planos de projeto e demais artefatos. 2-49
GP 2.2 Habilidade 1 Planejar o Processo Estabelecer e manter um plano para execução do processo de gestão de requisitos. Tipicamente, este plano para a execução do processo de gestão de requisitos é uma parte do plano do projeto. GP 2.3 Habilidade 2 Fornecer Recursos Fornecer recursos adequados para execução do processo de gestão de requisitos, desenvolvendo os artefatos e fornecendo os serviços do processo. Exemplos de Recursos: - Ferramentas de acompanhamento de requisitos - Ferramentas de rastreabilidade de requisitos 2-50
GP 2.4 Habilidade 3 Associar Responsabilidades Associar responsabilidade e autoridade para execução do processo de gestão de requisitos, desenvolvimento dos artefatos e fornecimento dos serviços do processo. GP 2.5 Habilidade 4 Treinar Pessoas Treinar as pessoas para execução e suporte ao processo de gestão de requisitos conforme as necessidades. Exemplos de tópicos de treinamento: - Domínio da aplicação - Definição, análise, revisão e gestão de requisitos - Ferramentas de Gestão de Requisitos - Gerência de Configuração - Negociação e solução de conflitos 2-51
GP 2.6 Direcionamento para Implementação 1 Gerenciar Configurações Colocar sob níveis apropriados de Gerência de Configuração os artefatos do processo de gestão de requisitos designados. Exemplos de artefatos a serem colocados sob Gerência de Configuração: - Requisitos - Matriz de Rastreabilidade de Requisitos GP 2.7 Direcionamento para Implementação 2 Identificar e Envolver Stakeholders Relevantes Identificar e envolver os stakeholders relevantes do processo de gestão de requisitos conforme planejado. Selecionar stakeholders relevantes dos cliente, usuários finais, desenvolvedores, analistas de negócios, testadores, fornecedores, marketing, equipe de suporte e outros que podem ser impactados ou podem influenciar no produto ou no processo. 2-52
GP 2.8 Direcionamento para Implementação 3 Monitorar e Controlar o Processo Monitorar e Controlar o processo de gestão de requisitos, utilizando o plano de execução do processo e implementar as ações corretivas apropriadas, caso ocorram desvios entre o previsto e realizado. Exemplo de medição utilizada na monitoração : - Volatilidade de Requisitos (percentual requisitos modificados) GP 2.9 Verificação da Implementação 1 Avaliar Objetivamente a Aderência Avaliar objetivamente a aderência do processo de gestão de requisitos, utilizando a descrição do processo, padrões e procedimentos. Tratar as não conformidades encontradas. Exemplos de artefatos revisados: - Requisitos - Matriz de Rastreabilidade de Requisitos 2-53
GP 2.10 Verificação da Implementação 2 Revisar Status com a Alta-Administração Revisar as atividades, status e resultados do processo de gestão de requisitos com a altaadministração para resolver questões. Mudanças propostas em compromissos externos a organização são revisados com a alta-administração (Gerência Sênior) para garantir que os compromissos sejam realizados. GG 3 Institucionalizar o Processo Definido O processo é institucionalizado como um processo definido. 2-54
GP 3.1 Estabelecer um Processo Definido Estabelecer e manter a descrição de um processo de gestão de requisitos definido. GP 3.2 Coletar Informação de Melhoria Coletar dados dos artefatos, métricas, resultados de medições e informações de melhoria derivadas do planejamento e execução do processo de gestão de requisitos para suportar o uso futuro e melhoria do processo da organização e artefatos gerados pelo processo. 2-55
5 Elementos da Mudança Visão Habilidades Incentivos Recursos Plano de Ação Mudança Habilidades Incentivos Recursos Plano de Ação Confusão Visão Incentivos Recursos Plano de Ação Ansiedade Visão Habilidades Recursos Plano de Ação Mudança Gradual Visão Habilidades Incentivos Plano de Ação Frustração Visão Habilidades Incentivos Recursos Falsos Inícios Contato Claudia Hazan MSc. Qualidade de Software Certified Function Point Specialist (SUPSD/SDARJ) Tel: (21) 2159-4407 Claudia.Hazan@serpro.gov.br claudinhah@yahoo.com 2-56