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.