capitulo_04 - engenharia de requisitos.pptx

Upload: gregori-menegazzo

Post on 10-Oct-2015

5 views

Category:

Documents


0 download

TRANSCRIPT

Figures Chapter 4

Captulo 4

Engenharia de requisitos 2011 Pearson Prentice Hall. Todos os direitos reservados.slide 1

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Tpicos abordadosRequisitos funcionais e no funcionais

O documento de requisitos de software

Especificao de requisitos

Processos de engenharia de requisitos

Elicitao e anlise de requisitos

Validao de requisitos

Gerenciamento de requisitos

2slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Engenharia de requisitosO processo de estabelecer os servios que o cliente necessita do sistema e as restries sob as quais ele opera e desenvolvido.

Os prprios requisitos so as descries dos servios do sistema e restries geradas durante o processo de engenharia de requisitos.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.O que um requisito?Pode variar de uma declarao abstrata de alto nvel de um servio ou de uma restrio do sistema para uma especificao matemtica funcional.

Isso inevitvel quando os requisitos podem servir a uma funo dupla.

Pode ser a base para a proposta de um contrato - portanto, deve ser aberto interpretao;

Pode ser a base para o contrato em si, portanto, deve ser definido em detalhe;

Ambas as declaraes podem ser chamadas de requisitos.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Abstrao de requisitos (Davis)"Se uma empresa quer fechar um contrato para um projeto de desenvolvimento de software de grande porte, deve definir as suas necessidades de forma abstrata o suficiente para que a soluo no seja pr-definida. Os requisitos devem ser escritos de forma que vrios contratantes possam concorrer pelo contrato e oferecer diferentes maneiras de atender s necessidades da organizao do cliente. Uma vez que um contrato tenha sido adjudicado, o contratante deve escrever para o cliente uma definio mais detalhada do sistema, para que esse entenda e possa validar o que o software far. Ambos os documentos podem ser chamados de documentos de requisitos para o sistema.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Tipos de requisitosRequisitos de usurio

Declaraes em linguagem natural com diagramas dos servios que o sistema dever fornecer e suas restries operacionais. Escrito para os clientes.Requisitos de sistema

Um documento estruturado estabelecendo descries detalhadas das funes do sistema, servios e restries operacionais. Define o que deve ser implementado assim, pode ser parte de um contrato entre o cliente e o empreiteiro.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados. Requisitos de usurio e de sistema

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Leitores de diferentes tipos de especificao de requisitos

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Requisitos funcionais e no-funcionaisRequisitos funcionaisO sistema deve fornecer declaraes de servios, como o sistema deve reagir a entradas especficas e como o sistema deve se comportar em determinadas situaes.Pode explicitar o que o sistema no deve fazer.

Requisitos no-funcionaisRestries aos servios ou funes oferecidas pelo sistema, tais como restries de tempo, restries no processo de desenvolvimento, padres.Muitas vezes se aplica ao sistema como um todo ao invs de caractersticas individuais ou servios.

Requisitos de domnioRestries no sistema a partir do domnio de operao

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Requisitos Funcionais Descrever a funcionalidade ou os servios do sistema.

Depende do tipo de software, possveis usurios e o tipo de sistema em que o software usado.

Requisitos funcionais dos usurios podem ser declaraes de alto nvel a respeito do que o sistema deve fazer.

Requisitos funcionais do sistema devem descrever detalhadamente os servios do sistema.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Requisitos funcionais para o MHC-PMSUm usurio deve ser capaz de pesquisar as listas de agendamentos para todas as clnicas.

O sistema deve gerar, a cada dia, para cada clnica, uma lista de pacientes esperados para as consultas daquele dia.

Cada membro da equipe que usa o sistema deve ser exclusivamente identificado pelo seu nmero de funcionrio de 8 dgitos.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Impreciso de requisitosProblemas surgem quando os requisitos no so precisamente definidos.

Requisitos ambguos podem ser interpretados de maneiras diferentes por desenvolvedores e usurios.

Considere o termo 'pesquisa' no requisito 1

A inteno do usurio busca pelo nome de um paciente em todos as consultas em todas as clnicas;

Interpretao do desenvolvedor busca pelo nome de um paciente em uma clnica. O usurio escolhe a clnica e em seguida pesquisa.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Integridade e consistncia dos requisitosEm princpio, os requisitos devem ser completos e consistentes.

