Análise de Requisitos

Segundo a IEEE (1990) a análise de requisitos é um processo que envolve o estudo das necessidades do usuário para se encontrar uma definição correta ou completa do sistema ou requisito de software. Este processo consiste no levantamento de dados e especificações de dados para o desenvolvimento do sistema. O modelo sugere vários métodos para a obtenção de dados com o cliente - que serão citadas ao final - que, se escolhida corretamente, pode evitar erros de desenvolvimento por parte do programador pela má comunicação com o cliente. 

Através desta análise muitos erros na composição do sistema, pois visa expor a melhor forma de se dirigir ao usuário para obter os dados e especificação que o mesmo exige. Através dos dados coletados o analista pode construir um planejamento sistematizado e detalhado do projeto, prevendo possíveis erros que estes requisitos solicitados pelo cliente possa gerar, bem como suas respectivas soluções. Este processo é fundamental para a construção de um projeto e é a base da Engenharia de Software.

A Análise de Requisitos consiste em:

• Reconhecer o problema – nesta fase encontra-se a especificação do sistema, o planejamento, o contato do analista com o cliente com a intenção de entender a visão do cliente com relação ao problema.
• Avaliar o problema e a síntese da solução – tem-se o entendimento do problema, e faz-se a identificação das informações que serão necessárias ao usuário, identificação das informações que serão necessárias ao sistema e a seleção da melhor solução possível dentro das soluções propostas.
• Modelar (Modelagem) – é um recurso usado para o suporte da síntese da solução, o modelo vai apresentar ferramentas que facilitarão o entendimento do sistema, como as funcionalidades, informações e comportamento do sistema.
• Especificar os requisitos – consolida funções, interfaces, desempenho, o contexto e as restrições do sistema.
• Revisar (Revisão) – Juntos, cliente e analista, avaliarão o objetivo do projeto com o intuito de eliminar possíveis redundâncias, inconsistências e omissões do sistema, obtendo uma mesma visão.

Classificação dos Requisitos

Existem dois tipos de classificação de requisitos, são eles: Requisitos Funcionais (RF) e Requisitos Não-Funcionais (RNF).

Os requisitos funcionais referem-se sobre o que o sistema deve fazer, ou seja, suas funções e informações. Os requisitos não funcionais referem-se aos critérios que qualificam os requisitos funcionais. Esses critérios podem ser de qualidade para o software, ou seja, os requisitos de performance, usabilidade, confiabilidade, robustez, etc. Ou então, os critérios podem ser quanto a qualidade para o processo de software, ou seja, requisitos de entrega, implementação, etc.

Evidentemente que as prioridades podem variar conforme a natureza do software. Isso quer dizer que um software para uma plataforma de celular terá diferentes requisitos de um software que roda num browser na web. Assim como um software de tempo real que precisa ser executado em 1 segundo é diferente de outro software que pode ter um tempo maior para execução de uma determinada tarefa.

Portanto, requisitos funcionais preocupam-se com a funcionalidade e os serviços do sistema, ou seja, as funções que o sistema deve fornecer para o cliente e como o sistema se comportará em determinadas situações. Segue abaixo alguns exemplos de requisitos funcionais:

• [RF001] O Sistema deve cadastrar médicos profissionais (entrada)
• [RF002] O Sistema deve emitir um relatório de clientes (saída)
• [RF003] O Sistema deve passar um cliente da situação "em consulta" para "consultado" quando o cliente terminar de ser atendido (mudança de estado)
• [RF004] O cliente pode consultar seus dados no sistema

Já, os requisitos não funcionais definem propriedades e restrições do sistema como tempo, espaço, linguagens de programação, versões do compilador, SGBD, Sistema Operacional, método de desenvolvimento, etc. Uma dica importante é que os requisitos não funcionais são geralmente mensuráveis e assim devemos preferencialmente associar uma medida ou referência para cada requisito não funcional. Segue a baixo exemplos de requisitos não funcionais:

• [RNF001] O sistema deve imprimir o relatório em até 5 segundos.
• [RNF002] Todos os relatórios devem seguir o padrão de relatórios especificado pelo setor XYZ.
• [RNF003] O sistema deve ser implementado em Java.

