O Que São Requisitos?

Vinícius Medina Kern

engenheiro civil, doutor em engenharia de produção
kern@eps.ufsc.br
Sinopse do capítulo 1
1

Neste capítulo se considera o porquê do interesse em requisitos. A engenharia

de requisitos vem antes do desenvolvimento de um produto. Os requisitos
podem ser funcionais (o que o produto precisa fazer) ou não-funcionais (as
qualidades que o produto deve possuir). Restrições são requisitos globais do
produto. Uma lista padrão (template) de requisitos é apresentada, juntamente
com uma ficha para o registro de requisitos segundo o procedimento Volere.
Preâmbulo
Requisitos são coisas a descobrir antes de começar a construir um produto.
Descobrir requisitos durante a construção ou, pior, quando os clientes começam
a usar o produto, é tão caro e ineficiente que vamos assumir que nenhuma
pessoa em juízo são agiria assim.
Qualquer esforço no qual o resultado é importante é melhor empreendido
se um processo organizado for utilizado. Neste livro é apresentado Volere, um
processo e template para especificação de requisitos para a coleta, confirmação e
documentação de requisitos de um produto, também conhecida como engenharia
de requisitos. Os requisitos podem especificar o que o produto deve fazer
(requisitos funcionais) e quais qualidades deve ter (requisitos não-funcionais).
A necessidade de conhecer os requisitos antes de começar a construção de
um produto é mais ou menos óbvia. Muitas organizações fazem algum tipo de
análise de sistemas para descobrir o que o produto deve fazer. Estas análises são
representadas usando alguma representação, como diagramas de fluxo de dados,
ou diagramas UML.
A engenharia de requisitos não é uma tarefa extra na análise de sistemas,
mas algo que a melhora. A figura 1 ilustra o ciclo de vida de desenvolvimento
de um produto: a engenharia de requisitos e a análise de sistemas, atividades
iniciais, determinam o problema de negócios a resolver ou a oportunidade a ser
aproveitada, e o que o produto fará para contribuir neste sentido. Só então se
pode pensar em projeto, construção e uso do produto, que retroalimentam o
processo de engenharia de requisitos e análise de sistemas.
1
Resumo do capítulo, para uso acadêmico de alunos e professor da disciplina EPS 3245 do
PPGEP/UFSC, do livro "Mastering the Requirements Process", de Suzanne & James
Robertson, ACM Press, Addison-Wesley, 1999, ISBN 0 201 36046 2.
2
Figura 1 - Ciclo de vida de desenvolvimento
Engenharia de requisitos e análise de sistemas
Há sobreposição entre análise de sistemas e engenharia de requisitos. O
descobridor de requisitos usa modelos de análise para auxilia-lo a encontrar os
requisitos, e o analista de sistemas usa os requisitos como entrada no processo
de desenho de funções e dados. No início do desenvolvimento, há muito mais
engenharia de requisitos do que análise de sistemas. Esta proporção se inverte à
medida em que o trabalho avança.
A funcionalidade identificada na engenharia de requisitos é modelada para
provar sua correção, isto é, para provar que as funções e os dados funcionarão
corretamente, resultando no que o cliente espera. O produto da análise de
sistemas serve como entrada para o projeto do produto, e daí para a sua
construção e uso. Os requisitos evoluem a partir destas etapas, num processo
impossível de prever com precisão. A engenharia de requisitos precisa levar em
conta esta evolução.
A técnica de análise de sistemas é bem documentada, o que não é verdade
para a engenharia de requisitos. Este livro detalha um procedimento para
produzir requisitos corretamente.
Ambiente operacional pretendido
Processo
(eng.) de
requisitos
Desejos e necessidades dos interessados
Feedback sobre
o produto
Especificação de
análise e requisitos
Uso do
produto
Construção
Projeto de
produto
Análise de
sistemas
Especificação
de requisitos
Produto
Feedback sobre
projeto
Feedback sobre
construção
Feedback
sobre análise
Especificação
de projeto

