Levantamento e Análise de Requisitos conceitos e aplicação

Facilitador: Luiz Gustavo Arantes
Brasília, Novembro 2007

Copyright © 2007 Accenture All Rights Reserved. Accenture, its logo, and High Performance Delivered are trademarks of Accenture.

Agenda
Objetivos do Treinamento e Fontes
Conceitos Gerais Coleta de Requisitos Documentação de Requisitos Análise de Requisitos Aprovação e Transição dos Requisitos Gerenciamento e Controle de Mudanças

Metodologia da Brasil Telecom - MDS
Dicas e Sugestões
Copyright © 2007 Accenture All Rights Reserved.

Agenda
Objetivos do Treinamento e Fontes
Conceitos Gerais Coleta de Requisitos Documentação de Requisitos Análise de Requisitos Aprovação e Transição dos Requisitos Gerenciamento e Controle de Mudanças

Metodologia da Brasil Telecom - MDS
Dicas e Sugestões
Copyright © 2007 Accenture All Rights Reserved.

Objetivos do treinamento  Nivelar e padronizar o conhecimento sobre requisitos.  Capacitar pessoas nas atividades de levantamento e análise de requisitos. Copyright © 2007 Accenture All Rights Reserved.  Formar disseminadores de conhecimento. .  Aplicar o conhecimento adquirido no Projeto.

com/Communities/Pages/RequirementsCoP.aspx  My Learning  Requirements Development and Management  Accenture Knowledge Exchange (KX)  Requirements CoP https://kx.accenture.accenture. .com/Offerings/Pages/ADM.Fontes  ADM (Accenture Delivery Methods)  Accenture Delivery Methods for Packaged Development https://kx.aspx Copyright © 2007 Accenture All Rights Reserved.

MDS Dicas e Sugestões Copyright © 2007 Accenture All Rights Reserved. .Agenda Objetivos do Treinamento e Fontes Conceitos Gerais Coleta de Requisitos Documentação de Requisitos Análise de Requisitos Aprovação e Transição dos Requisitos Gerenciamento e Controle de Mudanças Metodologia da Brasil Telecom .

Condição a ser preenchida das formalidades legais. segundo certas formas 2. 3. Exigência imprescindível para legais. dentro 3. necessariamente pelo feita pelo parlamentar produto ou serviço. a consecução de certo fim. . Petição por escrito. deverá estar para que uma coisa satisfazer em conformidade. Ato a qual o de requerer. fique legal e regular. Condição a quecondição ou uma capacidade com ou efeitosistema 1.” 2. Petição por escrito.Conceitos Gerais  Qual a diferença entre Requisito e Requerimento? Conceito do RUP: Requisito: Requerimento: “Requisito = uma se deve 1. versando sobre matéria de expediente ou de ordem ≠ Copyright © 2007 Accenture All Rights Reserved.

procedimentos.  Descrevem as políticas.  Geralmente são complementos de um determinado requisito. Copyright © 2007 Accenture All Rights Reserved. definições e restrições que se aplicam a uma organização.  As regras de negócio podem ser descritas em forma de requisito.Conceitos Gerais  Conceito de Regras de Negócio  Regra de negócio expressa determinada condição . .tem uma expressão lógica associada.

Conceitos Gerais Os requisitos devem descrever exatamente o que o cliente deseja Os requisitos definem o escopo do projeto ou da demanda Os requisitos devem permitir ao fornecedor entender exatamente o que o cliente quer Copyright © 2007 Accenture All Rights Reserved. .

estouram orçamento ou não atingem seus objetivos. por isso que geralmente a solução é dividida em dois documentos: requisitos do usuário (user requirements) e especificação do sistema (com a visão do desenvolvedor). Detalhar bem os requisitos requer tempo.Fatores Motivadores   A qualidade dos requisitos podem justificar o sucesso ou fracasso do projeto. mas gera uma grande economia de tempo. . custaria muito mais caro corrigir. Desenvolvedores tem uma perspectiva diferente dos usuários. esforço e habilidade no início do projeto. Sem a análise adequada dos requisitos os projetos atrasam. custo e esforço no decorrer das demais fases do projeto. Copyright © 2007 Accenture All Rights Reserved.   A análise de requisitos antecipa problemas que se fossem encontrados mais tarde.

Vijay Purugulla.  Mais de 80% do retrabalho é gasto corrigindo falhas na definição dos requisitos.Fatores Motivadores  Mais de 50% dos defeitos de software encontrados são atribuídos a erros de requisitos. Copyright © 2007 Accenture All Rights Reserved. Kamal. minimizando o impacto em custos e atrasos no cronograma. ." Justine Chiang. O Objetivo do Gerenciamento de Requisitos é evitar o retrabalho. Andrew White. Fonte: Source: "Requirements Overview: Processes and Deliverables. Sinha. May 2001.

.Fatores Motivadores Estudos mostram que grande parte dos defeitos apresentados podem ser atribuídos aos requisitos quando não existe um processo formal de gestão de requisitos definido. Projeto COM processo formal de gestão de requisitos Projeto SEM processo formal de gestão de requisitos Source: “Borland: Best Practices for Requirements Development & Management” Copyright © 2007 Accenture All Rights Reserved.

Principais Problemas  Os problemas encontrados durante a levantamento de requisitos são muitos e bem conhecidos. Desenvolvimento e Testes Problemas “Eu não sei o que eu quero” “Eu quero tudo” “Eu não quero pagar muito caro ou esperar por muito tempo” “Nós não chegamos a um consenso sobre o que a gente quer” “Nós não temos idéia de quanto deveria custar” Copyright © 2007 Accenture All Rights Reserved. está muito vago” 13 . São problemas assim que transformam a fase de requisitos em uma fase complexa e confusa. Stakeholders Time de Requisitos Documento de Requisitos Times de Desenho. “Eu estou falando com as pessoas certas?” “Será que eles esqueceram de mencionar algum requisito ou está implícito?” “Eu não entendo o que eles estão dizendo” “Eu não sei se todos tiveram o mesmo entendimento acerca do requisito” “Não sei quais são as prioridades do cliente” “Eu não entendi este requisito” “Algumas coisas estão faltando” “Estes dois requisitos são contraditórios” “Este requisito não me diz nada.