Métodos para Coleta de Requisitos 

1. Entrevistas: É uma forma de comunicação entre, no mínimo, duas pessoas com o objetivo de obter informações. Perguntas feitas diretamente aos usuários alocados nos postos de trabalhos relacionados ao processo que está sendo analisado.
2. Revisão de documentação: Uma das modalidades mais comuns de obtenção de dados sobre a situação atual do sistema. Utiliza várias fontes de informação como:
• Manuais de procedimentos,
• Documentação,
• Manuais de projeto,
• Relatórios,
• Diagramas e outros.
3. Brainstorm:
1. Termo do Inglês que significa “tempestade de ideias”;
2. Metodologia que objetiva explorar as ideias de um grupo de pessoas a fim de obter as melhores soluções;
3. Não há julgamento ou autocrítica;
4. Todas as ideias são aceitas, mesmo aquelas que parecem ser absurdas;
5. Tem-se como objetivo principal fazer com que o grupo libere o seu conhecimento e criatividade;
6. O resultado da técnica Brainstorm tem o seu mérito distribuído porque foi obtido usando as ideias de todo o grupo envolvido;
7. Metodologia que objetiva explorar as ideias de um grupo de pessoas a fim de obter as melhores soluções;
8. Não há julgamento ou autocrítica: Todas as ideias são aceitas, mesmo aquelas que parecem ser absurdas;
9. O resultado da técnica Brainstorm tem o seu mérito distribuído porque foi obtido usando as ideias de todo o grupo envolvido.
4. Questionário: Perguntas organizadas com o objetivo de levantar dados para uma pesquisa ou estudo, cujas respostas são fornecidas pelo informante sem a orientação direta do pesquisador.
5. Análise de observação: Consiste em observar os usuários em seu ambiente de trabalho enquanto eles executam suas atividades. Pode ser usada para confirmar os resultados de uma entrevista, identificar documentos que devem ser analisados etc.
6. JAD: Metodologia criada pela IBM que é baseada em sessões de dinâmica de grupo. Define o ponto de vista dos usuários sobre o sistema, incluindo objetivos e as aplicações do sistema até a geração de telas e relatórios. Diferente da técnica Brainstorm, é refinada, organizada e com uma abordagem mais estruturada.

Ciclos de Desenvolvimento de Software

O ciclo de vida de um "software (em inglês software lifecycle), designa todas as etapas do desenvolvimento de um software, da sua concepção ao seu desaparecimento. O objectivo de tal segmentação é definir balizas intermédias que permitem a validação do desenvolvimento do software, isto é, a conformidade do software com as necessidades exprimidas, e a verificação do processo de desenvolvimento, quer dizer, a adequação dos métodos aplicados.

A origem desta discriminação provém da constatação que os erros têm um custo ainda mais elevado quando são detectados tardiamente no processo de realização. O ciclo de vida permite detectar os erros o mais depressa possível e assim dominar a qualidade do software, os prazos da sua realização e os custos associados.


Geralmente, o ciclo de vida do software compreende, no mínimo, as actividades seguintes:
Definição dos objectivos, consistindo em definir a finalidade do projecto e a sua inscrição numa estratégia global.
Análise das necessidades e viabilidade, quer dizer a expressão, a recolha e a formalização das necessidades do requerente (o cliente) e do conjunto dos constrangimentos.
Concepção geral. Trata-se da elaboração das especificações da arquitectura geral do software.
Concepção detalhada, que consiste em definir precisamente cada subconjunto do software.
Codificação (Aplicação ou programação), quer dizer a tradução numa linguagem de programação das funcionalidades definidas aquando das fases de concepção.
Testes unitário, que permitem verificar individualmente que cada subconjunto do "software" é aplicado em conformidade com as especificações.
Integração, cujo objectivo é assegurar a intercomunicação dos diferentes elementos (módulos) do software. É objecto de testes de integração consignados num documento.
Qualificação (ou receita), isto é, a verificação da conformidade do software às especificações iniciais.
Documentação, destinada a produzir as informações necessárias para a utilização do software e para desenvolvimentos ulteriores.
Produção,
Manutenção, compreendendo todas as acções correctivas (manutenção correctiva) e evolutivas (manutenção evolutiva) no software.