Completos

Eles devem incluir descries de todos os servios necessrios.

Consistentes

No devem haver conflitos ou contradies nas descries dos recursos do sistema.

Na prtica, impossvel produzir documentos de requisitos completos e consistentes .

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Requisitos No-funcionaisEsses requisitos definem as propriedades e as restries do sistema por exemplo, confiabilidade, tempo de resposta e ocupao de rea.

As restries so capacidades de dispositivos de E/S, as representaes do sistema, etc.

Os requisitos de processo tambm podem ser especificados impondo um IDE particular, linguagem de programao ou mtodo de desenvolvimento.

Os requisitos no-funcionais podem ser mais crticos do que os requisitos funcionais. Se esses no forem atendidos, o sistema pode ser intil.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Tipos de requisitos no funcionais

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Implementao de requisitos no funcionais Requisitos no-funcionais podem afetar a arquitetura geral de um sistema, em vez de componentes individuais.

Por exemplo, para assegurar que os requisitos de desempenho sejam cumpridos, voc pode ter que organizar o sistema para minimizar a comunicao entre os componentes.

Um nico requisito no-funcional, como um requisito de proteo, pode gerar uma srie de requisitos funcionais relacionados que definem os servios do sistema que so necessrios.

Ele tambm pode gerar requisitos que restringem os requisitos existentes.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Classificaes de requisitos no funcionais Requisitos de produtoRequisitos que especificam que o produto entregue deve se comportar de uma maneira particular, por exemplo velocidade de execuo, confiabilidade, etc.

Requisitos organizacionaisRequisitos que so consequncia de polticas e procedimentos organizacionais, por exemplo padres de processo usados, requisitos de implementao, etc.

Requisitos externosRequisitos que surgem de fatores externos ao sistema e seu processo de desenvolvimento, por exemplo, requisitos de reguladores, requisitos legais, etc.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Exemplos de requisitos no funcionais no MHC-PMS

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Metas e requisitosRequisitos no-funcionais podem ser muito difceis de se definir precisamente e requisitos imprecisos podem ser difceis de se verificar.

MetasA inteno geral do usurio, facilmente usvel.

Requisito no-funcional mensurvel.Uma declarao usando alguma mtrica que pode ser objetivamente testada.

Metas so teis para desenvolvedores quando exprimem as intenes dos usurios do sistema.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Requisitos de UsabilidadeO sistema deve ser de fcil uso pelo pessoal mdico e deve ser organizado de tal forma que os erros dos usurios sejam minimizados. (Meta)

A equipe mdica deve ser capaz de usar todas as funes do sistema depois de quatro horas de treinamento.

Aps esse treinamento, o nmero mdio de erros cometidos pelos usurios experientes no deve exceder dois por hora de uso do sistema. (Requisito no-funcional testvel)

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Mtricas para especificar requisitos no funcionais

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Requisitos de domnioO domnio operacional do sistema impe requisitos ao sistema.

Por exemplo, um sistema de controle de trem deve levar em conta as caractersticas de frenagem em diferentes condies climticas.

Requisitos de domnio criam novos requisitos funcionais, restries sobre requisitos existentes ou definem clculos especficos.

Se os requisitos de domnio no forem satisfeitos, o sistema pode ser impraticvel.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Sistema de segurana de tremEsse um requisito de domnio de um sistema de segurana de um trem:

A desacelerao do trem deve ser computada como:

Dtrain = Dcontrol + Dgradient

onde Dgradient 9.81ms2 * gradiente / alfa compensado e onde os valores de 9.81ms2 / alpha so conhecidos para diferentes tipos de trem.

difcil para um no-especialista entender as implicaes desse requisito e de como ele interage com outros requisitos.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Problemas de requisitos de domnioCompreensibilidade

Requisitos so expressos na linguagem do domnio da aplicao;

O que geralmente no compreendido pelos engenheiros de software que desenvolvem o sistema.

Implicitude

Especialistas de domnio compreendem to bem essa rea que eles no pensam em tornar explcitos os requisitos de domnio.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Pontos importantesOs requisitos para um sistema de software estabelecem o que o sistema deve fazer e definir restries sobre o seu funcionamento e implementao.

Os requisitos funcionais so declaraes dos servios que o sistema deve fornecer ou so descries de como alguns processamentos devem ser realizados.

