PRINCÍPIOS FUNDAMENTAIS DA ANÁLISE DE REQUISITOS

ANÁLISE DE

ANÁLISE DE

REQUISITOS

REQUISITOS

pazos@unb.br

pazos@unb.br

Índice

Índice

Introdução...3

Introdução...3

PRINCÍPIOS

PRINCÍPIOS FUNDAMENT

FUNDAMENTAIS

AIS DA

DA ANÁLISE

ANÁLISE DE

DE

REQUISIT

REQUISITOS...

OS...

...4

..4

Bibliografia...7

Bibliografia...7

Conclusão...8

Conclusão...8

Introdução

Introdução

 Nossos objetivos ao realizarmos este trabalho são dois, a saber: aprendermos e dominarmos o aspecto  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

teórico da Análise de Requisitos e o repasse das conclusões para a turma de computação C06A.turma de computação C06A.

  Na tentativa de explicar a Análise de Requisitos deparamo-nos com alguns conceitos, as vezes   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 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 Desenvolvimento de Sistemas de Software. Com estes novos conceitos adquiridos estamos capacitados a

a resresponponder algumder algumas perguas perguntantas, antes sem s, antes sem resresposposta, ta, que agora passque agora passam a am a reprepresresententar uma ar uma novanova fronteira do nosso conhecimento.

fronteira do nosso conhecimento.

Este documento nos dá uma visão sucinta dos conceitos e características pertinentes ao objeto da 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á  pesquisa. É um eficiente material de apoio que deverá ser complementado com a apresentação que será

exibida pelo grupo. exibida pelo grupo.

A equipe. A equipe.

PRINCÍPIO

PRINCÍPIOS

S FUNDAMENT

FUNDAMENTAIS

AIS DA

DA ANÁLISE

ANÁLISE DE 

DE 

REQUISITOS

REQUISITOS

Roger S. Pressman em “Engenharia de Software”“Engenharia de Software”explica:explica:

“Uma compreensão completa dos requisitos de software é fundamental para um bem-sucedido “Uma compreensão completa dos requisitos de software é fundamental para um bem-sucedido desenvo

desenvolvimelvimento de nto de softsoftware. Não importware. Não importa quão bem projetado ou quão bem codificada quão bem projetado ou quão bem codificado seja, umo seja, um  programa mal analisado e especificado

 programa mal analisado e especificado desapontará o usuário e trará aborrecimentos ao desapontará o usuário e trará aborrecimentos ao desenvolvedor.desenvolvedor. A tarefa de análise de requisitos é um processo de descoberta, refinamento, modelagem e 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 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 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 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

alternativas são analisadas e atribuídas a vários elementos de software.software.

Tanto o desenvolvedor como o cliente desempenham um papel ativo na análise a especificação 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 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 nebuloso, em detalhes concretos. O desenvolvedor age como indagador, consultor e solucionador de  problemas.

 problemas.

A análise e especificação de requisitos pode parecer uma tarefa relativamente simples, mas as A análise e especificação de requisitos pode parecer uma tarefa relativamente simples, mas as apa

aparêrêncnciaias s engengananamam. . O O conconteteúdo údo de de comcomuniunicaçcação ão é é mumuitito o elelevaevado. Abundo. Abundadam m as as chachancnces es dede interpretações errôneas e lnformações falsas. A ambigüidade é provável. O dilema com o qual interpretações errôneas e lnformações falsas. A ambigüidade é provável. O dilema com o qual sese defronta um engenheiro de software pode ser mais bem entendido repetindo-se a declaração de um 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 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...”

que percebe que aquilo que ouviu não é o que eu pretendia dizer...” ANÁLISE DE REQUISITOS

ANÁLISE DE REQUISITOS

A análise de requisitos é uma tarefa da engenharia de software que efetua a ligação entre a 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 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, 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 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  projeto que o software deve enfrentar. A análise de requisitos permite que o engenheiro de software

