análise orientada a objetos - início | faculdade de …bacala/daw/aula02-1 - engenharia...

175
Análise Orientada a Objetos Engenharia de Requisitos

Upload: duongliem

Post on 14-Aug-2018

217 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Análise Orientada a

Objetos

Engenharia de Requisitos

Page 2: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Objetivos

• Introduzir a noção de requisitos do sistema e o processo da engenharia de requisitos.

• Explicar como a engenharia de requisitos se encaixa no processo mais abrangente da engenharia de sistemas

• Explicar a importância do documento de requisitos

Page 3: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Motivação

• No início da computação não havia nenhuma processo para a descoberta dos requisitos

• Os programadores sentavam-se e começavam a codificar.

Page 4: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Reconhecendo o cu$$$to

• Quando começa um processo de desenvolvimento de software, um lápis custa pouco mais de R$ 1,00 .

• Só que a borracha para efetuar os ajustes custa milhões...

Page 5: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Não é fácil...

• ... entender a funcionalidade.

Page 6: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Não é fácil...

• ...obter a forma correta.

Page 7: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Não é fácil...

...entender problemas que você não está familiarizado

...entender os detalhes da solução.

Page 8: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Requisitos do sistema

• Definem o que é solicitado ao sistema fazer e com quais limitações ele é requisitado a operar.

• Por exemplo: – O sistema deve manter registro de todos os materiais da

biblioteca incluindo livros, séries, jornais e revistas e CDROMs. (requisito funcional)

– O sistema deve permitir que os usuários pesquisem um item através do título, autor ou ISBN. (requisito funcional)

– A interface de usuário do sistema deve ser implementada para ser acessível via browser de WWW (World-Wide-Web). (requisito não-funcional)

– O sistema deve suportar pelo menos 20 transações por segundo. (requisito não-funcional)

Page 9: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Tipos de requisitos

• Funcionais – definem as funcionalidades do sistema.

• Serviços que o sistema deve fornecer • Como o sistema deve reagir a entradas específicas • Como o sistema deve se comportar em determinadas situações • Ex.: O sistema deve permitir a realização de compras de livros

• Não-Funcionais – dizem respeito à restrições de desenvolvimento, aspectos de

desempenho, interfaces com o usuário, confiabilidade, segurança, manutenibilidade, portabilidade, padrões a serem seguidos • Ex.: O sistema deve possuir uma GUI que siga o padrão de

interface do Windows

Page 10: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Exemplos de requisitos

funcionais

• O usuário deve ser capaz de pesquisar em todo o conjunto inicial de banco de dados ou selecionar um subconjunto a partir dele

• Para todo pedido deve ser alocado um identificador único (ORDER_ID) que o usuário possa copiar para a área de armazenamento permanente da sua conta

• O sistema deve fornecer telas apropriadas para o usuário ler os documentos no repositório de documentos

Page 11: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Requisitos não-funcionais

• Definem propriedades e restrições de sistema – Ex: confiabilidade, tempo de resposta e requisitos de

armazenamento

• Restrições são capacidade de dispositivos de E/S, representações de sistema, etc.

• Requisitos de processo podem também ser especificados, impondo uma linguagem de programação, IDE ou método de desenvolvimento particular

• Requisitos não-funcionais podem ser mais críticos do que os requisitos funcionais

Page 12: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Tipos de requisitos não-

funcionais

Page 13: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Tipos de requisitos

• Organizacionais

– dizem respeito às metas da empresa.

• políticas estratégicas adotadas,

• os empregados da empresa com seus respectivos objetivos;

• enfim toda a estrutura da organização.

• Ex.: O sistema visa aumentar os lucros da empresa

Page 14: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Problemas dos Requisitos

• Os requisitos não refletirem as reais necessidades dos clientes do sistema.

• Os requisitos serem inconsistentes e/ou incompletos.

• O custo alto para se fazer mudanças de requisitos depois de terem sido concordados.

• Existirem mal entendidos entre clientes, aqueles que desenvolvem os requisitos do sistema e os engenheiros de software que desenvolvem ou mantêm o sistema.

Page 15: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Imprecisão de requisitos

• Problemas surgem quando os requisitos não são precisamente definidos

• Requisitos ambíguos podem ser interpretados de maneiras diferentes pelos desenvolvedores e usuários

• Considere o termo ‘telas apropriadas’ – Intenção do usuário – tela de propósito especial para cada tipo

diferente de documento

– Interpretação do desenvolvedor – fornece uma tela de texto que mostra o conteúdo do documento

Page 16: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Requisitos completos e

consistentes

• Em princípio, requisitos devem ser completos e consistentes

• Completude

– Eles devem incluir descrições de todos os recursos requeridos

• Consistência

– Não deve haver conflitos ou contradições nas descrições dos recursos de sistema

• Na prática, é impossível produzir um documento de requisitos completo e consistente

Page 17: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Questões mais frequentemente

perguntadas sobre requisitos

(FAQS) • O que são requisitos?

– Uma descrição de um serviço ou de uma limitação

• O que é a engenharia de requisitos?

– O processo envolvido no desenvolvimento de requisitos de um sistema

• Quanto custa a engenharia de requisitos?

– Cerca de 15% dos custos do desenvolvimento do sistema.

Page 18: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

FAQs continuação

• O que é o processo de engenharia de requisitos? – Um conjunto estruturado de atividades envolvidas no

desenvolvimento dos requisitos do sistema

• O que acontece quando os requisitos estão errados? – Os sistema atrasam, ficam não confiáveis e não satisfazem

as necessidades dos clientes.

• Existe um processo de engenharia de requisitos ideal? – Não - os processos precisam ser adaptados as necessidades

organizacionais.

• O que é um documento de requisitos? – Uma descrição formal dos requisitos do sistema.

Page 19: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

FAQs continuação

• O que são stakeholders do sistema? – Qualquer pessoa afetada de alguma forma pelo

sistema.

• Qual é o relacionamento entre requisitos e projeto? – Requisitos e projeto são interligados. Idealmente eles

deveriam ser separados, mas na prática isto é impossível.

• O que é gerenciamento dos requisitos? – O processo envolvido no gerenciamento das mudanças

dos requisitos

Page 20: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

O que é a Engenharia de

Requisitos?

• Disciplina para desenvolver uma especificação completa, consistente e não ambígua - que sirva como base para um acordo entre todas as partes envolvidas - descrevendo o que o produto de software irá fazer (mas não como ele será feito).

Page 21: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Engenharia de Sistemas

• Existe um relacionamento próximo entre software e os requisitos mais gerais do sistema

• Os sistemas baseados em computadores são de duas categorias: – Sistemas configurados para o usuário, onde o

comprador compõe um sistema a partir de produtos de software existentes - COTS

– Sistemas onde o cliente produz um conjunto de requisitos para sistemas de software/hardware e a um contratado desenvolve e entrega o sistema

Page 22: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

O Processo da Engenharia de

Sistemas

Page 23: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Atividades da Engenharia de

Sistemas

• Engenharia de Requisitos do Sistema – Os requisitos do sistema como um todo são

estabelecidos e escritos para serem entendidos por todas as partes interessadas (stakeholders)

• Projeto de arquitetura – O sistema é decomposto em subsistemas

• Partição de requisitos – Os requisitos são alocados a estes subsistemas

• Engenharia de Requisitos de Software – Requisitos de software mais detalhados são derivados

para o software do sistema