Na realidade. 14 .  Os requisitos são alterados.Principais Problemas A coleta de requisitos pode parecer uma tarefa bem precisa. Copyright © 2007 Accenture All Rights Reserved.  Os requisitos têm propriedades exclusivas ou valores de propriedade.  Existem diversos tipos de requisitos em diferentes níveis de detalhe. o que significa que os requisitos precisam ser gerenciados por grupos de pessoas de diferentes funções. Por exemplo.  Há várias partes interessadas. os projetos enfrentam dificuldades pelos seguintes motivos:  Nem sempre os requisitos são óbvios e podem vir de várias fontes. eles não são necessariamente igualmente importantes ou igualmente fáceis de se atender. porém.  Os requisitos nem sempre são expressos em palavras de modo fácil ou claro.

 Reduz o esforço de desenvolvimento. Copyright © 2007 Accenture All Rights Reserved.Benefícios Benefícios da Gestão de Requisitos:  Estabelece uma base de acordo entre o cliente e o fornecedor em relação ao que deve ser feito.  Pode ser utilizado como fator de comparação.  Define o escopo e permite a rastreabilidade dos artefatos gerados.  Facilita a “transição” dos requisitos para as demais equipes (desenvolvimento.  Fornece uma base para validação e verificação do que foi desenvolvido.  Fornece uma base para estimativa de custos e prazos.  Facilita a negociação de contratos. .  Serve como “base de conhecimento”. testes e treinamento).

Requisitos .Etapas Project Life Cycle Gerenciamento dos Requisitos Planejamento Análise Desenho Construção Testes Deploy Coleta de Requisitos Controle de Mudanças Documentação dos Requisitos Análise dos Requisitos Aprovação e Transição dos Requisitos Copyright © 2007 Accenture All Rights Reserved. .

MDS Dicas e Sugestões Copyright © 2007 Accenture All Rights Reserved. .Agenda Objetivos do Treinamento e Fontes Conceitos Gerais Coleta de Requisitos Documentação de Requisitos Análise de Requisitos Aprovação e Transição dos Requisitos Gerenciamento e Controle de Mudanças Metodologia da Brasil Telecom .

Requisitos .Coleta de Requisitos Coleta de Requisitos Documentação dos Requisitos Análise dos Requisitos Aprovação e Transição dos Requisitos Identificando os Stakeholders Identificando os Requisitos Categorizando os Requisitos Características de um “bom” requisito Características de um requisito “ruim” Copyright © 2007 Accenture All Rights Reserved. .

os usuários-chave e os demais Stakeholders do Projeto.Coleta de Requisitos – Identificando os Stakeholders Stakeholders são pessoas que influenciam positiva ou negativamente. Copyright © 2007 Accenture All Rights Reserved.  Definir a abordagem ou estratégia para o levantamento de requisitos.  Identificar o nível de comprometimento dos Stakeholders.  Entender os objetivos e a expectativa dos Stakeholders. Exemplos de Stakeholders: Usuários Clientes / Patrocinadores Gerentes Órgãos Reguladores Fornecedores Nesta etapa. .  Definir os macro-requisitos do negócio (High Level Requirements). ou sofrem influência do novo sistema ou sistema que será alterado. você deve:  Identificar o Sponsor.

Copyright © 2007 Accenture All Rights Reserved.  São definidos na etapa de planejamento do projeto. serão levantados os macro-requisitos que irão definir o escopo da demanda ou do projeto.Coleta de Requisitos – Definindo os Requisitos Macro Nesta etapa. .  Documentos já existentes do projeto podem servir como ponto de partida para obter os macro-requisitos: Plano do Projeto RFP (Request of Proposal) Proposta Draft de requisitos redigidos previamente pelo cliente Os macro-requisitos devem ser confirmados com o sponsor e/ou usuário-chave antes de coletar e documentar os requisitos detalhados.  Antes de coletar os requisitos é necessário identificar os macro-requisitos. pois é o que irá definir o escopo do projeto.

Copyright © 2007 Accenture All Rights Reserved.  Técnicas de Abordagem: as técnicas mais comuns de levantamento de requisitos detalhados são:  Focus Groups  JAD (Joint Application Design Session)  Pesquisas . orçamento e escopo.de Documentos (inclusive Intranet e Internet) e Pesquisas de Campo  Entrevistas Individuais  Observação  Construção / Visualização de Cenários A estratégia para a definição da abordagem deve considerar a limitação de tempo. além da disponibilidade dos recursos.Coleta de Requisitos – Identificando os Requisitos Detalhados Os macro-requisitos servirão para direcionar o detalhamento dos requisitos. .

Esta observação pode ser feita presencialmente ou via vídeo. Políticas. Também podem ser realizadas pesquisas através de questionários(abertos ou fechados) distribuídos aos interessados Discussões individuais com os usuários-chave para obter detalhes sobre as tarefas e os processos realizados pelo usuário. Esta técnica é a mais utilizada para detalhar os requisitos. Geralmente 8 a 12 participantes. etc). . ou seja. Um facilitador lidera a discussão acerca de um propósito ou tópico específico. Manuais.Técnicas de Abordagem Técnica Focus Groups Descrição Na técnica do tipo Focus Groups (ou "discussão em grupo") os stakeholders e/ou usuários finais são reunidos em um local (ou via audio/video conference). O facilitador conversa com o usuário através de um exercício de visualização tentando reproduzir os seus processos de negócio através de uma aplicação considerada ideal É utilizada para entender melhor a complexidade dos processos de negócio existentes. Muito similar ao Focus Groups. Esta técnica é ideal para sistemas que não existem ainda e que serão usados para substituir processos manuais. durante as definições e validações iniciais. esta técnica é tradicionalmente utilizada para se obter maiores detalhes sobre uma proposta ou requisito macro já definido em uma reunião de Focus Groups. além da intranet e internet Entrevistas individuais são necessárias para entender a complexidade dos processos de negócio e as tarefas executadas por um usuário em um sistema já existente que será customizado ou substituído. JAD (Joint Application Design Session) Pesquisas Entrevistas Individuais Observação Esta técnica consiste em observar o usuário interagindo com a aplicação. quando se juntam em uma reunião os analistas de requisitos e os usuários-chave para detalhar os macro requisitos. Não faz sentido fazer este tipo de reunião quando as definições macro já estão claras e definidas. Ex: definição dos macro-requisitos. Construção / Visualização de Cenários Copyright © 2007 Accenture All Rights Reserved. Este tipo de entrevista pode ser formal ou informal. Envolve grupos menores e mais interativos Geralmente envolve pesquisas nas documentações disponíveis sobre um assunto (incluindo a Intranet e Internet).Coleta de Requisitos . É um exercício. Quando é mais apropriada Geralmente é utilizada nas primeiras fases do projeto. É o tipo de técnica de levantamento mais utilizada nos projetos É recomendada no início do projeto onde são pesquisados os documentos disponibilizados pelo cliente (Proposta.

Coleta de Requisitos – Identificando os Requisitos Detalhados
O processo de levantamento de requisitos pode envolver uma combinação das técnicas abaixo:
Agrupamento

Levantamento

Pesquisa

Proposta de Novos Processos (Inovação)

Reutilização de Requisitos

Entrevistas

Focus Group

Observação dos Processos de Negócio

Pesquisa de Documentos

JAD

“A vida não é simples, infelizmente levantar requisitos não é simplesmente perguntar ao cliente o que ele quer”
Copyright © 2007 Accenture All Rights Reserved.

Coleta de Requisitos – Categorizando os Requisitos
Os requisitos devem ser organizados por tipo. Existem 6 categorias principais para classificar um requisito.
Funcionais – especificam o que o usuário espera poder fazer no sistema Técnicos – especificam as restrições técnicas que o sistema deve obedecer De Negócio – especificam as regras de negócio que o sistema deve considerar Performance – mensuram os objetivos de agilidade e capacidade do sistema Usabilidade – especifica a facilidade que o usuário espera para executar uma tarefa Conteúdo – especifica o tipo de conteúdo do sistema
Demais categorias de requisitos:  Dados – define os dados que devem ser migrados dos sistemas legados

 Segurança e Controle – considera as políticas de segurança, privacidade e controles internos
 Integração – define as aplicações e fontes de dados que deverão estar integradas ao sistema  Qualidade – define os critérios de confiabilidade e flexibilidade do sistema
Copyright © 2007 Accenture All Rights Reserved.

Exercício – Tipos de Requisitos
Classifique os requisitos de acordo com a categoria:
1) O sistema deve suportar até 20.000 usuários concorrentes 2) Os gráficos de comparação devem ser apresentados sempre em conjunto com as tabelas de origem 3) O sistema deve permitir que o usuário ordene os produtos de acordo com o preço de compra 4) A aplicação deve ser acessada através do IE 6 (ou Superior) 5) O sistema deverá permitir ao usuário retornar à página inicial de qualquer página do site.
Copyright © 2007 Accenture All Rights Reserved.

