Análise dos requisitos do sistema

Atps 2 Etapa P2.Análise de requisitos do sistema

A análise de requisitos tem por objetivo tratar do processo de definição dos requisitos de software .

Para isso, todas as atividades de desenvolvimento precisam ser criteriosamente elaboradas e desenvolvidas, é essencial que a equipe de desenvolvimento compreenda exatamente o que é esperado do aplicativo a ser construído e também o que o não é. Isso pode parecer óbvio, mas nem sempre fica claro para todos os envolvidos do projeto qual será o alcance da aplicação. A equipe também deve preocupar-se com o desempenho e com a interface exigida pelo cliente. Esse processo deve lidar com diferentes pontos de vista e usar uma combinação de métodos, ferramentas e pessoal, para assim elicitar , analisar e modelar o programa a ser desenvolvido. Os requisitos, tanto para o sistema como para o.

Software deveserdocumentados e revistos com o cliente. Os requisitos, de modo geral, podem ser classificados em dois grandes grupos: requisitos funcionais e não funcionais.

Atps 2 Etapa P1

2.Análise de requisitos do sistema

A análise de requisitos tem por objetivo tratar do processo de definição dos requisitos de software .

Para isso, todas as atividades de desenvolvimento precisam ser criteriosamente elaboradas e desenvolvidas, é essencial que a equipe de desenvolvimento compreenda exatamente o que é esperado do aplicativo a ser construído e também o que o não é. Isso pode parecer óbvio, mas nem sempre fica claro para todos os envolvidos do projeto qual será o alcance da aplicação. A equipe também deve preocupar-se com o desempenho e com a interface exigida pelo cliente. Esse processo deve lidar com diferentes pontos de vista e usar uma combinação de métodos, ferramentas e pessoal, para assim elicitar , analisar e modelar o programa a ser desenvolvido. Os requisitos, tanto para o sistema como para o.

Software deveserdocumentados e revistos com o cliente. Os requisitos, de modo geral, podem ser classificados em dois grandes grupos: requisitos funcionais e não funcionais.

2.1 Requisitos funcionais

Os requisitos funcionais são aqueles que descrevem o comportamento do sistema, suas ações para cada entrada, ou seja, é aquele que descreve as funcionalidades as quais se espera que o sistema forneça. Eles dependem do tipo de software que está sendo desenvolvido e dos usuários de software que se espera atingir.

2.2. Requisitos não funcionais

Os requisitos não-funcionais não estão ligados diretamente com as funções fornecidas pelo sistema. Em geral se preocupam com padrões de qualidade como confiabilidade,desempenho, robustez, segurança, usabilidade, portabilidade, legibilidade, qualidade,manutenibilidade, entre outros. São muito importantes, pois definem se o sistema seráeficiente para a tarefa que se propõe a fazer. Um sistema ineficiente certamente não seráusado.

3. Softwares “fast food”

Atualmente com o rápido desenvolvimento das tecnologias e com as várias facilidadesque encontramos para a comunicação, empresas de todos os portes acreditam que quanto maisrápido o software estiver pronto para ser usado, melhor. É aí que eles se enganam,

softwares“fast food

” podem dar a impressão de estar agilizando o trabalho, mas os problemas logoaparecem.

Softwares

não são feitos da noite para o dia. Eles englobam muito mais que linhas decódigo. Horas de testes, manuais, documentação e treinamento fazem parte de um sistema bem desenvolvido. Se o cliente exige um prazo absurdamente curto, é melhor nem começar odesenvolvimento. O software desenvolvido dessa maneira terá tanto problema no futuro que oque pedir para fazê-lo não valerá a pena. Percebemos isso claramente no trecho a seguir:

Interessante ver que as grandes conquistas não são feitas a toque decaixa. Dias atrás reli o livro 100 dias entre o céu e o mar de Amyr Klink onde ele narra não somente sua travessia pelo Atlântico em um barco a remo,mas principalmente os anos de preparativos para a empreitada. Não é a toaque Klink é um dos melhores palestrantes brasileiros quando se desejaconhecer estratégia e pés no chão. Ele sabe o que faz e principalmente quetempo não é uma questão de dinheiro; é uma questão de coerência. O tempoque se ganha agora pode-se perder pouco depois.(Amyr Klink apud

Paulino Michelazzo

- On-line)

Em primeiro lugar, é importante identificar o que não contribui para o fracasso nesse tipode software. Jim Johnson, do The Standish Group, afirma que "quando um projeto falha,raramente a causa é técnica". Com isso pode-se afirmar que o problema não é se o .NET, Javaou outras tecnologias e ferramentas sejam instrumentos limitados para a construção de

softwares

. A raiz da maioria das falhas está na (ausência de) utilização de metodologias dedesenvolvimento adequadas e como elas interagem com os

stakeholders

em um projeto desoftware.Se a metodologia adotada não for seguida corretamente é certo que o produto final sofreráas conseqüências.Um dos piores problemas que a utilização de uma metodologia pode apresentar é ignorar o cliente e o usuário final em um projeto. A falta de envolvimento de ambos durante todo odesenvolvimento está diretamente relacionada ao fracasso, pois serão o cliente e o usuáriofinal que saberão especificamente o que o sistema deverá realizar. Por melhor preparados queos desenvolvedores estejam, não saberão ao certo quais funcionalidades deverão estar habilitadas nesse software.Somente muita comunicação entre os desenvolvedores, cliente e usuário final trará asinformações necessárias para que se possa começar o desenvolvimento do sistema. Emboraesta comunicação não seja fácil, também não é impossível. O grande problema é que o clientenem sempre sabe como expressar suas idéias e exigências, muitas vezes ele até sabe o quequer do sistema, mas tem uma idéia distorcida do que o software pode fazer por ele.

4.Atividades do processo de análise de requisitos

Empresas distintas lidam