FACULDADES INTEGRADAS DO PLANALTO CENTRAL - FIPLAC BRASÍLIA, 29 de Novembro de 1999
ANÁLISE DE REQUISITOS
[email protected]
Engenharia de Software
Análise de Requisitos
Índice Introdução....................................................................3 PRINCÍPIOS FUNDAMENTAIS FUNDAMENTAIS DA ANÁLISE DE REQUISITOS...................... REQUISITOS............................................................. .........................................4 ..4 ANÁLISE DE REQUISITOS................................................................................................................................................4 ATIVIDADES DE ANÁLISE................................................................................................................................................5
Bibliografia..................................................................7 Conclusão.....................................................................8
2
Engenharia de Software
Análise de Requisitos
Introdução Nossos objetivos ao realizarmos este trabalho são dois, a saber: aprendermos e dominarmos o aspecto teórico da Análise de Requisitos e o repasse das conclusões para a turma de computação C06A. Na tentativa de explicar a Análise de Requisitos deparamo-nos com alguns conceitos, as vezes conflitantes, que nos deram o devido entendimento sobre esta fase tão importante do Processo de Desenvolvimento de Sistemas de Software. Com estes novos conceitos adquiridos estamos capacitados a respon responder der algumas algumas pergunta perguntas, s, antes sem respos resposta, ta, que agora passam passam a repres represent entar ar uma nova fronteira do nosso conhecimento. Este documento nos dá uma visão sucinta dos conceitos e características pertinentes ao objeto da pesquisa. É um eficiente material de apoio que deverá ser complementado com a apresentação que será exibida pelo grupo. A equipe.
3
Engenharia de Software
Análise de Requisitos
PRINCÍPIOS PRINCÍPIO S FUNDAMENTAIS FUNDAMENTAIS DA ANÁLISE DE REQUISITOS Roger S. Pressman em “Engenharia de Software” explica: “Uma compreensão completa dos requisitos de software é fundamental para um bem-sucedido desenvolvime desenvolvimento nto de software. software. Não importa importa quão bem projetado ou quão bem codificado codificado seja, um programa mal analisado e especificado desapontará o usuário e trará aborrecimentos ao desenvolvedor. A tarefa de análise de requisitos é um processo de descoberta, refinamento, modelagem e especificação. O escopo do software, inicialmente estabelecido pelo engenheiro de sistemas é refinado durante o planejamento do projeto de software, é aperfeiçoado em detalhes. Modelos do fluxo de informação e controle exigido, comportamento operacional e conteúdo de dados são criados. Soluções alternativas são analisadas e atribuídas a vários elementos de software. Tanto o desenvolvedor como o cliente desempenham um papel ativo na análise a especificação de requisitos. O cliente tenta reformular um conceito de função e desempenho de software, às vezes nebuloso, em detalhes concretos. O desenvolvedor age como indagador, consultor e solucionador de problemas. A análise e especificação de requisitos pode parecer uma tarefa relativamente simples, mas as aparê aparênc ncia iass engan enganam am.. O conte conteúdo údo de comuni comunicaç cação ão é mu muit itoo eleva elevado. do. Abunda Abundam m as chanc chances es de interpretações errôneas e lnformações falsas. A ambigüidade é provável. O dilema com o qual se defronta um engenheiro de software pode ser mais bem entendido repetindo-se a declaração de um cliente anônimo: "Sei que você acredita que entedeu o que acha que eu disse, mas não estou certo de que percebe que aquilo que ouviu não é o que eu pretendia dizer...” ANÁLISE DE REQUISITOS
A análise de requisitos é uma tarefa da engenharia de software que efetua a ligação entre a alocação de software em nível de sistema e o projeto de software (Figura abaixo). A análise de requisitos possibilita que o engenheiro de sistemas especifique a função e o desempenho do software, indique a interface do software com outros elementos do sistema e estabeleça quais são as restrições de projeto que o software deve enfrentar. A análise de requisitos permite que o engenheiro de software (muitas (muitas vezes chamado chamado de analista nesse papel) aprimore a alocação de software e construa modelos do processo, dos dados e dos domínios comportamentais que serão tratados pelo software. A análise de requisitos proporciona ao projetista de software uma representação da informação a da função que pode ser traduzida em projeto procedimental, arquitetônico e de dados. Finalmente, a especificação de requisitos proporciona ao desenvolvedor e ao cliente os critérios para avaliar a qualidade logo que o software for construído.
4
Engenharia de Software
Análise de Requisitos
ATIVIDADES DE ANÁLISE
A análi análise se de requi requisi sito toss de soft softwa ware re pode pode ser ser divi dividi dida da em cinco cinco área áreass de esfo esforç rço: o: (1) (1) reconhecimento do problema, (2) avaliação e síntese, (3) modelagem, (4) especificação e (5) revisão. Inicialmente, o analista estuda a Especificação do Sistema (caso exista um) e o Plano de Projeto de Software. É importante entender o software num contexto de sistema e revisar o escopo do software que foi usado para gerar as estimativas de planejamento. A seguir, deve ser estabelecida comunicação com a atividade de análise, de forma que o reconhecimento do problema seja garantido. O analista precisa estabelecer contato com a administração e com o pessoal técnico da organização do usuário/cliente e com a organização de desenvolvimento do software. O gerente de projetos pode atuar como um coordenador para facilitar a abertura de caminhos de comunicação. A meta do analista é o reconhecimento dos elementos problemáticos básicos, conforme percebidos pelo usuário/cliente. A síntese de avaliação e solução dos problemas é a maior área de esforço de análise seguinte. O analista deve avaliar o fluxo e o conteúdo de informação, definir e elaborar todas as funções do software, entender o comportamento 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. Cada uma dessas tarefas serve para descrever o problema de forma que uma abordagem ou solução global possa ser sintetizada.
Engenharia de Sistema de Computador
Análise de Requisitos de Software
Projeto de Software
Sobreposição da tarefa de análise.
Por exemplo, um sistema de controle de estoques é exigido por um grande fornecedor de autope autopeças ças.. O anali analist staa descob descobre re que que os probl problem emas as com o atual atual sist sistem emaa manu manual al envol envolve vem m (1) (1) incapacidade de obter o status de um componente rapidamente; (2) turno de dois a três dias para atualizar um arquivo de cartões; (3) múltiplas reencomendas ao mesmo vendedor porque não há nenhuma forma de associar vendedores com componentes etc. Logo que o problema é identificado, o analista determina quais informações devem ser produzidas pelo novo sistema e quais dados serão oferecidos ao sistema. Por exemplo, o cliente deseja um relatório diário que indique quais peças foram requi requisi sita tada dass do esto estoqu quee e quant quantas as peças peças idên idênti tica cass perm perman anec ecem em nele nele.. O clie client ntee indi indica ca que que os funcionários do setor de estoques registrarão o número de identificação de cada peça quando elas saírem da área de estoque.
5
Engenharia de Software
Análise de Requisitos
Depois de avaliar os problemas atuais e as informações desejadas (entrada e saída), o analista começa a sintetizar uma ou mais soluções. Um sistema on-line baseado em terminal resolverá um conjunto de problemas, mas ele ficará dentro do escopo esboçado no Plano de Software? Um sist sistem emaa de gere gerenc ncia iame ment ntoo de banc bancoo de dado dadoss pare parece ceri riaa nece necess ssár ário io,, mas mas a nece necess ssid idad adee de associatividade do usuário/cliente é justificada? O processo de avaliação e síntese prosseguirá até o analista bem como o cliente tiverem confiança de que o software tenha de ser adequadamente especificado para as etapas do desenvolvimento subseqüentes. No decorrer da síntese de avaliação e solução, o principal foco do analista recai sobre "o que", não sobre "como". Quais dados o sistema produz e consome, quais funções o sistema deve executar, quais interfaces são definidas e quais restrições se aplicam. Durante Durante a atividade atividade de síntese síntese de avaliação avaliação e solução, solução, o analista analista cria modelos do sistema sistema num esforço para compreender melhor o fluxo de dados e de controle, o processamento funcional e a operação comportamental. além do conteúdo de informação. O modelo serve como um fundamento para o projeto de software a como base para a criação de sua especificação. As atividades associadas à análise e especificação esforçam-se para oferecer uma representação de software que possa ser revisada e aprovada pelo cliente. Num mundo ideal, o cliente desenvolveria uma Especificação dos Requisitos de Software em sua totalidade. Isso raramente acontece no mundo real. No máximo, a especificação é desenvolvida como um esforço conjunto entre o desenvolvedor e o cliente. Logo que inform informaçõe açõess básica básicas, s, funçõe funções, s, desempe desempenho nho,, compor comportam tament entoo e interf interface acess forem forem descritos, critérios de validação serão especificados para demonstrar o entendimento e viabilizar uma implementação de software bem-sucedida. Esses critérios servem de base para as atividades de teste que ocorrerão posteriormente no processo de engenharia de software. Uma especificação de exigências formal é escrita para definir as características e os atributos do software. Além disso, um Manual do pode ser rascunhado para casos em que um protótipo não tenha sido desenvolvido. Usuário Preliminar pode Pode parecer estranho que um manual do usuário seja desenvolvido tão cedo no processo de engenharia de software. Afinal de contas, ainda estamos muito longe de usar o programa. De fato, um manual do usuário preliminar força o analista (desenvolvedor) a assumir um ponto de vista de usuário do software (particularmente importante em sistemas interativos). O manual estimula o usuário/cliente a revisar o software a partir de uma perspectiva de engenharia humana a freqüentemente provoca o comentário: "A idéia é boa mas não é desse jeito que eu pretendia fazer isso". O melhor é provocar tais comentários o quanto antes no processo. Os documentos da análise de requisitos (especificação a manual do usuário) servem de base para uma revisão levada a efeito pelo cliente e pelo desenvolvedor. A revisão dos requisitos quase sempre resulta em modificações na função, desempenho, representações da informação, restrições ou critérios critérios de validação. validação. Além disso, o Plano de Projeto Projeto de Software é reavaliado para determinar se as estimativas continuam válidas, dado o conhecimento adicional obtido.”
6
Engenharia de Software
Análise de Requisitos
Bibliografia YOURDON, Edward. Análise Estruturada Moderna. Yourdon Press.1992 REZENDE, Denis Alcides, Engenharia de Software e Sistemas de Informação. Brasport. 1999 PRESSMAN, Roger. Engenharia de Software. Makron Books. 1995 BORG BORGES ES,, Gile Gilene. ne. SG SGMO MOO: O: Si Sist stem emaa Gest Gestor or de Méto Métodos dos Orie Orient ntad ados os a Obje Objeto toss Basea Baseado do em Conhecimento.
7
Engenharia de Software
Análise de Requisitos
Conclusão Na comparação entre os vários autores, pudemos constatar uma enorme gama de pontos de vista conceituais na maioria das vezes divergentes. O que demonstra uma certa imaturidade da Engenharia de Software em relação à Engenharia de Hardware. Porém o estudo nos dá a possibilidade de evitar armadilhas que podem ser contornadas com a adoção de medidas metódicas e adequadas ao perfil profissional da equipe desenvolvedora. O objeto do estudo nos permitiu entender a necessidade de aplicação de medidas metódicas que incrementou os benefícios advindos do produto resultante da pesquisa. É unânime a opinião que foi valioso o ganho advindo da idéia de executarmos este exercício.
8
Engenharia de Software
Análise de Requisitos
Anexo
Anexo
9