A) Funcional

B) Técnico

C) Performance

D) Usabilidade

E) Conteúdo

dentro do orçamento e prazo?  Modificável – o requisito pode facilmente ser alterado?  Priorizável – baseado na importância e urgência  Necessário – o requisito tem utilidade?  Rastreável – o requisito tem um único código de identificação? Copyright © 2007 Accenture All Rights Reserved.Requisitos – Características de “Bons” Requisitos Alguns critérios são determinantes para definir um “bom” requisito e devem ser considerados durante coleta e documentação de requisitos. Os requisitos devem ser:  Correto – o requisito representa exatamente o que o cliente quer?  Completo – o requisito expressa completamente a idéia ou a instrução?  Claro – o requisito está ambíguo ou dando margem a dúvidas?  Consistente – o requisito está coincidindo com os demais requisitos ou está contradizendo algum?  Verificável – dá para confirmar que o sistema atenderá o requisito? Ele é testável?  Realista – é factível atender o requisito do ponto de vista técnico. .

altamente versátil. ainda. . mas. provavelmente 100% confiável. flexível. também. normalmente Se. a menos que. campos ou telas Pode. talvez.Requisitos – Características de Requisitos Ruins Problema 1 Palavras-Chave ou. e assim por diante. poderia. porventura. exceto. assim Geralmente. dentre outros e. o máximo possível. garanta Interface amigável. o mínimo possível Ambiguidade Requisitos Combinados Especulação Cláusulas de exceção Define o sistema Expressa possibilidades Pede o impossível Termos vagos 2 3 4 5 6 7 8 Copyright © 2007 Accenture All Rights Reserved. apesar de Nome de componentes. frequentemente. roda em todas as plataformas. etc. quando.

Exercício: Qualidade dos Requisitos Classifique os requisitos abaixo: Requisito A aplicação deve ser compatível com o Windows XP Bom X Ruim Deve ser possível que o usuário faça uma pesquisa pelo modelo do veículo ou pelo fabricante Os usuários selecionarão o tipo do modelo através de uma drop down O nome da página que o usuário estiver visualizando deverá aparecer na barra de tarefas quando a página for minimizada X X X Copyright © 2007 Accenture All Rights Reserved. .

Agenda Objetivos do Treinamento e Fontes Conceitos Gerais Coleta de Requisitos Documentação de Requisitos Análise de Requisitos Aprovação e Transição dos Requisitos Gerenciamento e Controle de Mudanças Metodologia da Brasil Telecom .MDS Dicas e Sugestões Copyright © 2007 Accenture All Rights Reserved. .

Requisitos – Documentação dos Requisitos Coleta de Requisitos Documentação dos Requisitos Análise dos Requisitos Aprovação e Transição dos Requisitos Guia para documentação de requisitos Transformando informações em requisitos Documentação de Requisitos Copyright © 2007 Accenture All Rights Reserved. .

Cada requisito deve conter um sujeito e um predicado. Definir o requisito de forma que o usuário/cliente possa facilmente entendê-lo 3. onde o sujeito é o tipo do usuário ou do sistema em discussão e o predicado é a condição. Manter as sentenças curtas e concisas 2. . Copyright © 2007 Accenture All Rights Reserved. Apenas defina requisitos que sejam necessários ao sistema / aplicação 10. demonstração ou teste. Tenha certeza que o requisito não seja contraditório ou sobreponha outros requisitos 9.Confirme que o requisito possa ser verificado através de uma inspeção. ação ou o resultado desejado 6. Cada requisito deve formar uma única sentença completa 5. Documentar individualmente os requisitos testados.Documentação dos Requisitos – Guia para Documentação de Requisitos O time de requisitos deve seguir o guia abaixo para a documentação de requisitos e fazer a revisão em pares (Peer Review) antes de submetê-los ao cliente: 1. Use a palavra “deve” 7. análise. Evitar parágrafos longos que contenham mais de um requisito 4. O requisito deve especificar o objetivo ou resultado final desejado 8.

D) O usuário deveria ter a possibilidade de imprimir as informações da sua conta através do site da empresa Copyright © 2007 Accenture All Rights Reserved. B) O site da empresa na internet deve prover um endereço de e-mail onde os usuários podem submeter dúvidas ao Help-Desk. e deve fornecer ao usuário um suporte caso ele não se lembra da sua senha.Exercício – Documentação de Requisitos Qual das sentenças abaixo é um exemplo de um bom requisito: A) 15. .000 usuários devem ser capazes de acessar o site da empresa na internet. C) O site da empresa na internet deve exigir que o usuário se conecte através de um nome de usuário e senha.

. A página inicial deve ser acessada a partir de qualquer outra página secundária. O usuário deve conseguir pesquisar o cliente através do telefone do cliente. Eu tenho que ficar clicando no botão de Voltar para acessar a página inicial. Como se isso não fosse ruim o suficiente. elas deverão ser traduzidas em requisitos formais. O usuário deve conseguir pesquisar o cliente através do número do cliente. a função de pesquisa é péssima! Você só pode pesquisar pelo número do cliente. Exemplo de um problema relatado pelo cliente: “É impossível retornar à página inicial de qualquer outra página secundária – Eu fico perdido e confuso.Documentação dos Requisitos – Traduzindo Informações em Requisitos Depois de coletar as informações dos Stakeholders. O usuário deve conseguir pesquisar o cliente através do sobrenome do cliente.  A equipe de requisitos deve procurar entender os problemas do cliente (ou oportunidades) e transformar estas informação em requisitos que promovam o entendimento comum. Bom. uma vez que é difícil traduzir as informações em requisitos que sejam facilmente compreendidos por qualquer um.  Esta é a parte mais difícil do levantamento de requisitos. que tal pesquisar também pelo sobrenome e pelo número do telefone?” Copyright © 2007 Accenture All Rights Reserved.

