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 :

  • 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…

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:

  • Funcionalidade (finalidade do produto);

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

  • Confiabilidade (freqüê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).

  • 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:

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

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

  • definições 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 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:

  • os casos de uso podem ser facilmente adicionados ao projeto de software e removidos do projeto de software assim que as prioridades mudarem;

  • os casos de uso podem também servir como base para estimar, escalonar e validar esforços;

  • 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:

  • 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 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

  • A descrição resumida do caso de uso é uma breve descrição do caso de uso.

  • Fluxo principal descreve o fluxo natural seguido pelo caso de uso se todas as hipóteses foram verdadeiras e se nenhum erro tiver ocorrido.

  • Os fluxos alternativos representam os desvios alcançados pela execução do caso de uso, causados pelos atores, por condições intrínsecas ao caso de uso ou por erros ou exceções.

  • Os pontos de extensões são somente rótulos que indicam, nos fluxos, a extensão do caso de uso. Podem existir vários pontos de extensões no mesmo fluxo.

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

Referências:

José Carlos Macoratti
http://www.macoratti.net/

Compatilhe esse artigo!

Um comentário sobre “Conceitos: Especificação de requisitos

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.