MODELO CASCATA

O modelo clássico ou cascata, que também é conhecido por abordagem “top-down”, foi proposto por Royce em 1970. Até meados da década de 1980 foi o único modelo com aceitação geral. Esse modelo foi derivado de modelos de atividade de engenharia com o fim de estabelecer ordem no desenvolvimento de grandes produtos de software. Comparado com outros modelos de desenvolvimento de software, este é mais rígido e menos administrativo.

O modelo cascata é um dos mais importantes modelos, e é referência para muitos outros modelos, servindo de base para muitos projetos modernos. A versão original deste modelo foi melhorada e retocada ao longo do tempo e continua sendo muito utilizado hoje em dia.

Grande parte do sucesso do modelo cascata está no facto dele ser orientado para documentação. No entanto deve salientar-se que a documentação abrange mais do que arquivo de texto, abrange representações gráficas ou mesmo simulação.

Uma abordagem incorporando processos, métodos e ferramentas deve ser utilizada pelos criadores de software. Esta abordagem é muitas vezes designada de Abordagem do Processo de Desenvolvimento. Existem três abordagens de modelos de processo de desenvolvimento de software. Elas tentem colocar ordem numa atividade inerentemente caótica.

MODELO INCREMENTAL
Barry Boehm sugeriu, tendo em vista as limitações da abordagem tradicional, que o desenvolvimento de sistemas de informação poderia ser administrado numa série de incrementos. Assim, poderia haver uma série de ciclos de vida tradicionais para cada incremento.

O Modelo Incremental foi desenvolvido através da combinação entre os modelos linear e prototipação. O desenvolvimento é dividido em etapas, denominadas “incrementos”, que produzirão incrementalmente o sistema, até a sua versão final.

Em cada incremento é realizado todo o ciclo do desenvolvimento de software, do planejamento aos testes do sistema já em funcionamento. Cada etapa produz um sistema totalmente funcional, apesar de ainda não cobrir todos os requisitos.

O Modelo Incremental apresenta diversas vantagens para o desenvolvimento de um software, especialmente se os requisitos não estão claros inicialmente. Por exemplo: quando o Modelo Incremental é utilizado, o primeiro incremento é normalmente constituído do núcleo do sistema. Isto é, os requisitos básicos são implementados, e os detalhes suprimidos. Esse produto será entregue para uma avaliação, que poderá detectar, inicialmente, problemas que poderiam ser de dimensões muito maiores se detectados somente na entrega do produto final.

Outra vantagem para o desenvolvedor é que, em contato com o sistema, o cliente esclarece seus requisitos e suas prioridades para os próximos incrementos, além de contar com os serviços da versão já produzida.



MODELO ESPIRAL

Este modelo baseia-se em quatro principais atividades:

• Determinação dos objetivos, alternativas e restrições;
• Análise de risco e prototipação;
• Validação e verificação;
• Planejamento da fase seguinte.

Esta concepção tende a criar um roteiro de atividades e etapas para que se alcance uma maturidade do processo evolutivo de desenvolvimento de sistemas complexos e obter, ao final, um produto em sua forma mais completa possível.


Problemas do Modelo espiral:

• O modelo em espiral, por suas características de avaliação e planejamento baseadas em risco, exige que se tenha gerentes e técnicos experientes.
• As tarefas gerenciais para acompanhamento e controle do projeto tornam-se mais difíceis, uma vez que o modelo em espiral pode levar ao desenvolvimento em paralelo de múltiplas partes do projeto, cada uma sendo abordada de modo diferenciado. É necessário o uso de técnicas específicas para estimar e sincronizar cronogramas, bem como para determinar os indicadores de custo e progresso mais adequados.

MODELO DE PROTOTIPAGEM


Baseado no desenvolvimento de um protótipo com base no conhecimento dos requisitos iniciais para o sistema. O desenvolvimento é feito obedecendo à realização das diferentes etapas de análise de requisitos, o projeto, a codificação e os testes. Não necessariamente estas etapas devem ser realizadas de modo muito explícito ou formal


