Verificação e Validação de Requisitos

Apresentação em tema: "Verificação e Validação de Requisitos"— Transcrição da apresentação:

1 Verificação e Validação de Requisitos

2 Verificação e Validação dos Requisitos
Casos de Uso e Esp. Suplementar Plano e Casos de Teste Requisitos p/ Inspeção Verificar conflitos de requisitos Verificar consistência de requisitos Verificar completude de requisitos Verificar existência de requisitos ambíguos Inspetor Garantir a rastreabilidade dos requisitos Validar requisitos com o cliente Analista de Requisitos Especificação de Requisitos Atualizada Resultado dos Casos de Teste

3 Diretrizes para uma boa especificação
Separe funcionalidade de implementação É necessária uma linguagem de especificação de sistemas orientada ao processo A especificação deve abranger o sistema do qual o software é um componente Uma especificação deve abranger o ambiente no qual o sistema opera Uma especificação de sistema deve ser um modelo cognitivo Uma especificação deve ser operacional A especificação do sistema deve ser tolerante com a não completude e ser expansível Uma especificação deve ser localizada e fracamente acoplada (Balzer, Goldman, Wile, 1978) 2 – não irá utilizar Diagramas de Computação 3 – entender o todo 8 – cada “assunto” deve estar localizado em um único lugar e com “fraca” dependência.

4 Revisão da Especificação (nível macroscópico)
Os revisores tentam garantir que a especificação seja completa, consistente e precisa Questões: Metas e objetivos do software permanecem consistentes com metas e objetivos do sistema? O fluxo e a estrutura de informação são adequadamente definidas para o domínio da informação? O modelo de casos de uso estão claros? Foram descritas as interfaces importantes para todos os elementos do sistema?

5 Revisão da Especificação (nível macroscópico)
As funções importantes permanecem dentro do escopo e cada uma foi adequadamente descrita? O comportamento do software é consistente com a informação que ele deve processar e as funções que deve executar? As restrições de projeto são realísticas? Qual é o risco tecnológico de desenvolvimento? Requisitos de software alternativos foram considerados? Critérios de Validação foram declarados detalhadamente? Eles são adequados para descrever um sistema bem sucedido? Existem inconsistências, omissões ou redundâncias? Como as estimativas do Plano de Projeto de Software foram afetadas?

6 Revisão da Especificação (nível detalhado)
A preocupação é com o enunciado da especificação. Tenta-se descobrir problemas que possam estar ocultos no conteúdo da especificação Diretrizes: Esteja alerta para perceber conectivos persuasivos (certamente, claramente, obviamente) e perguntar por que eles estão presentes Procure termos vagos e peça esclarecimento (algum, às vezes, usualmente, freqüentemente) Quando forem fornecidas listas que não sejam completas, certifique-se de que todos os itens sejam entendidos (evite colocar etc, tal como, assim por diante)

7 Revisão da Especificação (nível detalhado)
Esteja certo de que os limites declarados não contenham pressuposições não declaradas “os códigos válidos variam de 0 a 100” - números inteiros ou reais? Cuidado com verbos vagos. Há muitas maneiras de interpretá-los manuseado, rejeitado, pulado Cuidado com pronomes "pendentes” o módulo I/O comunica-se com o módulo de validação de dados e seu sinal de controle está ligado. Sinal de controle de qual dos dois módulos? Procure declarações que impliquem certeza (sempre, cada, todos, nunca) e depois peça prova

8 Revisão da Especificação (nível detalhado)
Quando um termo for explicitamente definido num lugar, evite utilizar outras definições para o mesmo termo (normalização dos termos: documento - arquivo) Quando uma estrutura for descrita em palavras, verifique se há um gráfico ou uma figura para auxiliar a compreensão Quando um cálculo for especificado, desenvolva pelo menos dois exemplos Quando uma estrutura for descrita em palavras, verifique se há um gráfico ou uma figura para auxiliar a compreensão: pode ser colocado no campo outros do Doc. De Caso de Uso. Figuras são importantes para áres isoladas como, por exemplo, “poços de perfuração de petróleo”.