Muitas vezes os requisitos no-funcionais, limitam o sistema a ser desenvolvido e o processo de desenvolvimento a ser usado.

Muitas vezes eles se relacionam com as propriedades emergentes do sistema e, portanto, se aplicam ao sistema como um todo.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.O documento de requisitos de softwareO documento de requisitos de software a declarao oficial do que demandado dos desenvolvedores do sistema.

Deve incluir ambas, uma definio de requisitos do usurio e uma especificao de requisitos do sistema.

NO um documento de projeto. Na medida do possvel, deve definir O QUE o sistema deve fazer ao invs de COMO deve faz-lo.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Requisitos e Mtodos geis Muitos mtodos geis argumentam que a produo de um documento de requisitos um desperdcio de tempo pois esses mudam rapidamente.

Portanto, o documento estar sempre desatualizado.

Mtodos geis, tais como XP usam a engenharia de requisitos incrementais e expressam os requisitos como estrias de usurio" (discutido no Captulo 3).

O que prtico para os sistemas de negcios, mas problemtico para sistemas que exigem vrias anlises pr-entrega (por exemplo, sistemas crticos) ou sistemas desenvolvidos por vrias equipes.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Usurios de um documento de requisitos

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Usurios de um documento de requisitos

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Variabilidade do documento de requisitosAs informaes no documento de requisitos dependem do tipo de sistema e da abordagem de desenvolvimento usada.

Normalmente, os sistemas desenvolvidos de forma incremental tero menos detalhes no documento de requisitos.

Os padres dos documentos de requisitos foram concebidos, tendo como exemplo, a norma IEEE.

Esses so aplicveis, principalmente, aos requisitos para projetos de engenharia de sistemas de grande porte.slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.A estrutura de um documento de requisitos

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.A estrutura de um documento de requisitos

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.O processo de escrever os requisitos de usurio e de sistema em um documento de requisitos.

Os requisitos precisam ser compreensveis para usurios finais e clientes que no tm formao tcnica.

Requisitos de sistema so mais detalhados e podem incluir informaes mais tcnicas.

Os requisitos podem ser parte de um contrato para o desenvolvimento do sistema.

Portanto, importante que esses sejam to completos quanto possvel.Especificao de requisitosslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Formas de escrever uma especificao de requisitos de sistema

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Em princpio, os requisitos devem indicar o que o sistema deve fazer e o projeto deve descrever como fazer isso.

Na prtica, os requisitos e o projeto so inseparveisA arquitetura do sistema pode ser projetada para estruturar os requisitos;

O sistema pode interoperar com outros sistemas que restringem o projeto e impem requisitos sobre o novo sistema;

O uso de uma arquitetura especfica para satisfazer os requisitos no funcionais pode ser um requisito de domnio.

Essa pode ser a consequncia de um requisito de um regulador.to completos quanto possvel.Projeto e requisitos slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Os requisitos so escritos como sentenas em linguagem natural complementadas por diagramas e tabelas.

Usado para escrever os requisitos, pois expressivo, intuitivo e universal.

Isso significa que os requisitos podem ser entendidos pelos usurios e pelos clientes.Especificao em linguagem naturalslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Inventar um formato padro e us-lo para todos os requisitos.

Usar a linguagem de uma forma consistente.

Usar deve para requisitos obrigatrios e pode para os requisitos desejveis.

Usar o realce de texto para identificar as partes fundamentais do requisito.

Evitar o uso de jarges de computador.

Incluir uma justificativa (lgica) de por que um requisito necessrio.Diretrizes para escrever requisitosslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Falta de clareza

difcil conseguir preciso sem tornar o documento de difcil leitura.

Confuso de requisitos

Requisitos funcionais e no funcionais tendem a ser misturados.

Amlgama de requisitos

Vrios requisitos diferentes podem ser expressos juntos.Problemas com a linguagem naturalslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Exemplo de requisitos para o sistema de software de bomba de insulina

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Uma abordagem para escrever requisitos em que a liberdade do escritor de requisitos limitada e os requisitos so escritos de uma maneira padro.

Isso funciona bem para alguns tipos de requisitos, por exemplo, requisitos para o sistema embutido de controle, mas s vezes demasiado rgido para escrever os requisitos de sistema de negcios.Especificaes estruturadasslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Definio da funo ou entidade.

Descrio de entradas e de onde eles vm.

Descrio das sadas e para onde iro.