A definição de todos os requisitos necessários ao sistema pelo cliente ou usuário geralmente é uma tarefa muito difícil. É quase impossível prever como o sistema irá afetar o funcionamento das práticas de trabalho, como será a interação com outros sistemas e que operações dos usuários devem ser automatizadas. Mas para poder testar os requisitos de uma forma mais eficiente, seria necessária a utilização de um protótipo do sistema.


Um protótipo é uma versão inicial de um sistema de software, que é utilizada para mostrar conceitos, experimentar opções de projeto e, em geral, para conhecer mais sobre os problemas e suas possíveis soluções. O desenvolvimento rápido de um protótipo é essencial para que os custos sejam controlados e os usuários possam fazer experiências com o protótipo no início do processo de software.

Vantagens da prototipação:

• modelo de desenvolvimento interessante para alguns sistemas de grande porte que representem um certo grau de dificuldade para exprimir rigorosamente os requisitos
• é possível demonstrar a realizabilidade através da construção de um protótipo do sistema
• é possível obter uma versão, mesmo simplificada do que será o sistema, com um pequeno investimento inicial
• A experiência adquirida no desenvolvimento do protótipo vai ser de extrema utilidade nas etapas posteriores do desenvolvimento do sistema real, permitindo reduzir o seu custo e resultando num sistema melhor concebido

Problemas da prototipação:

• Quando informamos que o produto precisa ser reconstruído, o cliente exige que alguns acertos sejam aplicados para tornar o protótipo um produto; muito freqüentemente, a gerência de desenvolvimento de software cede.
• O desenvolvedor muitas vezes faz concessões de implementação a fim de colocar um protótipo em funcionamento rapidamente. Depois de algum tempo, o desenvolvedor pode familiarizar-se com essas opções e esquecer-se de todas as razões pelas quais elas são inadequadas - a opção menos ideal se tornou então parte integrante do sistema.

UML

UML (Unified Modeling Language - Linguagem de Modelagem Unificada) é uma linguagem para visualização, especificação, construção e documentação das funções e objetos de um sistema computacional, para realizar a modelagem orientada a objeto. Por meio desta linguagem é possível desenvolver especificações e visualizações de um sistema de modo a tornar o trabalho do programador e/ou analista no desenvolvimento de um sistema. A UML auxilia na organização e esquematização das funções do sistema, construindo assim um planejamento para realizar o desenvolvimento do sistema.

A UML cria o "guia" que o programador/analista irá seguir para alcançar seu objetivo final - o desenvolvimento completo do sistema - de modo a garantir mais segurança e confiabilidade para não consumir tempo ou recursos demasiados, que são gastos quando não há um planejamento esquematizado.

A Linguagem Unificada de Modelagem possui diagramas (representações gráficas do modelo parcial de um sistema) que são usados em combinação, com a finalidade de obter todas as visões e aspectos do sistema.

Os Diagramas da UML estão divididos em Estruturais e Comportamentais.

Diagramas Estruturais

• De Classe: Este diagrama é fundamental e o mais utilizado na UML e serve de apoio aos outros diagramas. O Diagrama de Classe mostra o conjunto de classes com seus atributos e métodos e os relacionamentos entre classes.
• De Objeto: O diagrama de objeto esta relacionado com o diagrama de classes e, é praticamente um complemento dele. Fornece uma visão dos valores armazenados pelos objetos de um Diagrama de Classe em um determinado momento da execução do processo do software.
• De Componentes: Está associado à linguagem de programação e tem por finalidade indicar os componentes do software e seus relacionamentos.
• De implantação: Determina as necessidades de hardware e características físicas do Sistema.
• De Pacotes: Representa os subsistemas englobados de forma a determinar partes que o compõem.
• De Estrutura: Descreve a estrutura interna de um classificador.

Diagramas Comportamentais

• De Caso de Uso: Geral e informal para fases de levantamento e análise de Requisitos do Sistema.
• De Máquina de Estados: Procura acompanhar as mudanças sofridas por um objeto dentro de um processo.
• De Atividades: Descreve os passos a serem percorridos para a conclusão de uma atividade.
• De Interação: Dividem-se em:
• De Sequência: Descreve a ordem temporal em que as mensagens são trocadas entre os objetos.
• Geral interação: Variação dos diagramas de atividades que fornece visão geral dentro do sistema ou processo do negócio.
• De comunicação: Associado ao diagrama de Seqüência, complementando-o e concentrando-se em como os objetos estão vinculados.
• De tempo: Descreve a mudança de estado ou condição de uma instância de uma classe ou seu papel durante o tempo.

