Conceitos : Especificação de requisitos.

A especificação de requisitos tem como objetivo obter produtos de software de melhor qualidade que satisfaçam às reais necessidades dos clientes dentro de prazo e orçamento adequados.

Podemos entender requisito como uma função, restrição ou propriedade que deve ser fornecida, encontrada ou atendida para satisfazer às necessidades do usuário do sistema. (Descreve um serviço ou uma limitação)

Esta comprovado : a maior parte dos problemas , os de maior impacto negativo e os mais onerosos tem origem nas etapas iniciais do desenvolvimento de software. Justamente nas etapas de especificação dos requisitos é onde as principais atividades são definidas e onde os requisitos do produto devem ser identificados e mapeados com objetividade e clareza.

Podemos dizer que as principais causas para o fracasso dos projetos de software são: especificação de requisitos mal formulada e alterações constantes nos requisitos.

Por serem atividades bases do processo de desenvolvimento de software as falhas cometidas nas atividades de definição e validação de requisitos irão originar documentos de requisitos inconsistentes afetando as etapas seguintes de projeto , implementação e testes e gerando produtos de softwares de baixa qualidade.

Embora não exista um modelo padrão consagrado para gerenciar requisitos podemos definir alguns passos para um processo de especificação de requisitos :(Soares, 2005) (Os processos devem ser adaptados a cada necessidade/conjuntura)

  1. Descoberta dos requisitos - consultas , documentos, pesquisas, entrevistas, JAD(Joint Application Design);
  2. Análise dos requisitos identificados com refinamento e detalhamento dos mesmos;
  3. Modelagem e Validação dos requisitos verificando sua consistência (Documento de requisitos);
  4. Acompanhamento dos requisitos;

Ao final deste processo deve-se ter um documento de requisitos bem definido e entendido por todos os intervenientes do processo: Clientes, desenvolvedores, líderes, analistas, gerentes, patrocinadores, etc. (stakeholders)

Mas o que é especificar um requisito ?

Especificar um requisito implica em compreender exatamente o que deve ser feito e que se espera receber como resultado.

Podemos classificar os requisitos em :

