O Documento de Requisitos do Sistema
Este documento deve conter a especificação do sistema, ou seja, uma descrição das necessidades ou dos requisitos do sistema a ser desenvolvido.
Nele deve-se descrever:
a) uma visão geral do sistema;
b) quem são os clientes do sistema;
c) quais os objetivos;
d) quais as funções principais do sistema;
e) quais os atributos necessários do sistema
A seguir, estudaremos os conceitos de funções e atributos do sistema
a) Funções do sistema
As funções do sistema são “o que” se supõe que o sistema faça e devem ser identificadas, listadas e agrupadas logicamente.
Uma boa regra para verificar se uma expressão X é, de fato, uma função do sistema, colocamos X na sentença “O sistema deveria fazer X” e essa sentença deve fazer sentido.
Exemplo: Num sistema de registro de notas escolares, poderemos duvidar se “elaborar prova” é uma função do sistema. Colocamos então as palavras “elaborar prova” na frase grifada acima: “O sistema de registro de notas escolares deveria fazer a elaboração das provas”. Por experiência, sabemos que as provas de uma escola são elaboradas pelos professores e não por sistemas computacionais. Logo, “elaborar prova” não é uma função desse sistema.
Agrupamos as funções em três categorias:
a) evidente: deve executar e o usuário deve saber que é executada;
b) oculta: deve executar, mas não deve ser visível para os usuários;
c) enfeite/decoração: opcional.
b) Atributos do sistema
Os atributos do sistema são qualidades não funcionais do sistema.
Em alguns projetos é conveniente construir um documento exclusivo para os atributos do sistema. Esse documento fica separado do documento que contém as funcionalidades do sistema.
Exemplos de atributos do sistema:
a) facilidade de uso: que tipo de interface o sistema possui com o usuário?
b) tolerância a falhas: qual a expectativa aceitável para falhas no sistema?
c) tempo de resposta: qual o tempo aceitável para a resposta do sistema?
Tipos de requisitos
Para melhor entendermos os requisitos, é comum separá-los em grupos ou tipos.
Os tipos de requisitos são:
a) funcionalidade: descreve características, capacidades, segurança, etc., do sistema;
b) usabilidade: descreve características relativas a fatores humanos, ajuda on-line, documentação;
c) confiabilidade: descreve necessidades do sistema quanto à frequência de falhas, recuperabilidade, etc;
d) performance: descreve necessidades relativas a tempos de respostas, precisão, disponibilidade, utilização de recursos, etc;
e) suportabilidade: descreve necessidades relativas à adaptabilidade, manutenibilidade, internacionalização, configurabilidade, etc;
f) implementação: descreve limitações de recursos, linguagens e ferramentas, hardware, etc.;
g) interface: descreve as restrições impostas pelo interfaceamento com sistemas externos;
h) operação: descreve as necessidades relativas à administração do sistema em sua configuração operacional;
i) aspectos legais: descrevem licenciamento, etc.
Recomendações para obtenção dos requisitos
Nesta seção são apresentadas recomendações úteis para a obtenção dos requisitos dos sistemas.
a) Questões fundamentais
As seguintes questões podem ajudar a esclarecer os requisitos de um sistema:
1. Para quem é esse sistema?
2. O que eles irão fazer com esse sistema?
3. Por que fazemos isso? Por que fazemos assim? Por que fazemos desse modo?
4. Quais as necessidades de negócio esse sistema deve suportar?
5. O que nosso cliente demanda?
6. Como são as mudanças no negócio?
7. O que nossos competidores estão fazendo? Por quê? Como podemos fazer melhor?
8. Precisamos fazer isso?
9. Se estivéssemos iniciando o negócio, faríamos dessa forma?
10.Se fomos bem-sucedidos fazendo dessa forma no passado, seremos bem-sucedidos fazendo assim no futuro?
11.Poderemos combinar várias funções?
12.Como o sistema vai afetar as funções dentro da empresa?
13.De que informações as pessoas necessitam para executar o serviço?
14.O trabalho está sendo executado onde ele faz mais sentido?
15.Existe alguma tarefa simples que pode ser automatizada?
16.As pessoas estão realizando somente atividades complexas que o sistema não pode realizar?
17.O sistema vai se pagar?
18.O sistema suporta trabalho de grupo?
19.Os usuários possuem formação para lidar com o sistema?
20.Que treinamento é necessário?
21.Quais os objetivos e as metas estratégicas da organização? O sistema suporta essas metas?
22.Como podemos fazer mais rápido?
23.Como podemos fazer mais barato?
24.Como podemos fazer melhor?
b) Dez regras para obtenção dos requisitos
Para facilitar a obtenção dos requisitos, a empresa Software Productivity Center (http://www.spc.ca) nos apresenta as dez regras, reproduzidas a seguir:
1. a obtenção dos requisitos tem por objetivo descobrir e entender problemas, e não encontrar soluções. Você só é capaz de realmente entender os problemas do cliente quando pode demonstrar que conhece esses requisitos;
2. os clientes costumam confundir aquilo de que precisam com o que desejam. Durante a fase de levantamento dos requisitos, por meio de questionamentos e entendimento, será possível separar o necessário do desejável;
3. documente os problemas e as necessidades do cliente e peça para verificar a sua precisão e completude. Esse é o meio de demonstrar que você entende as necessidades do cliente;
4. analise cuidadosamente os requisitos para que não haja conflito entre eles;
5. quantifique “quão bem” um usuário espera a funcionalidade do sistema como parte dos requisitos. Todos os requisitos devem ser testáveis;
6. formule os requisitos claramente, sem ambiguidades. Requisitos claros eliminam o “retrabalho” e facilitam a entrega do produto no prazo;
7. quando houver pressão para mudanças de requisitos, antes de prosseguir, envolva todos os principais interessados para fazer uma avaliação do impacto e custo da alteração;
8. procure trabalhar com requisitos “bons o suficiente”. A busca de requisitos “perfeitos” pode aumentar os riscos e ocasionar atrasos;
9. para coletar e documentar os requisitos, procure pessoas que saibam “escutar, falar e escrever”;
10. não dependa somente dos conhecimentos da equipe de desenvolvimento. Os requisitos são, geralmente, definidos por pessoas fora da equipe de desenvolvimento. Garanta que todos os envolvidos que fornecem informações de requisitos entendam o que é um bom requisito e participe de sua criação.
