ANÁLISE DE PROGRAMAÇÃO

REVISÃO DE CONTEÚDOS
Marco Antônio Gusmão Carvalho

2011
Sumário
1 Requisitos ........................................................................................................................................ 4
1.1 Requisitos Funcionais .............................................................................................................. 5
1.2 Requisitos Não Funcionais ...................................................................................................... 5
2 Identificação e Coleta de Requisitos ............................................................................................... 5
2.1 Entrevista ................................................................................................................................ 6
2.2 Preparação da Entrevista ........................................................................................................ 6
2.3 Realização da Entrevista.......................................................................................................... 6
2.4 Documentação da Entrevista .................................................................................................. 7
3 Descrevendo Requisitos .................................................................................................................. 7
3.1 Descrição Funcional – Caso de Uso ......................................................................................... 7
3.2 UML – Diagrama de Caso de Uso ............................................................................................ 8
1 Requisitos
requisito
re.qui.si.to
adj (lat requisitu) desus Requisitado, requerido. sm
1 Condição a que se deve satisfazer para que uma
coisa fique legal e regular. 2 Exigência
imprescindível para a consecução de certo fim. 3
Qualidades, dotes, predicados exigidos para certa
profissão
[ Dicionário Michaelis ]
Requisito é a condição ou capacidade que um sistema deve atender. Segundo uma das
normas padrões IEEE (1220, de 1994), um requisito é uma sentença identificando uma capacidade,
uma característica física ou um fator de qualidade que limita um produto ou um processo.
Portanto, para a análise de um processo de software, requisito é uma condição ou
função que um determinado sistema deve possuir para que o sistema atinja sua finalidade.
Os requisitos devem atender à algumas exigências para que ele seja aplicável no
ambiente de desenvolvimento de softwares:
 Necessário: Indispensável para atender o objetivo do sistema;
 Não Ambíguo: Possui apenas uma interpretação tanto para o desenvolvedor
como para o cliente;
 Verificável: Não é vago nem genérico;
 Conciso: Define apenas uma característica/função a ser desenvolvida;
 Alcançável: Realizável a um custo definido;
 Completo: Não precisa ser explicado ou aumentado;
 Consistente: Não contradiz ou duplica outro requisito;
 Ordenável: Tem uma ordem definida;
 Aceito: Acolhido pelos usuário e desenvolvedores.
Os requisitos serão descritos em um documento chamado documento de requisitos1
que será a peça fundamental na comunicação entre os desenvolvedores e os clientes, visto que ele
definirá o que o cliente deseja e o que o desenvolvedor fará.

1
Exemplo de Documento de Requisito no Anexo I
1.1 Requisitos Funcionais
Os requisitos funcionais descrevem as funções do sistema. Definem o que o sistema fará
e como fará, sem entrar no contexto da implementação, ou seja, sem levar em consideração
questões de programação.
Os requisitos funcionais básicos são descritos pelo cliente, porém no decorrer da análise
dos requisitos surgirão funcionalidades necessárias para dar suporte às funções necessárias do
sistema, sendo que definindo características do software, também são requisitos funcionais.
Podemos citar como exemplo disto um gerenciamento de usuários que acessarão o sistema, não é
um requisito tido como objetivo do sistema, mas serve para dar suporta as funções do sistema.
Um Sistema de Informação somente cumprirá seu objetivo se fornecer informações que
auxiliem os usuários na tomada de decisões gerenciais, portanto a geração de instrumentos que
auxiliem na tomada de decisões também se trata de requisitos funcionais, como a geração de
relatórios. Portanto, descrever as informações que o sistema deverá inferir segundo a sua base de
dados são requisitos primordiais para a elaboração do sistema, por exemplo: “O sistema deverá dar
suporte a geração de relatórios semanais informando a movimentação de estoque e destacando os
produtos que estão abaixo do limite estabelecido como mínimo”.
Um conceito que vale ressaltar é que os requisitos funcionais não são o modelo de
dados do sistema, mas sim, definem o modelo de dados do sistema.

1.2 Requisitos Não Funcionais