Documentação dos Requisitos – Formas de Documentação  Formulário de Requisitos (Word ou Excel)  Exige um controle de versões para manter o histórico de alterações  Não possibilita uma ratreabilidade bi-direcional de requisitos  Modelos de Caso de Uso  O caso de uso descreve a seqüência de ações ou eventos que a aplicação executa  Cada evento de caso de uso é suportado por um ou mais requisitos  Requirements Traceability Matrix (RTM)  Exige um controle de versões para manter o histórico de alterações  É a principal ferramenta que o time usa para gravar e rastrear requisitos depois de validados e assinados pelo cliente Copyright © 2007 Accenture All Rights Reserved. .

MDS Dicas e Sugestões Copyright © 2007 Accenture All Rights Reserved. .Agenda Objetivos do Treinamento e Fontes Conceitos Gerais Coleta de Requisitos Documentação de Requisitos Análise de Requisitos Aprovação e Transição dos Requisitos Gerenciamento e Controle de Mudanças Metodologia da Brasil Telecom .

.Requisitos – Análise dos Requisitos Coleta de Requisitos Documentação dos Requisitos Análise dos Requisitos Aprovação e Transição dos Requisitos Verificação dos Requisitos Priorização dos Requisitos Validação dos Requisitos Copyright © 2007 Accenture All Rights Reserved.

.  A verificação é um processo que deve ocorrer internamente  O processo se dá através da revisão por pares (Peer Review)  A verificação também é feita na etapa de testes. para garantir que a solução está atendendo os requisitos especificados Copyright © 2007 Accenture All Rights Reserved.Análise dos Requisitos – Verificação dos Requisitos A proposta da verificação é confirmar que os requisitos especificados coincidem com o trabalho que deverá ser executado para atingir os objetivos esperados.

Análise dos Requisitos – Priorização dos Requisitos É necessário criar uma hierarquia que reflita quais requisitos são mais importantes e quais são menos importantes. tais como: Custo / Benefício Esforço para Implantação Cronograma Relevância para os objetivos de negócio  Este processo deve ser realizado em conjunto com o cliente  Em alguns casos. .  A equipe de requisitos deve analisar cada requisito de acordo com algum critério. Copyright © 2007 Accenture All Rights Reserved. este processo nem precisa ser feito (Ex: demandas simples e com orçamento suficiente).

 Podem ser usados durante a Validação de Requisitos. Matriz de Rastreabilidade de Requisitos Mapeamento de Processos Casos de Uso Protótipo  Nesta fase. . devem ser descobertos os requisitos “implícitos” Copyright © 2007 Accenture All Rights Reserved.Análise dos Requisitos – Validação dos Requisitos O objetivo da validação dos requisitos é confirmar que o que o cliente deseja é o que está especificado e será desenvolvido.

MDS Dicas e Sugestões Copyright © 2007 Accenture All Rights Reserved. .Agenda Objetivos do Treinamento e Fontes Conceitos Gerais Coleta de Requisitos Documentação de Requisitos Análise de Requisitos Aprovação e Transição dos Requisitos Gerenciamento e Controle de Mudanças Metodologia da Brasil Telecom .

Requisitos – Aprovação e Transição dos Requisitos Coleta de Requisitos Documentação dos Requisitos Análise dos Requisitos Aprovação e Transição dos Requisitos Copyright © 2007 Accenture All Rights Reserved. .

o time de requisitos deve agrupar todos os requisitos em um documento único. . os requisitos passarão a ser considerados a linha de base (escopo) do projeto.  Após a revisão e aprovação do cliente. Copyright © 2007 Accenture All Rights Reserved.  A aprovação do cliente pode ser obtida através da assinatura de um documento ou de um e-mail de aprovação.  Depois de definida a linha de base de requisitos. qualquer alteração deverá ser formalizada de forma a determinar o impacto e controlar a execução da mudança.Obtendo a Aprovação (Sign-off) dos Stakeholders Antes de obter a assinatura do cliente.

as informações de requisitos serão transferidas para o cliente e/ou para outros times do projeto  O objetivo da transição de requisitos bem feita é garantir o sucesso das próximas fases do projeto  Os demais times do projeto (desenvolvimento. testes e treinamento) devem entender perfeitamente o que os requisitos significam  Os requisitos devem ficar armazenados em um local de fácil acesso e devem ser realizados backups freqüentes  Deve ser definido um processo para atualização dos requisitos. As mudanças nos requisitos devem ser acordadas e comunicadas a todos os grupos envolvidos Copyright © 2007 Accenture All Rights Reserved. .Transição dos Requisitos Depois de validados e aprovados.

Agenda Objetivos do Treinamento e Fontes Conceitos Gerais Coleta de Requisitos Documentação de Requisitos Análise de Requisitos Aprovação e Transição dos Requisitos Gerenciamento e Controle de Mudanças Metodologia da Brasil Telecom . .MDS Dicas e Sugestões Copyright © 2007 Accenture All Rights Reserved.

.Requisitos – Gerenciamento de Requisitos e Controle de Mudanças Project Life Cycle Gerenciamento dos Requisitos Planejamento Análise Desenho Construção Testes Deploy Coleta de Requisitos Documentação dos Requisitos Análise dos Requisitos Controle de Mudanças Objetivo: Controlar a linha de base de requisitos e fazer o gerenciamento do escopo em relação ao que está sendo entregue Aprovação e Transição dos Requisitos Copyright © 2007 Accenture All Rights Reserved.

 O Controle de Mudanças. organizar e controlar os requisitos de um sistema” Copyright © 2007 Accenture All Rights Reserved. assim como as demais atividades.Gerenciamento de Requisitos e Controle de Mudanças O gerenciamento de requisitos é um esforço contínuo durante o ciclo de vida de um projeto. . faz parte do Gerenciamento de Requisitos “O gerenciamento de requisitos é uma abordagem sistemática para localizar.  É importante manter todos os requisitos em um único local e de uma forma organizada. documentar.  O Gerenciamento de requisitos ajuda a manter a integridade dos requisitos e a definição do escopo.

.Gerenciamento de Requisitos e Controle de Mudanças É importante ressaltar que qualquer mudança afeta pelo menos duas variáveis do triângulo abaixo: Custo Prazo (Cronograma) Adequação ao Uso (Escopo) Copyright © 2007 Accenture All Rights Reserved.