Exemplos de requisitos funcionais:

  • O sistema deve possibilitar o cadastramento dos dados pessoais dos clientes;
  • O sistema deve emitir relatórios gerenciais;
  • O sistema deve permitir a baixa automática do estoque quando da venda de um produto;
    •

    A Norma ISO / IEC 9126 define seis características de qualidade de software que devem ser avaliadas:

    Exemplos de requisitos não funcionais:

  • tempo de resposta do sistema não deve ultrapassar 10 segundos;
  • software deve ser operacionalizado no sistema Windows;
  • O banco de dados usado deverá ser o Oracle;
    •

    Obs: "Os requisitos não funcionais são críticos para o sucesso de sistemas de software e estão diretamente relacionados com a satisfação dos usuários. Devido a essa importância, alguns requisitos funcionais podem ser sacrificados para atender às restrições impostas pelos requisitos não funcionais"

    O documento de requisitos de sistema - DRS - pode ser entendido como a descrição formal e oficial onde é descrita e comunicada os requisitos a todos os envolvidos no processo de desenvolvimento de software (stakeholders). Ele é basicamente composto de:

    1. os serviços e funções que o sistema deve prover;
    2. as limitações sobre as quais o sistema deve operar;
    3. definições de outros sistemas com os quais o sistema deve integrar;
    4. limitações no processo usado para desenvolver o sistema;
    5. descrições sobre o hardware no qual o sistema irá executar

    Os requisitos podem ser modelados e validados através de casos de uso que incluem o diagrama de casos de uso e a especificação do caso de uso.

    Um caso de uso representa uma funcionalidade completa, conforme percebida pelo ator e é definido como "um conjunto de seqüências de ações que um sistema executa que produzem um resultado observável por um particular ator".

    Os casos de uso é uma das técnicas usadas para descrever claramente todos os requisitos de um dado sistema, esta técnica foi proposta por Ivar Jacobson em sua metodologia de desenvolvimento de sistemas orientados a objetos , visando identificar os requisitos de um sistema.(Wikipédia).

    O Diagrama de Casos de Uso fornece um modo de descrever a visão externa do sistema e suas interações com o mundo exterior, representando uma visão de alto nível da funcionalidade do sistema mediante uma requisição do usuário.(Wikipédia).

    O modelo de casos de uso é um formato ágil para capturar requisitos de software. Ele contrasta com documentos maiores e descritivos que tentam conter todos os requerimentos possíveis antes do início da construção de um novo sistema, mas falham completamente neste intento. Os principais benefícios dos casos de uso na modelagem de requisitos são:

    1. os casos de uso podem ser facilmente adicionados ao projeto de software e removidos do projeto de software assim que as prioridades mudarem;
    2. os casos de uso podem também servir como base para estimar, escalonar e validar esforços;
    3. uma razão porque os casos de uso se tornaram populares: são fáceis de entender por pessoas da área de negócio e assim provaram ser uma excelente ponte entre quem desenvolve o software e os utilizadores finais.

    Os casos de uso também têm as suas dificuldades. São excelentes para capturar os requisitos funcionais de um sistema, mas não têm tanto sucesso em capturar os não funcionais.

    É importante notar que os modelos de casos de uso não descrevem como o software deverá ser construído, e sim, como ele deverá se comportar. As descrições de casos de uso normalmente evitam o uso de termos técnicos, preferindo a linguagem do usuário final. Normalmente, os casos de uso são feitos por quem desenvolve o software e/ou por quem vai utilizar esse mesmo software.
    Propósitos básicos:

    1. decidir e descrever os requisitos funcionais do sistema;
    2. prover uma descrição clara e consistente do que o sistema deve fazer;
    3. prover a base para a realização de testes que validam e verificam o sistema;
    4. prover facilidades para rastrear requisitos funcionais dentro das classes e operações do sistema.

    Principais Componentes do Modelo de Casos de Uso:

    A seguir temos a sequência que pode ser usada para construir o modelo de casos de uso:

  • Definir o sistema (conjunto de casos de uso);
  • encontrar os atores;
  • encontrar e descrever os casos de uso;
  • definir os relacionamentos entre os casos de uso;
  • validar o modelo.

    • Como identificar um ator ?

    As respostas às seguintes perguntas podem auxiliar na identificação dos atores:

    1. Quem utiliza a principal funcionalidade do sistema?
    2. Quem vai precisar de suporte do sistema para realizar suas tarefas diárias?
    3. Quem precisa manter, administrar e deixar o sistema "rodando"?
    4. Quais dispositivos de hardware o sistema precisa manipular?
    5. Com quais outros sistemas o sistema precisa interagir?
    6. Quem ou o quê tem interesse nos resultados produzidos pelo sistema?

    Propriedades de um caso de uso

    Como identificar um caso de uso ?

    As respostas às perguntas abaixo podem auxiliar a identificar os Casos de Uso:

    1. Quais funções o ator requer do sistema? O que o ator precisa fazer?
    2. Ator precisa criar, ler, destruir, modificar ou armazenar algum tipo de informação dentro do sistema?
    3. Ator precisa ser notificado de eventos do sistema? O ator precisa notificar o sistema sobre algum evento?
    4. Trabalho diário do ator poderia ser simplificado ou tornado mais eficiente por meio de novas funcionalidades do sistema?
    5. Quais entradas e saídas o sistema precisa?
    6. Quais os principais problemas com o atual sistema?

    Mesmo ainda nesta fase do processo de desenvolvimento de software, através de uma especificação de requisitos bem elaborada e documentada através dos casos de uso pode-se usar a métrica Pontos por Caso de Uso - PCU - (Use Case Points ) para realizar estimativas de tamanho, prazo e custo em projetos de software.

    O processo de contagem da métrica PCU é constituída por seis passos descritos a seguir:

    1. Contar os atores e atribuir o grau de complexidade;
    2. Contar os casos de uso e atribuir a complexidade;
    3. Somar o total dos atores com o total de casos de uso para obter o PCU não ajustado;
    4. Determinar a complexidade do fator técnico;
    5. Determinar a complexidade do fator ambiente;
    6. Calcular o PCU ajustado;

    A técnica de análise de Pontos por Casos de Uso foi criada para permitir que seja possível estimar o tamanho do sistema ainda na fase de levantamento de Casos de Uso, utilizando-se dos próprios documentos gerados nesta fase de análise como subsídio para efetuar estimativas de tamanho, prazo e custo de software.

    Naturalmente existe um grau de incerteza inerente a fase inicial do processo e as definições de requisitos da ordem de 45%.

    Assim,  a medida do tamanho, complexidade e riscos de um projeto de software vai depender da qualidade e coerência dos requisitos definidos . É de vital importância que a tarefa de  levantamento de requisitos seja executada de forma criteriosa e detalhada, pois uma falha nessa etapa do ciclo de vida do software vai gerar um projeto mal sucedido e a insatisfação do cliente.

    Referências:

    Veja os Destaques e novidades do SUPER DVD Visual Basic (sempre atualizado) : clique e confira !

    Quer migrar para o VB .NET ?

    Quer aprender C# ??

     

                 Gostou ?   Compartilhe no Facebook   Compartilhe no Twitter
     

    Referências:

    José Carlos Macoratti