Page 24: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Atividades da Engenharia de

Sistemas

• Desenvolvimento de subsistemas – Os subsistemas de hardware e software são

projetados e implementados em paralelo.

• Integração de sistemas – Os subsistemas de hardware e software são

colocados juntos para compor o sistema.

• Validação do sistema – O sistema é validado em relação aos requisitos.

Page 25: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Propriedades Emergentes

• Propriedades do sistema como um todo que somente emergem quando todos os subsistemas estiverem integrados. – Exemplos de propriedades emergentes

• Confiabilidade

• Manutenabilidade

• Desempenho (Performance)

• Usabilidade

• Segurança

Page 26: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Documento de Requisitos

• Documento formal usado para comunicar os requisitos aos clientes, engenheiros e gerentes.

• Descreve: – Os serviços e funções que o sistema deve prover; – As limitações sobre as quais o sistema deve operar; – Propriedades gerais do sistema, isto é limitações

nas propriedades emergentes; – Definições de outros sistemas com o qual o

sistema deve se integrar.

Page 27: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Documento de Requisitos

• Descreve (continuação): – Informações sobre o domínio da aplicação do sistema;

Ex.: como calcular um certo tipo de computação – Limitações nos processos usados para desenvolver o

sistema; – Descrições sobre o hardware no qual o sistema irá

executar.

• Deverá sempre conter uma capítulo introdutório que provê um resumo do sistema, necessidades de negócio suportadas pelo sistema e um glossário que explica a terminologia usada.

Page 28: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Usuários do documento de

requisitos

• 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.

• Engenheiros de Sistema – Usam os requisitos para entenderem o sistema em

construção.

Page 29: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Usuários do documento de

requisitos (cont.)

• Engenheiros de teste do sistema

– Usam os requisitos para desenvolverem testes de validação do sistema.

• Engenheiros de manutenção do sistema

– Usam os requisitos para entenderem o sistema.

Page 30: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Estrutura do documento de

requisitos

• Padrão IEEE/ANSI 830-1998 uma estrutura para o documento de requisitos

1. 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

Page 31: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Estrutura do documento de

requisitos

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

Page 32: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Adaptando um padrão

• O padrão do IEEE é genérico e pretende ser aplicado em uma variada gama de documentos de requisitos.

• Em geral, nem todas as partes do documento são necessárias para todos os documentos de requisitos.

• Cada organização deverá adaptar o padrão de acordo com o tipo de sistema que desenvolve.

• Considere uma companhia (XYZ) que desenvolve equipamentos científicos.

Page 33: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Padrão da empresa XYZ

• Prefácio – Define os leitores do documento e descreve a história

das versões, incluindo um explicação da criação de novas versões e um resumo das mudanças feitas em cada versão.

• Introdução – Define o produto no qual o software está embutido,

seu uso esperado e apresenta um resumo da funcionalidade do software de controle.

• Glossário – Define todos os termos técnicos e abreviações usadas

no documento.

Page 34: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Padrão da empresa XYZ

• Requisitos gerais do usuário

– Define os requisitos do ponto de vista dos usuários do sistema. Isto inclui uma mistura de linguagem natural e diagramas.

• Arquitetura do sistema

– Apresenta uma visão de alto nível da arquitetura prevista do sistema, mostrando a distribuição das funções dos módulos do sistema. Indica os componentes da arquitetura que serão reusados.

Page 35: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Padrão da empresa XYZ

• Especificação de Hardware – Parte opcional que especifica o hardware que o

software deverá controlar. Poderá ser omitido se uma plataforma padrão de instrumento for ser utilizada.

• Especificação detalhada de software – Descrição detalhada da funcionalidade esperada do

software. Poderá incluir detalhes de algoritmos específicos que devem ser usados na computação. Se for ser usada uma abordagem de prototipação para o desenvolvimento numa plataforma padrão de instrumento, esta seção poderá ser omitida.

Page 36: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Padrão da empresa XYZ

• Quando apropriado, os seguintes apêndices poderão ser adicionados: – Especificação da interface de Hardware;

– Componentes de Software que deverão ser reusados na implementação do sistema;

– Especificação da estrutura de dados;

– Modelos de fluxo de dados do sistema de software;

– Modelos detalhados de objetos do sistema de software.

• Índice

Page 37: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Escrevendo requisitos

• Requisitos são geralmente escritos como textos em linguagem natural complementados por diagramas e equações.

• Problemas com os requisitos – Uso de cláusulas condicionais complexas que

podem confundir;

– Terminologia inconsistente;

– Os escritores assumem que os leitores possuem conhecimento do domínio.

Page 38: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

O essencial da escrita

• Requisitos são lidos mais frequentemente do que são escritos. Você deverá investir tempo lendo e entendendo os requisitos.

• Não assuma que todos os leitores dos requisitos tenham o mesmo background e usem a mesma terminologia sua.

• Permita tempo para revisão e refeita do documento de requisitos.

Page 39: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Escrevendo diretrizes

• Defina templates (modelos) padrões para descrição de requisitos;

• Use a linguagem de forma simples, consistente e concisa;

• Use diagramas de forma apropriada;

• Complemente a linguagem natural com outras descrições de requisitos;

• Especifique requisitos de forma quantitativa.

Page 40: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Pontos Principais

• Requisitos definem o que o sistema deve provê e define os limites do sistema;

• Problemas nos requisitos causam a entrega tardia dos sistemas e solicitações de mudanças depois que o sistema estiver em uso;

• Engenharia de requisitos diz respeito a elicitação, análise e documentação dos requisitos do sistema.

Page 41: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Pontos Principais

• Engenharia de sistemas diz respeito ao sistema • como um todo, incluindo hardware, software e • processos operacionais; • O documento de requisitos é a especificação • definitiva para os clientes, engenheiros e • gerentes; • O documento de requisitos deve incluir um • resumo, glossário, definição de requisitos • funcionais e limitações operacionais.

Page 42: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Referências

• SOMMERVILLE, Ian. Engenharia de Software. 8ª ed. São Paulo: Addison-Wesley, 2007. – Parte 2. Engenharia de Requisitos Capítulo 7

• PRESSMAN, Roger S. Engenharia de Software. 5ª ed. São Paulo: McGraw-Hill, 2001. – Parte 3. Métodos Convencionais para Engenharia de Software

• Capítulo 10. Engenharia de Sistemas – Seção 10.5.1 Elicitação de Requisitos

• G. Kotonya and I. Sommerville, Requirements Engineering: Processes and Techniques, John Wiley & Sons, 1998.

Page 43: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

O PROCESSO DE ENGENHARIA

DE REQUISITOS

Page 44: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

OBJETIVO DO

MÓDULO

• Introduzir as noções de processos e modelos de processo para a engenharia de requisitos.

• Explicar o papel crítico das pessoas no processo de engenharia de requisitos.

• Explicar porque a melhoria do processo é importante e sugerir um modelo de melhoria de processo para a engenharia de requisitos.

Page 45: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Processos

• Processo é um conjunto organizado de atividades que transforma entradas em saídas;

• Descrições de processos encapsulam conhecimento e permitem que sejam reusados;

• Exemplos de descrições de processo:

– Manual de instrução de uma máquina de lavar, receitas de bolo, ER, etc

Page 46: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Processo de ER

entradas e saídas

Processo de Engenharia

de Requisitos

Informações de Sistemas Existentes

Necessidades das partes envolvidas

Padrões Organizacionais

