O documento discute princípios fundamentais da análise de requisitos para o desenvolvimento de software. Ele descreve as etapas da análise de requisitos, incluindo descoberta, refinamento e modelagem. Também discute os participantes do processo e suas responsabilidades, como o cliente e o analista de sistemas. Finalmente, fornece diretrizes para a especificação e comunicação de requisitos.

1. Princípios Fundamentais da Análise de Requisitos Prof.. Buba Bibliografia: Pressman, Roger S. - Engenharia de Software. APA II

2. Princípios Fundamentais da Análise de Requisitos Como ser bem sucedido no desenvolvimento de software? Ter uma compreensão completa dos requisitos de software Análise de Requisitos é: Descoberta Refinamento Modelagem Especificação Participantes: Cliente Analista de Sistemas Papel dos participantes da análise de requisitos Cliente - tenta formular um conceito de função e desempenho de software em detalhes concretos. Analista - age como indagador, consultor e solucionador de problemas. Cuidados necessários na especificação dos requisitos: Comunicação; Interpretação errônea do problema; Informações falsas; Ambigüidade.

3. Princípios Fundamentais da Análise de Requisitos Análise de Requisitos A análise de requisitos permite: especificar a função e desempenho do software; identificar interface do software com outros elementos do sistema; estabelecer as restrições de projeto que o software deve enfrentar; desenvolver os modelos comportamentais do software; possibilita ao cliente e ao desenvolvedor a identificação dos critérios para avaliar a qualidade logo que o software for construído. Atividades na Análise de Requisitos Reconhecimento do problema - estabelecer os contatos no ambiente do usuário com as áreas envolvidas no problema. Análise e síntese do problema - o analista deve: Avaliar o fluxo e o conteúdo das informações; Definir e elaborar todas as funções do software; Entender o funcionamento do software no contexto dos eventos que afetam o sistema; Estabelecer as características de interface com o sistema e descobrir restrições de projeto. Nesta fase o foco recai sobre “o que” , não sobre “como” fazer Modelagem do problema Especificação da solução a ser proposta Revisão

4. Princípios Fundamentais da Análise de Requisitos O Analista de Sistemas O Analista de Sistemas deve ter: A capacidade de compreender conceitos abstratos, reorganiza-los em divisões lógicas e sintetizar “soluções” baseadas em cada divisão; A capacidade de absorver fatos pertinentes de fontes conflitantes ou confusas; A capacidade de entender os ambientes do usuário/cliente; A capacidade de aplicar elementos do sistema de hardware e/ou software aos elementos do usuário/cliente; A capacidade de se comunicar bem nas formas escrita e verbal; A capacidade de “ ver a floresta por entre as árvores ” Cliente Desenvol- vedor Consultor Especificador Projetista Analista de Sistemas

5. Princípios Fundamentais da Análise de Requisitos Áreas problemáticas Problemas encontrados: Dificuldades para obter informações; Cuidar da complexidade dos problemas; Acomodar mudanças que ocorrem durante e após a análise. Obtenção de informações: Conflito entre áreas do cliente; Funções e desempenho do software entram em conflito com a restrição imposta por outros elementos do sistema; Percepção das metas do sistema modifica-se com o tempo; Questões do tipo: A) Quais informações devem ser compiladas e como representa-las?; B) Quem fornece as várias peças de informação?; C) Quais ferramentas e técnicas estão a disposição para facilitar a coleta de informação? Complexidade dos problemas Problemas Complexidade da tarefa de análise

6. Princípios Fundamentais da Análise de Requisitos Áreas problemáticas Mudanças durante a análise: Como o mercado não para assim como as organizações, logo é preciso estar atento e identificar: Como as mudanças afetarão o sistema e as exigências de software?; Como avaliar o impacto das mudanças sobre outra partes do software aparentemente não relacionadas?; Como corrigir erros de especificação de forma que efeitos colaterais não sejam gerados? Técnicas de comunicação Tenho um problema e quero uma solução baseada em computador. Posso ajudar-lhe! Inicio da comunicação

