Requisitos de Software

Engenharia de requisitos
• Estabelece
• os serviços que o cliente requer de um
sistema e
• as restrições sob as quais tal sistema
operará e será desenvolvido.
O que é um requisito?
• Pode ser uma descrição abstrata de alto nível de um
serviço, uma restrição de sistema ou até uma
especificação matemática, entre outras coisas
• O problema cujo desenvolvimento do sistema deve
resolver
• O sistema tem que ser construído de modo a satisfazer todos
os seus requisitos
Tipos de requisitos

⚫ Requisitos de usuário
⚫ Declarações de alto nível escritas em linguagem natural
⚫ Escritos para os clientes
⚫ Requisitos de sistema
⚫ Um documento estruturado estabelecendo descrições
detalhadas das funções, serviços e restrições operacionais do
sistema.
⚫ Define o que deve ser implementado e pode até ser parte de
um contrato entre o cliente e o desenvolvedor
Definições e especificações
Requisitos funcionais e não-
funcionais
⚫ Requisitos funcionais
⚫ Serviços que o sistema deve fornecer
⚫ Como o sistema deve reagir a entradas específicas
⚫ Como o sistema deve se comportar em determinadas situações
⚫ Requisitos não-funcionais ou de qualidade
⚫ 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.
Exemplos de requisitos funcionais
⚫ O usuário deve ser capaz de pesquisar em todo o conjunto
inicial de banco de dados ou selecionar um subconjunto a
partir dele
⚫Para todo pedido deve ser alocado um identificador único
(ORDER_ID) que o usuário possa copiar para a área de
armazenamento permanente da sua conta
⚫ O sistema deve fornecer telas apropriadas para o usuário
ler os documentos no repositório de documentos
 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.

Requisitos completos e consistentes

⚫ Em princípio, requisitos devem ser completos e

consistentes
⚫ Completude

⚫ Eles devem incluir descrições de todos os recursos

requeridos
⚫ Consistência
⚫ Não deve haver conflitos ou contradições nas
descrições dos recursos de sistema
⚫Na prática, é impossível produzir um documento de
requisitos completo e consistente
Requisitos não-funcionais
⚫ Definem propriedades e restrições de sistema
⚫ Exemplos incluem confiabilidade, tempo de resposta e

requisitos de armazenamento
⚫ Restrições são capacidade de dispositivos de E/S,

representações de sistema, etc.

⚫ Requisitos de processo podem também ser especificados,

impondo uma linguagem de programação, IDE ou método de

desenvolvimento particular
⚫ Requisitos não-funcionais podem ser mais críticos do que os

requisitos funcionais
Tipos de requisitos não-funcionais
Exemplos de requisitos não-
funcionais
Metas e requisitos
⚫ Requisitos não-funcionais podem ser difíceis de definir precisamente
⚫ Requisitos imprecisos podem ser difíceis de verificar
⚫ Meta
⚫ Uma intenção geral do usuário, tal como facilidade de uso
⚫ Requisito não-funcional verificável
⚫ Uma declaração usando alguma medida que pode ser
objetivamente testada
⚫ Metas são úteis para desenvolvedores quando exprimem as
intenções dos usuários do sistema
Exemplo
Medidas de requisitos
 Interação de requisitos
⚫ Conflitos entre os diferentes requisitos não-funcionais são
comuns em sistemas complexos
⚫ Sistema de aeronave

⚫ Para minimizar o peso, o número de chips separados no

sistema deve ser minimizado
⚫ Para minimizar o consumo de energia, chips de baixa

potência devem ser usados

⚫ E o desempenho pode ser impactado!
⚫ Contudo, o uso de chips de baixa potência pode significar
que mais chips devem ser usados . Qual é o requisito mais
crítico?
 Requisitos de usuário
⚫Requisitos funcionais e não-funcionais descritos de modo a ser
compreensíveis por usuários que não têm conhecimento técnico
detalhado
⚫São definidos usando uma linguagem simples, tabelas e
diagramas quando estes podem ser compreendidos por todos
os usuários
Requisito de grade de editor
 Diretrizes para escrever requisitos
⚫ Usar um formato padrão para todos os requisitos
⚫ Usar a linguagem de uma forma consistente
⚫ ‘deve’ para requisitos obrigatórios, e
⚫ ‘deveria’ para requisitos desejáveis
⚫Realçar o texto para identificar as partes principais do
requisito
⚫ Evitar o uso de jargões de computação
 Requisitos de sistema