Regulamentações

Informações do Domínio

Requisitos Acordados

Especificação do Sistema

Modelos de Sistema

Page 47: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Descrição da entrada/saída Entrada ou Saída Tipo Descrição

Informação sobre Sistemas Existentes

Entrada Informação sobre a funcionalidade dos sistemas a serem substituídos ou de outros sistemas que interagem com o sistema que está sendo especificado.

Necessidades dos Participantes

Entrada Descrições do que os participantes necessitam do sistema para suportar seus trabalhos

Padrões da Organização

Entrada Padrões usados na organização relativos às práticas de desenvolvimento de sistemas, gerenciamento da qualidade, etc.

Regulamentações Entrada Regulamentações externas tais como regulamentações de saúde e segurança que se aplicam ao sistema

Informação do Domínio

Entrada Informações gerais sobre o domínio de aplicação do sistema

Page 48: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Variação do Processo de

Requisitos

• Os processos de requisitos variam radicalmente de uma organização para outra;

• Fatores que contribuem para esta variação:

– Maturidade Técnica;

– Envolvimento disciplinas;

– Cultura Organizacional;

– Domínio de aplicação.

• Portanto não existe um processo ‘ideal’ de engenharia de requisitos.

Page 49: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Modelo de ER de alto nível

Page 50: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Modelo de ER de alto nível

Page 51: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Atividades do processo de

ER

• Elicitação de Requisitos

– Os requisitos são descobertos através da consulta com as partes interessadas

• Análise e negociação de requisitos

– Requisitos são analisados e os conflitos resolvidos através de negociação

• Documentação de requisitos

– Um documento de requisitos é produzido

• Validação de requisitos

– É checada a consistência e completude do documento de requisitos

Page 52: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Modelo espiral do processo

de ER

Page 53: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Fatores Humanos e

Sociais

• Os processos de engenharia de requisitos são dominados por fatores humanos, sociais e organizacionais

– porque eles sempre envolvem um conjunto de partes interessadas com backgrounds diferentes e com objetivos organizacionais e individuais diferentes

• As partes interessadas (stakeholders) pelo sistema podem ter uma variedade de background técnico e não técnico e de diferentes disciplinas

Page 54: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Fatores influenciando

requisitos

• Personalidade e status dos stakeholders;

• Os objetivos pessoais dos indivíduos dentro da empresa;

• O grau de influência política dentro de uma organização.

Page 55: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Melhoria de Processo

• A melhoria de processo está relacionado com a modificação do processo de forma a alcançar algum objetivo de melhora;

• Objetivos de melhora:

– Melhoria de qualidade;

– Redução de prazo;

– Redução de recursos.

Page 56: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Planejando a melhoria do

processo

• Quais são os problemas com os processos atuais?

• Quais são os objetivos de melhora?

• Como o processo de melhora poderá ser introduzido para alcançar estes objetivos?

• Como o processo de melhora poderá ser controlado e gerenciado?

Page 57: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Problemas do processo de

ER

• Falta de envolvimento dos stakeholders;

• As necessidades do negócio não são consideradas;

• Falta de gerenciamento dos requisitos;

• Falta de definição de responsabilidades;

Page 58: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Problemas do processo de

ER

• Problemas de comunicação dos stakeholders;

• Planejamento longo demais e baixa qualidade dos documentos de requisitos.

Page 59: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Um modelo de maturidade

de processo para ER

Page 60: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Níveis de maturidade da

ER

• Nível inicial

– Não há processo definido de ER. Sofre de problemas tais como volatilidade dos requisitos, stakeholders não satisfeitos e alto custo de refeita dos sistemas. Depende de habilidades e experiências individuais.

Page 61: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Níveis de maturidade da

ER

• Nível repetível

– Padrões definidos para os documentos de requisitos e políticas e procedimentos para o gerenciamento de requisitos.

• Nível definido

– Um processo definido de ER, baseado em boas práticas e técnicas. Em funcionamento um processo ativo de melhoria.

Page 62: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Boas práticas para a

melhoria do processo de ER

• Os processo de ER podem ser melhorados pela sistemática introdução de boas práticas de engenharia de requisitos;

• Cada ciclo de melhoria identificará diretrizes práticas e trabalhará em direção para a sua introdução na organização.

Page 63: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Exemplos de diretrizes de

boas práticas

• Defina uma estrutura de documento padronizada;

• Identifique de forma única cada requisito;

• Defina políticas para o gerenciamento de requisitos;

Page 64: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Exemplos de diretrizes de

boas práticas

• Use checklists durante a análise de requisitos;

• Use cenários para elicitar requisitos;

• Especifique requisitos de forma quantitativa;

• Use prototipagem para animar requisitos;

• Reuse requisitos.

Page 65: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Pontos principais

• O processo de engenharia de requisitos é estruturado como um conjunto de atividades que leva a produção do documento de requisitos.

• As entradas do processo de engenharia de requisitos são as informações existentes dos sistemas, necessidade dos stakeholders, padrões organizacionais, regulamentações e informações do domínio.

• Os processos de engenharia de requisitos variam radicalmente entre empresas. A maioria dos processos incluem a elicitação de requisitos, análise e negociação dos requisitos e validação dos requisitos.

Page 66: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Pontos principais

• Os modelos do processo de engenharia de requisitos são descrições simplificadas que são apresentadas de uma perspectiva particular.

• Fatores humanos, sociais e organizacionais são influências importantes no processo de engenharia de requisitos.

• A melhoria do processo de engenharia de requisitos é difícil, sendo tratada melhor de forma incremental.

• Os processos de engenharia de requisitos podem ser classificados de acordo com seus graus de maturidade.

Page 67: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

ELICITAÇÃO DE REQUISITOS

Page 68: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Objetivos

• Descrever o processo da elicitação e análise requisitos.

• Introduzir um número de técnicas elicitação de requisitos e análise de requisitos.

• Discutir como protótipos podem ser usados no processo de ER.

Page 69: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Elicitação de requisitos

• ELICITAR: descobrir, tornar explícito, obter o máximo de informações para o conhecimento do objeto em questão

• Cabe à elicitação a tarefa de identificar os fatos relacionados aos requisitos do Sistema, de forma a prover o mais correto e mais completo entendimento do que é demandado daquele software

Page 70: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Componentes da

elicitação de requisitos

Problema a ser resolvido

Domínio da aplicação

Contexto do negócio

Necessidades dos

stakeholders

Page 71: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Atividades da Elicitação

• Entendimento do domínio da aplicação

– O conhecimento do domínio da aplicação é o conhecimento geral onde o sistema será aplicado.

• Entendimento do problema

– Os detalhes dos problemas específicos do problema do cliente onde o sistema será aplicado deve ser entendido.

Page 72: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Atividades da Elicitação

• Entendimento do negócio

– Você de entender como os sistemas interagem e contribuem de forma geral com os objetivos de negócio.

• Entendimento das necessidades e limitações dos stakeholders do sistema

– Você deve entender, em detalhe, as necessidades específicas das pessoas que requerem suporte do sistema no seu trabalho.

Page 73: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Elicitação de Requisitos:

Dificuldades

• Usuários podem não ter uma idéia precisa do sistema por eles requerido;

• Usuários têm dificuldades para descrever seu conhecimento sobre o domínio do problema;

• Usuários e analistas têm diferentes pontos de vista do problema (por terem formações diferentes)