7. Princípios Fundamentais da Análise de Requisitos Técnicas de comunicação Inicio do processo de comunicação O que perguntar no primeiro encontro? Quem esta por traz do pedido deste trabalho? Quem usará a solução? Qual beneficio econômico de uma solução bem-sucedida? Há outra fonte para a solução exigida? O que fazer para melhorar a compreensão do problema e o cliente verbalizar suas percepções sobre uma solução? Como você caracterizaria um “bom” resultado (saída) que seria gerado por uma solução bem-sucedida? Qual(is) problema(s) essa solução resolverá? Você poderia mostrar-me (ou descrever-me) o ambiente em que a solução será usada? Existem questões de desempenho ou restrições especiais que afetarão a maneira pela qual a solução é abordada? Você é a pessoa certa para responder a essas perguntas? Suas respostas são oficiais? Minhas perguntas são pertinentes ao problema que você tem? Estou fazendo perguntas de demais? Há mais alguém que possa fornecer informações adicionais? Existe algo mais que eu deva perguntar-lhe? Como buscar a efetividade do encontro? Esta é uma forma de quebrar o gelo do primeiro encontro, depois as perguntas e respostas podem ser substituídas por uma forma que combine elementos de solução de problemas, negociações e especificações.

8. Princípios Fundamentais da Análise de Requisitos Técnicas de comunicação O primeiro encontro dará ao analista e ao cliente o escopo do problema e a percepção global de uma solução e será possível uma requisição de produto de uma ou mais páginas. Especificando a aplicação Os participantes A requisição de produto gerada nos primeiros encontros com o cliente deve ser distribuída entre os responsáveis das áreas envolvidas no problema. 1° Tarefa dos participantes Fazer uma lista dos objetos que fazem parte do ambiente que circunda o sistema (funcionário, entregador, despachante, etc........); Outros objetos que são usados para que o sistema execute suas funções (catálogo de endereço, cadastro de devedores, etc...........); Objetos que são usados para que o sistema execute suas funções (cliente, produto, fornecedores, etc.......); Fazer uma lista das operações (processos ou funções) que manipulam ou interagem com os objetos. Fazer uma lista de restrições (custo, tamanho, etc.......) fazer uma lista dos critérios de desempenho (velocidade, precisão, etc.......). As listas não devem ser exaustivas, mas espera-se que elas reflitam as perspectivas de cada pessoa sobre o sistema.

9. Princípios Fundamentais da Análise de Requisitos Especificando a aplicação 2° Tarefa dos participantes Apresentar suas listas; Analisar as listas e buscar consenso; O grupo busca desenvolver uma única lista contendo todos os: Objetos; Operações; Restrições; Desempenho; Critérios de validação. 3° Tarefa dos participantes Dividir o grupo em subgrupos para definir mini-especificação dos objetos ( Ex: cliente, fornecedores, dependentes, catálogos, etc.......) 4° Tarefa dos participantes Desenvolvidas as especificações elas são apresentadas e discutidas pelo grupo podendo ter adições, supressões e alguma elaboração adicional. Questões levantadas e não resolvidas pelo grupo devem ser guardadas para posterior discussão. 5° Tarefa dos participantes Reunir novamente os subgrupos para definirem os critérios de validação para o produto/sistema a ser discutido pelo grupo em mais uma tarefa. Esta técnica tem uma vantagem que é o comprometimento do cliente com a especificação do sistema por ser ele quem a faz com acessoramento do Analista de Sistemas.

10. Princípios Fundamentais da Análise de Requisitos Princípios de especificação 1. Separe funcionalidade de implementação: Especificação é uma descrição daquilo que é desejado, e não de como tem de ser realizado (implementação). Ex.: funções matemáticas. 2. Uma linguagem de especificação de sistemas orientada ao processo é exigida: Especificação de um modelo de comportamento desejado em termos das respostas funcionais a vários estímulos do ambiente. 3. A especificação deve abranger o sistema do qual o software é um componente: Especificação dos componentes que comporão o sistema e interagirão entre si. 4. Uma especificação deve abranger o ambiente no qual o sistema opera: Especificação dos agentes externos os quais o sistema irá interagir e delimita o seu escopo. 5. Uma especificação de sistema deve ser um modelo cognitivo: Especificação de como o sistema é percebido pela comunidade dos usuários. 6. Uma especificação deve ser operacional: Especificação deve ser completa formal o bastante para que possa ser usada para determinar se a implementação proposta a satisfaz em situação de teste arbitrariamente escolhidas. 7. A especificação do sistema deve ser tolerante com a não-inteireza e ser expansível: A especificação jamais será completa pois o ambiente em que o sistema atuará é demasiadamente complexo, portanto é impossível atingir-se a completes das especificações. 8. Uma especificação deve ser localizada e fracamente acoplada: Especificação deve suportar as mudanças que o tempo exige sem comprometer aquilo que não será mudado. Busque a maior independência possível entre as especificações. Fim