⚫Especificações mais detalhadas das funções do sistema, dos
serviços e das restrições
⚫ Visam fornercer uma base para o desenvolvimento do sistema
⚫ Eles podem ser incorporados no contrato de sistema
⚫Requisitos de sistema podem ser definidos ou ilustrados usando
notações gráficas
 Requisitos e Projeto
⚫Requisitos devem definir o que o sistema deve fazer e o projeto
deve descrever como ele faz isto
⚫ Requisitos => problema
⚫ Projeto => solução
⚫ Na prática, requisitos e projeto são inseparáveis
⚫ Uma arquitetura de sistema pode ser projetada para
estruturar os requisitos
⚫ O sistema pode ter que interoperar com outros sistemas
que geram novos requisitos
⚫ O uso de uma solução de projeto específica pode ser um
requisito de domínio
 Problemas com linguagem natural
⚫ Falta de clareza
⚫ É difícil atingir uma precisão sem tornar o documento difícil
de ler e ambíguo
⚫ Confusão de requisitos
⚫ Requisitos funcionais e não-funcionais tendem a estar
misturados.
⚫ Fusão de requisitos
⚫ Vários requisitos diferentes podem ser expressos juntos
⚫ Dificuldade de estruturar a especificação
Alternativas à especificação em linguagem
natural
Especificações em linguagem estruturada

⚫A liberdade do elaborador de requisitos é limitada por um

template pré-definido para requisitos
⚫ Todos os requisitos são escritos de maneira padronizada
⚫ A terminologia usada na descrição pode ser limitada
⚫ A vantagem é que a maior parte da expressividade da
linguagem natural é mantida
⚫ Mas o grau de uniformidade é imposto na especificação
Apresentação estruturada
Especificação baseada em formulário
Especificação tabular
⚫ Usada para suplementar a linguagem natural
⚫Particularmente útil quando você tem de definir uma
série de possíveis cursos alternativos de ação
Especificação tabular
 O documento de requisitos
⚫O documento de requisitos é a declaração oficial do que é
requisitado pelos desenvolvedores do sistema
⚫Deve incluir ambos, uma definição dos requisitos de usuário e
uma especificação dos requisitos de sistema
⚫ NÃO É um documento de projeto.
⚫ Logo que possível, será preciso definir como o sistema deve
fazer, ao invés de o que deve ser feito
Usuários de um documento de requisitos
Engenharia de
Requisitos
O Processo da Engenharia de
Requisitos
Estudo de Elicitação de
viabilidade requisitos e
análise
Especificação
de requisitos
Validação
Relatório de de requisitos
viabilidade

Requisitos do
usuário e do
sistema