Gerenciamento de Requisitos e Controle de Mudanças Passos para o Controle de Mudanças: Identificar as Requisições de Mudança Documentar as Requisições de Mudança Obter Autorização para a Mudança Implementar a Mudança Atualizar os Documentos Impactados  Os principais aspectos do gerenciamento do escopo e dos requisitos são:  Definir as regras para o processo de solicitação de mudança (Change Request)  Identificar o que realmente constitui uma mudança de escopo  Definir as regras para a análise de impacto que a alteração pode causar  Definir as regras para a aprovação da mudança e implementação da alteração Copyright © 2007 Accenture All Rights Reserved. .

.Gerenciamento de Requisitos e Controle de Mudanças Identificar as Requisições de Mudança: Identificar as Requisições de Mudança Documentar as Requisições de Mudança Obter Autorização para a Mudança Implementar a Mudança Atualizar os Documentos Impactados  A alteração mais comum no escopo é a adição de novos requisitos  Um novo requisito pode ser sugerido em qualquer fase do projeto  Quanto mais tarde for solicitada uma mudança de escopo. maior o impacto em custos  Muitas vezes as necessidades de mudanças são percebidas apenas nas fases de testes e homologação Copyright © 2007 Accenture All Rights Reserved.

além das justificativas para a mudança  No CR também deve envolver as informações de prazo e custo para a implantação da mudança  Deve ser feita uma análise de impacto também na documentação já gerada Copyright © 2007 Accenture All Rights Reserved.Gerenciamento de Requisitos e Controle de Mudanças Documentar as Requisições de Mudança: Identificar as Requisições de Mudança Documentar as Requisições de Mudança Obter Autorização para a Mudança Implementar a Mudança Atualizar os Documentos Impactados  Nesta etapa deve ser documentada a solicitação de mudança (Change Request . .CR)  O CR deve detalhar a mudança a ser feita.

Gerenciamento de Requisitos e Controle de Mudanças Obter Autorização para a Mudança: Identificar as Requisições de Mudança Documentar as Requisições de Mudança Obter Autorização para a Mudança Implementar a Mudança Atualizar os Documentos Impactados  Todas as solicitações de mudanças devem ser aprovadas pelo sponsor e/ou pelo usuário-chave do projeto  A solicitação de mudança pode ser:  Rejeitada: deve notificar a decisão de rejeição e registrar as justificativas  Adiada: deve ser definida uma nova data para reavaliação  Aprovada: deve notificar a decisão de aprovação e definir uma data para implantação Copyright © 2007 Accenture All Rights Reserved. .

. isto implica em:  Desenhar. será disparado o processo para implantação. construir e testar o Change Request  Obter a aprovação para implementar a mudança (homologação)  Comunicar a implementação da mudança Copyright © 2007 Accenture All Rights Reserved.Gerenciamento de Requisitos e Controle de Mudanças Implementar a Mudança: Identificar as Requisições de Mudança Documentar as Requisições de Mudança Obter Autorização para a Mudança Implementar a Mudança Atualizar os Documentos Impactados  Uma vez que a mudança foi aprovada.

 os Modelos de Caso de Uso.  o Desenho Funcional. Copyright © 2007 Accenture All Rights Reserved.  o Desenho Técnico. dentre outros. .  o Plano de Testes. isto inclui:  a Matriz de Rastreabilidade de Requisitos.Gerenciamento de Requisitos e Controle de Mudanças Atualizar os Documentos Impactados: Identificar as Requisições de Mudança Documentar as Requisições de Mudança Obter Autorização para a Mudança Implementar a Mudança Atualizar os Documentos Impactados  Qualquer alteração implementada deve ser documentada.

Agenda Objetivos do Treinamento e Fontes Conceitos Gerais Coleta de Requisitos Documentação de Requisitos Análise de Requisitos Aprovação e Transição dos Requisitos Gerenciamento e Controle de Mudanças Metodologia da Brasil Telecom . .MDS Dicas e Sugestões Copyright © 2007 Accenture All Rights Reserved.

 Modelo de Requisitos (ferramenta padrão: EA – Enterprise Architect)  Modelo de Processos – BPM (ferramenta padrão: EA)  Documento de Visão (Desenho de Aplicações. quando aplicável)  Modelo de Caso de Uso (ferramenta padrão – EA)  Desenho Funcional (ferramenta padrão – Word) Copyright © 2007 Accenture All Rights Reserved. .Metodologia da Brasil Telecom  A metodologia da Brasil Telecom prevê os seguintes artefatos relacionados a etapa de requisitos:  EPF (Especificação Funcional do Usuário).

. .Justificativas. . . .Impacto se Não Implementada.Detalhamento das Regras de Negócio. .Descrição Sumária.Áreas de Negócios Envolvidas.Informações Adicionais.Sistemas Relacionados. .Processo Impactadas.Título da Demanda (ou Projeto). .EPF (Especificação Funcional do Usuário) Documento gerado pela área usuária: . . Copyright © 2007 Accenture All Rights Reserved.

Integração de sentido único com o EA.Classificação e priorização dos requisitos. . .Criação de um Identificador único para cada requisito.Planilha de Requisitos Vantagens: .Facilidade para o cadastramento dos requisitos. . A planilha de requisitos é ideal para fazer a primeira carga de requisitos no EA Desvantagem: . atualizações feitas no EA não refletem na planilha. Copyright © 2007 Accenture All Rights Reserved.Integração com o EA para a criação de requisitos. . ou seja.

Copyright © 2007 Accenture All Rights Reserved. . .Cada requisito deve ter um identificador único para permitir a rastreabilidade.Modelo de Requisitos no EA Comentários: .A aba Projetc Browser exibe a árvore detalhada dos requisitos.O EA permite o agrupamento dos requisitos. .

Modelo de Processos . .BPM Notações: Copyright © 2007 Accenture All Rights Reserved.

de forma a permitir a rastreabilidade entre eles. Copyright © 2007 Accenture All Rights Reserved.BPM Comentários: .Os processos de negócio devem ser publicados no Modelo Único da Brasil Telecom.Modelo de Processos no EA .Os processos de negócio devem estar vinculados aos requisitos. . .

onde cada um representa um fluxo de eventos específico. que gera um resultado observável de valor para um determinado ator. Ator A funcionalidade de um sistema é definida por casos de uso diferentes. ou seja. . Copyright © 2007 Accenture All Rights Reserved. Pode ser um usuário ou mesmo outro sistema.Modelo de Caso de Uso .EA Uma instância de casos de uso é uma seqüência de ações realizadas por um sistema. os casos de uso devem representar a interação dos atores com o sistema. Caso de Uso Um ator é alguém ou algo externo ao sistema que interage com ele.

Modelo de Caso de Uso . .Os casos de uso devem estar vinculados aos processos.O detalhamento de um caso de uso é representado pelo Diagrama de Atividades e define o que ocorre no sistema quando o caso de uso é executado. Copyright © 2007 Accenture All Rights Reserved. de forma a permitir a rastreabilidade entre eles. .EA Comentários: .