9 Desenvolvimento orientado a reuso
Abordagem já tratada no início do curso, agora vai-se abordar o “reuso”

10 O que vem depois? A especificação de Requisitos e os modelos elaborados na Análise são a base para o design do sistema A fase de design vai evoluir os modelos incorporando características de implementação Neste momento é importante uma abordagem gerencial para incrementar a produtividade é importante garantir que os modelos do software atendam aos requisitos

11 Desenvolvimento orientado a reuso
Baseado em reutilização de componentes de software Podem ser acessados com alguma infra-estrutura de integração para estes componentes Design com reuso: reuso de sistemas de aplicações: COTS reuso de componentes reuso de funções Vantagens: reduzir a quantidade de software a ser desenvolvido reduzir o prazo de desenvolvimento reduzir os custos Escolhe no mercado o que tem disponível e faz o mínimo de customização para ele. A elicitação de requisitos não começa do “zero”. Sommerville, pag. 260. Projeto com reuso: Reuso de sistemas de aplicações: COTS (produtos de prateleiras) Reuso de componentes Reuso de funções

12 COTS (Commercial off-the-shelf)
Sistemas COTS COTS (Commercial off-the-shelf) Produtos de Prateleira: componente oferecido por um terceiro Um sistema de aplicações pode ser reutilizado pela sua incorporação, sem mudança, em outros sistemas Exemplo: Sistemas de Comércio Eletrônico Base de Dados Compra e Venda de Produtos (carrinho de compra) Processo de Pagamento Sommerville, pag. 267 Ex. COTS: SAP, Portais Oracle... BR tem interfaces reutili’zaveis...

13 Desvantagens: Sistemas COTS
O produto final pode não ser aquele que o cliente pediu Adequação dos requisitos é inevitável Problemas com interoperabilidade de sistemas COTS Controle fraco sobre a evolução do sistema Suporte técnico dos fabricantes de COTS O fato destes produtos serem usualmente sistemas grandes em si e que são freqüentemente vendidos como “stand-alone” (separados) apresentam alguns problemas adicionais. Os requisitos não funcionais são muito importantes neste contexto. Sommerville, pg. 267 e 268.

14 Validação dos Requisitos

15 Validação dos Requisitos
Será que realmente entendí o que o cliente deseja? Devo me certificar de que não houve falha em nossa interação (comunicação) Há diversas técnicas de validação

16 Validação de Requisitos
Demonstrar que os requisitos definem o sistema que o cliente realmente deseja Custos com erros de requisitos são altos Consertar um erro de requisitos após entrega do sistema pode custar mais de 100 vezes o custo de um erro de implementação

17 Validação de Requisitos
Validade: O sistema possui as funções para suprir as necessidades dos usuários? Completude: Foram incluídas todas as funções requisitadas pelo cliente? Consistência: Existe algum requisito conflitante? Não ambíguos: Todos estão descritos de forma clara e objetiva? Verificação: Os requisitos podem ser verificados? Rastreáveis: os requisitos tem definidos: A origem? As interdependências entre os requisitos? Os relacionamentos com os diagramas de projeto e componentes de implementação? Usar checklist para validar requisitos. A equipe de inspeção também avalia se os requisitos estão: · Corretos – estão associados aos objetivos e necessidades do projeto; · Completos – se os requisitos definidos são suficientes para atender as necessidades do cliente; . Consistentes entre si – se não há nenhum requisitos conflitante ou contraditório; · Não ambíguos – todos estão descritos de forma clara e objetiva; · Verificáveis (testáveis) – se são passíveis de teste e se podem ser objetivamente validados; · Rastreáveis – os requisitos tem definidos a origem, as interdependências entre os requisitos e os relacionamentos com os diagramas de projeto e componentes de implementação. A Validação dos requisitos é feita em dois âmbitos: o primeiro técnico pela equipe de testes e o segundo pelo cliente. Fonte: Plano de Gerenciamento de Requisitos (PETROBRAS) Realismo: Os requisitos podem ser implementados considerando o orçamento e as tecnologias? Sommerville, pag. 116