Modelos do Documento de
sistema requisitos
Estudo de Viabilidade
• Estudo que indica se o esforço em desenvolver a idéia
vale a pena
• Visa tanto a tomada de decisão
• Como a sugestão de possíveis alternativas de
solução
Estudo de Viabilidade
• Deve oferecer informações para ajudar na decisão
• Se o projeto pode ou não ser feito
• Se o produto final irá ou não beneficiar os usuários
interessados
• Escolha das alternativas entre as possíveis soluções
• Há uma melhor alternativa?
O Que Estudar?
• Sistema organizacional apresentado
• Usuários, políticas, funções, objetivos, etc.
• Problemas com o sistema apresentado
• Inconsistências, funcionalidades inadequadas,
performance, etc.
• Objetivos e outros requisitos para o novo sistema
• O que precisa mudar?
O Que Estudar?
• Restrições
• Incluindo requisitos não-funcionais do sistema
(superficialmente)
• Alternativas possíveis
• Sistema atual é geralmente uma das alternativas
• Vantagens e desvantagens das alternativas
Testes de Viabilidade
• Operacional
• Medida do grau de adequação da solução para a
organização
• Avaliação de como as pessoas se sentem sobre o
sistema/projeto
• Técnica
• Avaliação da praticidade de uma solução técnica
específica e a disponibilidade dos recursos técnicos
e dos especialistas
Testes de Viabilidade
• Cronograma
• Avaliação de quão razoável está o cronograma do
projeto
• Econômica
• Avaliação de custo-eficiência de um projeto ou
solução
• Conhecida como análise de custo/benefício
Viabilidade Operacional
• Avalia a urgência do problema (visão e fases de
estudo) ou a aceitação da solução (definição, seleção,
aquisição, e fases do projeto)
• Há dois aspectos da viabilidade operacional a serem
considerados
• O problema vale a pena ser resolvido ou a solução
proposta para o problema funcionará?
• Como o usuário final e a gerência sentem-se sobre o
problema (solução)?
Viabilidade Técnica
• A solução ou a tecnologia proposta é prática?
• Se a tecnologia é ou não madura o suficiente para
ser facilmente aplicada aos nossos problemas
• Já possuímos a tecnologia necessária?
• Se está disponível ou pode ser adquirida
• Já possuímos o conhecimento técnico
necessário?
• Se temos as habilidades requeridas para aplicar a
tecnologia.
Viabilidade de Cronograma
• Dado nosso conhecimento técnico, os prazos dos
projetos são razoáveis?
• Alguns projetos são iniciados com prazos específicos
• Você precisa determinar se os prazos são obrigatórios ou desejáveis
• Se são mais desejáveis que obrigatórios, o analista pode propor outros
cronogramas
• É preferível (a não ser que o cronograma seja absolutamente
obrigatório) entregar um sistema de informação funcionando
excelentemente dois meses mais tarde do que entregar um
sistema com erros e inútil no tempo certo!
• Não cumprir o cronograma é ruim.
• Entregar sistemas inadequados é pior!
Viabilidade Econômica
• Talvez a mais crítica
• Durante as fases iniciais do projeto, a análise da
viabilidade econômica consiste em julgar se os
possíveis benefícios de solucionar o problema são
ou não vantajosos
• Tão logo os requisitos específicos e soluções sejam
identificados, o analista pode levar em consideração
os custos e benefícios de cada alternativa
• Isso é chamado de análise de custo-benefício
Tipos de Custos
• Custos de desenvolvimento de sistemas
• Desenvolvimento e aquisição
• Custos de instalação e de conversão
• Custos operacionais (contínuo)
• Manutenção
• Pessoal
Análise Custo-Benefício
• Há três técnicas principais
• Análise do retorno financeiro (payback analysis)
• Retorno do investimento (return on investments)
• Valor atual líquido (Net present value)
Análise de Retorno Financeiro
• Um método simples e popular para determinar se e
quando um investimento trará retorno.
• Porque custos de desenvolvimento de sistemas ocorrem
muito antes dos benefícios começarem a surgir (pois leva
algum tempo para os benefícios superarem os custos).
• Depois da implementação, você irá encontrar despesas
operacionais adicionais que deverão ser recuperadas.
• Análise de retorno (payback analysis) determina quanto
tempo será necessário para que os benefícios superem os
custos.
• Esse período de tempo é chamado de período de retorno
(payback period).
Valor Atual Líquido (Net present
value)
• Considerada a técnica preferida de custo-benefício pela
maioria dos gerentes.
• Custos são representados por fluxos de caixa negativos
enquanto benefícios são representados por fluxos de caixa
positivos
• Descontando todos os custos e benefícios, subtrai a soma
dos custos atualizados da soma dos benefícios atualizados
para determinar o valor atual líquido.
• Se é positivo, o investimento é bom.
• Se é negativo, o investimento é ruim.
• Quando comparamos múltiplas soluções ou projetos, o
que tem o valor atual líquido (net present value) maior é o
melhor investimento.
Análise de Retorno do
Investimento (ROI)
• Compara os benefícios das diferentes soluções ou
projetos
• O ROI para uma solução ou projeto é a taxa percentual
que mede a relação entre a quantia que a empresa
obtém de retorno ao seu investimento e a quantia
investida
ROI = (Benefícios totais - Custos totais) / Custos totais
• A solução que oferecer o ROI mais alto é a melhor
alternativa
Análise de Retorno do
Investimento
• O ROI para uma solução ou projeto potencial é
calculado como a seguir:
• ROI = (Benefícios totais - Custos totais) / Custos
totais
• ROI = valor atual líquido / Custos totais
• Ex: ROI = (22508,64-17321,20)/ 17321,20= 29,95%
• EX: ROI = 5187,44/ 17321,20 = 29,95%
• A solução que oferecer o ROI mais alto é a melhor
alternativa
Matriz de Viabilidade
• Como nós comparamos alternativas quando existem
vários critérios de seleção e nenhuma das alternativas
é superior em todos os aspectos?
• Use uma Matriz de Análise de Viabilidade!
Documento de Viabilidade
• Após o esforço inicial deve-se elaborar um relatório de
viabilidade
• Para cada aspecto apresentado, deve haver seção de
avaliação
• Deve haver uma seção conclusiva sobre a melhor
alternativa ou que o sistema não é viável