.MDS Dicas e Sugestões Copyright © 2007 Accenture All Rights Reserved.Agenda Objetivos do Treinamento e Fontes Conceitos Gerais Coleta de Requisitos Documentação de Requisitos Análise de Requisitos Aprovação e Transição dos Requisitos Gerenciamento e Controle de Mudanças Metodologia da Brasil Telecom .

Se a data do vencimento for anterior à data atual. Exemplo: Forma incorreta: “Para cada pagamento existente no arquivo (tabela) “pagamentos_a_vencer”. o sistema deve comparar a data vencimento do pagamento com a data atual. Copyright © 2007 Accenture All Rights Reserved. As frases longas precisam ser lidas mais de uma vez antes de serem entendidas por completo. o cliente deve ser incluído na relação de clientes com pagamento em atraso”. Mantenha frases curtas. Forma correta: “O sistema deve informar os clientes com pagamento em atraso”.Requisitos – Dicas e Sugestões Orientações para a redação dos requisitos: A. .

utilizando-se de listas numeradas. Copyright © 2007 Accenture All Rights Reserved. . Regras de Negócio: 1) São considerados clientes com pagamento em atraso os clientes cuja data de vencimento do pagamento for anterior a data atual (data do processamento). pré e pós condições em tópicos à parte a descrição do requisito.Requisitos – Dicas e Sugestões Orientações para a redação dos requisitos: B. Forma correta: “O sistema deve informar os clientes com pagamento em atraso”. Expresse as regras de negócio. Exemplo: Para o mesmo exemplo apresentado no item 1. validação e manutenção do documento de requisitos. Desta forma ficará mais fácil à leitura.

Evite utilizar o termo “e” nas frases. os clientes inadimplentes”. Copyright © 2007 Accenture All Rights Reserved. São considerados clientes inadimplentes os clientes que tiverem 3 ou mais pagamentos em atraso. Forma incorreta: “O sistema deve informar os clientes com pagamento em atraso e. “O sistema deve informar os clientes inadimplentes”. . Exemplo: Forma correta: “O sistema deve informar os clientes com pagamento em atraso”. Nunca expresse mais de um requisito na mesma frase. Regras de Negócio: 1) 2) São considerados clientes com pagamento em atraso os clientes cuja data de vencimento do pagamento for anterior a data atual (data do processamento). Isso implica que mais de um requisito ou conceito está sendo discutido. também.Requisitos – Dicas e Sugestões Orientações para a redação dos requisitos: C.

Forma incorreta: “O sistema deve disponibilizar a consulta do extrato da conta corrente via ATM”.Requisitos – Dicas e Sugestões Orientações para a redação dos requisitos: D. . Evite o uso de jargões. ou esteja aderente ao glossário do projeto. nenhum parágrafo deve ser feito utilizando-se mais de 7 linhas. Mantenha parágrafos curtos. Exemplo: O acrônimo „ATM‟ é usado tanto em sistemas bancários como em domínios de aplicações de redes. Copyright © 2007 Accenture All Rights Reserved. abreviações e acrônimos. E. Forma correta: “O sistema deve disponibilizar a consulta do extrato da conta corrente em terminais ATM (Máquinas Automáticas de Saque Bancário)”. a não ser que possa ser entendido por todos os leitores do documento em diferentes âmbitos. Como regra geral.

– Telefone residencial do cliente. 3. CPF – Código de identificação de Pessoa Física do cliente Forma incorreta: “O sistema deve manter as seguintes informações sobre o cliente: Nome. a conferência e validação do requisito. preferencialmente numeradas. também. 2. As listas são mais fáceis de entender do que seqüências apresentadas em um simples parágrafo. Nome – Nome completo do cliente. telefone e CPF” Copyright © 2007 Accenture All Rights Reserved.Requisitos – Dicas e Sugestões Orientações para a redação dos requisitos: F. endereço. Endereço RES. Exemplo: Forma correta: “O sistema deve manter as seguintes informações sobre o cliente”: 1. 4. descreva seus significados. Quando as listas referirem-se a conjuntos de informações. – Endereço residencial do cliente. A numeração facilita a referência de um item e. Use listas e tabelas. onde for possível apresentar seqüências de informações. Telefone RES. .

Exemplo: “O sistema deve manter um cadastro de fornecedores” Copyright © 2007 Accenture All Rights Reserved. principalmente quando diferentes pessoas são responsáveis pela escrita de diferentes partes do documento.Requisitos – Dicas e Sugestões Orientações para a redação dos requisitos: G. mantenha um documento contendo o glossário de palavras para definir termos referentes ao negócio. Utilize. Este tipo de situação é muito comum nos sistemas. termos técnicos e qualquer outra palavra que possa facilitar o entendimento do documento H. Use uma terminologia de forma consistente. acrônimos. sempre na medida do possível palavras como “DEVE”. Não utilize um termo que signifique uma coisa em um lugar do documento e outra diferente em outro lugar. . onde a redação de um documento do mesmo sistema é atribuída a vários analistas. É difícil manter essa consistência no documento. Para tentar melhorar esse aspecto.

Forma correta: “O sistema deverá possibilitar ao usuário consultar os processos que tramitam na empresa. se a situação do processo for igual a “Concluído” o processo deverá ser relacionado na consulta aos processos concluídos. Forma incorreta: “Se a situação do processo for igual a “Encaminhado” o processo deverá ser relacionado na consulta aos processos encaminhados para análise. Regras de Negócio: 1) A situação dos processos que tramitam na empresa pode ser: a) Encaminhado. Copyright © 2007 Accenture All Rights Reserved. ou d) Situação não definida. relacionados por situação”. caso a situação do processo seja diferente de uma das citadas acima o processo deverá ser relacionado na consulta aos processos sem situação definida. b) Em análise. . se a situação do processo for igual a “Em análise” o processo deverá ser relacionado na consulta aos processos em análise.Requisitos – Dicas e Sugestões Orientações para a redação dos requisitos: I. c) Concluído. Não expresse requisitos usando sentenças condicionais aninhadas.

Copyright © 2007 Accenture All Rights Reserved.Requisitos – Dicas e Sugestões Orientações para a redação dos requisitos: J.” K. A. Utilize preferencialmente a voz ativa em relação à passiva. particularmente quando descrever ações tomadas por pessoas ou pelo sistema. . Não tente expressar relacionamentos complexos em descrição de linguagem natural. Forma correta: “O sistema deve possibilitar ao usuário incluir informações relativas ao cliente”. Não expresse requisitos usando sentenças condicionais aninhadas. Diagramas são bem mais eficientes para esse objetivo. Forma incorreta: “A inclusão de informações relativas ao cliente deverá ser possibilitada pelo sistema.

.Perguntas? Copyright © 2007 Accenture All Rights Reserved.