(muit

(muitas vezes as vezes chamadchamado o dede analistaanalista nesse papel) aprimore a alocação de software e construa modelosnesse 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 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 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  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 requisitos proporciona ao desenvolvedor e ao cliente os critérios para avaliar a qualidade logo que o software for construído.

ATIVIDADES DE ANÁLISE ATIVIDADES DE ANÁLISE

A

A anáanálilise se de de rerequiquisisitotos s de de sosoftftwaware re popode de seser r didivivididida da em em cicinco nco áráreaeas s de de esesfoforçrço: o: (1(1)) reconhecimento do problema, (2) avaliação e síntese, (3) modelagem, (4) especificação e (5) revisão. reconhecimento do problema, (2) avaliação e síntese, (3) modelagem, (4) especificação e (5) revisão.

Inicialmente, o analista estuda a

Inicialmente, o analista estuda a   Especificação do Sistema (caso  Especificação do Sistema (caso exista um) e oexista um) e o  Plano de  Plano de  Projeto de Software.

 Projeto de Software. É importante entender o software num contexto de sistema e revisar o escopo doÉ 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 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. 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 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  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 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.

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 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 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, 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 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 dessas tarefas serve para descrever o problema de forma que uma abordagem ou solução global possa ser sintetizada.

ser sintetizada.

 Sobreposição da tarefa de análise.  Sobreposição da tarefa de análise.

Por exemplo, um sistema de controle de estoques é exigido por um grande fornecedor de Por exemplo, um sistema de controle de estoques é exigido por um grande fornecedor de aut

autopeopeçasças. . O O anaanaliliststa a desdescobcobre re quque e os os prprobloblememas as com com o o atatual ual sisiststemema a mamanunual al envenvololvevem m (1(1)) incapacidade de obter o

incapacidade de obter o status status de um componente rapidamente; (2) turno de dois a três dias parade 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á 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 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 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 oferecidos ao sistema. Por exemplo, o cliente deseja um relatório diário que indique quais peças foram re

requiquisisitatadadas s do do esestotoquque e e e ququantantas as pepeças ças ididênêntiticacas s pepermrmananececem em nenelele. . O O clclieientnte e inindidica ca quque e osos funcionários do setor de estoques registrarão o

funcionários do setor de estoques registrarão o número de identificação de cada peça quando elasnúmero de identificação de cada peça quando elas saírem da área de estoque.

saírem da área de estoque.

Engenharia de Engenharia de

Sistema de Sistema de Computador 

Computador  _{Análise deAnálise de} Requisitos de Requisitos de Software Software Projeto de Projeto de Software Software

Depois de avaliar os problemas atuais e as informações desejadas (entrada e saída), o analista 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

começa a sintetizar uma ou mais soluções. Um sistema on-line on-line  baseado em terminal resolverá um baseado em terminal resolverá um

conjunto de problemas, mas ele ficará dentro do escopo esboçado no

conjunto de problemas, mas ele ficará dentro do escopo esboçado no Plano de Software? Plano de Software? UmUm

si

siststemema a de de gegererencnciaiamementnto o de de babancnco o de de dadadodos s paparerececeriria a nenececessssárárioio, , mamas s a a nenececessssididadade e dede associatividade do usuário/cliente é justificada? O processo de avaliação e síntese prosseguirá até o 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 analista bem como o cliente tiverem confiança de que o software tenha de ser adequadamente especificado para as etapas do desenvolvimento subseqüentes.

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",  No decorrer da síntese de avaliação e solução, o principal foco do analista recai sobre "o que",

não

não sobre "como".sobre "como". QuaisQuais dados o sistema produz e consome,dados o sistema produz e consome, quaisquais funções o sistema deve executar,funções o sistema deve executar, quais

quaisinterfaces são definidas einterfaces são definidas equaisquais restrições se aplicam.restrições se aplicam.

Durant

Durante a e a ativiatividade de dade de síntsíntese de ese de avaliaçavaliação e ão e soluçsolução, o ão, o analisanalista cria modelos do ta cria modelos do sistsistema numema num esforço para compreender melhor o fluxo de dados e de controle, o processamento funcional e a 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 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.

 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 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 de software que possa ser revisada e aprovada pelo cliente. Num mundo ideal, o cliente desenvolveria uma

uma Especificação dos Requisitos de Software Especificação dos Requisitos de Softwareem sua totalidade. Isso raramente acontece no mundoem 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 real. No máximo, a especificação é desenvolvida como um esforço conjunto entre o desenvolvedor e o cliente.

cliente.

Logo

Logo que que infinformormaçõeações s básbásicaicas, s, funfunçõeções, s, desdesempeempenhonho, , comcomporportamtamentento o e e intinterferfaceaces s forforemem descritos,

descritos, critérios de validaçãocritérios de validação serão especificados para demonstrar o entendimento e viabilizar umaserã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 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 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

formal é escrita para definir as características e os atributos do software. Além disso, um Manual doManual do Usuário Preliminar 

Usuário Preliminar  pode ser rascunhado para casos em que um protótipo não tenha sido desenvolvido. 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 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 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 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 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 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á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.

comentários o quanto antes no processo.

Os documentos da análise de requisitos (especificação a manual do usuário) servem de base 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  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 sempre resulta em modificações na função, desempenho, representações da informação, restrições ou crité

critérios de rios de validaçvalidação. Além disso, o ão. Além disso, o Plano de Plano de ProjProjeto deeto de Software é reavaliado para determinar se asSoftware é reavaliado para determinar se as estimativas continuam válidas, dado o conhecimento adicional obtido.”

Bibliografia

Bibliografia

YOURDON, Edward. Análise

YOURDON, Edward. Análise Estruturada Moderna. Yourdon Press.1992Estruturada Moderna. Yourdon Press.1992

REZENDE, Denis Alcides, Engenharia de Software e Sistemas de Informação. Brasport. 1999 REZENDE, Denis Alcides, Engenharia de Software e Sistemas de Informação. Brasport. 1999 PRESSMAN, Roger. Engenharia de Software. Makron Books. 1995

PRESSMAN, Roger. Engenharia de Software. Makron Books. 1995 BO

BORGRGESES, , GiGilelene. ne. SGSGMOMOO: O: SiSiststemema a GeGeststor or de de MéMétotodos dos OrOrieientntadados os a a ObObjejetotos s BasBaseaeado do emem Conhecimento.

Conclusão

Conclusão

 Na comparação entre os vários autores, pudemos constatar uma enorme gama de pontos de vista  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 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  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 armadilhas que podem ser contornadas com a adoção de medidas metódicas e adequadas ao perfil  profissional da equipe desenvolvedora.

 profissional da equipe desenvolvedora.

O objeto do estudo nos permitiu entender a necessidade de aplicação de medidas metódicas que 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 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.

Anexo

Anexo

 Anexo

 Anexo