• Usuários podem antipatizar com o novo sistema e se negar a participar da elicitação (ou mesmo fornecer informações errôneas).

Bacalá 73

Page 74: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Elicitação, análise e

negociação

Page 75: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

O processo da elicitação

de requisitos

Page 76: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Estágios da Elicitação

Definir objetivos

Aquisição de conhecimento do background

Organização do conhecimento

Coletar os requisitos dos stakeholders

Bacalá 76

Page 77: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Estágios da Elicitação

• Definir objetivos

– Os objetivos organizacionais devem ser estabelecidos incluindo objetivos gerais do negócio, um descrição geral do problema a ser resolvidos porque o sistema é necessário e as limitações do sistema.

• Aquisição de conhecimento do background

– Informação de background do sistema inclui informação acerca da organização onde o sistema será instalado, o domínio de aplicação do sistema e informação acerca de outros sistemas existente

Page 78: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Estágios da Elicitação

• Organização do conhecimento

– A grande quantidade de conhecimento que foi

coletada nos estágios anteriores devem ser organizadas e colocadas em ordem.

• Coletar os requisitos dos stakeholders

– Os stakeholders do sistema são consultados para

descoberta de seus requisitos.

Page 79: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Algumas técnicas de

elicitação

• Entrevistas

• Questionários

• Brainstorm

• Leitura de documentos

• Cenários

• Observações e análise sociais (etnografia)

• Reuso de requisitos

• Prototipação

Page 80: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Entrevistas e questionários

• Defina onde começar

• Sempre pergunte:

– O que? Por que(m)? Como?

• Pergunte o óbvio

• Organize as respostas: durante e depois

• Observe

• Seja humilde, procure aprender!

Page 81: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Brainstorm

• Não pode ter muita gente

• Pessoas com diferentes perfis

• Presença de um facilitador

• Aceite todo tipo de sugestão e filtre depois!

• Evite pensar em detalhes

• Consulte todos

• Dê sugestões

Page 82: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Cenários

• São estórias que explicam como um sistema poderá ser usado.

• São exemplos de sessões de interação que descrevem como o usuário interage com o sistema.

• O termo “caso de uso” ou use case (um caso específico de uso do sistema) é usado às vezes para se referir a um cenário.

Page 83: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Exemplo de cenário:

Sistema de livraria virtual

• Entre no sistema

• Escolha o comando “pedido de documentos”

• Entre o número de referência do documento pedido

• Selecione um ponto de entrega

• Saia do sistema

Page 84: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Observação e análise

social

• As pessoas geralmente acham difícil descrever o que elas fazem. Às vezes, a melhor forma de entender será observá-las no trabalho.

• Etnografia é uma técnica das ciências sociais que se mostrou útil no entendimento dos processos reais realizados nos trabalhos.

• Os processos reais de trabalho geralmente diferem daqueles processos formais descritos.

• Um etnógrafo passa algum tempo observando as pessoas no trabalho e constrói uma imagem de como o trabalho é realizado.

Page 85: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Diretrizes para etnografia

• Procure formas não padronizadas de trabalho.

• Gaste algum tempo conhecendo as pessoas e estabeleça um relacionamento de confiança.

• Tome nota, de forma detalhada, de todas as práticas de trabalho. Analise-as e chegue a uma conclusão a partir delas.

• Combine observação com entrevistas abertas.

• Organize regularmente sessões de relato, onde o etnógrafo fala para pessoas externas ao processo.

• Combine etnografia com outras técnicas de elicitação.

Page 86: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Reuso de requisitos

• Envolve considerar requisitos que foram desenvolvidos para um sistema e usá-los em sistemas diferentes.

• O reuso de requisitos economiza tempo e esforço, pois requisitos reutilizados já foram analisados e validados em outros sistemas.

Page 87: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Prototipação (na Elicitação)

• Um protótipo é uma versão inicial de um sistema que poderá ser usado para experimentação.

• Protótipos são úteis para elicitação de requisitos porque os usuários poderão experimentar o “sistema” e mostrar os pontes fortes e fracos. Eles terão algo concreto para criticar.

• O desenvolvimento rápido dos protótipos é essencial para que eles fiquem disponíveis logo para o processo de elicitação.

Page 88: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Benefícios da prototipação

• O protótipo permite que os usuários experimentem e descubram o que eles realmente necessitam para suportar o trabalho deles

• Estabelece a viabilidade e utilidade antes que altos custos de desenvolvimento tenham sido realizados

• Essencial para desenvolvimento do aspecto look and feel da interface do usuário

• Pode ser usado para teste do sistema e desenvolvimento da documentação

• Força um estudo detalhado dos requisitos, revelando inconsistências e omissões

Page 89: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Análise de requisitos

• O objetivo da análise de requisitos é descobrir problemas, incompletude e inconsistência nos requisitos elicitados.

• Outro objetivo importante da análise de requisitos é descobrir as interações (rastreamento) entre requisitos e informar os conflitos e sobreposições encontrados.

• Os problemas existentes com os requisitos são retornados aos stakeholders para resolvê-los, através de um processo de negociação.

• A análise é intercalada com elicitação, pois problemas são descobertos quando os requisitos são elicitados.

• Uma lista de verificação de problemas (checklist) poderá ser usada para ajudar a análise. Cada requisito poderá ser avaliado contra esta lista.

Page 90: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Análise e negociação de

requisitos

Page 91: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Estágios da análise dos

requisitos

• Checagem da necessidade

– A necessidade dos requisitos é analisada. Em alguns casos, alguns requisitos propostos podem não contribuir para os objetivos de negócio da organização ou para o problema específico tratado pelo sistema.

• Checagem da consistência e completude

– Os requisitos são verificados entre si para determinar consistência e completude. Consistência significa que nenhum requisito deve ser contraditório; completude significa que nenhum serviço (ou limitação) que seja necessário foi esquecido.

Page 92: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Estágios da análise dos

requisitos

• Checagem da viabilidade

– Os requisitos são verificados para garantir que são viáveis dentro do orçamento e tempo disponível para o desenvolvimento do sistema.

Page 93: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Uso de checklist para

análise

• Projeto prematuro

– Os requisitos incluem informação prematura de projeto ou implementação?

• Requisitos combinados

– A descrição do requisito descreve um requisito único ou este pode ser descrito em vários requisitos diferentes?

• Requisitos desnecessários

– O requisito é realmente necessário, ou será que é uma mera adição cosmética ao sistema?

Page 94: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Uso de checklist para

análise

• Uso de hardware não padronizado – Os requisitos implicam no uso de uma plataforma de hardware

não padronizada? Para tomar esta decisão, você precisa conhecer os requisitos de plataforma do computador.

• Está de acordo com os objetivos de negócio – O requisito é consistente com os objetivos de negócio definidos no

documento de requisitos?

• Ambiguidade de requisitos – O requisito é ambíguo, isto é, pode ser lido de forma diferente por

pessoas diferentes? Quais são as possibilidades de interpretação dos requisitos?

Page 95: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Uso de checklist para

análise

• Realismo dos requisitos

– O requisito é realístico em relação a tecnologia usada para a implementação do sistema?

• Teste dos requisitos

– Podemos testar os requisitos, ou seja, eles foram escritos de tal forma que um engenheiro de teste poderá derivar o teste que mostrará se o sistema satisfaz os requisitos?

Page 96: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Negociação de requisitos