18 Técnicas de Validação de Requisitos
Revisões de Requisitos Análise manual sistemática dos requisitos Prototipação Uso de modelo “executável” (interfaces) do sistema para avaliar requisitos Geração de Casos de Teste Desenvolver testes específicos para avaliar os requisitos Análise de Consistência Automática Avaliar uma especificação dos requisitos Sommerville, pag. 116

19 Processo de Projeto de Sistemas - Prototipação

20 Processo de Projeto de Sistemas - Prototipação
Uma forma de avaliação de interface é a prototipação Provê a avaliação das interfaces junto aos clientes, com o auxílio de técnicas apropriadas (usabilidade) A partir desta avaliação um novo ciclo de especificação, prototipação e avaliação deve ser realizada Prototipação é fundamental para mensurar por Pontos por Funções

21 Processo de Projeto de Interfaces

22 A prototipação é parte essencial do processo de projeto de interface
O protótipo permite ao projetista avaliar seu projeto ao longo do processo de criação A prototipação é parte essencial do processo de projeto de interface

23 Prototipação O esforço envolvido na especificação, no projeto e na implementação de uma interface com o usuário representa parte significativa dos custos de desenvolvimento de aplicações Como este é um artefato não-acabado e com finalidade de testes, a sua construção deve ser rápida e de baixo custo

24 Ferramenta para especificar e gerenciar requisitos

25 Ferramentas de Especificação Automatizadas
1a categoria: técnicas automatizadas que nada mais são do que um método manual que foi complementado com uma ferramenta CASE possibilitam que o analista atualize informações e rastreie as conexões entre representações novas e existentes do sistema Ex: RequisitePro (IBM) Texto sugerido para leitura: Os cinco níveis de maturidade na gestão de requisitos. Texto retirado do site: Outros exemplos de ferramentas: DEC Design (Digital Equipment Corp.), Design Aid (Transform Logic Corp.), Excelerator (Intersolv), IEF (Texas Instruments), ADW (Knowledgeware), STP (Interative Development Environments), Teamwork (Cadre Technologies).

26 Ferramentas de Especificação Automatizadas
2a categoria: técnicas automatizadas que fazem uso de uma notação especial (na maioria dos casos, essa é uma linguagem de especificação de requisitos) que foi explicitamente projetada para processamento usando-se uma ferramenta automatizada Ex: PSL/PSA (linguagem de especificação: PSL)

27 Rastreabilidade e Gestão de Mudanças

28 Rastreabilidade e Gestão de Mudanças
Necessidade Avaliar o impacto nos requisitos Validar com o cliente Notificar os envolvidos Atualizar as especificações de requisitos Garantir a rastreabilidade nos requisitos Analista de Negócios Solic. Mudança Analista de Requisitos Especificação de Requisitos Atualizada Documento de Visão Atualizado

29 Requisitos são inevitavelmente incompletos e inconsistentes
Gerência de Mudanças Requisitos são inevitavelmente incompletos e inconsistentes Requisitos novos surgem durante o processo mudanças nas necessidades do negócio melhor entendimento do sistema que está sendo desenvolvido Diferentes pontos de vista têm diferentes requisitos e esses geralmente são contraditórios É função do analista durante a elicitação de requisitos identificar Requisitos contraditórios Tendências de mudanças Um Sistema de CM é útil para gerenciar diversas variantes de sistemas de software em desenvolvimento, controlando as versões que são usadas em determinados builds do software, compilando builds de programas individuais ou de releases inteiras de acordo com especificações de versão definidas pelo usuário e impondo políticas de desenvolvimento específicas do site. Alguns dos benefícios diretos obtidos pelo uso de um Sistema de CM incluem: - suporte a métodos de desenvolvimento, - preservação da integridade do produto, - garantia de abrangência e precisão do produto configurado, - ambiente estável no qual o produto deve ser desenvolvido, - Restrição das mudanças feitas nos artefatos com base nas políticas do projeto e - trilha de auditoria indicando por que, quando e por quem um artefato foi alterado. Além disso, um Sistema de CM armazena dados detalhados sobre a 'contabilidade' do processo de desenvolvimento: quem criou uma versão específica (e também quando e por que), quais versões dos códigos-fonte foram usadas em um determinado build, além de outras informações relevantes. Fonte: RUP