Informaes sobre as informaes necessrias para o processamento e outras entidades usadas.

Descrio da ao a ser tomada.

Pr-ps condies (se for o caso).

Os efeitos colaterais (se houver) da operao.Especificaes baseadas em formulriosslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Uma especificao estruturada de um requisito para uma bomba de insulina

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Usados para complementar a linguagem natural.

Particularmente til quando necessrio definir um nmero de situaes alternativas possveis.

Por exemplo, o sistema de bomba de insulina baseia seus clculos sobre a taxa de mudana de nvel de acar no sangue e a especificao tabular explica como calcular a necessidade de insulina para diferentes cenrios.Especificao tabularslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Especificao tabular de processamento para uma bomba de insulina

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Os processos usados para a engenharia de requisitos variam muito, dependendo do domnio da aplicao, das pessoas envolvidas e da organizao que desenvolve os requisitos.

No entanto, existe uma srie de atividades genricas comuns a todos os processosElicitao de requisitos;Anlise de requisitos;Validao de requisitos;Gerenciamento de requisitos.

Na prtica, engenharia de requisitos uma atividade iterativa em que estes processos so intercalados.Processos de engenharia de requisitosslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Uma viso em espiral do processo de engenharia de requisitos

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.s vezes chamada de elicitao ou descoberta de requisitos.

Envolve tcnicos trabalhando com os clientes para levantar dados sobre o domnio da aplicao, os servios que o sistema deve fornecer e as restries operacionais do sistema.

Pode envolver usurios finais, gerentes, engenheiros envolvidos na manuteno, especialistas de domnio, sindicatos, etc.

Esses so chamados stakeholders.Elicitao e anlise de requisitosslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Engenheiros de software trabalham com uma gama de stakeholders do sistema para descobrir sobre o domnio da aplicao, os servios que o sistema deve fornecer, o desempenho do sistema necessrios, restries de hardware, outros sistemas, etc.

Estgios incluem:Descoberta de requisitos,

Classificao e organizao de requisitos,

Priorizao e negociao de requisitos,

Especificao de requisitos.

Elicitao e anlise de requisitosslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.O processo de elicitao e anlise de requisitos

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Os stakeholders no sabem o que realmente querem.

Os stakeholders expressam requisitos em seus prprios termos.

Diferentes stakeholders podem ter requisitos conflitantes.

Fatores polticos e organizacionais podem influenciar os requisitos de sistema.

Os requisitos mudam durante o processo de anlise. Novos stakeholders podem surgir e o ambiente de negcios pode mudar.Problemas de anlise de requisitosslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.O documento de requisitos de software uma declarao dos requisitos do sistema acordada.

Deve ser organizada de forma que os clientes do sistema e desenvolvedores de software possam us-la.

O processo de engenharia de requisitos um processo iterativo incluindo um estudo de viabilidade, elicitao e anlise, especificao e validao de requisitos.

A elicitao e anlise um processo iterativo que pode ser representado como uma espiral de atividades descoberta de requisitos, classificao e organizao de requisitos, negociao de requisitos e documentao de requisitos.Pontos importantesslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.O processo de coleta de informaes sobre os sistemas necessrios e os existentes, e separar os requisitos do usurio e sistema dessas informaes.

A interao com os stakeholders do sistema desde os gerentes at os reguladores externos.

Normalmente, os sistemas tm vrios stakeholders.Descoberta de requisitosslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Pacientes cujas informaes so registradas no sistema.

Mdicos que so responsveis por avaliar e tratar os pacientes.

Enfermeiros que coordenam as consultas com mdicos e administram alguns tratamentos.

Recepcionistas dos mdicos que gerenciam as consultas dos pacientes.

A equipe de TI responsvel pela instalao e manuteno do sistema.Stakeholders no MHC-PMSslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Um gerente de tica mdica, que deve garantir que o atual sistema atenda s diretrizes ticas para o cuidado do paciente.

Gerentes de cuidados de sade que obtiverem informaes de gerenciamento do sistema.

Registros mdicos, equipes responsveis por garantir que as informaes do sistema possam ser mantidas e preservadas, e que a manuteno de registros foi executada corretamente.Stakeholders no MHC-PMSslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Entrevistas formais ou informais com os stakeholders fazem parte da maioria dos processos de engenharia de requisitos.