• Problemas nos requisitos são inevitáveis quando um sistema possui muitos stakeholders. Conflitos não são falhas, mas refletem necessidades e prioridades diferentes entre as partes interessadas.

• A negociação de requisitos é o processo de discussão dos conflitos de requisitos e a busca de um compromisso no qual todas as partes interessadas concordem.

Page 97: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Negociação de requisitos

• No planejamento do processo de engenharia de requisitos, é importante deixar tempo para negociação.

• Alcançar um compromisso aceitável pode tomar um tempo considerável.

Page 98: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Estágios da negociação

• Discussão dos requisitos – Os requisitos que foram identificados como problemáticos são

discutidos e os stakeholders envolvidos apresentam seus pontos de vista acerca dos requisitos.

• Priorização dos requisitos – Os requisitos disputados são priorizados para identificar requisitos

críticos e ajudar o processo de tomada de decisão.

• Concordância dos requisitos – Soluções para os problemas dos requisitos são identificadas e um

conjunto de requisitos são acordados. Geralmente isto envolve mudanças em alguns dos requisitos.

Page 99: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Encontros de negociação

• A natureza dos problemas associados com os requisitos são explicados.

• As partes interessadas discutem como o problema poderá ser resolvido.

• São atribuídas prioridades aos requisitos.

• As ações que dizem respeito ao requisito são concordadas. Estas ações podem ser: deletar o requisito, sugerir modificações ao requisito ou elicitar mais informações sobre o requisito.

Page 100: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Documentação de

requisitos

• O documento de requisitos é a documentação oficial que descreve os requisitos do sistema

• Na medida do possível, ele deve definir O QUE o sistema deve fazer em vez do COMO ele deve fazer

• Funciona como um acordo contratual entre os clientes e fornecedores de um software

Page 101: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

O essencial na escrita de um

documento de requisitos

• Requisitos são lidos mais frequentemente do que são escritos. Então, deve-se investir tempo lendo e entendendo os requisitos no documento

• Não assuma que todos os leitores dos requisitos tenham o mesmo background e usem a mesma terminologia sua

• Permita tempo para revisão e ajustes do documento de requisitos

Page 102: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Problemas com a documentação

em Linguagem Natural

• Falta de clareza

– Precisão é difícil sem tornar o documento difícil para leitura

• Confusão entre requisitos

– Requisitos funcionais e não funcionais tendem a ser misturados

• Fusão de requisitos

– Vários requisitos diferentes podem ser expressos juntos

Page 103: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Problemas com a documentação

em Linguagem Natural

• Ambiguidade – Os leitores e escritores do requisito devem interpretar as mesmas

palavras da mesma maneira. LN é naturalmente ambígua o que torna o seu uso muito difícil.

• Flexibilidade – A mesma coisa pode ser dita de várias formas diferentes na

especificação

• Falta de modularização – Estruturas de LN são inadequadas para estruturar requisitos do

sistema

• Conclusão: Necessidade de uma notação mais apropriada

Page 104: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Pontos principais

• A elicitação de requisitos envolve a compreensão do domínio da aplicação, o problema específico a ser resolvido, as necessidades e limitações organizacionais e as facilidades especificas necessárias para as partes interessadas.

• Os processos de elicitação de requisitos, análise e negociação são interativos e intercalados, precisando serem repetidos várias vezes.

• Existem várias técnicas de elicitação de requisitos que podem ser usadas, incluindo entrevistas, cenários, métodos soft systems, prototipagem e observação dos participantes.

Page 105: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Pontos principais

• Protótipos são efetivos para a elicitação de requisitos pois as partes interessadas têm algo para experimentar e encontrar seus reais requisitos.

• Listas de checagem são formas particularmente úteis para organizar o processo de validação dos requisitos. Elas lembram ao analista o que deve ser checado quando da leitura dos requisitos propostos.

• Negociação dos requisitos é sempre necessário para resolver conflitos e remover a sobreposição de requisitos. Negociação envolve a troca de informação, discussão e resolução de conflitos.

Page 106: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

VALIDAÇÃO DE REQUISITOS

Page 107: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Objetivos da Validação

• Certificar que o documento de requisitos é uma descrição aceitável do sistema a ser implementado

• Verificar as seguintes propriedades do documento:

– Completude e consistência

– Se está de acordo com os padrões

– Conflitos de requisitos

– Erros técnicos

– Requisitos ambíguos

Page 108: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Análise e validação