Figura1. Diagramas da UML

Figura 2. Diagrama de Classe (o mais utilizado)

O Profissional de ADS

Esse tecnólogo desenvolve, analisa, projeta implementa e atualiza sistemas de informação para diversos setores de atividade. Tem noções de gerenciamento, mas sua especialidade é a criação de sistemas informatizados. Ele programa computadores e desenvolve softwares que permitem o melhor aproveitamento das máquinas, a ampliação da capacidade de armazenamento de dados e maior velocidade no processamento das informações. Pode dedicarse à implantação e ao desenvolvimento de banco de dados para sistemas de computação e para a internet e intranet, criando estruturas de programas compatíveis com as necessidades de uma empresa. Para isso, ele deve conhecer a estrutura física dos equipamentos e periféricos, softwares, bancos de dados, bem como os negócios da companhia em que vai trabalhar. Tem de manterse atualizado também sobre as linguagens de programação e os ambientes operacionais que servem de suporte aos aplicativos. Pode atuar, ainda, como consultor na área de sistemas de informação. (GUIA DO ESTUDANTE)

O mercado de desenvolvimento de software, no Brasil, atualmente, necessita de cerca de 39,9 mil profissionais qualificados. Até 2015, segundo a revista EXAME e a faculdade IDC, a tendência é que o mercado necessite de mais de 100 mil profissionais qualificados. O profissional de ADS está concorrendo a estas vagas, e tem função especializada para cada empresa. 

O analista tem espaço em qualquer segmento de mercado. Sua atuação abrange múltiplos modelos de negócio, incluindo aqueles que demandam tanto a computação tradicional quanto a computação embarcada que está oculta em diversos dispositivos, presentes em veículos terrestres, aeronaves, máquinas e sensores; elementos que já começam a fazer parte da emergente Internet of Things.

Ele planeja e pode desenvolver aplicações para tomada de decisão, automação e controle de processos, além de sistemas embarcados e especialistas. E não apenas as empresas de TI precisam dos seus serviços, mas todas aquelas que contam com soluções computacionais para suportar suas atividades. Um pequeno comércio, uma grande indústria, um clube de futebol ou um banco são alguns exemplos de geradores de demanda para analistas.

Sua função é importante no desenvolvimento de soluções de integração, principalmente no cenário atual em que empresas têm buscado novos negócios, mediante aquisições ou parcerias. Em muitos casos são negócios globalizados, envolvendo aspectos legais e culturas diversificadas, exigindo do profissional a capacidade de dominar outros idiomas, superar limites e entender como adaptar os sistemas para atender a tal diversificação. São múltiplas plataformas, diferentes sistemas operacionais e variadas linguagens de programação, sendo frequente o uso de infraestrutura geograficamente dispersa ou contratada de terceiros.

Esse profissional moderno precisa conhecer bem a tecnologia e acompanhar sua inovação, ter boa noção de projetos e trabalhar usando metodologias que proporcionem padrões adequados de qualidade. Isso significa ser capaz de conceber uma solução aderente aos requisitos e identificar as oportunidades para o seu uso, mediante a familiaridade com diversos modelos de negócios e suas peculiaridades.

O analista de sistemas deve ser capaz de compreender as disciplinas de engenharia de software e as das atividades da organização. A relação existente entre essas duas áreas e o nível corrente de tecnologia determinam a interação entre o exeqüível e o desejável. Cada aplicação em potencial deverá ser submetida a uma séria de exames para se verificar se, de fato, a função solicitada apresentará a qualidade de desempenho almejada pelo usuário. Se a melhoria em questão parecer ser viável, e havendo os recursos necessários à elaboração da aplicação, o projeto recebe a permissão para prosseguir. Nesta conjuntura, o papel do analista de sistemas muda e o detalhe citado anteriormente deve ser substituído. Para tanto, torna-se necessário identificar as funções que serão entregues quando a aplicação terminar. As funções representarão os “testes” que a aplicação completa deverá satisfazer, a fim de provar que os requisitos foram, realmente, atendidos.