Não descrevem funções do sistema, mas impõem restrições para a sua implementação
definindo características “externas” ao sistema, mas que serão variáveis a serem consideradas no seu
desenvolvimento.
Devemos nos atentar que tais requisitos podem tanto ser definidos pelo cliente como
pela estrutura de desenvolvimento que será utilizada no pojeto. Exemplo: “O cliente deseja utilizar
para operar o sistema a estrutura funcional já instalada contendo máquinas Pentium 4 com 2Gb de
memória RAM e capacidade de armazenamento de 120Gb rodando com sistema operacional
Windows XP”, ou ainda, “O cliente deseja utilizar sua intranet disponibilizando o acesso ao sistema
através de um servidor WEB”.
Tais funcionalidades não definirão funções do sistema a ser implementado, mas
características necessárias na sua implementação.

2 Identificação e Coleta de Requisitos

Quando se insere uma ferramenta informatizada em um ambiente organizacional, está
se buscando precisão e produtividade, portanto a ferramenta deve agilizar os processos que já são
realizados e não propor um novo método produtivo para a empresa. Para que o sistema a ser
desenvolvido atenda este conceito o projeto deve se basear no processo produtivo já existente na
organização e para isto devemos conhecer tal método.
Neste tópico descreveremos os métodos de coleta mais utilizados para identificar o
ambiente funcional onde o sistema residirá, a entrevista e o JAD.

2.1 Entrevista
A entrevista é uma forma de contato com a estrutura da organização ou com o público
alvo para a qual o sistema será desenvolvido e podemos subdividi-la em categorias:
 Por questionário: Muito utilizada em pesquisas e mercado e opinião, é voltada a
atingir uma amostragem grande com uma única interação, portanto deve
abranger todas as possibilidades do conteúdo analisado e deve ter uma redação
clara e objetiva visto que não abre a possibilidade à maiores explicações. Ex:
“Um sistema de vendas web, aplica um questionário on-line à seus clientes para
definir uma nova página de vendas”.
 Entrevista Estruturada: Seguindo um roteiro previamente elaborado, o
entrevistador conduz a entrevista levando sempre em consideração a
informação que deseja ser obtida. São entrevistas individuais onde o
entrevistador tem um contato próximo com o usuário do sistema.

2.1.1 Preparação da Entrevista

Um dos pontos principais em uma entrevista é a escolha do entrevistado visto que
devem ser levadas em consideração as informações que desejam ser obtidas para que seja chamado
o entrevistado certo.
Conhecendo o entrevistado, podemos adequar a entrevista a ele, visto que o
nivelamento do vocabulário ao nível de conhecimento do entrevistado é de vital importância para a
obtenção das informações corretas. Outro ponto a ser considerado é a adequação e cumprimento
dos horários estabelecidos.

2.1.2 Realização da Entrevista

Devemos ter sempre em mente, e passar para o entrevistado, que ele é nosso
colaborador pois dependemos da correção de suas respostas para a perfeita adequação do sistema
às necessidades da organização.
Nunca induzir pressa ao entrevistado, buscando sempre que ele pense muito bem nas
respostas a ser fornecidas.
Buscar clareza e especificidade nas interações evitando ambiguidades, jargões e
abreviaturas se aprofundando somente no que for necessário.
 Ser sempre objetivo, incluído apenas uma ideia por interação, para evitar dispersão do
objetivo proposto para entrevista.

2.1.3 Documentação da Entrevista

Toda entrevista deve ser documentada a fim de ser analisada posteriormente, devendo
conter neste documento os objetivos propostos para a entrevista, a descrição dos assuntos tratados
e as conclusões do entrevistador, contendo também os requisitos identificados durante a entrevista,
além da identificação do entrevistado dentro da organização.

2.2 JAD – Joint Application Design

O JAD, nada mais é do que uma dinâmica de grupo onde usuários e desenvolvedores se
reúnem para uma “entrevista coletiva”, sendo que em reuniões, os participantes discutem sobre um
determinado ponto do projeto a ser abordado identificando requisitos e promovendo uma maior
interação entre a equipe de desenvolvimento e os integrantes da organização que serão usuários do
sistema.

3 Descrevendo Requisitos
Em linhas gerais, a descrição dos requisitos se dá em linguagem natural (inglês,
português, etc..) buscando sentenças curtas e objetivas e utilizando verbos no futuro.
Pode-se, e deve-se sempre que possível, utilizar elementos gráficos (tabelas, diagramas
e imagens) para descrever os requisitos já que o público alvo deste documento é composto de
técnicos (desenvolvedores) e clientes.

3.1 Descrição Funcional – Caso de Uso

Uma interessante ferramenta para a descrição dos nossos requisitos é o caso de uso que
consiste em descrever como as coisas acontecem levando em considerações os cenários possíveis,
identificando fluxos prováveis e improváveis, detectando possíveis erros e falhas.
Um caso de uso é composto dos seguintes elementos:
 Ator: Um ator é quem interage com o sistema, sendo humano ou não, ele faz
uso de alguma função do sistema que esta sendo descrito.
 Caso de Uso: É a função que está sendo descrita, sendo que toda função é
atômica, ele realiza uma tarefa determinada.
 Cenário: Um cenário é uma possibilidade de execução do caso de uso sendo que
cada caso de uso pode ter uma infinidade de cenários devemos começar
descrevendo o mais provável (o bem sucedido).
 O caso de uso deve ser descrito como uma lista numerada a fim de que possamos definir
uma ordem de execução.
Um cenário alternativo geralmente deriva de um cenário principal mas nem sempre
retorna ao cenário principal para finalizar a tarefa.
Exemplo:
Solicitação de Guincho à Seguradora – Cenário Principal (Bem sucedido)
1. Cliente entra em contato com atendente;
2. Atendente solicita informações do cliente;
3. Sistema valida os dados informados pelo cliente;
4. Atendente finaliza a solicitação informando o tempo estimado de atendimento

Solicitação de Guincho à Seguradora – Cenário Alternativo: Dados Incorretos

3.1. Sistema invalida dados informados pelo cliente
3.2. Atendente finaliza a solicitação informando que o guincho não será enviado

3.2 UML – Diagrama de Caso de Uso

O diagrama de caso de uso é outra notação para a definição das funções do sistema
porém com um nível de detalhamento menor do que os casos de uso.
Os componentes do diagrama de caso de uso são:
 Ator: Um ator é quem interage com o sistema, sendo humano ou não, ele faz
uso de alguma função do sistema que esta sendo descrito.
 Caso de Uso: É a função que está sendo descrita, sendo que toda função é
atômica, ele realiza uma tarefa determinada.
 Relacionamentos: Notação que busca demonstrar como os componentes do
diagrama se inter-relacionam.

3.2.1 Ator
Representado por um boneco com um rótulo abaixo definem seres interagentes com o
sistema.

Ator
3.2.2 Caso de Uso
Representado no diagrama por uma elipse, define uma, e somente uma, função do
sistema a ser desenvolvida.

Caso de Uso

3.2.3 Relacionamentos
Definem as interações entre os componentes do caso de uso e podem ser de quatro
tipos distintos: Associação, Generalização, Inclusão e extensão.

3.2.3.1 Associação
Representam interações entre atores e casos de uso, são grafados no diagrama como
uma seta.

Caso de Uso

Ator

3.2.3.2 Generalização
Significa que um determinado ator possui as mesmas características funcionais de outro.

Funcionário

Gerente
3.2.3.3 Inclusão – Include
Demonstra que o caso de uso B é necessário para o comportamento do caso de uso A,
sendo representado no diagrama por uma seta tracejada.

Caso de Uso A

<< include >>

Caso de Uso B

3.2.3.4 Extensão – Extend

Especifica uma espécie de generalização entre casos de uso, ou seja, o comportamento
do caso de uso B acrescenta funcionalidades no caso de uso A.

Caso de Uso A

<< extend >>

Caso de Uso B
3.2.3.5 Exemplo de aplicação