Engenharia de Software - Campus Universitário do...
Transcript of Engenharia de Software - Campus Universitário do...
Engenharia de Software
Engenharia de Software 2012/3Aula 4 – Engenharia de Requisitos
Thiago P. da [email protected]
02/05/13 2
Agenda
● Engenharia de Requisitos
● Níveis de Descrição dos Requisitos
● Tipos de Requisitos
– Requisitos Funcionais
– Requisitos Não Funcionais● Documento de Requisitos de Software (ERS)
● Processos de Engenharia de Requisitos
● Gerenciamento de Requisitos
02/05/13 3
Objetivos da Aula
● Compreender os conceitos de requisitos de usuário e de sistema;
● Compreender a diferença entre requisitos de software funcionais e não funcionais;
● Entender a organização dos requisitos em um documento de requisitos de software (ERS)
● Compreender as principais atividades de elicitação, análise e validação da engenharia de requisitos;
● Entender a importância do gerenciamento de requisitos.
02/05/13 4
Requisitos de Software
● Requisitos de um sistema são declarações do que o sistema deve fazer, os serviços e as restrições a seu funcionamento
– Refletem a necessidade dos clientes● Existem níveis de descrição e detalhamento dos requisitos
– Comunicam informações sobre o sistema para diferentes tipos de leitor
– Os clientes não sabem detalhes técnicos, mas os desenvolvedores necessitam destes detalhes
● Requisitos devem definir as necessidades do sistema de uma forma abstrata de tal forma que não deixe a solução pré-definida
● Podem ser parte do contrato
02/05/13 5
Engenharia de Requisitos
● Engenharia de Requisitos
– É o processo de descobrir, analisar, documentar e verificar os serviços e restrições do sistema
– Faz parte do processo de especificação do sistema, comum a qualquer processo de software
– Nos processo de software tradicionais existem uma fase da engenharia de requisitos claramente identificável antes de se iniciar a implementação do sistema
– Nas abordagens ágeis, simultaneamente são elicitados os requisitos enquanto a sistema é desenvolvido
● Raramente são utilizados para grandes sistemas
02/05/13 6
Níveis de Detalhamento dos Requisitos
● Requisitos de Usuário
– Expressam os requisitos abstratos de alto nível
– Usam linguagem natural com diagramas, de quais serviços o sistema deverá fornecer e as suas restrições
● Requisitos de Sistema
– Declarações mais detalhadas do que o sistema deve fazer, serviços e restrições operacionais
– Deve definir exatamente o que deve ser implementado
02/05/13 7
Níveis de Detalhamento dos Requisitos
● Requisitos de Usuário não se importam como será implementado. Interessados com as Funcionalidades
● Requisitos de Sistema ditam como será implementado. Interessados com os Detalhamentos
02/05/13 8
Requisitos Funcionais
● Descrevem o que o sistema deve fazer
● Quando expressos como requisitos de usuário, são normalmente descritos de forma abstrata, para serem compreendidos pelos usuários do sistema
● Requisitos de sistema funcionais descrevem em detalhes as funções do sistema, suas entradas e saídas
● A especificação dos requisitos funcionais de um sistema deve ser completa e consistente
– Todos os serviços requeridos pelo cliente devem ser definidos
– Os requisitos não devem ter definições contraditórias● A imprecisão na especificação dos requisitos é a causa de muitos
problemas na engenharia de software
02/05/13 9
Tipos de Requisitos
● Requisitos Funcionais
– Declarações de serviços que o sistema de fornecer, de como deve reagir a entradas específicas e se comportar em determinadas situações
– Podem também explicitar o que o sistema não deve fazer● Requisitos Não Funcionais
– Restrições aos serviços ou funções oferecidas pelo sistema
– As vezes atingem todo o sistema. Exemplo: segurança● A distinção entre os tipos de requisitos não é tão clara
– Exemplo: Um requisito de usuário relacionado a proteção pode gerar outros requisitos, claramente funcionais, como a necessidade de incluir recursos de autenticação de usuário
● Requisitos não são independentes
– Podem gerar outros requisitos ou até mesmo restringir outros requisitos
02/05/13 10
Requisitos Funcionais
● Descrevem o que o sistema deve fazer
● Quando expressos como requisitos de usuário, são normalmente descritos de forma abstrata, para serem compreendidos pelos usuários do sistema
● Requisitos de sistema funcionais descrevem em detalhes as funções do sistema, suas entradas e saídas
● A especificação dos requisitos funcionais de um sistema deve ser completa e consistente (é possível?)
– Todos os serviços requeridos pelo cliente devem ser definidos
– Os requisitos não devem ter definições contraditórias● A imprecisão na especificação dos requisitos é a causa de muitos
problemas na engenharia de software
02/05/13 11
Requisitos Funcionais
● Exemplos de Requisitos Funcionais:
– Todos os usuários do sistema devem ser identificados apenas pelo seu número de CPF
– O sistema deve gerar relatórios diários sobre a quantidade de acessos à porta 2222
– O sistema deve importar dados do calendário no formato CVS
02/05/13 12
Requisitos Não Funcionais
● São requisitos que não estão diretamente relacionados com os serviços específicos oferecidos pelo sistema e seus usuários
● Atributos de qualidade do sistema
● Propriedades emergentes do sistema (Surgem quanto os subsistemas ou componentes estiverem integrados)
– Confiabilidade
– Tempo de resposta
– Usabilidade● Restrições sobre a implementação do sistema
– Tipo de IDE
– Tipos de dispositivos
– Linguagem de programação/Arquitetura
– Tipos de dados
– Processo de Software
02/05/13 13
Requisitos Não Funcionais
● São mais críticos que os requisitos funcionais, pois se não forem atendidos talvez o sistema seja inútil
– Exemplos● Sistema de aeronaves não cumpre requisito de
confiabilidade. Logo não será homologado● Sistema do freio ABS não cumpre requisito de
desempenho. Poderá provocar acidentes.● Tipicamente é difícil relacionar os componentes do
sistema com os requisitos não funcionais
– Requisitos Não Funcionais podem afetar toda arquitetura
– Um único requisito funcional pode gerar uma série de requisitos funcionais relacionados
02/05/13 14
Requisitos Não Funcionais
● Surgem de Necessidades dos usuário:
– Devido a restrições de orçamento
– Políticas organizacionais
– Necessidade de interoperabilidade com outros sistemas ou hardware
– Fatores externos● Reguladores de segurança● Legislação de privacidade
02/05/13 15
Requisitos Não Funcionais
Classificação de Requisitos Não Funcionais
02/05/13 16
Requisitos Não Funcionais
Classificação de Requisitos Não Funcionais
02/05/13 17
Requisitos Não Funcionais
Classificação de Requisitos Não Funcionais
– Requisitos de Produto● Especificam e restringem o comportamento do software
– portabilidade, confiança, disponibilidade, eficiência, proteção, etc
● Exemplos:– O sistema terá disponibilidade de 98%– O sistema processará 23 transações por segundo.– O sistema deve ser implementado usando as tecnologias
JavaEE– O sistema será instalado no servidor de aplicação JBoss
02/05/13 18
Requisitos Não Funcionais
Classificação de Requisitos Não Funcionais
02/05/13 19
Requisitos Não Funcionais
Classificação de Requisitos Não Funcionais(continuação)
– Requisitos Organizacionais● Derivados de políticas e procedimentos da
organização do cliente e do desenvolvedor– padrões, ISOS, ambientais (S.O.) e infraestrutura
● Exemplos:– O processo de desenvolvimento deve ser ágil– A ferramenta Eclipse de ser usada para apoiar o
processo de desenvolvimento– O processo de desenvolvimento deve ser definido
conforme o padrão ISO 9000
02/05/13 20
Requisitos Não Funcionais
Classificação de Requisitos Não Funcionais
02/05/13 21
Requisitos Não Funcionais
Classificação de Requisitos Não Funcionais(continuação)
– Requisitos Externos● Fatores externos ao sistema e seu processo de
desenvolvimento– requisitos de interoperabilidade, legislação, direitos
autorais e localização geográfica (País)● Exemplos:
– O layout do sistema deve seguir a política de marcas da empresa
– Os relatórios gerados pelo sistema devem estar em conformidade com o padrão XYZ
– Conformidade com as resoluções da UFMT
02/05/13 22
Requisitos Não Funcionais
● Requisitos Não Funcionais devem ser testáveis e precisos
– Evitar usar metas gerais como nos requisitos não funcionais, por exemplo:
● O sistema deve ser de fácil uso pelo cliente– Devem ser escritos quantitativamente, para que
possam ser testados● Métricas podem ser usadas para especificar as
propriedades não funcionais do sistema
02/05/13 23
Requisitos Não Funcionais
Métricas para especificar requisitos não funcionais
Propriedade MétricaDesempenho • transações processadas por segundo
• tempo de resposta para entrada do usuárioConfiança • taxa de ocorrência de falha
• tempo médio de falhaDisponibilidade • probabilidade de falha na demandaTamanho • kbytesUsabilidade • tempo necessário para aprender 80% das
facilidades• número de erros cometidos pelo usuário
num dado período de tempoRobustez • tempo para reiniciar após uma falha no
sistemaPortabilidade • número de sistemas alvo
02/05/13 24
Requisitos Não Funcionais
Problemas na especificação dos requisitos não funcionais
– Compreensão, Clareza e Ambiguidade● Podem ser expressos com linguagem do domínio da
aplicação● Não necessariamente os engenheiros de software e
desenvolvedores entenderão● Língua portuguese é ambígua
– Conhecimento Implícito● Talvez o especialista do domínio se esqueça de deixar
claro alguns conceitos e requisitos de domínio
02/05/13 25
Documento de Requisitos de Software
Especificação de Requisitos de Software (ERS)
● É uma declaração oficial de que os desenvolvedores do sistema devem implementar.
● Inclui os requisitos de usuário e de sistema.
● Não é um documento de projeto/design.
● Diz o que será o software
● Tem um conjunto diversificado de usuários:
– Desenvolvedores
– Clientes
– Administradores
02/05/13 26
Documento de Requisitos de Software
Usuários do ERS
02/05/13 27
Documento de Requisitos de Software
Usuários do ERS
● Clientes do Sistema
– Especificam os requisitos e os leem para checar se eles satisfazem suas necessidades
● Gerentes de Projeto
– Usam os documentos de requisitos para planejarem uma proposta para o sistema e o processo de desenvolvimento do sistema
02/05/13 28
Documento de Requisitos de Software
Usuários do ERS
● Engenheiros de Sistema
– Usam os requisitos para entenderem o sistema em construção
● Engenheiros de Teste
– Usam os requisitos para desenvolverem testes de validação do sistema
● Engenheiros de Manutenção de Sistema
– Usam os requisitos para entenderem o sistema e o relacionamento entre suas partes
02/05/13 29
Documento de Requisitos de Software
● Para a maioria dos métodos ágeis, produzir documento de requisitos é perca de tempo
– Eles alegam que os Requisitos mudam constantemente
– O documento sempre estará desatualizado● XP utiliza engenharia de requisitos incremental
– Expressa os requisitos como “Estórias de usuário”
– A cada iteração um subconjunto de requisitos é elicitado● Mas para alguns tipos de sistemas como, por exemplo,
sistemas críticos, torna-se necessário ter elicitados todos os requisitos antes do desenvolvimento
02/05/13 30
Documento de Requisitos de Software
● 40% dos erros do sistema, deve-se as especificação mal feita [2]
02/05/13 31
Documento de Requisitos de Software
Organização de um documento de requisitos
● Padrão IEEE/ANSI 830-1993 apresenta uma estrutura para o documento de requisitos
– Introdução● 1.1 Propósito do documento de Requisitos● 1.2 Escopo do produto● 1.3 Definições, acrônimos e abreviações● 1.4 Referencias● 1.5 Resumo do resto do documento
– 2. Descrição Geral● 2.1 Perspectiva do produto● 2.2 Funções do produto● 2.3 Características do usuário● 2.4 Limitações gerais● 2.5 Suposições e dependências
– 3. Requisitos específicos● Cobrem requisitos funcionais, não-funcionais e Interface
– 4. Apêndices
– Índice
02/05/13 32
Documento de Requisitos de Software
Organização de um documento de requisitos
● Padrão IEEE/ANSI 830-1993 é genérico
– Certas partes talvez não são necessárias para o documento de requisitos
● Qualquer pessoa/empresa pode criar o seu modelo
● Tipos diferentes de sistemas requerem níveis de detalhamento em suas especificações diferentes
● Pode-se usar a linguagem natural para especificação de requisitos ou templates, que representam os requisitos como formulários estruturados
– Poema, verso, cartões de papel, etc.
02/05/13 33
Documento de Requisitos de Software
● Prática
– Leitura da IEEE/ANSI 830-1993
02/05/13 34
Processos de Engenharia de Requisitos
● Os processos de Engenharia de Requisitos possuem quatro atividades genéricas:
– Avaliar se o sistema é útil (estudo de viabilidade)
– Descobrir requisitos (elicitação e análise de requisitos)
– Converter os requisitos em uma forma padrão (especificação de requisitos)
– Verificar se os requisitos definem o sistema (validação de requisitos)
● Gerenciamento de Requisitos também é necessário!
– Inevitavelmente os requisitos mudam
– Mas será que todas as empresas gerenciam os requisitos?
02/05/13 35
Processos de Engenharia de Requisitos
Modelo Conceitual (Esta é uma visão tradicional)
– Não necessariamente é assim!!!
– Na prática a engenharia de requisitos é um processo iterativo em que as atividades são intercalados (não sequenciais)
Estudode Viabilidade
Elicitação e Análisede Requisitos Especificação
de requisitosValidação
de requisitos
Relatório deViabilidade
Modelosde Sistema
Requisitos deUsuário e Sistema
ERS
02/05/13 36
Processos de Engenharia de Requisitos
Visão em Espiral dos processos de engenharia de requisitos
02/05/13 37
Processos de Engenharia de Requisitos
Visão em Espiral dos processos de engenharia de requisitos
– No início do processo (anéis internos) deve-se compreender:● os requisitos de negócio● requisitos não funcionais em alto nível● requisitos de usuário (conhecimento do domínio)
– Depois (anéis externos)● elicitar e compreender os requisitos de sistema em detalhes
– O número de iterações em torno da espiral varia de acordo:● nível de detalhamento desejado● tipo de software● Modelo de Processo de software adotado
02/05/13 38
Processos de Engenharia de Requisitos
Visão em Espiral dos processos de engenharia de requisitos
02/05/13 39
Processos de Engenharia de Requisitos
Elicitação e Análise de requisitos
– Após um estudo inicial de viabilidade
– Obtenção de informações sobre o domínio da aplicação, os serviços, desempenho, restrições de hardware, etc.
– As fontes destas informações são diversas● stakeholders● Manuais, especificações e normas● Sistemas semelhantes
– É um processo contínuo, com feedback contínuo de cada atividade para outras atividades
02/05/13 40
Processos de Engenharia de Requisitos
Problemas inerentes da elicitação de requisitos
– Stakeholders não sabem realmente o que querem
– Stakeholders expressam requisitos com seus termos (linguagem)
– Diferentes Stakeholders terão requisitos conflitantes
– Fatores organizacionais e políticos podem influenciar os requisitos do sistema
– Os requisitos mudam durante o processo de análise
02/05/13 41
Processos de Engenharia de Requisitos
Modelo para processo de Elicitação e Análise de Requisitos
02/05/13 42
Processos de Engenharia de Requisitos
Modelo para processo de Elicitação e Análise de Requisitos
– 1 - Descoberta de requisitos – Elicitar requisitos, reunir informações sobre o sistema. Existem várias fontes e técnicas para descoberta de requisitos.
– 2 - Classificação e Organização de requisitos – Agrupamento de requisitos relacionados.
– 3 - Priorização e negociação de requisitos – priorizar requisitos e resolver conflitos.
– 4 - Especificação de requisitos – Documentos formais.
02/05/13 43
Processos de Engenharia de Requisitos
Descobrir os Requisitos
– Obtenção de informações sobre o domínio da aplicação, os serviços e restrições do sistema
– As fontes de informação incluem:● Documentação● Stakeholders● especificações de sistemas similares● Protótipos também podem ser usados tanto para descobrir quanto para
validar requisitos– Como obter tais informações?
● Entrevistas● Cenários (formato de texto, tabelas e/ou diagramas)● Casos de Uso● Etnografia (observação)
02/05/13 44
Processos de Engenharia de Requisitos
Exemplo de stakeholders para supermercado
– Cliente do supermercado
– Representantes comerciais de produtos
– Dono do estabelecimento
– Caixas do supermercado
– Empacotadores
– Administradores
– Departamento de marketing, vendas, etc
– Fiscais
– Distribuidores
– Etc
02/05/13 45
Processos de Engenharia de Requisitos
Como Descobrir os Requisitos
EntrevistasEntrevistas● Formais ou informais● Entrevistas fechadas com uma lista predeterminada de questões● Entrevistas abertas onde várias questões são exploradas
– As perguntas estão relacionadas ao sistema atual em uso e o sistema a ser desenvolvido
– Normalmente se usa uma mistura de entrevista fechada e aberta
– Entrevistas são boas para obtenção de um entendimento geral do que os stakeholders fazem e como eles podem interagir com o sistema
02/05/13 46
Processos de Engenharia de Requisitos
Como Descobrir os Requisitos
EntrevistasEntrevistas– Entretanto, não são boas para elicitar o conhecimento do domínio
● Os engenheiros de requisitos podem não entender a terminologia específica de domínio
● Alguns conhecimentos de domínio são tão especificos que as pessoas acham difícil explicar ou pensam que não vale a pena mencioná-los
– Também não são uma técnica eficaz para elicitação do conhecimento sobre requisitos e restrições organizacionais
● Relações de poder● Estrutura organizacional não corresponde á realidade
02/05/13 47
Processos de Engenharia de Requisitos
Como Descobrir os Requisitos
EntrevistasEntrevistas– Características dos entrevistadores eficazes
● Abertura a novas ideias● Estimular o entrevistado a participar de discussões
– As entrevistas podem deixar escapar informações essenciais● Desta forma necessitam ser usadas juntamente com
outras técnicas
02/05/13 48
Processos de Engenharia de Requisitos
Como Descobrir os Requisitos
CenáriosCenários– São exemplos do mundo real de como o sistema pode ser usado
– Devem incluir:● Uma descrição do que o sistema e usuário esperam quando o cenário iniciar● Descrição do fluxo normal de eventos e como é tratado● Descrição do fluxo excepcional (quando ocorre erro)● Informações sobre atividades concorrentes● Uma descrição do estado do sistema quando o cenário acaba
– Podem ser escritos como texto, suplementados por diagramas e telas
– Estórias usadas no Extreme Programming são exemplos de cenário de requisitos
– Podem ser usado protótipos de GUI para sistemas interativos
02/05/13 49
Processos de Engenharia de Requisitos
Como Descobrir os Requisitos
CenáriosCenários● Exemplo no material impresso!
02/05/13 50
Processos de Engenharia de Requisitos
Como Descobrir os Requisitos
Casos de UsoCasos de Uso– São cenários baseados na UML que identificam as
interações no sistema
– Um conjunto de casos de uso podem descrever todas as interações com o sistema
– Cenários e casos de uso não são eficazes para elicitar restrições ou requisitos de negócio e não funcionais ou para descobrir requisitos de domínio
02/05/13 51
Processos de Engenharia de Requisitos
Como Descobrir os Requisitos
Casos de UsoCasos de Uso● Exemplo no material impresso!
02/05/13 52
Processos de Engenharia de Requisitos
Como Descobrir os Requisitos
EtnografiaEtnografia– Técnica de observação para compreender os
processos operacionais (funcionamento da empresa) e extrair os requisitos que apoiam esse processos
– Observação do trabalho do dia a dia e anotações sobre as tarefas reais em que os participantes estão envolvidos
– O observador é inserido na organização e as pessoas não precisam explicar seu trabalho
– Fatores sociais e organizacionais de importância podem ser observados
02/05/13 53
Processos de Engenharia de Requisitos
Como Descobrir os Requisitos
EtnografiaEtnografia– São requisitos originados a partir do modo como as
pessoas realmente trabalham● Maneira como realmente as pessoas trabalham e
não como as definições dos processos dizem.● Cooperação e conhecimento das atividades de
outras pessoas– Não é boa para descobrir novos requisitos
02/05/13 54
Processos de Engenharia de Requisitos
Visão em Espiral dos processos de engenharia de requisitos
02/05/13 55
Processos de Engenharia de Requisitos
Especificação de Requisitos
– Escrever os requisitos de usuário e de sistema em um documento
– Os requisitos de usuário devem descrever os requisitos funcionais e não funcionais de modo que sejam compreensíveis para usuários que não tenham conhecimento técnico detalhado
– Os requisitos de sistema são mais detalhados e incluem mais informações técnicas
– Os requisitos podem ser parte do contrato de desenvolvimento do sistema
● Idealmente o documento de requisitos não deve possuir detalhes da arquitetura ou projeto do sistema
● Evitar usar jargões de software
02/05/13 56
Processos de Engenharia de Requisitos
Especificação de Requisitos
– Os requisitos devem estabelecer o que o sistema deve fazer e o projeto/design descrevo como fazer
– Na prática, requisitos e projeto são inseparáveis● A arquitetura do sistema é projetada para suportar os
requisitos● O sistema deve interoperar com outros sistemas
que podem gerar requisitos de projeto (não funcionais)● O uso de uma arquitetura específica para satisfazer
requisitos não funcionais pode ser necessário
02/05/13 57
Processos de Engenharia de Requisitos
Especificação de Requisitos
– Especificação em linguagem naturalEspecificação em linguagem natural● Texto com apoio de diagramas e tabelas● Expressivo, intuitivo e universal● Pode ser entendido pelo cliente e desenvolvedores
facilmente● Entretanto:
– Precisão é difícil– Difícil organização– Diferentes requisitos podem ser expressos em uma
única sentença
02/05/13 58
Processos de Engenharia de Requisitos
Especificação de Requisitos
– Especificação em linguagem natural (Exemplo)Especificação em linguagem natural (Exemplo)● Req 1 – O sistema deve medir o açúcar no sangue e
fornecer insulina, se necessário, a cada dez minutos.● Req 2 – O sistema, deve a cada dez minutos, realizar
a rotina de autoteste com as condições a serem testadas e as ações associadas definidas na Tabela 5.2.
02/05/13 59
Processos de Engenharia de Requisitos
Especificação de Requisitos
– Especificação estruturadaEspecificação estruturada● A liberdade do escritor é limitada e os requisitos são
escritos de uma forma padronizada● Garante certa uniformidade sobre a especificação● Faz uso de templates para representar os requisitos
como formulários estruturados
02/05/13 60
Processos de Engenharia de Requisitos
Especificação de Requisitos
– Especificação estruturadaEspecificação estruturada● Estrutura de um formulários
– Descrição da funcionalidade– Entradas e de onde vieram– Saídas e para onde irão– Informação necessário para o processamento– Descrição da ação a ser tomada– Pré e pós condições (se aplicável)– Efeitos colaterais da função (se aplicável)
02/05/13 61
Processos de Engenharia de Requisitos
Especificação de Requisitos
– Especificação estruturadaEspecificação estruturada (Exemplo) (Exemplo)
02/05/13 62
Processos de Engenharia de Requisitos
Especificação de Requisitos
– Especificação estruturadaEspecificação estruturada (Exemplo) (Exemplo)
02/05/13 63
Processos de Engenharia de Requisitos
Visão em Espiral dos processos de engenharia de requisitos
02/05/13 64
Processos de Engenharia de Requisitos
Validação de Requisitos
– Verifica se os requisitos definem o sistema que o cliente realmente quer
– Os custos de requisitos errados são altos● Arrumar um requisito errôneo depois da liberação do
sistema pode custar 100 vezes o preço de se arrumar um erro de implementação.
– Diferentes tipos de verificação devem ser efetuados com os requisitos
02/05/13 65
Processos de Engenharia de Requisitos
Validação de Requisitos
– Tipos de Verificação● Verificação de Validade – O sistema provê as
funcionalidades que melhor atendem a necessidade dos clientes?
● Verificação de Consistência – Existem requisitos conflitantes?
● Verificação de Completude – Todas as funções requeridas pelo cliente estão inclusas?
● Verificação de Realismo – Os requisitos podem ser implementados de acordo com a tecnologia atual?
● Verificabilidade – Os requisitos podem ser conferidos?
02/05/13 66
Processos de Engenharia de Requisitos
Validação de Requisitos
– Técnicas de Verificação● Revisões de Requisitos – Os requisitos são
analisados de forma manual e sistemática● Prototipação – Uso de versões funcionais do sistema
para verificar os requisitos● Geração de Caso de Testes – Desenvolver testes
para os requisitos. Se os testes falharem, então provavelmente os requisitos estão errados
02/05/13 67
Gerenciamento de Requisitos
● É um processo para compreender e controlar as mudanças de requisitos
● Requisitos são, inevitavelmente, incompletos e inconsistentes
– Novos requisitos surgem durante o processo inteiro
– Os diferentes pontos de vista têm requisitos diferentes e estes são frequentemente contraditórios
● Diferentes stakeholders atribuem diferentes prioridades para os mesmos requisitos
● Os ambientes técnico e de negócio do sistema mudam durante seu desenvolvimento
– Novos requisitos surgem
02/05/13 68
Gerenciamento de Requisitos
● É necessário manter a rastreabilidade dos requisitos
● Associar via links os requisitos dependentes
● O gerenciamento de requisitos necessita de apoio automatizado
02/05/13 69
Gerenciamento de Requisitos
Estabelecer decisões de gerenciamento
– Identificar os requisitos - unicamente
– Definir processo de gerenciamento de de mudanças – avaliar o impacto e custos da mudança
– Política de Rastreabilidade - relacionamento entre cada requisito
– Ferramenta de Apoio● Armazenar os requisitos● Gerenciar mudanças● Gerenciar rastreabilidade
02/05/13 70
Gerenciamento de Requisitos
Gerenciamento de Mudança de Requisitos (decidir se aceita ou não uma mudança)
– Deve ser aplicado a todas as mudanças propostas aos requisitos
– Estágios principais:● Análise de problema - discutir problemas e mudanças
de requisitos● Análise de mudança e estimativa de custo - avaliar
os efeitos das mudanças sobre outros requisitos● Implementação de mudança - Modificar vários
artefatos para refletir as mudanças
02/05/13 71
Referências