Page 2
3
Por que especificar requisitos?
Se não há uma especificação dos requisitos, um produto não pode ser
construído. Ou, pelo menos, um produto não pode ser construído corretamente
sem os requisitos corretos.
Há relatos de que 60% dos erros já existem em tempo de projeto, e de que
até 60% dos erros têm origem nas atividades de engenharia de requisitos e
análise de sistemas. Embora os desenvolvedores tenham a oportunidade de
quase eliminar a maior categoria de erros, escolhem (ou pior: seus gerentes
escolhem) precipitar-se a construir o produto errado (para depois pagar muitas
vezes em retrabalho o preço de uma boa análise).
O que é um requisito?
Um requisito é algo que um produto deve fazer, ou uma qualidade que deve ter.
O primeiro caso é o de requisitos funcionais, por exemplo: "o produto deve
acionar o monitor de segurança quando um cliente classe A faz um saque em
horário não-comercial (no local do saque) superior à sua média mensal de
retiradas". Neste caso, os clientes do produto são funcionários de um banco
que precisam ser alertados sobre movimentações pouco usuais de alguns clientes
do banco.
Requisitos não-funcionais são propriedades ou qualidades do produto, por
exemplo: "o produto deve mostrar uma mensagem no terminal do monitor,
acompanhada de sinal sonoro, em até 10 segundos". Às vezes, especificam
características que melhoram o produto: "a tela de saída do produto deve utilizar
cores e caracteres piscantes que inquestionavelmente chamem a atenção do
responsável pelo monitor no momento".
Restrições são requisitos globais, como o propósito do produto, ou os
usuários que deve atender. São aplicáveis ao produto como um todo, e
geralmente são especificados antes do início da coleta dos demais requisitos.
Template para a especificação de requisitos e restrições
O template Volere para a especificação de requisitos e restrições estabelece um
arcabouço para redação. Os requisitos são classificados em categorias ou tipos,
servindo como guia para a coleta. Os 26 tipos são:
Restrições - restrições e limitações aplicáveis ao projeto e ao produto
1. Propósito do produto - razão para desenvolver e vantagem competitiva a ser
obtida.
2. Freguês, cliente e interessados (stakeholders) - pessoas com interesse no
produto.
3. Usuários do produto - usuários finais e o efeito que causam na usabilidade.
4. Restrições de requisitos - limitações sobre o projeto e restrições quanto ao
desenho do produto.
4
5. Convenções de nomenclatura e definições - o vocabulário do produto.
6. Fatos relevantes - influências exteriores que fazem alguma diferença para o
produto.
7. Suposições - coisas que os desenvolvedores presumem.
Requisitos funcionais - a funcionalidade do produto
8. Escopo do produto - limites e conexões com sistemas adjacentes.
9. Requisitos de dados e funções - coisas que o produto deve fazer e os dados
manipulados pelas funções.
Requisitos não funcionais - as qualidades do produto
10. Requisitos sensoriais - aparência, look-and-feel.
11. Requisitos de usabilidade - baseados nos usuários pretendidos.
12. Requisitos de desempenho - quão rápido, grande, preciso, seguro, confiável,
etc.
13. Requisitos operacionais - o ambiente operacional pretendido para o produto.
14. Requisitos de manutenibilidade e portabilidade - quão mutável ou
atualizável o produto precisa ser.
15. Requisitos de segurança - a segurança, confidencialidade e integridade do
produto.
16. Requisitos de políticos e culturais - fatores humanos.
17. Requisitos legais - conformidade com as leis aplicáveis.
Questões de projeto - aplicáveis ao projeto para a construção do produto
18. Questões abertas - aspectos não resolvidos que podem afetar o sucesso do
produto.
19. Soluções prontas - componentes que podem ser comprados, ao invés de
serem desenvolvidos.
20. Problemas novos - causados pela introdução do novo produto.
21. Tarefas - coisas a serem feitas para que o produto possa ser produzido.
22. Portes (cutover) - tarefas de conversão a partir de sistemas existentes.
23. Riscos - os riscos que o projeto mais provavelmente enfrentará.
24. Custos - estimativas preliminares de custo ou esforço necessários para
construir o produto.
25. Documentação de usuário - plano para construir as instruções e
documentação para usuários.
26. Sala de espera - requisitos que podem vir a ser incluídos em futuras versões
do produto.
Ficha para registro de requisitos
Cada requisito tem uma estrutura. Cada componente nesta estrutura tem sua
importância para a compreensão do requisito (mesmo que pareçam burocráticos,
a princípio).
 Page 3
5
A ficha para registro de requisitos, mostrada na figura 2, é completada
progressivamente, pois não é prático tentar encontrar todos os componentes
antes de passar a tratar do próximo requisito. Por esta razão, as fichas são
impressas em cartões, que são usados nas entrevistas com usuários.
Esta abordagem low-tech dá flexibilidade, permite trabalhar em quase
qualquer ambiente. Os cartões podem ser agrupados de acordo com o caso de
uso ao qual pertencem e, quando se julga que estão bem formados, podem ser
inseridos em meio digital.
Req. #: ident. único Tipo: seção do Evento/caso de uso: origem do
template
requisito
Descrição: Uma sentença descritiva do significado do requisito
Justificativa: Por que este requisito é considerado importante ou necessário?
Fonte: Quem levantou este requisito?
Critério de aceitação: Uma quantificação do requisito usada para determinar
se a solução atende ou não ao requisito.
Satisfação do cliente: Mede o desejo de
Insatisfação do cliente: Mede insa-
ter o requisito implementado.
tisfação se não há implementação.
Dependências: Outros requisitos que o
Conflitos: Requisitos que o
afetam.
contradizem.
Materiais de apoio: Referência a informação de apoio.
História: Origem e mudanças operadas neste requisito.
VOLERE
Copyright © Atlantic Systems Guild

Figura 2 - Ficha para registro de requisitos segundo o processo Volere

O procedimento Volere
O restante do livro explica como coletar, verificar e documentar requisitos com
sucesso. É importante ter em mente que o que se faz neste processo é dirigido
pelas soluções relevantes, e não pelas funções (nota do autor desta versão: eis
por que as formas normais são usadas na verificação de projeto de banco de
dados e não na concepção das estruturas -- ao normalizar um relatório, toma-se
uma função existente como fim, enquanto a oportunidade de identificar aspectos
que não fazem parte da função é desperdiçada).
Importância para a disciplina de metodologia de modelagem da informação
A engenharia de requisitos e a análise de sistemas tratam de funções e dados. A
modelagem da informação trata apenas dos dados, embora estes devam ser
usáveis pelas funções. Vários aspectos listados no template coincidem com
aspectos do método IDEF1X para modelagem da informação, como o requisito
tipo 1, que tem semelhança com o propósito do modelo estabelecido na Fase 0
da modelagem IDEF1X.