/Desenvolvimento

voltar
/Desenvolvimento

Especificação de Requisitos (Por que os projetos atrasam?)

PorDaniel Batista Fernandes em

Mas, afinal, o que são requisitos? Requisito
pode ser descrito como:

. Uma condição ou capacidade necessitada por um usuário para resolver um problema ou alcançar um objetivo;
. Condição necessária para a obtenção de certo objetivo, ou para o preenchimento de certo fim;
. Uma condição ou capacidade que deve ser satisfeita por um sistema para satisfazer um contrato ou um padrão;
. Tudo o que o sistema deve fazer para implementar uma necessidade de automação requerida pela solução.

Na prática, requisito é o que o sistema tem que ter para atender plenamente ao propósito para o qual foi criado. Para garantir a aderência aos requisitos, é fundamental que a Metodologia implemente e gerencie eficazmente o documento: Especificação dos Requisitos de Software, que tem como objetivos:

. Descrever, cuidadosamente, quais os requisitos do sistema e como o sistema deverá implementar tais requisitos.
. Descrever, objetivamente, como essa implementação poderá ser testada e verificada pelo usuário.

Os requisitos podem ser classificados em:

Requisitos Funcionais – funcionalidade a ser implementada no software para atender a uma necessidade de automação.

Requisitos Operacionais – Especificação de características relacionadas com o processamento do software, tais como: volume, freqüência, disponibilidade, performance, localização física, etc…

Requisitos de Contingência – Tarefas alternativas para o caso de não funcionamento ou indisponibilidade eventual do software.

Requisitos Técnicos – Premissas e restrições quanto a arquitetura tecnológica, padrões, comunicação, ferramentas, linguagens, etc…

Exemplo:
Projeto ABC

. Objetivo do Projeto
. Público Alvo
. Políticas Internas
. Premissas Básicas que regem o negócio
. Definição do Produto
. Condições de operacionalização
. Aspectos envolvendo processamento e comunicação com o Cliente
. Fatores que deram origem ao projeto
. Limitações ou Restrições Operacionais
. Benefícios Esperados pelos Usuários com a implantação do Sistema
. Principais necessidades que deverão ser atendidas pelo projeto
. Alternativas de Solução
. Necessidade de Integração com Sistemas Corporativos
. Padrões de Qualidade e Performance a serem obtidos
. Atribuição de Responsabilidades
. Fatores de Risco
. Aspectos Contábeis e Financeiros
. Aspectos Legais e Jurídicos
. Gerenciamento das Informações do Sistema.

Além desses requisitos que definem objetivos e funcionalidades do sistema, devemos lembrar que qualquer sistema deve estar aderente às políticas da organização em relação à qualidade e segurança das informações; deve rodar em um ambiente produtivo em que rodam os outros sistemas da empresa, portanto deve estar em compatibilidade com todas as características operacionais desse ambiente sem impactar ou causar distúrbios nesses processamentos;  deve estar em conformidade com os padrões de mercado em termos de tempo de resposta, desempenho e performance em máquina, minimizando a utilização dos recursos computacionais.

A indústria de software vem demonstrando crescente interesse em engenharia de requisitos, isto é, entender o que se deseja construir antes de começar a fazê-lo. Estão percebendo que o tempo utilizado no entendimento do problema é um excelente investimento. Os requisitos de software são a base a partir da qual a qualidade é medida. Desta forma, a falta de conformidade aos requisitos significa falta de qualidade. O modelo de avaliação de maturidade do processo de desenvolvimento CMM (Capability Maturity Model) considera o gerenciamento de requisitos como sendo uma das primeiras etapas para alcançar a maturidade organizacional, e para haver o gerenciamento é preciso que o processo de desenvolvimento de requisitos esteja implantado na empresa.

Desta forma, para se alcançar a gerência de requisitos é necessário que os requisitos tenham sido definidos, e é importante que a empresa também possua seus processos de desenvolvimento de requisitos definidos.