Tipos de entrevistaEntrevistas fechadas com base em uma lista de perguntas pr-determinada.Entrevistas abertas, em que vrias questes so exploradas com os stakeholders.

Entrevistar eficazmenteTer a mente aberta, evitar ideias pr-concebidas sobre os requisitos e estar disposto a ouvir os stakeholders. Induzir os entrevistados a discutir usando uma questo trampolim, uma proposta de requisitos, ou trabalhando em conjunto em um sistema prottipo.Entrevistasslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Normalmente, uma mistura de entrevistas fechadas e abertas.

Entrevistas so boas para a obteno de um entendimento geral do que os stakeholders fazem e como eles podem interagir com o sistema.

Entrevistas no so boas para a compreenso dos requisitos de domnio:

Engenheiros de requisitos no podem entender a terminologia especfica de domnio;

Algum conhecimento de domnio to familiar que as pessoas acham difcil articular ou pensam que no vale a pena articular.Entrevistas, na prticaslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Cenrios so exemplos da vida real de como um sistema pode ser usado.

Eles devem incluir:

A descrio da situao inicial;

A descrio do fluxo normal de eventos;

A descrio do que pode dar errado;

Informaes sobre outras atividades concorrentes;

A descrio do estado do sistema quando o cenrio acaba.Cenriosslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Cenrio para a coleta do histrico mdico em MHC-PMS

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Cenrio para a coleta do histrico mdico em MHC-PMS

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Casos de uso uma tcnica da UML baseada em cenrios que identificam os atores em uma interao e que descreve a interao em si.

Um conjunto de casos de uso deve descrever todas as possveis interaes com o sistema.

Modelo grfico de alto nvel complementado por uma descrio tabular mais detalhada.

Diagramas de sequncia podem ser usados para adicionar detalhes aos casos de uso, mostrando a sequncia de processamento de eventos no sistema.Casos de usoslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Casos de uso para o MHC-PMS

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Um analista gasta um tempo considervel observando e analisando como as pessoas realmente trabalham.

As pessoas no precisam explicar ou articular seu trabalho.

Podem ser observados fatores sociais e organizacionais de importncia.

Estudos etnogrficos tm mostrado que o trabalho geralmente mais rico e complexo do que o sugerido pelos modelos simples de sistemas.Etnografiaslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Requisitos que so derivados da maneira como as pessoas realmente trabalham e no da maneira como as definies de processo sugerem que elas deveriam trabalhar.

Requisitos que so derivados da cooperao e conscientizao das atividades das outras pessoas.

Conscincia do que outras pessoas esto fazendo leva a mudanas no modo como fazemos as coisas.

A etnografia eficaz para a compreenso dos processos existentes, mas no pode identificar novos recursos que devem ser adicionados a um sistema.mbito da etnografiaslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Desenvolvida em um projeto de estudo do processo de controle do trfego areo.

Combina etnografia com prototipao.

O desenvolvimento de prottipos resultou em questes sem respostas, as quais se centram na anlise etnogrfica.

O problema com a etnografia que ela estuda as prticas existentes, as quais podem ter alguma base histrica que no continua sendo relevante.Etnografia focadaslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Etnografia e prototipao para anlise de requisitos

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Preocupados em demonstrar se os requisitos definem o sistema que o cliente realmente quer.

Os custos de erros de requisitos so altos, logo, a validao muito importante.

Corrigir um erro de requisitos aps a entrega pode custar at 100 vezes o custo de corrigir um erro de execuo.Validao de requisitosslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Validade. O sistema fornece as funes que melhor atendem s necessidades do cliente?

Consistncia. Existe algum conflito de requisitos?

Completude. Esto includas todas as funes e restrioes requeridas pelo cliente ?

Realismo. Os requisitos podem ser implementados com o oramento e a tecnologia disponveis?

Verificabilidade. Os requisitos podem ser verificados?Verificao de requisitos slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Revises de requisitos

Anlise manual sistemtica dos requisitos.

Prototipao

Usando um modelo executvel do sistema para verificar os requisitos.

Gerao de casos de teste

Desenvolvimento de testes para verificar os requisitos implementados.

Tcnicas de validao dos requisitosslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Revises peridicas devem ser feitas enquanto a definio dos requisitos est sendo formulada.

Ambos, cliente e fornecedor, devem ser envolvidos nas revises.

Os comentrios podem ser formais (com documentos completos) ou informais.

