Baixe o app para aproveitar ainda mais
Prévia do material em texto
09/03/2012 1 2 � Stakeholders (Partes interessadas) ◦ Um stakeholder pode ser definido como alguém que ganha ou perde algo com o resultado do projeto [Conte 2007] 09/03/2012 2 3 � Exemplos típicos de stakeholders: ◦ Usuários – grupo que irá usar o software ◦ Clientes – grupo que encomendou o software ou que representa o público alvo do mesmo ◦ Analistas de mercado – para casos de produtos que precisam da análise de mercado ◦ Autoridades de regulamentação – para aplicações com regulamentações próprias, como transporte público ◦ Desenvolvedor/Engenheiro de Software ◦ Outros engenheiros de software [Conte 2007] 4 � O contato inicial normalmente indica pessoas com quem se deve falar, seus papéis e seus interesses � Stakeholders incluem usuários diretos do sistema e interessados indiretos também � Stakeholders podem sugerir outras pessoas que devem ser consultadas … [Conte 2007] 09/03/2012 3 5 interessados fregueses desenvolvedores usuários clientes dono especialista contratado parceiro cliente terceirizados investidor Controle Qualidade programadores engenheiros de software não clientes [Breitman 2007] � Atores do Universo de Informações ◦ Clientes ◦ Usuários ◦ Desenvolvedores � Documentos � Livros � Sistemas de Software 6 09/03/2012 4 7 � É aquele conhecimento que é trivial para o entrevistado e não o é para o entrevistador � Por ser trivial nunca é lembrado como importante e, portanto, não é transmitido ao entrevistador, que, não sabendo, não pode perguntar [Breitman 2007] 8 Perguntar por que? “A cafeteira deve ser feita de aço” � qual a razão disto? � pode me explicar porquê? � qual o pensamento por detrás disto? Ian Alexander, Writing better requirements 09/03/2012 5 9 “Porque se for de vidro pode quebrar” Requisito real: � A cafeteira deve ser feita de material inquebrável � Plástico � Poliuretano � Até mesmo aço Ian Alexander, Writing better requirements 10 � “a cafeteira tem uma luz vermelha que pisca quando está ligada, quando a água chega na temperatura certa ela fica ligada (sem piscar)” ◦ Quais seriam as perguntas do tipo “por que” que poderiam ser utilizadas nesta situação? ◦ Quais seriam os “reais” requisitos? Dica: Separar requisito de solução/implementação 09/03/2012 6 11 � Os usuários misturam a solução com os requisitos Separar NECESSIDADE da solução proposta! [Breitman 2007] 12 � Os clientes dificilmente têm uma idéia clara do que realmente querem � Diferentes pessoas dentro da organização normalmente possuem requisitos conflitantes � Podem existir na maioria dos casos limitações tecnológicas influenciando os requisitos. � … 09/03/2012 7 13 14 � Entrevistas estruturadas ◦ requer um prévio conhecimento sobre o contexto onde se aplica a entrevista. ◦ é feita com base em perguntas previamente pensadas ou delineadas. ◦ Claro, que o entrevistador tem liberdade de inserir perguntas de clarificação ou eventualmente outras que se façam necessárias, mas o núcleo de perguntas já é definido a priori. ◦ O papel do entrevistador na entrevista estruturada é um papel de questionador. Fonte:[Leite 2007] 09/03/2012 8 15 � Entrevista não-estruturada ◦ é aplicada quando se inicia o contato com o Universo de Informações e serve para garimpar informações iniciais. ◦ Fundamentalmente o entrevistador deixa o entrevistado falar, mas procura orientá-lo para que a entrevista mantenha o foco no tópico de interesse. ◦ O papel do entrevistador é um papel de aprendizado. Fonte:[Leite 2007] 16 � Extensão da entrevista � Brainstorm � Workshop de Requisitos [Breitman 2007] 09/03/2012 9 17 � Toda reunião/entrevista deve ser planejada ◦ Os objetivos da reunião devem estar claros; ◦ Os participantes devem ser bem escolhidos ◦ Deve haver uma convocação (com pauta) ◦ Deve ser entregue aos participantes uma ata de reunião anterior (para relembrar as decisões tomadas) e uma lista com os requisitos já elicitados até o momento 18 � Manter o foco e os objetivos da reunião � Registrar o conteúdo ◦ Anotar ◦ gravar � Gerenciar conflitos � Definir próximos passos. � Após reunião: ◦ Elaborar uma ata e atualizar documentação relevante 09/03/2012 10 19 � + � facilidade de acesso às fontes de informação � volume de informação � - � dispersão das informações 20 ◦ baixo custo ◦ pouca complexidade da tarefa ◦ dependência do ator (observador) ◦ superficialidade decorrente da pouca exposição ao universo de informações [Breitman 2007] 09/03/2012 11 © Carla A. Lima Reis, 2007 21 [Leite, 2007] 22 � Qualitativo � Quantitativo � O que perguntar ◦ exige conhecimento mínimo ◦ similar a entrevista estruturada [Breitman 2007] 09/03/2012 12 23 � Quantitativo 0 5 10 15 20 25 30 35 40 45 50 55 60 N u m . d e R e s p o s ta s 5. A XXX mantém dados estatísticos sobre o processo de desenvolvimento de software? SIMNÃO [Breitman 2007] 24 � Qualitativo � O quê você acha da sua formação no que se refere a produção de software de qualidade? � O que você acredita ser necessário para aprimorar seu desempenho? � Quais conhecimentos você desejaria adquirir? Por quê? � Objetivo: verificar a opinião em relação a política de treinamento � Justificativa: uma organização madura tem políticas bem definidas de treinamento. [Breitman 2007] 09/03/2012 13 25 26 � Taxonomias propostas na literatura servem de guia para a elicitação 09/03/2012 14 © Carla A. Lima Reis, 2007 27 Requisitos não Requisitos não funcionaisfuncionais Processo Requisitos de Processo Requisitos de Produto Externos Requisitos Externos requisitos de entrega requisitos de usabilidade requisitos de eficiência requisitos de confiabilidade requisitos de portabilidade requisitos de implementação requisitos para padrões requisitos de espaço requisitos de custo interoperabilidade requisitos de interoperabilidade requisitos legais requisitos de performance Taxonomia – Proposta 1 Sommerville 92 09/03/2012 15 30 Requisito Inverificável Requisito Verificável “ O banco de dados ZZ deve ser flexível” �O banco de dados ZZ deve possuir oito campos por registro. “MNOP deve ser seguro” �MNOP deve parar sua operação se uma pessoa se aproximar a menos de 2 metros de uma de suas partes móveis �MNOP deve desligar os aquecedores se a temperatura da água exceder 37°C �MNOP deve estar dentro dos padrões estabelecidos pela norma N567 seção 3.6 para temperaturas de superfícies externas. “O sistema CE deve processar depósitos rapidamente” �O sistema CE deve escanear os dados do usuário e conta de cada folheto de depósito em 2 segundos ou menos” • Requisitos não funcionais devem ser elaborados até que se tornem verificáveis Ralph Young – effective requirements practices 09/03/2012 16 31 Palavras não Verificáveis Possíveis substitutos Amigável Número máximo de passos Lista de funcionalidades presentes em outras aplicações Menus ou prompts para auxiliar usuários Portável Dimensões Requisitos mínimos de hardware Sistemas operacionais em que deve funcionar Pequeno Dimensões aceitáveis (em número de Bytes) Flexível Possui variáveis que podem acomodar mudanças de valores Ralph Young – effective requirements practices • Algumas palavras levam a requisitos impossíveis de serem verificados 32 � Reescreva os seguintes requisitos: ◦ o sistema bibliotecário deve serfácil de usar; ◦ o sistema deve fornecer um serviço confiável a todas as classes de usuários; ◦ o sistema deve permitir uma resposta rápida a todos os pedidos de informação. 09/03/2012 17 33 34 � O sistema deve + [frase verbal ] + [complemento de agente | nulo] + [condições | nulo] � Frase verbal é uma frase que expressa a funcionalidade do requisito � Complemento de agente é a identificação de um agente relacionado com o requisito; Agente pode ser uma pessoa, uma instituição, um grupo ou um dispositivo físico externo ao software � Condições são as possíveis condições externas ou internas ao sistema que influenciam o requisito [Breitman 2007] 09/03/2012 18 35 � O sistema deve emitir um recibo para o cliente. � O sistema deve emitir o recibo para o cliente em no máximo 2 segundos. � O sistema deve cadastrar o cliente, desde que o cliente possua identificação. � O sistema deve transformar uma fita disponível em fita emprestada, quando a fita for alugada pelo cliente. � O sistema deve cadastrar bibliotecários. � O sistema deve verificar a identidade do bibliotecário. � O sistema não pode deixar que um livro fique na reserva mais de um mês. [Breitman 2007] 36 � Claro � Não Ambíguo � Completo � Simples � Bem escrito [Breitman 2007] 09/03/2012 19 37 Um requisito claro Tipo de usuário O engenheiro de testeC Resultado desejado Csimula Objeto Cerros de componente C. Condições Cutilizando as funções de teste QQ e TT. Um requisito vago Em geral o sistemaC Precisa ou não? C deve ser capazC Quais? Cde diagnosticar possíveis errosC Como verificar isto? C em um prazo razoável. [Breitman 2007] 38 � No evento de falha da rede elétrica, o sistema deve enviar mensagem de erro ao usuário, salvar a configuração atual do sistema e os dados entrados, até então. � O sistema deve manter dados estatísticos sobre compra, venda e movimentação do estoque de materiais de limpeza. Informação relativa a comissão de vendedores também deve ser mantida. [Breitman 2007] 09/03/2012 20 39 Mas, com exceção, apesar, quando… � O sistema deve mostrar o total do pedido a medida em que os códigos dos produtos vão sendo entrados no pedido, a não ser que se trate de um produto promocional. [Breitman 2007] 40 � O sistema poderá ser acessado remotamente por qualquer unidade internacional da Petrobras, com isso, ele deverá ter um desempenho compatível ao acesso. [Breitman 2007] 09/03/2012 21 41 � Descreva cinco requisitos sobre um sistema de venda de passagens aéreas. � Descreva um requisito incompleto. [Breitman 2007] 42 Identificação , descoberta de requisitos análise e negociação de requisitos documentaçã o de requisitos validação de requisitos documento de requisitos necessidades dos utilizadores, sistemas legados, informação do domínio, normas organizacionais, etc. 09/03/2012 22 � No conjunto de requisitos identificados pode ◦ haver requisitos que se sobrepõem ◦ haver requisitos que estão em conflito ou que são contraditórios ◦ faltar requisitos � Análise de completude é uma das mais difíceis de serem realizadas. 43 � matriz de dependências 44 requisito r1 r2 r3 r4 r1 x x x x r2 conflito x x x r3 x x r4 sobreposição sobreposição x 09/03/2012 23 � Risco nos requisitos tem relação com ◦ Dificuldades no desenvolvimento de Requisitos ◦ Dificuldades na análise de Requisitos 45 46 � Normalmente requisitos que têm alto risco devem estar associados com alta prioridade. tempo risco Risco tem de decair com a evolução do projeto. 09/03/2012 24 47 � Negociação para quê? ◦ Chegar a acordo em relação a opções mais adequadas aos interesses dos stakeholders ◦ Definir as prioridades para os requisitos 48 � stakeholders primáriosprimáriosprimáriosprimários ◦ os que operam o sistema ◦ preocupam-se com os requisitos funcionais e questões de usabilidade ◦ pretendem sistemas fáceis de usar e aprender 09/03/2012 25 49 � stakeholders secundáriossecundáriossecundáriossecundários ◦ não operam o sistema mas consomem o que este produz ◦ o sucesso das suas atividades depende da qualidade do sistema ◦ são tipicamente gestores que usam a informação do sistema para controlar, monitorar e ajustar processos organizacionais 50 � Stakeholders terciáriosterciáriosterciáriosterciários ◦ Gestores de topo da hierarquia que raramente consomem as saídas do sistema (diretamente) ◦ Usam as saídas indiretamente para planejar e controlar estrategicamente o negócio ◦ Interessam-se pelo papel que o sistema desempenha para obtenção dos objetivos estratégicos do negócio 09/03/2012 26 51 � Problemas num processo de negociação ◦ separar os aspectos a debater das questões pessoais ◦ falta de entendimento compartilhado e de pontos de vista pessoais 52 � Lidar com os ataques pessoais ◦ Evitá-los... ◦ Se acontecerem: mudar de assunto, fazer um intervalo... ◦ Resolver o problema fora da reunião 09/03/2012 27 53 � Impedir as seguintes reações: ◦ "isso não funciona", “é impossível", "dá muito trabalho", “quem foi o imbecil que propôs…" � Deve solicitar que os participantes justifiquem a posição negativa 54 � Conflitos entre grupos ◦ choque de pontos de vista entre grupos ◦ exemplos: � Qualidade vs. Prazos � Segurança vs. Acesso � Complexidade funcional vs. Usabilidade � etc. � É necessário tentar: ◦ encontrar potenciais benefícios para todos ◦ evitar tomar partido 09/03/2012 28 55 Gerência de Requisitos 56 � Maiores riscos: ◦ “passar por cima” de um requisito crucial ◦ definir requisitos incorretamente ◦ representar inadequadamente os clientes ◦ modelar apenas aspectos funcionais ◦ falta de inspeções nos requisitos [Breitman 1007] 09/03/2012 29 57 Parte 3 VerificaçãoVerificaçãoVerificaçãoVerificação 58 ValidaçãoValidaçãoValidaçãoValidação estamos estamos estamos estamos construindo o construindo o construindo o construindo o produto de produto de produto de produto de maneira certa?maneira certa?maneira certa?maneira certa? estamos estamos estamos estamos construindo o construindo o construindo o construindo o produto certo?produto certo?produto certo?produto certo? 09/03/2012 30 59 � Estamos construindo o produto certo? ◦ Teste ◦ Execução de cenários (leitura em reunião) ◦ Leituras por atores interessados ◦ Protótipos 60 09/03/2012 31 © Carla A. Lima Rei/ Rodrigo Reis, 2007 61 � Prototipagem em papel ◦ Processo simples: muitas iterações ◦ Identificação precoce de problemas ◦ Baixo custo para reparar erros ◦ Notas de Post-it ou rascunhos no papel � Menus � Janelas � Botões � Caixas de diálogos � Etc. [Lemos, Kuroki, 2007] 62Fonte: http://www.sapdesignguild.org/resources/glossary_web/index2.html 09/03/2012 32 © Carla A. Lima Rei/ Rodrigo Reis, 2007 63Fonte: http://www.snyderconsulting.net/article_paperprototyping.htm 64 � Ajudam a clarear requisitos ◦ Requisitos que embora conhecidos estão pobremente definidos e pouco compreendidos ◦ Reações do tipo “agora que estou vendo funcionar também preciso de …..” � Disponibilidade de ferramentas que permitem a construção rápida e barata de protótipos Breitman, 2007] 09/03/2012 33 65 � Vertical X Horizontal ◦ Horizontal � implementa grande parte da funcionalidade ◦ Vertical � implementa poucas funções � maior qualidade © Carla A. Lima Rei/ Rodrigo Reis, 2007 66 09/03/2012 34 67 � Desafio Atual: ◦ O que se deve gerenciar? ◦ É possível gerenciar efetivamente requisitos? ◦ Qual o ganhocom o gerenciamento? 68 � Antes do Processo de Gerência de Requisitos ◦ “Quem definiu isso? Vou tentar me lembrar...” � Depois do Processo de Gerência de Requisitos ◦ “Quem definiu isso? Foi a área de negócio XYZ no dia 10 de janeiro segundo consta aqui nessa ata...” 09/03/2012 35 69 � Gerenciamento ◦ Antes do Processo de Gerência de Requisitos � “Como o usuário pode estar insatisfeito com a mudança de prazo se estamos fazendo tudo que ele quer?” ◦ Depois do Processo de Gerência de Requisitos � “Informe ao usuário que os novos requisitos acarretarão um desvio de 20% no prazo e 5% no custo” 70 � Um requisito é rastreável se for possível identificar: ◦ Quem solicitou o requisito ◦ Porque o requisito existe ◦ Quais os requisitos relacionados ◦ Como os requisitos se relacionam a outras informações 09/03/2012 36 71 � Seu objetivo é criar vínculos (links) entre os requisitos e outros itens do sistema � A rastreabilidade é importante para auxiliar a avaliação do impacto de mudanças nos requisitos � E também para demonstrar a completa satisfação dos requisitos 72 Requisitos do Usuário Projeto do Sistema Especificações do Sistema forward – p/ avaliar o impacto de mudança backward – p/a rastrear a origem de um componente 09/03/2012 37 73 � Ferramentas de Gerência de Requisitos devem oferecer facilidades para: ◦ Identificação e Armazenamento dos Requisitos; ◦ Gerenciamento de mudanças, que ajudem a garantir que as mudanças solicitadas foram avaliadas e tratadas corretamente; ◦ Rastreabilidade, que auxiliem a encontrar dependências entre os requisitos. � ReqManager (TABA) � Analyst Pro (Goda Software, Inc.) � CaliberRM (Borland) � Catalyze (SteelTrace) � Cradle (3SL - Structured Software Systems Ltd) � Enterprise Architect 74 � Doors (Telelogic AB) � Objectiver (Cediti) � RDT (Igatech) � Reconcile (Compuware Corporation) � Requisite Pro (IBM Rational Software) 09/03/2012 38 75 � Tabela utilizada para documentar os relacionamentos entre os requisitos � Rastreabilidade Horizontal e Vertical: ◦ Requisitos do Cliente, ◦ Módulos de Código, ◦ Casos de Teste... 76 09/03/2012 39 77 78 09/03/2012 40 79 � Ao adotar um processo de Gerenciamento de Requisitos, a organização precisa definir sua Política de Rastreabilidade de Requisitos que deve incluir: ◦ A informação de rastreabilidade que será mantida; ◦ As técnicas e ferramentas que serão utilizadas; ◦ Processo de coleta das informações de rastreabilidade: quem e quando ◦ Processo de atualização das informações de rastreabilidade, após alterações 80 09/03/2012 41 © Carla A. Lima Rei/ Rodrigo Reis, 2007 81 82 09/03/2012 42 83 © Carla A. Lima Rei/ Rodrigo Reis, 2007 84 09/03/2012 43 © Carla A. Lima Rei/ Rodrigo Reis, 2007 85 © Carla A. Lima Rei/ Rodrigo Reis, 2007 86 09/03/2012 44 87 � Ferramenta de gerência de requisitos � Integração com o Microsoft Word �Noção dos impactos de alterações dos requisitos © Carla A. Lima Rei/ Rodrigo Reis, 2007 88 projetoprojetoprojetoprojeto explorerexplorerexplorerexplorer visõesvisõesvisõesvisões pastapastapastapasta documentodocumentodocumentodocumento visãovisãovisãovisão requisitorequisitorequisitorequisito 09/03/2012 45 89 ---- Prioridade, status, dificuldade, risco...Prioridade, status, dificuldade, risco...Prioridade, status, dificuldade, risco...Prioridade, status, dificuldade, risco... 90 09/03/2012 46 91 Entendimento, comprometimento e mudança dos requisitos 92 � Fornecedores de Requisitos ◦ Para o MPS.BR é desejável que os fornecedores de requisitos estejam identificados e aprovados pelo patrocinador do projeto. ◦ Uma possível opção é registrar no plano do projeto quem serão os fornecedores de requisitos e como será a comunicação com os mesmos � Incluindo como mudanças nos requisitos poderão ser solicitadas 09/03/2012 47 93 � Meios e formas de comunicação com fornecedores de requisitos ◦ As comunicações devem ser registradas formalmente através de: � Atas de reunião � Documentos (devem ser aprovados/assinados) � Emails (devem ser armazenados) � Ou outras ferramentas de comunicação 94 � Meios e formas de comunicação com fornecedores de requisitos ◦ É importante a comprovação de que os interessados estão de acordo com o conteúdo registrado ◦ Devem ser definidos e evidenciados os meios e formas de comunicação, momentos e/ou freqüências para as comunicações 09/03/2012 48 95 � Procedimentos para obtenção do entendimento sobre os Requisitos ◦ Para o conjunto de requisitos especificados, é necessário rever com o cliente se as necessidades e expectativas estão sendo atendidas com os requisitos propostos. ◦ Como comprovação deste entendimento deve-se ter um documento de requisitos 96 � Comprometimento com os Requisitos ◦ Após o entendimento dos requisitos e da aceitação dos mesmos, é necessário o comprometimento dos responsáveis pela implementação dos requisitos � Partes envolvidas no Comprometimento ◦ Equipe técnica da empresa (equipe do projeto) ◦ Cliente 09/03/2012 49 97 � Efetivação do Comprometimento ◦ Pode ser feito de diversas formas, porém devem ser sempre documentados ◦ Exemplo de prática para efetivação do comprometimento: � Reunião de kick off onde se apresenta o projeto como um todo (incluindo seus requisitos) � Esta reunião possibilita que as diversas partes possam opinar e se comprometerem em relação aos requisitos do projeto ◦ Sempre que forem aprovadas mudanças nos requisitos, deve-se obter novos comprometimentos para os requisitos do projeto 98 � Estabelecimento da Rastreabilidade Bidirecional ◦ Um mecanismo que permita rastrear a dependência entre os requisitos, os planos do projeto e os produtos de trabalho deve ser estabelecido ◦ A rastreabilidade bidirecional deve ser tanto horizontal quanto vertical 09/03/2012 50 99 � Itens que devem ser rastreáveis ◦ A rastreabilidade só é efetiva para a avaliação do impacto das mudanças se existe rastreabilidade bidirecional entre os itens com impacto no produto: � Requisitos � Produtos de trabalho � Componentes do projeto � Códigos de unidade ou módulos do software � Casos de Teste (caso existam) 100 � Identificação de Inconsistências entre requisitos e outros produtos de trabalho ◦ Quando há mudanças nos requisitos: � Devem ser identificados os impactos da mudança com a utilização do instrumento de rastreabilidade dos requisitos � Deve-se examinar se os demais artefatos estão consistentes com as alterações realizadas 09/03/2012 51 101 102 � Processo: Gerência de Requisitos � Nível MPS.Br: G – Parcialmente Gerenciado � Propósito: O propósito do processo Gerência de Requisitos é ◦ Gerenciar os requisitos dos produtos e componentes do projeto ◦ Identificar inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto. 09/03/2012 52 10 3 Resultados esperados GRE 1. O entendimento dos requisitos é obtido junto aos fornecedores de requisitos; GRE 2. Os requisitos de software são aprovados utilizando critérios objetivos; GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida; 10 4 Resultados esperados GRE 4. Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos; GRE 5. Mudanças nos requisitos são gerenciadas ao longo do projeto. 09/03/2012 53 105� Resultados Atributos do Processo Esperados: RAP 1. O processo de Gerência de Requisitos atinge seus resultados definidos RAP 2. Existe uma política organizacional estabelecida e mantida para a Gerência de Requisitos RAP 3. A execução do processo de Gerência de Requisitos é planejada RAP 4. A execução da Gerência de Requisitos é monitorada e ajustes são realizados para atender aos planos 106 � Resultados Atributos do Processo Esperados: RAP 5. Os recursos necessários para a execução da Gerência de Requisitos são identificados e disponibilizados RAP 6. As pessoas que executam a Gerência de Requisitos são competentes em termos de formação, treinamento e experiência RAP 7. A comunicação entre as partes interessadas na Gerência de Requisitos é gerenciada de forma a garantir seu envolvimento no projeto RAP 8. O estado, atividades e resultados da Gerência de Requisitos são revistos com os níveis adequados de gerência (incluindo a gerência de alto nível) e problemas pertinentes são tratados 09/03/2012 54 107 � Informações adicionais para Gerência de Requisitos: ◦ Consulte NBR ISO/IEC 12207, emendas 1 e 2 da 12207: Subprocessos Elicitação de Requisitos e Análise de Requisitos de Software ◦ Consulte ISO/IEC 15504-5: Processos Elicitação de Requisitos e Análise de Requisitos de Software ◦ Consulte CMMI-SE/SW: Área de Processo Gerência de Requisitos 108 Gerência de Requisitos no CMMI Processos de Engenharia de Requisitos na ISO 12207 09/03/2012 55 109 � Relaciona-se com duas Áreas de Processo: ◦ Gerência de Requisitos (Nível de Maturidade 2) ◦ Desenvolvimento de Requisitos (Nível de Maturidade 3) 110 � Aplica-se ◦ a todos os requisitos de produtos e componentes do produto que são entregues com o projeto 09/03/2012 56 111 � Objetivo Específico: ◦ Gerenciar requisitos � Os requisitos são gerenciados e inconsistências com os planos de projeto e produtos de trabalho são identificadas 11 2 Matriz de Rastreabilidade Requisitos Obter Entendimento dos Requisitos Obter Aceite/ Comprometi- mento com os Requisitos Gerenciar Mudanças nos Requisitos Identificar Inconsistências entre o Trabalho do Projeto e os Requisitos Manter Rastreabilidade bidirecional dos Requisitos Gerenciar Requisitos 09/03/2012 57 113 � Gerenciar requisitosGerenciar requisitosGerenciar requisitosGerenciar requisitos � Deve ser mantido um conjunto atualizado de requisitos aprovados durante o projeto, sendo necessário: � Gerenciar todas as mudanças nos requisitos � Manter os relacionamentos entre os requisitos, os planos do projeto e os produtos � Identificar inconsistências entre o trabalho do projeto e os requisitos � Iniciar ações corretivas � 1) Escreva os requisitos funcionais do sistema escolhido � 2) Escreva os requisitos não-funcionais do sistema escolhido � 3) Faça a matriz de rastreabilidade dos requisitos funcionais x requisitos funcionais
Compartilhar