:2039... 4244.2502039.. 4579 ./48  &2.02  0803.20394/0#06:89480439740/0 :/.2:/.0884 5. /0391.:/.3.4 89425.3..7.748 4. :/.3.039:70 #98#0807.3.3.0703.3.7.7.574.7.3.7.7...2502039. 9:.8 2502039.3..7 .25.:203948 25.39.574. 2502039.45.74. 807E/85. -907:947..30#06:089  -907./.7.8 #06:808/0 :/.2:/.7.9.4  42:3.4/.43897:709089. 4...4 5.2:/.06:0.:/.0/ .7..3.8 #06:808/0 :/..7.14./44574.

8970.748 4.:  .../0/0#06:8948  484/048/0.8 #06:808/0 :/. :/./48 /0391.907.7.7./48  ":.43.3. -907:947.3..3.-/. 9:./..0807/4..  4 08034%F... 2502039.0/ .7484.97/0#.84/0&84  4 08034:3.:2039.4 5.3.039:70 #98#0807./.9.34/0%08908 /039704:9748 4579 .20394/0#06:89480439740/0 :/.9.3.3.:/.:20394825.7.:203948 25.8 9:. 4.0703.8 #06:808/0 :/.:2039.42502039./0.7..4  4 !.. 8943.6:07.

03/.20394043908 43.094807.40%7.4/0#06:8948 3E80/0#06:8948 574./0#06:8948 4..039:70 #98#0807.42 $ .8 409.0/ .48/4%703./.7.8 094/44.384/48#06:8948 0703.:2039..80$:08908 4579 .203940439740/0:/..3.. -09.8%00.

E.42  2094/44.039:70 #98#0807.4:3..90../4&8:E74   4/04/0#06:8948 1077.5.8%00.43.42570.3/4.H4880:3908.43.7901.43./74 390757807.08848 ! 1077./74   08034:3.948 70.1.2039.9  4/04/0!74.09.5./.08 6:../48.:20394/0'84 08034/05.5.5./0706:8948  ! 850.2039./74 47/ 4579 .094/44.7.5.84/0&84 1077.0   4/04/0. 1077.8%00.2039.5./74  4..0/ ./.7.2039.

948042502039./.9.1..43.3/.4:3.././450.0/ ..483.08/.74$:2E7.8 25. :8:E7.8 !74./. :891.8 $8902.43.8/0 0O.02.8#0..8 4579 .9.4./48 09.20394/.088425./4&8:E74 4. 4:!74094  08..E70.! 850.4 31472.43..039:70 #98#0807. 70.8#07. %J9:4/.8/00O..:2039407..

/473.7.897.3.4/08039/4 3..7.57207.  ..45.424 5.881.4.7.0/ .3.7.1..4/0:2 /0391.39.424 4:80.5.706:894 .!../.3... ./..4 .039:70 #98#0807.038 3907../05.4/0 706:8948 .20394/48 706:8948 7.08109.4. ./0706:8948F/0. 4579 .7..7.40 5747.834 3470109023..02 3907./0706:894834 08.39.5.4/48 706:8948 5./0#06:8948 './.9:.07..

./0 4579 .7.7:5. 7.-/.20394/48 706:8948 .039:70 #98#0807./48 706:8948 ..0/ ./473.-.74807 0-0.!7409.4 5..0907 :2/0391.8970.470 /09.706:894/0.507297.E7././.4/04/0#06:894834 42039E748 5072904 .

4/04/0!74..08848 ! 49.039:70 #98#0807.08 4579 .0/ .

-/.7.4/04/0!74.7...4 /0.08848/030O.8970.:.4 /0.3.028075:-. 507297.02089.08848/030O.8 %00.48706:8948 /01472.039:70 #98#0807.0/ .4/./0 03970008 8574.7./48 .42 4579 ./4834 4/04 3.0884834 ! 42039E748 8574..

/.7.848/0:84/0.947 4:80.039480850..42488902.3907.4/04/0.0/0 .0. .J1.02 705708039.4090734.806QH3./0.6:03907.:2705708039.43.4200  !4/0807:2:8:E744:208244:97488902..84/0&84 &2.. 6:007.488902.547..F/013/...7.84/0&84  &2.848/0:84F:2.08 70./.:2/090723.:F24:.94708.0/ .947F..:21:4 /00.039:70 #98#0807./44-807.E../0./.8547:288902..848 /0:84/10703908 43/0. 48.:2708:9.3893.475.4  4579 .  947 1:3./4./0/0:288902.4/48.

84/0&84  42039E748 /09. 6:.48 574.08848 /01472.-/..84/0:84F 00.4/04/0./48. 7.7./0 9./003970 008 4579 ..039:70 #98#0807.02 089.0/ .:9.8970.3.7.84/0:84F 705708039./4504 . 507297.20394/0:2 ....2././08 0/01304 6:04.:.848/0:84/0../4 8.47703488902.3/44.

0/ .:2039./0#06:8948 4.3.20394043908 43.48/4%703.094807..8 094/44..8 409.384/48#06:8948 0703.4/0#06:8948 3E80/0#06:8948 574.8%00..42 $ .203940439740/0:/../.80$:08908 4579 .03/.7. -09.039:70 #98#0807.40%7.

8.70/.203948*.03.42 ..03.47709.0/ .7. /.84 472.47709.808 .03908 . 3.9:.80$:08908 7039.*.20394 .8 8 17.20394 0890390 34 .97.7. /0.039:70 #98#0807.4 9.20394 147 ..84 4579 . 70.0 .9:.3908 /0 80702 03903//..8 /0 :2..9. 4 .03. /0..-0.97.9.76:. /. /4 .8 547 . .. !./.:79.085.4 /0 .9.0390 /0. .808 43.7 48 .:J/4 3..425. .7 .20394 02 . .4/48706:8948  . .0 31472. ..8 2.3903. 5.2 807 /.8 570.390747  /.42 5..20394 02 . 5.7. 17.0 807 3.9. $0 .425094 0254 472. /.03908 .#06:8948 .42 5. 88902.20394 /4 5.0 .07 4 88902.

4 57F 0 5O8 ./48 .438/07.8 089.80$:08908 7039.03.. /0 .3:9034 /4 /4.03908 .20394 4579 . 4 20824 00254 ./.790 .7 48 .03908 .84 48 .#06:8948 .20394 02 .088.8 /0 0O.43/08 02 9O5.42 5.8 3:207.20394 147 .3/4 80 /0 89.9.0 31472.5708039.4 0 2.9.8 /0 30O.4/48706:8948  570880 .84 #07.:.20394 /4 5.42 5. /./. 1472..9.70/. /08..8 707..085. 88902. /0. . /4 574.74 /4 706:894 :9.4  $4 .7.48  5.97.7E 2.7. /.9:.. . .:20394 /0 706:8948 0254 !.  09:7.03908 .20394 02 .8 1E.039:70 #98#0807. /.97.0/ .47709./4 34 902  472. 1...390747 ..