Uma boa comunicao entre os desenvolvedores, clientes e usurios pode resolver os problemas numa fase inicial.

Revises de requisitosslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.VerificabilidadeA exigncia realmente testvel?

CompreensibilidadeO requisito adequadamente compreendido?

RastreabilidadeA origem do requisito clara?

AdaptabilidadeO requisito pode ser alterado sem causar um grande impacto sobre outros requisitos?

Avaliao da revisoslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Gerenciamento de requisitos o processo de gerenciar os requisitos em constante mudana durante o processo de engenharia de requisitos e desenvolvimento de sistemas.

Aps o sistemas comear a ser usado, surgem novos requisitos.

preciso manter o controle das necessidades individuais e manter ligaes entre os requisitos dependentes para que voc possa avaliar o impacto das mudanas nos requisitos.

necessrio estabelecer um processo formal para fazer propostas de mudana e ligar essas aos requisitos de sistema.

Gerenciamento de requisitosslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.O ambiente tcnico e de negcios do sistema sempre muda aps a instalao.

Um novo hardware pode ser introduzido, pode ser necessrio para a interface do sistema com outros sistemas, as prioridades do negcio podem mudar (com as consequentes alteraes no sistema de apoio necessrio) e, podem ser que o sistema deve, necessariamente, respeitar.

As pessoas que pagam por um sistema e os usurios desse sistema raramente so as mesmas pessoas.

Clientes do sistema impem requisitos devido a restries oramentais e organizacionais. Esses podem entrar em conflito com os requisitos do usurio final e, aps a entrega, pode ser necessrio adicionar novos recursos para suporte ao usurio, caso o sistema seja para atender a seus objetivos.

Mudanas nos requisitosslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Sistemas de grande porte costumam ter uma comunidade de usurios diversos, com muitos usurios tendo necessidades diferentes e prioridades que podem ser conflitantes ou contraditrias.

Os requisitos do sistema final so, inevitavelmente, um compromisso entre eles e, a experincia mostra que, muitas vezes se descobre que o balano de apoio dado aos diferentes usurios precisa ser mudado.

Mudanas nos requisitosslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Evoluo dos requisitos

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Estabelece o nvel de detalhamento necessrio para o gerenciamento de requisitos. Decises do gerenciamento de requisitos:

Identificao de requisitos. Cada requisito deve ser identificado exclusivamente para que ele possa ser comparado com outros requisitos.Processo de gerenciamento de mudanas. Esse o conjunto de atividades que avaliam o impacto e o custo das mudanas. Esse processo discutido em mais detalhes na seo seguinte.Polticas de rastreabilidade. Essas polticas definem as relaes entre cada requisito e entre os requisitos e o projeto do sistema que deve ser registrado.Ferramentas de suporte. As ferramentas de suporte que podem ser usadas variam desde sistemas especialistas, sistemas de gerenciamento de requisitos at planilhas e sistemas de banco de dados simples.

Planejamento de gerenciamento de requisitos slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Decidir se uma mudana de requisitos deve ser aceita.

Anlise de problema e especificao de mudanasDurante essa fase, o problema ou a proposta de mudana analisada para verificar se vlida. O feedback dessa anlise devolvido para o solicitante, que pode responder com uma proposta mais especfica de mudana dos requisitos, ou decidir retirar o pedido.

Anlise de mudanas e custosO efeito da mudana proposta avaliado por meio de informaes de rastreabilidade e conhecimento geral dos requisitos do sistema. Uma vez que essa anlise concluda, toma-se a deciso de prosseguir ou no com a mudana de requisitos.

Gerenciamento de mundana de requisitosslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Implementao de mudanas

O documento de requisitos e, se necessrio, o projeto e implementao do sistema, so modificados. Idealmente, o documento deve ser organizado de modo que as mudanas possam ser facilmente implementadas.

Gerenciamento de mundana de requisitosslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Gerenciamento de mudana de requisitos

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Voc pode usar uma variedade de tcnicas para a elicitao de requisitos, incluindo entrevistas, cenrios, casos de uso e etnografia.

A validao dos requisitos o processo de verificao da validade, consistncia, completude, realismo e verificabilidade dos requisitos.

Mudanas organizacionais e tcnicas, e de negcios, inevitavelmente levam a mudanas nos requisitos de um sistema de software.

O gerenciamento dos requisitos o processo de gerenciamento e controle dessas mudanas.

Pontos importantesslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.