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).

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:

    -Funcionais - descrevem as funcionalidades do sistema desejadas pelos clientes, ou seja, O QUE se espera que o software faça;

   -Não funcionais - São as qualidades e restrições globais do sistema relacionados com manutenção, uso, desempenho, custo, interface, etc...

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

    - Funcionalidade (finalidade do produto);

    - Usabilidade (esforço para utilizar, aprender o produto);

    - Confiabilidade (frequência de falhas, recuperabilidade);

    - Eficiência (característica relacionada ao desempenho);

    - Manutenibilidade (esforço necessário para modificar);

    - Portabilidade (capacidade de transferir o produto para outros ambientes).

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:

    - Os serviços e funções que o sistema deve prover;

    - As limitações sobre as quais o sistema deve operar;

    - De outros sistemas com os quais o sistema deve integrar;

    - Limitações no processo usado para desenvolver o sistema;

    - 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 sequências de ações que um sistema executa que produzem um resultado observável por um particular ator".

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.

 Principais Componentes do Modelo de Casos de Uso:

Caso de uso: especifica uma funcionalidade completa do sistema. É sempre iniciado por um ator (direta ou indiretamente ordena ao sistema a execução de um caso de uso);

-Ator: entidade externa que interage com os casos de uso;

-Sistema: conjunto 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 caso de uso?

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

                             Quais funções o ator requer do sistema? 

                             O que o ator precisa fazer?

                      Ator precisa criar, ler, destruir, modificar ou armazenar algum tipo de informação dentro do sistema?

                             Ator precisa ser notificado de eventos do sistema?

                             O ator precisa notificar o sistema sobre algum evento?

                           Trabalho diário do ator poderia ser simplificado ou tornado mais eficiente por meio de novas funcionalidades do sistema?

                             Quais entradas e saídas o sistema precisa?

                             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.

           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%.

        Falha nessa etapa do ciclo de vida do software vai gerar um projeto mal sucedido e a insatisfação do cliente. 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 requisito 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.