Depois que se estabelece o detalhe e se especifica totalmente o “que” pelo menos em sua versão primeira, o papel do analista de sistemas muda mais uma vez, passando a ser o de arquiteto do software e gerente de projeto. O “que ”deverá ser transformado em “como”, simultaneamente á verificação contínua de que a aplicação permanece atendendo ás especificações detalhadas do sistema.

As funções de serviço atribuídas ao analista de sistemas e a profissão ligada á analise de sistemas são extremamente vastas. Muitas organizações definem uma categoria denominada programador / analista, ampliando ainda mais a descrição. Assim, de acordo com a abrangência do título do cargo tanto as organizações quanto os indivíduos se enquadram numa larga gama de usos. As organizações maiores possuem departamentos distintos para analise e programação e contam com analistas que “vivem” ou num grupo ligado a análise de desenvolvimento de sistemas, ou na organização do negócio que utilizará a aplicação. Algumas organizações possuem o cargo de arquiteto de sistemas; outras, o de gerente de projetos e outras ainda o de projetistas de sistemas.

Problemas no Desenvolvimento de Software

Diversos problemas são encontrados durante o processo de desenvolvimento de software. Alguns destes podem ser elencados como:

1 - Entender as necessidades do usuário
2 - Eficiência x Eficácia
3 - Visão abrangente do problema
4 - Falta de planejamento
5 - Pessoalidade do software
6 - Produtividade
7 - Confiabilidade
8 - Manutenabilidade
9 - Eficiência
10 - Portabilidade
11 - Segurança

1) Entender as necessidades do usuário

     Antes das etapas de desenvolvimento é necessário que o programador tenha em mente exatamente o que seu cliente espera do software a ser feito. Isto pode ser feito através de diversos métodos (entrevista, prototipagem e etc). 

2) Eficiência x Eficácia

    O excesso de abordagem técnica também é algo prejudicial! As funcionalidades principais devem ser feitas primeiro. Os "enfeites" deve ser deixado para o fim.

3) Visão abrangente do problema

    O desenvolvimento de um software não leva em conta apenas a qualidade de programação do programador. A interação entre os componentes é essencial para que a visão do desenvolvimento e dos problemas seja feita de forma ampla, e não apenas por quem desenvolve.

4) Falta de Planejamento

    A falta de planejamento não está restrita a codificação. Requer estimativas mais precisas: quantidade de pessoas envolvidas, dinheiro necessário para o desenvolvimento (e o lucro que obterá), tempo necessário para a entrega do programa. Se apoiar na engenharia de sotware (técnicas, métodos e ferramentas) são interessantes.

5) Pessoalidade do software

     50% do tempo deve ser feito em grupo! Um desenvolvimento focado no individual pode, muitas vezes, inviabilizar a manutenção corretiva, isto é, dificilmente o próprio programador vai encontrar os problemas (e soluções) em sua programação... Um analista de sistemas é sempre necessário.

6) Produtividade

    Diversos problemas podem afetar a produtividade em um desenvolvimento de software: problemas técnicos, problemas gerenciais, inexperiência da equipe, estrangulamento do tempo de desenvolvimento; são alguns destes.

7) Confiabilidade

     Existência de erros no processamento. A análise do software, assim como os testes pós-desenvolvimento, é necessária para programar um confiável software!

8) Manutenabilidade

     A manutenabilidade é um dos problemas quando é necessário que seja realizada a correção de erros... Outros fatores são: alteração do sistema econômico atual; alterações de regras governamentais; aprimoramento de rotinas; implementação de novas características

9) Eficiência

     A taxa de desempenho da equipe deve ser máxima e o tempo de resposta, rápido. Atraso pode afetar a eficiência da equipe.

10) Portabilidade

      Um dos problemas a ser superado é o da portabilidade. Atualmente, todo software (para ter grande abrangência) necessita estar adaptado a diferentes plataformas.

11) Segurança

     Um dos maiores problemas. Um software deve ser seguro e confiável; restringir acessos não-autorizados ao sistema ou aos dados requer cuidado e atenção. Não ter esta segurança pode afetar todo o software.