20394 02 .438/07.438/07. /0 . /.97.43.90 :9.97.03908 . /.:./48 .8 /0 :2 706:894 3.42 5.80 .0702  4: 2.42 5./2503908 4579 .47709.8 5.0 31472.9. 17./2503908 #07.84 88902.03908 . 88902. /0.0/ 9.03908 ..7 48 .7 48 .80$:08908 7039.8 /0 0O.70/.97..03908 .4   $4 .03908 6:0 9. .8 17. /0.20394 147 .808 884 25.7.:9/4 0254 472.203948 02 . /0.#06:8948 .088..03908 3..094 089E 803/4 /8.20394 02 . 2082.20394 02 .47709../2503908 48 .8 /0 :2 706:894 4: . 0570880 2.4/48706:8948  :3.03908 3..039:70 #98#0807..84 0 3..2-F2 48 .03908 ..9:. /4 574.97.0 31472. 3.20394 /4 5.03.84 48 . 6:0 2.20394 $4 . 88902.84 472.390747 ..42 5.9.7 48 .085. .7 4 90724 0 3./48 .0 31472. /.9.

3/4 80 2. %  .439.439.-70.708 .0 807 1094 :9.4/48706:8948  .3903.. ./070390 .7324 % F :8.7 ..394 02 88902. /4 097.94 /.8 % E6:3.0 /8543-.E74 472. 5.8 :942E9. .08 /0 70/08 472.#06:8948 . .4770390 . 07. 88902. .7.8 -.14 /0.70/.:20394 02 /10703908 2-948 4: 0890.0 /8543-...47709.94 /. 303:2 5./4 9.8 /0 $. .47709.085.8 4579 .6:0 .:7948 424 707..4 488E74 /4 574094 0254 .7E7.438:9.08 0 . .148 . 807 03903//4 547 94/48 48 094708 /4 /4..424 02 /42J348 /0 . 34 807 6:0 5488.5.4770390 02 90723. /0.3. 88902. .8 /0  3..7E7.7 .0/ . 3.80$:08908 7039.3. /0. /4 097.438:9. .E748 .73248 ..90 4 :84 /0 ..039:70 #98#0807.

8 80:3908 31472.0390 3/0704 708/03. .0390 472.08 84-70 4 . 70107H3. 3.2-F2 . /4 .0390   420 420 .70/./...8 0 9.70.43:3948 /0 31472. . 80:8 831.8 84 2.7.4 /4 706:894 ":..8 .4 1.7E7.7 806QH3../..8 57010703. .3/4 .4/48706:8948  &80 89.3907 .0390  3/0704 #$  %001430 #$  ! O/4 /0 /0391.08 /0 03903/07 /4 6:0 806QH3. 88902. 0 .0 . .425094 /4 ./.8 02 :2 82508 5.. /0.#06:8948 .0390 %001430 708/03.9.20390 3:207.8 80:3908 31472.0 2..8 1E.0 2.47709.5708039.039:70 #98#0807..0/ ./48 0254 472.-0.08 84-70 4 .5708039.3907 . /0 :2 902 0 9... 88902. J8.43107H3....0390 420 03/0704 9001430 0 ! 4579 .085.8 89.08 8 89.14  3:207.4 /0 !0884.80$:08908 7039.8 70107702 80 ..8 /0 31472.. /0.08 /08.8 43/0 147 5488J..47709. /4 . /4 .

0/4708 4579 . 1.0/ .:20394 890 954 /0 89:. /4 5488J.7.73248 907248 9F..3903.89.850.4 /0 :2 /4..:20394 0 4:97. 9072344. /0 /10703908 5. 70/.7. . F . . :2 /4.#06:8948 .70/.7.7 A /1J.085.5.80$:08908 7039.4 30O.7 4 03903/20394 /4 /4. .20390 6:. 9039..3. /0137 907248 7010703908 .97-:J/..43903/4 4 488E74 /0 5.94 2.:20394 573. /1070390 02 4:974 :.8 5..7.3/4 /10703908 50884.3907 :2 .8 84 7085438E. /0 1472.E748 .7 /4 /4...7.:20394 /4 20824 88902.438890390 4 :90 :2 90724 6:0 8316:0 :2.7908 /4 /4.8 ..8 !.4 F 2:94 .8974 /0 14730.4 .3.79.. 20//.0 5.3907 088.9. 02 :2 :.6:07 4:97. 34 /4. 2.43889H3.:20394  &90 802570 3..4/48706:8948  &80 :2. 6:0 5488.7.424 ' 0254 88902. 5.42:2 348 88902.08 50..48 0 6:.8 43/0 . 08.7 0880 .039:70 #98#0807.:20394 ..0 2. .48./. . /0.7 2047..

3. 3.07E 807 70.08848 .0884 147 :.2..33. .039:70 #98#0807.. 54/0 807 ./48 547 89:. ...7./.4/48706:8948  4 0570880 706:8948 :8.. .4 /4 574. 89:. /0./4 3.43.#06:8948 .4 /4 574. 43.085.8 /0 0O. 89:.48 574. .47709.23. 025708. $0 . 2 .70/./48 5. 89:./4 3.0884 80.4 /013/.07E 5488-9.8 . 70.08848 02 .438:9.48 574.29..43. /. 4 574. .3/4 803903.29.4   89:./4 .438:9../4 3.0/ .0884 /0.23.43/.4 #07.08848 6:0 97. 3.08848 6:0 97.80$:08908 7039.3E80 ..48 574./4 3.438:9. .0884 147 :..8 .4 /4 574. 89:.4 /4 574. 025708.0884 /0. 88902./.2 3.438:9.3E80 4 574. .48 574. 43.0884 147 :.:J/4 4: / $9:.43.43.8 . 4579 .07E 807 70.7.0884 /0.4 34 /013/...23.84 . /1070390 /0 :2.9. .4 :8:E74 .438:9..0884 /0..7 48 574. .4 /48 574.8 . .43.:J/4 4 574. .43.3E80 80 .2 3.08848 802 89:.07E 807 70.:J/48 .2 . . ./4 4 574.07E 807 70.47709. 472.8 472.08848 03.3E80 80 .7 .43.

4  5. 504 88902.08 70.43..43/. 3.7.0/ . 88902.9:7.720390 6:.4 4579 .3/4 /08..9.203948 ./.33.43.03908 5./.07 .:84 /0 31472.4 :8:E74 3.7 .8 4: 504 88902.  3.07E 807 5488-9.47709.4/48706:8948  4 0570880 706:8948 :8.8 ...79.:. 0880 4-09. .4 .4 .425048 02 /08.02 3.#06:8948 . 472..74 /0 3:.3/4 803903.9.8 84 -02 2.08 70.7.70/.20390 ./.0390 472..8  &90 57010703.7..  4 90390 057088.7 70. 02 70..8 ..0 5488-9.47709.8 .2.70.8 01.8 547 50884. . .80$:08908 7039.:7 31472. /0.8 .039:70 #98#0807.08 942.085.88. 5.4 .0390 /0.9.

.039:70 #98#0807.0/ .!07:39.8 4579 .