A cada dia, as empresas tornam-se mais dependentes dos seus sistemas de informações. Construir esses sistemas, em tempo hábil para serem úteis aos negócios,
com a qualidade e custos adequados à sua importância para a organização, é o desafio que todos os desenvolvedores estão enfrentando.

Pressman define qualidade de software como “conformidade a requisitos funcionais e de desempenho explicitamente declarados, a padrões de desenvolvimento claramente documentados e a características implícitas que são esperadas de todo software profissionalmente desenvolvido”

Requisitos Não-Funcionais

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

01. Funcionalidade (finalidade do produto);
02. Usabilidade (esforço para utilizar, aprender o produto);
03. Confiabilidade (freqüência de falhas, recuperabilidade);
04. Eficiência (característica relacionada ao desempenho);
05. Manutenibilidade (esforço necessário para modificar);
06. Portabilidade (capacidade de transferir o produto para outros ambientes).

Pressman define Requisitos Não-Funcionais como: Fatores de qualidade de software que podem ser medidos de forma indireta, ou como características implícitas que são esperadas de todo software profissionalmente desenvolvido.

01. Reusabilidade (capacidade de reutilização de módulos do sistema em outras aplicações). Este requisito está relacionado a outros fatores tais como:

. Modularidade: independência funcional dos componentes
. Generalidade: amplitude do potencial de aplicação
. Encapsulação
. Abstração

02. Portabilidade (esforço exigido para transferir um sistema de um ambiente de hardware e/ou software para outro). Fator diretamente relacionado à reusabilidade e às linguagens de programação e ferramentas utilizadas.

03. Manutenibilidade  (esforço exigido para localizar e reparar erros em um sistema ou para modificá-lo com o propósito de adaptá-lo a um novo ambiente, a novas funcionalidades ou a outras metas de qualidade). Este requisito está relacionado a outros fatores tais como:

. Boa documentação
. Legibilidade
. Reusabilidade e portabilidade

04. Multimodalidade (uso de diferentes mecanismos para representação ou apresentação da informação e para a interação com o usuário). Este requisito está relacionado ao uso de diversos canais de comunicação:

. Visual
. Tátil
. Auditiva
. Motora

05. Eficiência e Desempenho

. Eficiência: quantidade de recursos de computação e de código exigida para que o programa execute a sua função.
. Desempenho: é medido avaliando-se a velocidade de processamento, o tempo de resposta, o consumo de recursos, o throughput e a eficiência

Outros requisitos ou outras definições para o mesmo tipo de requisito ainda podem ser encontrados em diversas literaturas sobre o assunto.

06. Usabillidade (refere-se ao grau de facilidade oferecido para que um usuário aprenda a operar, fornecer entradas e interpretar saídas de um componente ou sistema). A usabilidade de um sistema é um conceito que se refere à qualidade da interação de sistemas com os usuários e depende de vários aspectos. Alguns destes fatores são:

. Facilidade de aprendizado do sistema: tempo e esforço necessários para que os usuários atinjam um determinado nível de desempenho;
. Facilidade de uso: avalia o esforço físico e cognitivo do usuário durante o processo de interação, medindo a velocidade de uso e o número de erros cometidos durante a execução de uma determinada tarefa; Pressupõe  a existência de Help, manuais de usuário e boa documentação
. Satisfação do usuário: avalia se o usuário gosta e sente prazer em trabalhar com este sistema;
. Flexibilidade e Nível de Parametrização: avalia a possibilidade de o usuário acrescentar e modificar as funções e o ambiente iniciais do sistema. Assim, este fator mede também a capacidade do usuário utilizar o sistema de maneira inteligente e criativa, realizando novas tarefas que não estavam previstas pelos desenvolvedores;
. Produtividade: avalia se o uso do sistema permite ao usuário ser mais produtivo do que seria se não o utilizasse.
. Consistência de interface
. Cuidado com a navegabilidade
. Tolerância a erros