30 Processo de Gerência de Mudanças
== Explicar figura Fonte: Sommerville, 2003, pag No gerenciamento de requisitos deve-se controlar as mudanças dos requisitos durante o processo da engenharia de requisitos e desenvolvimento do sistema

31 Funciona como um padrão oficial básico para os trabalhos subseqüentes
O que é Baseline ? Baseline – linha base Uma baseline é uma 'imagem' de uma versão de cada artefato no repositório do projeto Funciona como um padrão oficial básico para os trabalhos subseqüentes Somente mudanças autorizadas podem ser efetuadas na baseline Uma baseline de requisitos é uma versão da especificação de requisitos Todo o conjunto Uma baseline é uma 'imagem' de uma versão de cada artefato no repositório do projeto. Ela funciona como um padrão oficial básico para os trabalhos subseqüentes. Somente mudanças autorizadas podem ser efetuadas na baseline. Depois do estabelecimento de uma baseline inicial, toda mudança feita na baseline será registrada como um elemento delta até a próxima baseline ser definida.  Quando iniciam um projeto, os desenvolvedores preenchem suas áreas de trabalho com versões de diretórios e arquivos representadas por uma baseline. À medida que o tempo passa, a baseline incorpora o trabalho concluído pelos desenvolvedores desde a criação da última baseline. Depois que as mudanças são incorporadas à baseline, os desenvolvedores consultam essa nova baseline para se manterem atualizados com as últimas mudanças ocorridas no projeto. A criação de uma nova baseline insere arquivos do espaço de trabalho de integração no espaço de trabalho de desenvolvimento. Explicação Os três principais motivos para a criação de baselines são reprodutibilidade, rastreabilidade e elaboração de relatórios. Reprodutibilidade é a capacidade de retroceder no tempo e reproduzir determinado release de um sistema de software ou determinado ambiente de desenvolvimento do projeto. A rastreabilidade estabelece o relacionamento entre predecessor e sucessor nos artefatos do projeto. Sua finalidade é garantir que o design atenda aos requisitos, o código implemente o design e os executáveis sejam criados com o código correto. A elaboração de relatórios baseia-se na comparação do conteúdo das baselines. A comparação de baselines ajuda na depuração e criação de notas de release. Quando as baselines são criadas, todos os componentes e baselines que compõem essa nova baseline precisam ser rotulados para que possam ser identificados com exclusividade e recriados. A criação de baselines apresenta várias vantagens: Um baseline oferece um ponto estável e uma imagem dos artefatos de desenvolvimento. É a partir desse ponto estável que os novos projetos podem ser criados. O novo projeto, como uma ramificação separada, pode ser isolado das mudanças subseqüentes que serão efetuadas no projeto original (na ramificação principal). Os desenvolvedores podem individualmente utilizar componentes de baseline como base para atualizações em seus espaços de trabalho privados e isolados. Uma baseline permite que a equipe desfaça as mudanças caso as atualizações sejam consideradas instáveis ou não confiáveis. Uma baseline permite reproduzir erros reportados, pois você pode recriar a configuração de determinado release. Uso Crie baselines regularmente para manter os desenvolvedores sincronizados com o trabalho de cada um. Entretanto, durante o curso do projeto, as baselines devem ser criadas rotineiramente ao fim de iterações (marcos secundários) e de marcos principais associados ao encerramento de fases do ciclo de vida: - Marco dos Objetivos do Ciclo de Vida (Fase de Iniciação) - Marco da Arquitetura do Ciclo de Vida (Fase de Elaboração) - Marco da Capacidade Operacional Inicial (Fase de Construção) - Marco de Release do Produto (Fase de Transição Fonte: Rational Unified Process (RUP): 

32 O Gerenciamento de Mudanças envolve:
Gerência de Mudanças O Gerenciamento de Mudanças envolve: a identificação da baseline de requisitos a restrição de mudanças a auditoria das mudanças Que mudanças já foram efetuadas? Por que? Quais os problemas? Uma mudança nos requisitos pode implicar em alterações em um ou mais modelos subsequentes do software Os métodos, os processos e as ferramentas utilizados para o gerenciamento de configuração e mudança de uma organização podem ser considerados como o Sistema de CM da organização. O Sistema de Gerenciamento de Configuração e Solicitações de Mudança (Sistema de CM) de uma organização contém informações-chave sobre os processos de desenvolvimento, promoção, implantação e manutenção de produtos da organização e armazena a base de ativos de artefatos potencialmente reutilizáveis resultantes da execução desses processos. O Sistema de CM é parte fundamental e integrante dos processos gerais de desenvolvimento. Fonte: RUP

33 Mudança Gerência de Mudanças
Terá que ser efetuado um planejamento para acomodação da mudança Custo Prazo Revisar requisitos para evitar a introdução de conflitos Questionar stakeholders que especificaram um requisito sendo alterado para obter concordância com a alteração Os métodos, os processos e as ferramentas utilizados para o gerenciamento de configuração e mudança de uma organização podem ser considerados como o Sistema de CM da organização. O Sistema de Gerenciamento de Configuração e Solicitações de Mudança (Sistema de CM) de uma organização contém informações-chave sobre os processos de desenvolvimento, promoção, implantação e manutenção de produtos da organização e armazena a base de ativos de artefatos potencialmente reutilizáveis resultantes da execução desses processos. O Sistema de CM é parte fundamental e integrante dos processos gerais de desenvolvimento. Fonte: RUP

34 Rastreabilidade

35 Rastreamento de Origem
Rastreabilidade Responsável por dependências entre requisitos, suas origens e projeto do sistema Rastreamento de Origem Associação entre requisitos e stakeholders que propuseram tais requisitos

36 Rastreamento de Requisitos Rastreamento de Projeto
Rastreabilidade Rastreamento de Requisitos Associação entre requisitos dependentes Rastreamento de Projeto Associação dos requisitos com o projeto Usar hipertexto ou referência cruzada Ou matriz de rastreamento

37 Detalhados (Casos de Uso)
Rastreabilidade Requisitos Req A 1 Requisitos Detalhados (Casos de Uso) Req B 2 3 4 Baseados nesta estrutura, nós precisamos então estabelecer vínculos de rastreabilidade entre todos requisitos associados ou outros elementos de projeto. Projeto Teste Doc. Usuário Modelos Suítes Teste Plano

38 Rastreabilidade: Análise de Impacto
RequisitePro provides what are called “suspect links”, which notify that an associated requirement has changed. All directly related requirements should be reviewed to assess whether they are impacted. Why is the link from Req B to Req C not marked as suspect? Because it will only go suspect if B actually changes. The only way to resolve these are manually (by actually looking at the changes and the affected requirements). You can probably make a *lot* of money if you could figure out a way to do this automatically (joke). Req A antes “if return value > $5” Req B Req C “if return value > $2” Req A depois O RequisitePro oferece suporte aos chamados “links (Vínculos) suspeitos”, que podem notificar que um requisito associado se modificou. Todos os requisitos diretamente relacionados deviam ser revistos para avaliar se eles estão sendo afetados. Por que o vínculo do Req B com Req C não foi marcado como suspeitado? O único caminho para solucionar links suspeitos é manualmente (por constante olhar as mudanças e aos requisitos afetados). Links dos requisitos devem ser marcados como “suspeitos” Links “suspeitos” devem ser analisados

39 Exemplos de padrões de Rastreabilidade
Doc. Visão <Requisito Negócio> Glossário <Termo> Doc. Regras de Negócio <Regra Negócio> Esp. Suplementar <Esp. Suplem> Esp. Caso de Uso <Caso de Uso>

40 Rastreabilidade Necessidades Requisito de Negócio Requisito de Produto
Regra de Negócio Glossário Requisito de Negócio Requisito de Produto A figura seguinte mostra a um exemplo hierarquia de rastreabilidade mostrando a relação entre "características" definidas em um documento de visão e "requisitos de software" definido em um modelo de caso de uso e uma especificação suplementar. Também apresenta como os requisitos de software são rastreados em Requisitos de Teste, Projeto e Documentação de Usuário.

41 Gerência de Escopo RequisitePro na Petrobrás: existe um conjunto de licenças no suite do ReqPro com ordens, e tem um modo de busca de licenças.

42 Gerência de escopo O escopo de um projeto é definido pelo conjunto de requisitos alocados para ele Para o projeto se adequar aos recursos disponíveis (tempo, pessoas e dinheiro) é primordial o gerenciamento de escopo com êxito O escopo de um projeto é definido pelo conjunto de requisitos alocados para ele. O gerenciamento do escopo do projeto para se adequar aos recursos disponíveis (tempo, pessoas e dinheiro) é primordial para o gerenciamento de projetos com êxito. Gerenciar o escopo é uma atividade contínua que requer desenvolvimento iterativo ou incremental, que quebra o escopo do projeto em partes menores mais simples de gerenciar. RUP (Detalhamento do Fluxo de Trabalho: Gerenciar o Escopo do Sistema )

43 Inclui certificar-se que o projeto não crescerá além dos:
Gerência de escopo Inclui certificar-se que o projeto não crescerá além dos: Requisitos necessários Orçamento planejado Prazo estabelecido

44 É feito com o detalhamento do fluxo de trabalho com a finalidade de:
Gerência de escopo É feito com o detalhamento do fluxo de trabalho com a finalidade de: Priorizar e refinar as informações fornecidas para selecionar as características e os requisitos que serão incluídos Listar o conjunto de casos de uso (ou cenários) que representam alguma funcionalidade central e significativa Definir quais atributos dos requisitos e rastreabilidades devem ser mantidas A utilização de atributos de requisitos (por exemplo, prioridade, esforço e risco) como a base para negociar a inclusão de um requisito é uma técnica bastante útil de gerenciamento de escopo. Focar os atributos em vez de os requisitos propriamente ditos ajuda a desestimular negociações que são normalmente controversas. É proveitoso que os líderes de equipe sejam treinados para negociações, e que o projeto tenha um defensor na organização, assim como no lado do cliente. Os defensores do produto ou do projeto devem ter o poder organizacional para recusar mudanças de escopo além dos recursos disponíveis ou para expandir recursos a fim de acomodar escopo adicional. O escopo do projeto deve ser gerenciado continuamente ao longo do projeto. Uma compreensão melhor da funcionalidade do sistema é obtida da identificação da maioria dos atores e casos de uso. Os requisitos não funcionais, que não se encaixam no modelo de casos de uso, devem ser documentados nas Especificações Suplementares. O analista do sistema deve determinar valores de prioridade, esforço, custo, valores de risco, com os envolvidos apropriados, para reunir no repositório de atributos de requisitos .  Isso será usado pelo Gerente do Projeto ao planejar as iterações e permite que o arquiteto do software identifique os casos de uso significativos do ponto de vista da arquitetura , definindo a visão de caso de uso da arquitetura no Documento de Arquitetura do Software.  Como Definir a Equipe Todas as pessoas envolvidas neste detalhamento do fluxo de trabalho devem ser membros da equipe de arquitetura. Orientações de Trabalho A equipe de arquitetura liderará uma sessão para debater a melhor forma de priorizar os requisitos. RUP (Detalhamento do Fluxo de Trabalho: Gerenciar o Escopo do Sistema )

45 Exemplos de Template adotado numa grande empresa de TI
RequisitePro na Petrobrás: existe um conjunto de licenças no suite do ReqPro com ordens, e tem um modo de busca de licenças.

46 Documento de Visão (VIS) Glossário (GLOS)
Documento de Especificação de Caso de Uso (UCS) Documento de Especificação Suplementar (SUPL) Documento de Regras de Negócio (RN) Distribuição e análise dos Templates da PETROBRAS

47 Informações de Todos os Documentos
Código do Software Nome do Software Histórico de Revisões Data Versão Descrição Autor Campos existentes em todos os templates. Código do Software – alfanumérico de 4 caracteres (na Petrobrás)

48 Documento de Visão (VIS) 1/2
Objetivo Referências Visão Geral do Problema Visão Geral do Ambiente Atual Envolvidos (Função/Papel, Descrição, Órgão) Usuários (Função/Papel, Descrição, Órgão, Envolvido) Visão Geral da Solução Proposta Este documento apresenta uma visão gerencial do produto a ser desenvolvido em termos de requisitos de negócio e apresenta aqueles que estão direta/indiretamente envolvidos com o sistema. Contém os requisitos em um nível mais abstrato e é a base contratual para a obtenção dos requisitos mais detalhados do sistema. Classificação: Requisitos funcionais; Requisitos não funcionais; Requisitos inversos.

49 Documento de Visão (VIS) 2/2
Requisitos de Negócio Funcionais <Requisito Funcional 1> <Requisito Funcional N> Não Funcionais <Requisito Não Funcional 1> <Requisito Não Funcional N> Inversos <Requisito Inverso 1> <Requisito Inverso N> Restrições Os requisitos cancelados são textos ocultos neste Documento. ReqPro: O documento do Word é a porta de entrada dos requisitos, seleciona o texto e “chama” o ReqPro. Desvantagem: - Excluir requisito não deve-se, pois o “sistema” deve ser integrado e consistente. Para burlar isto, no Documento de Visão oculta o Requisito (o word deve estar configurado pra não exibir ocultos)

50 Documento de Visão (VIS): exemplo

51 Definições Referências Glossário (GLOS) <Termo 1>
<significado 1> Referências Este documento possui as definições dos termos importantes utilizados no projeto.

52 Glossário (GLOS): exemplo

53 Documento de Especificação de Caso de Uso (UCS)
<Nome do Caso de Uso> Breve Descrição Referências Atores Pré-condições <pré-condição 1> Fluxos de Eventos Fluxo Básico 1. Este caso de uso começa quando o <ator> ... 2. ... Fluxos Alternativos A1 – <nome do fluxo alternativo 1> Se no passo <nº do passo> do fluxo [básico|alternativo] <condição> então: 1. ... <para onde Caso de Uso retorna> | o Caso de Uso termina. Especificação de Requisitos de Software (ERS) A Especificação de Requisitos de Software - ERS captura completamente os requisitos do software em desenvolvimento. Este modelo foi concebido para um projeto baseado em casos de uso. A ERS é um artefato derivado, devendo ser gerado automaticamente através da ferramenta IBM Rational SoDA, capturando as informações dos seguintes artefatos: especificações de casos de uso e especificação suplementar. Documento de Especificação de Caso de Uso (UCS) Este documento traz a especificação detalhada de um caso de uso.

54 Documento de Especificação de Caso de Uso (UCS)
Pontos de Extensão <ponto de extensão1> Se no passo <nº do passo> do fluxo [básico|alternativo] <condição>, o caso de uso <nome do caso de uso extend> é acionado. Casos de Uso Incluídos <nome do caso de uso incluído1> Pós-Condições <pós-condição1> Outros Diagramas <nome do diagrama>

55 Documento de Especificação de Caso de Uso (UCS): exemplo
A caixa de diálogo sobreposta representa a integração com o RequisitePro, através da qual se cria “elos” (tags) entre os dados dos requisitos no Documento e na base de dados do RequisitePro.

56 Documento de Especificação Suplementar (SUPL)
Usabilidade <requisito de usabilidade 1> Confiabilidade <requisito de confiabilidade 1> Desempenho: <requisito de performance 1> Ambiente Operacional: <requisito de ambiente operacional 1> Segurança e Controle de Acesso: <requisito de Segurança/Controle de Acesso 1> Outras Categorias de Requisitos: <categoria 1> <requisito 1 da categoria 1> Referências Este documento traz as especificações do sistema que não foram capturadas pelos casos de uso, como itens de qualidade, incluindo usabilidade, segurança e desempenho, ou outras questões como sistema operacional e ambiente.

57 Documento de Especificação Suplementar (SUPL): exemplo

58 Documento de Regras de Negócio (RN)
<regra de negócio 1> <regra de negócio n> Referências Documento Opcional Neste documento são apresentadas as regras de negócio do sistema. É opcional.

59 Documento de Regras de Negócio (RN): exemplo

60 Rastreabilidade Proposta
Matrizes de Rastreabilidade: Regra de Negócio para Caso de Uso Termo para Regra de Negócio Requisito de Negócio para Caso de Uso Requisito de Negócio para Especificação Suplementar Pode-se criar outros links, outras matrizes de rastreabilidade. RN para UC Indica para cada regra de negócio em quais casos de uso ela deve ser seguida. Essa matriz é opcional. DEM para RQN Indica para cada demanda quais os requisitos de negócio que ela implementou ou modificou. (VER) RQN para UC Indica para cada caso de uso de qual requisito de negócio ele foi originado. RQN para SUPP Indica para cada especificação suplementar de qual requisito de negócio ele foi originado.

61 Rastreabilidade Proposta

62 Exercício Extra Os grupos apresentam a “Agenda Telefônica”, sendo discutida a modelagem proposta entregar solução aos professores distribuir solução xerocada, como exemplo Aviso aos alunos: trazer exercícios feitos em sala para aula de laboratório.

63 Referências Bibliográficas 1/2
Balzer, R.M.; Goldman, N.;Wile, D. Informality in program specifications. IEEE Transactions on Software Engineering, Ney York, V.SE-4, p , 1978. Breitman, K.; Sayão, M. Gerência de Requisitos. Simpósio Brasileiro de Engenharia de Software - SBES, 2005. Delicato, F. Modelagem de Requisitos. Notas de Aula. RN L UFRN Engenharia de Requisitos. RJ: PUC-Rio. Fortes, R.P.M. Capítulo 6 Princípios Fundamentais da Análise de Requisitos Engenharia de Software – Pressman. Notas de aula. SP : USP, 2006. Leite, J. III. Requisitos são Frases. Notas de aula. RJ : Puc-Rio Mota, A. Engenharia de Requisitos. Notas de aula. PE : UFPE PETROBRAS, Documento de Gerenciamento de Requisitos. PI-PR TI/IDTA, 2006.

64 Referências Bibliográficas 2/2
Processos da Engenharia de Requisitos: elicitação e análise de requisitos. Notas de aula. BA : UFBa, 2005 Sanchez, M.L. Modelagem Semi-formal de Sistemas: Orientação a Objetos. Notas de Aula. UFF, 2006. Sommerville, I. Engenharia de Software, São Paulo: Pearson Addison Wesley, 2003. Techniques for Requirements Elicitation. Valacich, J et al. Essential of systems Analysis & Design. New Jersey : Pearson Education, 2001.