Вы находитесь на странице: 1из 9

FACULDADES INTEGRADAS DO PLANALTO CENTRAL - FIPLAC

BRASÍLIA, 29 de Novembro de 1999

ANÁLISE DE
REQUISITOS

pazos@unb.br
Engenharia de Software Análise de Requisitos

Índice

Introdução....................................................................3
PRINCÍPIOS FUNDAMENTAIS DA ANÁLISE DE
REQUISITOS...............................................................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 responder algumas perguntas, antes sem resposta, que agora passam a representar 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 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


desenvolvimento de software. Não importa quão bem projetado ou quão bem 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ências enganam. O conteúdo de comunicação é muito elevado. Abundam as chances 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 vezes 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álise de requisitos de software pode ser dividida em cinco áreas de esforço: (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ças. O analista descobre que os problemas com o atual sistema manual envolvem (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
requisitadas do estoque e quantas peças idênticas permanecem nele. O cliente indica 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
sistema de gerenciamento de banco de dados pareceria necessário, mas a necessidade 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 a atividade de síntese de avaliação e solução, o analista cria modelos do 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 informações básicas, funções, desempenho, comportamento e interfaces 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
Usuário Preliminar pode ser rascunhado para casos em que um protótipo não tenha sido desenvolvido.

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 de validação. Além disso, o Plano de 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
BORGES, Gilene. SGMOO: Sistema Gestor de Métodos Orientados a Objetos Baseado 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

Вам также может понравиться