07. Rastreabilildade (capacidade de manutenção de histórico das ações dos usuários tais como: número de acessos ao sistema e material consultado ou do comportamento do sistema).

08. Extensibilidade  (capacidade de ampliar o sistema, pela incorporação de novas funcionalidades, pelo aumento da capacidade de armazenamento, etc. e a Medida do esforço necessário para isso).

09. Escalabilidade (capacidade de um componente ou de um software manter o mesmo desempenho – tempo de resposta – quando há um aumento no número de usuários e/ou de requisições simultâneas). Este requisito está relacionado aos fatores:

. Pool de conexões
. Cuidado com operações de I/O

10. Configurabilidade (capacidade de organizar e controlar elementos da configuração do sistema ou Capacidade de gerar diferentes configurações ou visões do sistema). Este requisito está relacionado a outros fatores tais como:

. Habilitação ou omissão de conteúdos e serviços
. Parametrização
. Personalização e customização do sistema ou componente de acordo com o  contexto ou com o perfil de usuário.

11. Variabilidade  (está associada à variação de componentes de uma arquitetura). Podem haver variações:

. de funcionalidade
. de dados
. de fluxo de controle
. de tecnologia
. de ambiente
. de metas de qualidade

12. Segurança  (premissas e Restrições para o controle e segurança do software além da disponibilidade de mecanismos que controlam ou projetam programas e dados). Este requisito está relacionado aos fatores como: necessidade de criptografia, autenticação de usuários, etc…

. Controle de acesso e manipulação de recursos
. Autenticação
. Autorização/permissão
. Integridade dos dados e confiabilidade
. Privacidade e confidencialidade

13. Tolerância à Falhas (capacidade do sistema de manter o seu funcionamento normal dada a ocorrência de uma falha de hardware ou software).  Este requisito está relacionado aos fatores:

. Disponibilidade
. Confiabilidade
. Freqüência e gravidade das falhas
. Acurácia dos resultados
. Capacidade de recuperação
. Redundância

Entre outros como:

. Interoperabilidade
.
Testabilidade
. Correção
. Consistência
. Compatibilidade
. Complexidade
. Internacionalização (Capacidade do sistema de suportar diferentes línguas – Português, Inglês, Espanhol, etc. – sem a necessidade de recodificação).

Bom pessoal, é isso. Espero que tenha ajudado
a entender como funcionam as especificações!

Grande abraço!

Deixe um comentário! 13

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

Comentando como Anônimo

  1. É importante para profisssionais como eu que estou saindo da faculdade ler artigos de tamanha utilidade e competência, saber como os profissionais experientes enxergam o “mundo real” do desenvolvimento de softwares.
    Parabéns pela matéria.

  2. Olá Daniel, gostei muito de sua matéria, principalmente pelo fato de trabalhar com Documentação de Software, foi de grande relevência no meu dia-a-dia.

  3. Acho fundamental a publicação de artigos neste nível tanto para profissionais da área quanto para acadêmicos pois precisamos estar cada vez mais informados sobre a importancia da especificação de requisitos. Parabéns

  4. Acredito que o artigo do colega não respondeu à principal proposta do título: Por que os projetos atrasam? Faltou uma “personalidade” no texto que, entretanto, me foi útil.

    Abraço,
    Crhistian

  5. Tem razão o Crhistian, nesse artigo só abordei uma parte do raciocínio: A Importância de uma boa Especificação de Requisitos. Nos próximos artigos darei continuidade ao assunto que é o tema do meu livro: “Análise de Sistemas Orientada ao Sucesso” e cujo sub-título é “Por que os Projetos Atrasam?”

  6. Parabéns. Estou tendo o primeiro contato ecom este assunto. Fiz um curso interno n asemana passada e estava procurando algi para complementar o conteudo da apostila. Obrigado e parabéns!!!

leia mais
Este projeto é mantido e patrocinado pelas empresas:
Hospedado por: