Aula 3 – Requisitos de Software

Análise, Projeto e Implementação de Sistemas I

Profª. Réryka Rubia da Silva

Requisitos de Software
 Uma compreensão completa dos Requisitos
do Software é fundamental para obter um
software e um processo de desenvolvimento
com alta qualidade

 O software deve evoluir para atender às

necessidades mutáveis dos clientes

Profª. Réryka Rubia Disciplina: Análise, Projeto e Implementação de Sistemas I Requisitos de Software 2
 Análise de Requisitos

Processo de descobrir, analisar,

documentar e verificar serviços
requeridos para um sistema e
suas restrições operacionais.

Profª. Réryka Rubia Disciplina: Análise, Projeto e Implementação de Sistemas I Requisitos de Software 3
O que é um requisito?
 Pode variar de uma declaração abstrata de alto
nível de um serviço ou de uma restrição de
sistema para uma especificação matemática
funcional.
 Isto é inevitável quando os requisitos podem
servir uma função dual
– Pode ser a base para uma proposta de um contrato –
portanto deve ser aberta para interpretação;
– Pode ser a base para o contrato em si – portanto deve
ser definido em detalhe;
– Ambas as declarações podem ser chamadas

Profª. Réryka Rubia Disciplina: Análise, Projeto e Implementação de Sistemas I Requisitos de Software 4
O que é um requisito?
 Requisitos servem como especificação do que
deve ser implementado

 Requisitos são descrições de como o sistema

deve se comportar, de uma propriedade ou
atributo do sistema

(Sommerville, 2003)

Profª. Réryka Rubia Disciplina: Análise, Projeto e Implementação de Sistemas I Requisitos de Software 5
Elicitação de Requisitos
 ELICITAR: descobrir, tornar explícito, obter o
máximo de informações para o conhecimento
do objeto em questão

 É agora que conhecemos algumas informações

como:
– Fonte de Requisitos;
– Quais são as partes interessadas no produto/serviço;
– Quais são as principais necessidades do usuário;
– Definimos as fronteiras do sistema;
– Quais são as premissas e restrições do sistema ou do
ambiente.

Profª. Réryka Rubia Disciplina: Análise, Projeto e Implementação de Sistemas I Requisitos de Software 6
Elicitação de Requisitos: Dificuldades
 Usuários podem não ter uma ideia precisa do sistema
por eles requerido;

 Usuários têm dificuldades para descreverem seu

conhecimento sobre o domínio do problema;

 Usuários e Analistas têm diferentes pontos de vista

do problema (por terem diferentes formações);

 Usuários podem antipatizar-se com o novo sistema e

se negarem a participar da elicitação (ou mesmo
fornecer informações errôneas).

Profª. Réryka Rubia Disciplina: Análise, Projeto e Implementação de Sistemas I Requisitos de Software 7
Um caso ...
 O Sistema que queremos deve fazer isto,
isto ..., e nesse caso também isto;

 Sim, Sim estou anotando;

 Conversei com os usuários e

basicamente este é o Sistema que
teremos que desenvolver;

 Sim chefe;

 Ótimo, começaremos a especificar os

requisitos imediatamente;

Profª. Réryka Rubia Disciplina: Análise, Projeto e Implementação de Sistemas I Requisitos de Software 8
ELICITAÇÃO DE REQUISITOS MOTIVAÇÃO (Cont. ...)

 ... Quatro Meses Depois ...

 Srs. Usuários, após o emprego
das mais modernas técnicas de
especificação, produzimos este
documento que descreve
minuciosamente o Sistema;
 Ótimo! Bom! Hum! ... é um
documento com 300 páginas e
todos estes gráficos, tabelas.
Enfim, vamos analisá-lo e
voltamos a falar;

Profª. Réryka Rubia Disciplina: Análise, Projeto e Implementação de Sistemas I Requisitos de Software 9
ELICITAÇÃO DE REQUISITOS MOTIVAÇÃO (Cont. ...)
... Depois de um mês e meio ...

 Sr. Analista, nosso pessoal analisou

com cuidado o documento.
Tivemos muita dificuldade e
dúvidas em entendê-lo. Mas o que
percebemos é que NÃO FOMOS
CORRETAMENTE ENTENDIDOS!!!
 Como não? Tudo que aí está, foi
fruto de nosso entendimento
pessoal. REALMENTE VOCÊS NÃO
SABEM O QUE QUEREM!!!

Profª. Réryka Rubia Disciplina: Análise, Projeto e Implementação de Sistemas I Requisitos de Software 10
Atividades da Elicitação
 Entendimento do domínio da aplicação
– O conhecimento do domínio da aplicação é o conhecimento geral
onde o sistema será aplicado.

 Entendimento do problema
– Os detalhes dos problemas específicos do cliente, onde o sistema
será aplicado deve ser entendido.

 Entendimento do negócio
– Você deve entender como os sistemas interagem e contribuem de
forma geral com os objetivos de negócio.

 Entendimento das necessidades e limitações dos stakeholders do

sistema
– Você deve entender, em detalhe, as necessidades específicas das
pessoas que requerem suporte do sistema no seu trabalho.

Profª. Réryka Rubia Disciplina: Análise, Projeto e Implementação de Sistemas I Requisitos de Software 11
Imprecisão de Requisitos
 Problemas surgem quando os requisitos não
são precisamente definidos.
 Requisitos ambíguos podem ser interpretados
de maneiras diferentes pelos
desenvolvedores e usuários.
 Considere o termo “telas apropriadas”
– Intenção do usuário –tela de propósito especial
para cada tipo diferente de documento;
– Interpretação do desenvolvedor –fornece uma
tela de texto que mostra o conteúdo do
documento.

Profª. Réryka Rubia Disciplina: Análise, Projeto e Implementação de Sistemas I Requisitos de Software 12
Negociação dos requisitos
 Discutir os requisitos
– Os requisitos que foram identificados como
problemáticos são discutidos e os stakeholders
envolvidos apresentam seus pontos de vista a cerca
dos requisitos.
 Priorizar os requisitos
– Os requisitos disputados são priorizados para
identificar requisitos críticos e ajudar o processo de
tomada de decisão.
 Concordância dos requisitos
– Soluções para os problemas dos requisitos são
identificadas e um conjunto de requisitos são
acordados. Geralmente isto envolve mudanças em
alguns dos requisitos.

Profª. Réryka Rubia Disciplina: Análise, Projeto e Implementação de Sistemas I Requisitos de Software 13
  visão ampla dos principais processos
existentes.

Profª. Réryka Rubia Disciplina: Análise, Projeto e Implementação de Sistemas I Requisitos de Software 14
Classificação de Requisitos
 Requisitos Funcionais (RF)

 Requisitos Não Funcionais (RNF)

 Requisitos de Domínios

Profª. Réryka Rubia Disciplina: Análise, Projeto e Implementação de Sistemas I Requisitos de Software 15
Classificação de Requisitos
 Requisitos funcionais
– Declarações de serviços que o sistema deve fornecer,
como o sistema deve reagir a entradas específicas e
como o sistema deve se comportar em determinadas
situações.
 Requisitos não funcionais
– Restrições sobre serviços ou funções oferecidos pelo
sistema tais como restrições de timing, restrições
sobre o processo de desenvolvimento, padrões, etc.
 Requisitos de domínio
– Requisitos que vêm do domínio de aplicação do
sistema e que refletem as características desse
domínio.

Profª. Réryka Rubia Disciplina: Análise, Projeto e Implementação de Sistemas I Requisitos de Software 16
Requisitos Funcionais
 Descreve funcionalidade e serviços do sistema

 Depende do
– Tipo do software
– Usuários esperados
– Onde o software é usado

Profª. Réryka Rubia Disciplina: Análise, Projeto e Implementação de Sistemas I Requisitos de Software 17
Exemplos de RF
 [RF001] O sistema deve cadastrar o cliente
(entrada)
 [RF002] O sistema deve emitir um recibo para
o cliente (saída)
 [RF003] O sistema deve transformar uma fita
disponível em fita emprestada, quando a fita
for alugada pelo cliente (mudança de estado)
 [RF004] Usuário pode pesquisar todo ou um
sub-conjunto dos clientes da loja

Profª. Réryka Rubia Disciplina: Análise, Projeto e Implementação de Sistemas I Requisitos de Software 18
Exercícios
 Dê alguns exemplos de RFs para:

1. Sistema da padaria de pequeno porte

2. Sistema de abertura automática de porta
3. Sistema da agenda de um celular.

Profª. Réryka Rubia Disciplina: Análise, Projeto e Implementação de Sistemas I Requisitos de Software 19
Requisitos não funcionais
 Estes definem propriedades e restrições de
sistema, por exemplo, confiabilidade, tempo de
resposta e requisitos de armazenamento.
 Restrições são capacidade de dispositivos de E/S,
representações de sistema, etc.
 Podem ainda estar relacionados a portabilidade,
de SO, de BD, etc.
 Requisitos de processo podem também ser
especificados impondo uma ferramenta CASE
particular, linguagem de programação ou
método de desenvolvimento.

Profª. Réryka Rubia Disciplina: Análise, Projeto e Implementação de Sistemas I Requisitos de Software 20
Classificação RNF
 Requisitos de produto
– Requisitos que especificam que o produto entregue
deve se comportar de uma maneira particular, por
exemplo, velocidade de execução, confiabilidade, etc.
 Requisitos organizacionais
– Requisitos que são uma conseqüência de políticas e
procedimentos da organização, por exemplo, padrões
de processo usados.
 Requisitos externos
– Requisitos que surgem a partir de fatores externos ao
sistema e seu processo de desenvolvimento, por
exemplo, requisitos legais.

Profª. Réryka Rubia Disciplina: Análise, Projeto e Implementação de Sistemas I Requisitos de Software 21
Técnicas de elicitação de requisitos
Técnicas
 Entrevistas

 Questionários

 Obsevação Pessoal

 Seminário

Profª. Réryka Rubia Disciplina: Análise, Projeto e Implementação de Sistemas I Requisitos de Software 23
Introdução
 O profissional de ER deve selecionar as técnicas a
serem utilizadas e estabelecer de que maneira
elas serão integradas

 É importante utilizar uma técnica de modelagem

de apoio para que os fatos elicitados fiquem
corretamente representados para futuro
tratamento

 O ponto importante é ter conhecimento sobre

estas técnicas e identificar onde uma técnica é
superior a outra

Profª. Réryka Rubia Disciplina: Análise, Projeto e Implementação de Sistemas I Requisitos de Software 24
Entrevistas
 Técnica direta
– Pode ser usada na análise do problema e na elicitação de
requisitos
 Objetivo
– Entender os problemas reais e soluções potenciais das
perspectivas dos usuários, clientes, e outros stakeholders

 O engenheiro de requisitos ou analista discute o sistema com

diferentes stakeholders e obtêm um entendimento dos requisitos.

Profª. Réryka Rubia Disciplina: Análise, Projeto e Implementação de Sistemas I Requisitos de Software 25
Entrevistas
 Deve ser planejada (tempo, ritmo, perguntas objetivas)
 Quantidade de entrevistados
 Obedece hierarquia de entrevistados

 Vantagens
– altera a ordem seqüencial das perguntas quando percebe que
esta mudança ira beneficiar a entrevista,
– incluir novas perguntas,
– completar questões,
– esclarecer duvidas,
 Mas,
– tem um alcance menor que o questionário,
– entrevistados podem não receber tratamento uniforme,
– pode ocorrer avaliações subjetivas,
– esquecimento por parte do entrevistador,
– perder tempo com conversas improdutivas.

Profª. Réryka Rubia Disciplina: Análise, Projeto e Implementação de Sistemas I Requisitos de Software 26
Entrevistas
 Quem são o cliente e o usuário?

 Possuem necessidades diferentes?

 Quais são suas

– Capacidades
– Ambientes, etc.

 Qual é o problema?

 Como é resolvido atualmente?

Profª. Réryka Rubia Disciplina: Análise, Projeto e Implementação de Sistemas I Requisitos de Software 27
Questionários
 Aplicabilidade a mercados específicos
– Onde perguntas são bem definidas

 Hipóteses
– Perguntas relevantes podem ser decididas
antecipadamente
– Leitor ouve da maneira desejada

 Úteis após uma entrevista inicial

Profª. Réryka Rubia Disciplina: Análise, Projeto e Implementação de Sistemas I Requisitos de Software 28
Questionários
 Deve ser cuidadosamente elaborado
 Deve possuir um roteiro bem estruturado
 Apresentar a todos o mesmo questionário
 Agiliza o processo,
 Menos dispendioso,
 Aplicação mais fácil,
 Aplicado a maior numero de pessoas,
 Garante anonimato,
 Menor pressão sob a resposta imediata,
 Mas,
 As informações podem ser manipuladas antes de seu
fornecimento,
 Tendência de concentração de respostas em alternativas
padrão,
 Meio frio de obtenção de informações.

Profª. Réryka Rubia Disciplina: Análise, Projeto e Implementação de Sistemas I Requisitos de Software 29
Observação Pessoal
 não interrompe as atividades
 não exige disponibilidade de tempo

 Mas,

 não oferece evidencias formais

 pode ocasionar mal-estar nos observados
 chegar a conclusões comprometedoras.

Profª. Réryka Rubia Disciplina: Análise, Projeto e Implementação de Sistemas I Requisitos de Software 30
Seminário
 Reunião planejada de pessoas-chave de diversas áreas,
 Proporciona rapidez
 Verificação de problemas de inter-relacionamento,
 Produz uma visão integrada dos problemas,

 Mas

 Mobiliza um grande numero de pessoas ao mesmo

tempo,
 Interfere na rotina de trabalho da empresa

Profª. Réryka Rubia Disciplina: Análise, Projeto e Implementação de Sistemas I Requisitos de Software 31
Dicas
 Sempre perguntar: o que? Por
que(m)? Como?
 Pergunte o óbvio
 Organize as respostas: durante
versus depois
 Viva a situação durante um tempo
 Observe
 Estudar o que? Por que? Onde
começar
 Seja humilde, procure aprender!

Profª. Réryka Rubia Disciplina: Análise, Projeto e Implementação de Sistemas I Requisitos de Software 32