Análise e Especificações de Requisitos

Faz parte do desenvolvimento de um software independente de sua linguagem ou metodologia de desenvolvimento a analise dos requisitos para a garantia do sucesso do projeto.

A analise e as especificações de requisitos de um software envolve atividades que determinarão o objetivo do sistema e todas as restrições associadas a ele.  A analise e especificações são atividades interdependentes e devem ser executadas em conjunto.

A Análise

A analise é o processo de observação e levantamento dos elementos do ambiente onde o software será implantado. Devem-se identificar as pessoas que terão contato com o software, quer seja um contato operacional ou para o fornecimento de informações relevantes para o seu desenvolvimento.

Também deve ser checadas todas as atividades que estão envolvidas no sistema: quem faz, por que faz, se existem outras formas de serem feitas. Não se esquecendo dos dados e informações que são gerados por essas atividades.

A Especificação

A especificação é a descrição sistemática e abstrata do que o software deve fazer a partir daquilo que foi analisado anteriormente. Ela apresenta a solução de como os problemas levantados na análise devem ser resolvidos pelo software em desenvolvimento.

A especificação é a forma de comunicação direta entre o analista e a equipe de desenvolvimento do software.

O que são requisitos?

Compreender os problemas que uma organização tem para serem resolvidos com ajuda de um software é muito difícil; consequentemente é difícil estabelecer com exatidão o que um sistema deverá fazer.

Os requisitos compõem o conjunto de necessidades estabelecido pelo cliente/usuário que define a estrutura e o comportamento do software que esta sendo desenvolvido, podemos citar: os processos, os dados que se espera serem gerados, as restrições operacionais, as pessoas que irão se utilizar do software e todas essas questões relacionadas entre si. São as premissas que o software que esta a ser desenvolvido possa:

• ·         Permitir que o cliente/usuário resolva os problemas relacionados ao negócio da sua empresa.
• ·         Atender as necessidades ou restrições da organização ou dos outros módulos do sistema.

Na atividade de levantamento de requisitos podemos separa-los em: requisitos diretos e indiretos.

Os requisitos diretos são chamados de requisitos funcionais e se refere as diferentes funcionalidades que o cliente/usuário deseja que o sistema faça, seja por comando do usuário ou acionados automaticamente por eventos internos ou externos dos sistemas. A descrição do requisito direto deve descrever detalhadamente o que se espera que o sistema ou faça, sem a preocupação de como ele será construído.

Os requisitos indiretos ou não funcionais, referem-se as qualidades globais do software, tais como sua facilidade de manutenção, segurança, facilidade de utilização e acessibilidade, desempenho, entre outras.

 Conciliar dois requisitos indiretos pode ser uma tarefa difícil, por exemplo por questões de motivos de interesse dentro da empresa do Cliente, como podemos citar: o acesso a recursos do software deve ser restrito a pessoas autorizadas, o tempo de resposta para determinada consulta pode ultrapassar as expectativas do cliente, porem ele necessita de todos os dados daquele relatório entre outros casos.

Os benefícios da analise de requisitos são:

• ·         Entendimento comum entre desenvolvedores, clientes e usuários sobre o trabalho a ser feito.
• ·         Uma fonte confiável para estimativa de custos, pessoal, prazos e etc.
• ·         Melhoria na qualidade do software a ser desenvolvido.
• ·         Objetivo traçado gerando assim uma menor manutenção e customização do software futuramente.

Uma boa especificação dos requisitos deve ser:

• ·         Clara e não ambígua
• ·         Completa
• ·         Correta
• ·         Consistente
• ·         Concisa
• ·         Confiável

Meios para se executar um levantamento de requisitos

Conhecer com exatidão o ambiente do usuário, sua forma de trabalho, a estrutura da organização, os problemas e necessidades a serem supridas pelo novo sistema é fundamental para o processo de desenvolvimento de software.

A busca pela informação sobre os requisitos envolve vários problemas: o usuário sempre tem uma visão parcial dos processos, podendo omitir ou supervalorizar certos aspectos, fazendo com que o analista acabe sendo um montador de quebra-cabeças.

• ·      Alguns meios para o levantamento dessas informações podem ser:
• ·         Entrevistas com os Colaboradores da Cliente
• ·         Aplicação de Questionários
• ·         Verificação de documentos utilizados no processo (se houver)
• ·         Observação in-loco do processo do Cliente

Normalmente a primeira atividade relativa ao levantamento de requisitos é o encontro entre o cliente/usuário e o analista, e o proposito desse encontro é delimitar a abrangência do software a ser desenvolvido e os benefícios que ele deverá trazer após sua conclusão.

Uma vez definido sua abrangência deve-se criar um planejamento para os detalhamentos dos processos envolvidos e o entendimento dos mesmos.

Documentação de Requisitos

O modelo que é empregado para especificações dos requisitos é variável, ainda não há um padrão que possa ser encontrado. O levantamento de requisitos precede qualquer método de desenvolvimento de software.

Existem sugestões que podem facilmente ser encontradas em literaturas, algumas tornam-se documentos tão completos que passam a ser considerados quase um contrato de desenvolvimento de software, por exemplo o modelo proposto por Pressman (1995), possui os seguintes tópicos:

1.       1. Introdução

a.       Do que trata o sistema

b.      Descrição geral do funcionamento do sistema

c.       Restrições do projeto

2.       2. Descrição da informação

a.       Representação do fluxo de informação

                                                               i.      Fluxo de dados

                                                             ii.      Fluxo de controle

b.      Representação do conteúdo de informação

c.       Descrição da interface e layout do sistema

3.       3. Abordagem funcional

a.       Divisão funcional entre os módulos do sistema

b.      Descrição funcional

                                                               i.      Narrativas

                                                             ii.      Restrições/Limitações

                                                            iii.      Exigências de desempenho

                                                           iv.      Restrições gerais do projeto

                                                             v.      Diagramas de apoio

c.       Descrição de controle

                                                               i.      Especificações de controle

                                                             ii.      Restrições de controle

4.       4. Descrição comportamental

a.       Estados do sistema

b.      Eventos e Ações

5.       5. Critérios de Validação

a.       Considerações Especiais

b.      Dicionário de Dados

6.       6. Bibliografia

7.       7. Apêndice

Perfil do Analista

Par uma boa atuação do Analista é conveniente observar algumas diretrizes de conduta, que servirão para facilitar o trabalho:

• ·         Procurar se aceito profissionalmente, em todos os níveis hierárquicos da empresa.
• ·         Tentar entender o que o usuário “quer dizer” e não o que “se pensa” que ele quer dizer.
• ·         Escutar muito primeiro, falar muito pouco depois.
• ·         Estar sempre familiarizados os as tendências tecnológicas e compreender como aplica-los em negócios.
• ·         Ser capaz de explicar conceitos complexos em uma linguagem simplificada e não técnica.
• ·         Conhecer a fundo a área de negocio que se pretende desenvolver o software, passando boa parte do tempo com o usuário, estude seu cliente.
• ·         Compreender conceitos abstratos, sintetizar em divisões lógicas e documenta-las.

Além de algumas características como: criatividade, concentração, persuasão, ação conciliadora, determinação, iniciativa, flexibilidade, clareza e raciocínio.

Referência: Tonsig, Sérgio Luiz – Engenharia de Software – Analise e Projeto de Sistemas 2 Ed.