• Análise trabalha com os dados ‘crus` que foram elicitados dos stakeholders do sistema

– Neste estágio a pergunta chave a ser respondida é “Temos os requisitos certos?”

• Validação usa uma versão final do documento de requisitos, como os requisitos que foram negociados e concordados

– Neste estágio a pergunta chave a ser respondida é “Temos certo os requisitos?”

Page 109: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Entradas e saídas da

validação

Page 110: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Entradas da validação

• Documento de requisitos

– Deve ser um versão completa do documento, não uma versão preliminar. Formatada e organizada de acordo com os padrões organizacionais.

• Conhecimento organizacional

– Conhecimento, frequentemente implícito, da organização que poderá ser usado para julgar o realismo dos requisitos

• Padrões organizacionais

– Padrões locais, ex. para a organização do documento de requisitos

Page 111: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Saídas da validação

• Lista de problemas

– Lista dos problemas descobertos no documento de requisitos

• Ações concordadas

– Lista de ações que foram acertadas em resposta aos problemas dos requisitos. Alguns problemas podem ter várias ações corretivas; alguns problemas podem não ter ações associadas.

Page 112: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Exemplo 1

• O Gerenciador de Tarefas deve fornecer mensagens de status a intervalos regulares e não menos que a cada 60 segundos

• Problemas:

– Quais são as mensagens de status?

– Quais as condições para fornecer a mensagem?

– Como elas são fornecidas?

– Por quanto tempo as mensagens são exibidas?

– Intervalo de 80 segundos satisfaz o requisito. Intervalo de 80 dias também

Page 113: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Exemplo 2

• O Editor XML deve alternar entre exibir e esconder caracteres não-imprimíveis, instantaneamente

• Problemas:

– Instantâneo?

– O que provoca a mudança? É temporizado, é acionado pelo usuário?

– O que será alterado? O texto selecionado, o documento inteiro, a página atual, etc.

– Quais são os caracteres não imprimíveis? Texto oculto, comentários, tags, etc.

Page 114: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Exemplo 3

• O Parser de XML deve produzir um relatório de erros de marcadores que permite uma rápida resolução dos erros quando usado por usuários novatos em XML

• Problemas:

– Quão rápido?

– Qual o conteúdo do relatório de erros?

– Quando o relatório é gerado?

– Como testar esse requisito?

Page 115: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Exemplo 3

• O Parser de XML deve produzir um relatório de erros de marcadores que permite uma rápida resolução dos erros quando usado por usuários novatos em XML

• Melhoria:

1. Depois que o Parser de XML tiver terminado de analisar um arquivo, ele deve gerar um relatório de erros que contém o número da linha e o texto de qualquer erro de XML encontrado no arquivo analisado, assim como a descrição de cada erro encontrado

2. Se nenhum erro de análise for encontrado, o Parser não deverá gerar um relatório de erros

Page 116: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

IMPORTÂNCIA DA VALIDAÇÃO

DE REQUISITOS

Page 117: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Mariner Bugs Out (1962)

• Cost: $18.5 million

• Disaster: The Mariner 1 rocket with a space probe headed for Venus diverted from its intended flight path shortly after launch. Mission Control destroyed the rocket 293 seconds after liftoff.

• Cause: A programmer incorrectly transcribed a handwritten formula into computer code, missing a single superscript bar. Without the smoothing function indicated by the bar, the software treated normal variations of velocity as if they were serious, causing faulty corrections that sent the rocket off course.

Page 118: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Hartford Coliseum Collapse

• Cost: $70 million, plus another $20 million damage to the local economy

• Disaster: Just hours after thousands of fans had left the Hartford Coliseum, the steel-latticed roof collapsed under the weight of wet snow.

• Cause: The programmer of the CAD software used to design the coliseum, incorrectly assumed the steel roof supports would only face pure compression. But when one of the supports unexpectedly buckled from the snow, it set off a chain reaction that brought down the other roof sections like dominoes.

Page 119: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Wall Street Crash (1987)

• Cost: $500 billion in one day

• Disaster: On “Black Monday” (October 19, 1987), the Dow Jones Industrial Average plummeted 508 points, losing 2.6% of its total value. The S&P 500 dropped 20.4%. This was the greatest loss Wall Street ever suffered in a single day.

• Cause: A long bull market was halted by a rash of SEC investigations of insider trading and by other market forces. As investors fled stocks in a mass exodus, computer trading programs generated a flood of sell orders, overwhelming the market, crashing systems and leaving investors effectively blind.

Page 120: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Como realizar a validação?

• Revisão de requisitos

• Prototipagem

• Validação de modelos

• Teste de requisitos

Page 121: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Revisão de requisitos

• Um grupo de pessoas lê e analisa os requisitos, procura problemas, se reúne, discute os problemas e concorda nas ações para tratar estes problemas

Page 122: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Processo de revisão de

requisitos

Page 123: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Atividades de Revisão

• Planejar a revisão

– Selecionar time de revisão, hora e local para o encontro de revisão.

• Distribuir os documentos

– O documento de requisitos é distribuído entre os membros do time de revisão

• Preparar para revisão

– Cada revisor individualmente lê os requisitos e encontra conflitos, omissões, inconsistências e desvios dos padrões e outros problemas.

Page 124: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Atividades de Revisão

• Realizar o encontro de revisão – Os problemas e comentários individuais são discutidos e um

conjunto de ações para tratar dos problemas é concordado.

• Ações de acompanhamento – O chefe da revisão verifica se todas as ações acertadas foram

executadas.

• Revisar o documento – O documento de requisitos é revisado para refletir as ações

concordadas. Nestes estágio, pode ser aceito ou revisado novamente

Page 125: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Ações para os problemas

• Clarificação dos requisitos

– O requisito pode ter sido mal escrito ou pode ter acidentalmente omitido alguma informação que foi coletada durante a fase de requisitos.

• Falta de informação

– Alguma informação está faltando no documento de requisitos. É responsabilidade do engenheiro de requisitos que está revisando o documento descobrir esta informação dos stakeholders do sistema.

• Conflito de requisitos

– Existe um conflito significante entre requisitos. Os stakeholders envolvidos devem negociar para resolver o conflito.

• Requisito não realístico

– O requisito não poderá ser implementado com a tecnologia disponível ou dentro da limitações do sistema. Os stakeholders devem ser consultados para decidir como tornar o requisito mais realístico.

Page 126: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Cheque de pré-revisão

• Revisões são caras porque envolvem um número de pessoas que gastará tempo lendo e verificando o documento de requisitos

• Estes gastos podem ser reduzidos usando uma pré-revisão, onde uma pessoa verifica o documento e procura por problemas mais simples tais como: erros tipográficos, falta de aderência ao padrão, falta de algum requisito, etc.

• O documento poderá ser retornado para correção ou enviada a lista de problemas para os revisores

Page 127: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Cheque de pré-revisão

Page 128: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Participantes do time de

revisão

• Os revisores devem incluir um número de stakeholders com backgrounds diferentes

• Pessoas com backgrounds diferentes trazem seus conhecimentos e habilidades para a revisão

• Os stakeholders se sentem envolvidos no processo e ER e desenvolvem um entendimento das necessidades dos outros stakeholders

• O time de revisão deve sempre incluir um especialista no domínio e um usuário final Time independente

Page 129: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Critérios de revisão

• Entendimento – Os leitores do documento podem entender o que o requisito significa?

• Redundância – A informação está desnecessariamente repetida no documento?

• Completude – O revisor conhece algum requisito que está faltando ou existe alguma

informação que está faltando na descrição individual de um requisito?

• Ambiguidade – Os requisitos foram expressos usando termos que estão claramente

definidos? É possível que leitores de backgrounds diferentes fazerem interpretações diferentes dos requisitos?

Page 130: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Critérios de revisão

• Consistência

– As descrições dos diferentes requisitos incluem contradições? Existem contradições entre requisitos individuais e requisitos gerais do sistema?

• Organização

– O documento está estruturado de uma forma apropriada? As descrições dos requisitos estão organizadas de forma que requisitos relacionados estejam agrupados?

• Conformidade a padrões

– O documento de requisitos ou os requisitos individuais estão conforme o padrão definido? Os desvios do padrão estão justificados?

• Rastreamento

– Os requisitos estão identificados de forma não ambígua, incluindo links a outros requisitos relacionados e às razões porque os requisitos foram incluídos?

Page 131: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Questões para o checklist

• Cada requisito está unicamente identificado?

• Os termos especializados estão definidos no glossário?

• O requisito sozinho faz sentido, ou precisamos examinar outros requisitos para entendê-lo?

• Os requisitos individuais usam os termos de forma consistente?

• O mesmo serviço é solicitado em requisitos diferentes? Existem contradições nestas solicitações?

• Se um requisitos faz referência a alguma outra facilidade, elas são descritas em outra parte do documento?

• Os requisitos que são relacionados estão agrupados? Se não, há um referência entre eles?

Page 132: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Exemplo de checklist • OBS: na prática, checklists não devem ser tão grandes!

• Organização e completude

– Todas as referências a outros requisitos estão corretas?

– Todos os requisitos estão escritos em um nível de detalhamento apropriado e consistente?

– Os algoritmos intrínsecos a requisitos funcionais estão definidos?

– A especificação incluí todas as necessidades do sistema e do cliente?

• Corretude – Cada requisito está escrito com uma linguagem clara, concisa e não ambígua?

– A satisfação de cada requisito pode ser verificada através de testes, demonstração, revisão ou análise?

– Cada requisito está dentro do escopo do projeto?

• Rastreabilidade – Cada requisito está unicamente e corretamente identificado?

– Cada requisito funcional de software está ligado um requisito de mais alto nível?

Page 133: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Prototipagem

• Protótipos para validação de requisitos demonstram os requisitos e ajudam aos stakeholders a descobrirem problemas

• Protótipos para validação devem ser completos, razoavelmente eficientes e robustos. Deverá ser possível usá-los da mesma forma que o sistema requerido

• Documentos do usuário e treinamento devem ser providenciados

Page 134: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Prototipagem para

validação

Page 135: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Atividade de Prototipagem

• Escolha os testadores do protótipo – Os melhores testadores são os usuários bem experientes e que

tenham cabeça aberta sobre o uso do novo sistema.

– Usuários finais que têm funções diferentes devem estar envolvidos para que diferentes áreas da funcionalidade do sistema possam ser cobertas.

• Desenvolva os cenários de teste – É necessário um planejamento detalhado para preparar um conjunto

de cenários de teste amplo, que faça cobertura de uma grande quantidade de requisitos.

– Os usuários finais não devem apenas brincar com o sistema, pois isto poderá não exercitar aspectos críticos do sistema.

Page 136: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Atividade de Prototipagem

• Execute cenários

– Os usuários do sistema, geralmente sozinhos, passa a testar o sistema através da execução do cenário planejado.

• Documente problemas

– É melhor definir algum formulário de problemas (eletrônico ou em papel) para que os usuários possam preencher ao encontrar um problema.

Page 137: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Desenvolvimento do

manual de usuário

• A escrita de um manual de usuário a partir de requisitos força uma análise detalhada dos requisitos e assim poderá revelar problemas com os requisitos

• Informação do manual de usuários

– Descrição da funcionalidade e como ela é implementada

– Que partes do sistema não foi implementada

– Como resolver problemas

– Como instalar e começar o sistema

Page 138: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Validação do Modelo

• Validação dos modelos do sistema é uma parte essencial do processo de validação

• Objetivos da validação dos modelos – Demonstrar que cada modelo é auto consistente

– Se existem vários modelos do sistema, demonstrar que eles são internamente e externamente consistentes

– Demonstrar que os modelos refletem de forma precisa os reais requisitos dos stakeholders do sistema

• Alguma verificação é possível com ferramentas automáticas

• Parafrasear o modelo é uma forma efetiva de checagem

Page 139: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Teste dos requisitos

• Cada requisito deve ser testável, isto é deverá ser possível definir um teste para verificar se o requisito foi ou não alcançado.

• A invenção de testes de requisitos é uma técnica efetiva de validação, pois informação ambígua ou incompleta dificulta a formulação dos testes

• Cada requisito funcional deve ter um teste associado

Page 140: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Definição de caso de teste

• Qual cenário de uso poderá ser usado para testar um requisito?

• O requisito, sozinho, inclui informação suficiente para a definição de um teste?

• É possível testar o requisito usando um único teste ou são necessários múltiplos testes?

• O requisito poderá ser reescrito para tornar os casos de teste mais óbvios?

Page 141: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Formulário de teste de

requisito • O identificador do requisito

– Deve haver pelo menos um para cada requisito.

• Requisitos relacionados

– Devem ser referenciados, pois o teste poderá ser relevante também a estes requisitos.

• Descrição do teste

– Uma breve descrição do teste. Deve incluir as entradas do sistema e as saídas correspondentes.

• Problemas do requisito

– Uma descrição dos problemas que tornaram difícil ou impossível a definição do teste.

• Comentários e recomendações

– São conselhos de como resolver os problemas dos requisitos que foram descobertos.

Page 142: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Exemplo de teste de

requisitos

• Quando os usuários acessarem o sistema, eles serão apresentados a páginas web com todos os serviços disponíveis para eles.

Page 143: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Formulário de teste de

requisitos

Page 144: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Requisitos difíceis de

testar

• Requisitos do sistema

– Requisitos que se aplicam ao sistema como um todo.

• Em geral, estes são os requisitos mais difíceis de validar independentemente do método usado, pois podem ser influenciados por quaisquer dos requisitos funcionais.

– Testes que não são executáveis, não podem testar características gerais não-funcionais do sistema, tais como usabilidade.

Page 145: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Requisitos difíceis de

testar

• Requisitos exclusão

– Existem requisitos que excluem comportamentos específicos.

• Por exemplo, um requisito poderia dizer que falhas do sistema nunca devem corromper o banco de dados. Não será possível testar este requisito exaustivamente.

Page 146: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Requisitos difíceis de

testar

• Alguns requisitos não-funcionais

–Alguns requisitos não-funcionais, tais como requisitos de confiabilidade só podem ser testados com um grande conjunto de teste. • O projeto destes testes não ajuda a validação dos

requisitos.

Page 147: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Pontos principais

• A validação de requisitos deve focar em verificar se a versão final do documento de requisitos apresenta conflitos, omissões ou desvios dos padrões.

• As entradas do processo de validação são os documentos de requisitos, padrões organizacionais, e conhecimento implícito da organização. As saídas são uma lista de problemas dos requisitos e as ações concordadas para tratar estes problemas.

• Revisões envolvem um grupo de pessoas fazendo análise detalhada dos requisitos.

• Os custos de revisão podem ser reduzidos se forem verificados, antes da revisão, desvios do padrão organizacional.

Page 148: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Pontos principais

• Checklists sobre o que procurar podem ser usadas para guiar o processo de revisão de requisitos.

• Prototipagem é efetivo para validação de requisitos se um protótipo for desenvolvido durante o estágio de elicitação de requisitos.

• Os modelos do sistema são validados através do seu parafraseamento. Isto significa que eles são sistematicamente traduzidos em uma descrição em linguagem natural.

• Projetando testes para requisitos pode revelar problemas com os requisitos. Se um requisito não estiver claro, poderá ser impossível definir uma teste para ele.

Page 149: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

GERENCIAMENTO DE

REQUISITOS

Page 150: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Gerenciamento de

requisitos

• Relaciona-se ao processo de gerenciar a mudança dos requisitos de um sistema

• As principais preocupações do gerenciamento de requisitos são: – Gerenciar mudanças nos requisitos que foram concordados

– Gerenciar o relacionamento entre requisitos

– Gerenciar as dependências entre os documentos de requisitos e outros documentos (artefatos)

– Analisar impactos e custos relacionados aos requisitos que mudaram

Page 151: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Gerenciamento x

rastreamento de requisitos

• Requisitos não podem ser gerenciados efetivamente sem rastreamento de requisitos.

– Um requisito é rastreável se você puder descobrir quem sugeriu o requisito, porque ele existe, quais os requisitos relacionados a ele e como o requisito está relacionado com outras informações tais como: projeto do sistema, implementações e documentação do usuário.

Page 152: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Rastreamento

• Rastreamento é aquela informação que ajuda a analisar o impacto de uma mudança de requisito.

• Rastreamento relaciona requisitos entre si e entre outras representações do sistema (ex: código, casos de teste, etc.).

Page 153: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Matrizes de rastreamento

• Mostram os relacionamentos (interações) entre requisitos ou entre requisitos e componentes de projeto

• Os requisitos são listados ao longo dos eixos horizontais e/ou verticais e os relacionamentos são marcados nas células da matriz

Page 154: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Uma matriz de rastreamento

Page 155: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Políticas de rastreamento

• As políticas de rastreamento definem o que e como a informação de rastreamento será mantida.

• As políticas de rastreamento podem incluir – A informação de rastreamento que deve ser mantida.

– Técnicas, tais como matrizes de rastreamento, que devem ser usadas para manter o rastreamento.

– Uma descrição de quando a informação de rastreamento deve ser coletada durante o desenvolvimento do sistema.

– A definição do papel das pessoas responsáveis pelo rastreamento.

– Uma descrição de como lidar e documentar exceções à política.

Page 156: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Fatores que influenciam a

política de rastreamento

• Número de requisitos

– Quanto maior o número de requisitos, maior a necessidade de políticas formais de rastreamento.

• Vida útil estimada do sistema

– Para sistemas com longa vida útil será necessário definir políticas mais abrangentes.

Page 157: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Fatores que influenciam a

política de rastreamento

• Nível de maturidade das organizações

– Políticas detalhadas serão mais efetivas em organizações com um alto nível de maturidade nos processos de desenvolvimento.

• Tamanho e composição do time de projeto

– Com um pequeno time, poderá ser possível avaliar o impacto de mudanças propostas informalmente, sem uma estrutura de informação de rastreamento. Com grande times, contudo, será necessário políticas mais formais de rastreamento.

Page 158: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Fatores que influenciam a

política de rastreamento

• Tipo do sistema

– Sistemas críticos (ex: de controle de tempo real) precisam de políticas mais abrangentes do que sistemas não críticos.

• Requisitos específicos do cliente

– Alguns clientes podem especificar que a informação de rastreamento deverá ser entregue como parte do sistema.

Page 159: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Atributos dos requisitos

• São informações a cerca do contexto e das propriedades dos requisitos.

– Data de criação

– Identificador

– Número de versão

– Autor

– Status (ex: proposto, aprovado, rejeitado)

– Origem

– Justificativa

– Subsistemas correlatos

Page 160: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Atributos dos requisitos

• São informações a cerca do contexto e das propriedades dos requisitos.

– Subsistemas correlatos

– Release correlatas

– Prioridade

– Estabilidade

– Custo

– Complexidade

• Matrizes de atributos são usadas para mostrar o relacionamento entre requisitos e seus atributos.

Page 161: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Gerenciamento de

mudança

• está relacionado com os procedimentos, processos e padrões que serão usados para gerenciar as mudanças (inclusive de requisitos) do Sistema

• A política de gerenciamento de mudanças poderá incluir: – O processo de solicitação de mudanças e a informação necessária para

processar cada solicitação de mudança

– O processo usado para analisar o impacto e custo da mudança e a informação de rastreamento associada

– Definição dos membros do comitê que formalmente considera as solicitações de mudanças

– O suporte de software necessário para o processo de controle de mudança

Page 162: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Requisitos estáveis e

voláteis

• Mudanças nos requisitos ocorrem enquanto eles estão sendo elicitados, analisados, validados e após o sistema entrar em serviço (produção).

• Alguns requisitos são mais sujeitos a mudanças do que outros

– Requisitos estáveis são aqueles relacionados com a essência do sistema e seu domínio de aplicação. Eles mudam mais devagar que os requisitos voláteis.

– Requisitos voláteis são específicos a instanciação do sistema em um ambiente em particular e para um cliente em particular.

Page 163: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Fatores para a

mudança dos requisitos

• Erros, conflitos e inconsistências nos requisitos

– Quando os requisitos são analisados e implementados, erros e inconsistências emergem e devem ser corrigidos. Eles podem ser descobertos durante a análise e validação de requisitos ou mais tarde durante o processo de desenvolvimento.

• Evolução do conhecimento do cliente/usuário-final do sistema

– Ao se desenvolver os requisitos, clientes e usuários-finais desenvolvem um melhor entendimento do que eles realmente querem do sistema.

Page 164: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Fatores para a

mudança dos requisitos

• Problemas técnicos, de custo e prazo

– Problemas podem ser encontrados quando da implementação de um requisito. Pode ser muito caro ou demorar demais para implementar certo requisito.

• Mudança na prioridade dos clientes

– A prioridade dos clientes pode mudar durante o desenvolvimento do sistema como resultado de mudanças no ambiente de negócios, o surgimento de novos competidores, mudanças na equipe, etc.

Page 165: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Fatores para a

mudança dos requisitos

• Mudanças ambientais

– O ambiente no qual o sistema será instalado poderá mudar de modo que os requisitos de sistema precisem ser alterados para manter a compatibilidade

• Mudanças organizacionais

– A organização que pretende usar o sistema pode precisar mudar sua estrutura e processos, resultando em novos requisitos do sistema

Page 166: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Estágios do gerenciamento

de mudanças

Page 167: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Estágios do gerenciamento

de mudanças

• Algum problema é identificado – Isto pode ser oriundo de uma análise do documento de requisitos,

novas necessidades dos clientes, ou problemas operacionais com o sistema. Com base no problema, mudanças são propostas.

• As mudanças propostas são analisadas – Verifica-se quantos requisitos (e se necessário, componentes de

sistema) serão afetados pela mudança e calcula-se de forma aproximada quanto custará, em tempo e dinheiro, realizar a mudança.

• A mudança é implementada – Um conjunto de alterações e uma nova versão do documento de

requisitos são produzidos.

Page 168: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Custo e análise de mudança

Page 169: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Ferramentas CASE para o

gerenciamento de requisitos

• O gerenciamento de requisitos envolve a coleta, armazenamento e manutenção de grande quantidade de informação.

• Existe um grande número de ferramentas CASE disponíveis que foram projetadas para suportar o gerenciamento de requisitos.

• Outras ferramentas CASE, tais como “sistemas de gerenciamento de configuração e versão” e “sistemas de gerenciamento de mudanças” podem ser adaptadas para a engenharia de requisitos.

Page 170: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Um sistema de gerenciamento

de requisitos

Page 171: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Vantagens do Uso de Ferramentas de

Gerenciamento de Requisitos

• Captura e Identificação dos Requisitos – Classificação dos requisitos;

– Identificação semiautomática dos requisitos.

• Análise de Rastreamento – Identificação de inconsistência;

– Verificação de requisitos.

• Gerenciamento de Configuração – Histórico das mudanças dos requisitos: quem, o que, quando,

onde, por que e como;

– Controle de versão dos requisitos;

– Controle de acesso.

Page 172: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Pontos principais

• A mudança dos requisitos é inevitável quando os clientes desenvolvem uma melhor entendimento das suas reais necessidades e quando ocorrem mudanças nas políticas, ambiente técnico e organizacional no qual o sistema irá ser instalado.

• Requisitos que estão relacionados com a essência do sistema são mais prováveis de serem estáveis do que aqueles que estão relacionados de como o sistema será implantado num determinado ambiente.

• Os requisitos voláteis incluem os seguintes tipos: requisitos mutáveis, requisitos emergentes, requisitos de consequência e requisitos de compatibilidade.

Page 173: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Pontos principais

• O gerenciamento de requisitos requer que cada requisitos seja identificado de forma única.

• Se o número de requisitos for grande, os requisitos devem ser armazenados num banco de dados e se deve manter relacionamentos entre os requisitos.

• A políticas de gerenciamento de mudança devem definir o processo usado para gerenciamento de mudança e a informação que deve está associado com uma solicitação de mudança. Devem também definir que é responsável por fazer o que no processo de gerenciamento de mudança.

Page 174: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Pontos principais

• Algum suporte automático para gerenciamento de mudança deve ser provido. Isto pode ser através de ferramentas especializados de gerenciamento de requisitos ou pela configuração de ferramentas existentes para suportar o gerenciamento de mudança.

• A informação de rastreamento guarda as dependências entre requisitos e as fontes desses requisitos, dependências entre requisitos e dependências entre requisitos e a implementação do sistema.

Page 175: Análise Orientada a Objetos - Início | Faculdade de …bacala/DAW/Aula02-1 - Engenharia de...Estrutura do documento de requisitos •Padrão IEEE/ANSI 830-1998 uma estrutura para

Pontos principais

• Matrizes de rastreamento são usadas para registrar a informação de rastreamento.

• A coleta e manutenção de informação de rastreamento é caro. Para ajudar a controlar estes custos, as empresas deve definir um conjunto de políticas de rastreamento que definem qual a informação a ser coletada e como ela será mantida.