Requisitos

Prévia do material em texto

Engenharia de Software, Jair C Leite
Requisitos
• Objetivos ou restrições estabelecidas por 
clientes e usuários do sistema que definem 
as diversas propriedades do sistema
• Condição ou capacidade necessária que o 
software deve possuir 
– para que o usuário possa resolver um problema 
ou atingir um objetivo 
– para atender as necessidades ou restrições da 
organização ou de outros componentes do 
sistema. 
Engenharia de Software, Jair C Leite
Requisitos do usuário, do sistema e 
do software [Sommerville, 2004]
• Requisitos do usuário
– Declarações, em linguagem natural e diagramas, sobre os 
serviços que o sistema oferece e as restrições para a sua 
operação. Escrito para os clientes.
• Requisitos do sistema
– Estabelecem detalhadamente as funções e restrições do 
sistema. O documento de requisitos, chamado de 
especificação funcional, pode servir como um contrato entre 
cliente e desenvolvedor.
• Especificação de software
– Especificação abstrata e precisa do software, indicando o 
que ele deve fazer (sem dizer como) que serve de base 
para o design e implementação. Acrescenta mais detalhes à 
especificação funcional e é escrito para a equipe de 
desenvolvimento.
Engenharia de Software, Jair C Leite
Definição e especificação
• Definição dos requisitos do usuário
– O software deve fornecer um meio de representar e acessar 
arquivos externos criados por outras ferramentas.
• Especificação dos requisitos do sistema
– O usuário deve dispor de recursos para definir o tipo dos arquivos 
externos.
– Cada tipo de arquivo externo pode ter uma ferramenta associada 
que pode ser aplicada a ele.
– Cada tipo de arquivo externo pode ser representado por um ícone.
– Quando um usuário seleciona um ícone, o efeito desta seleção é 
aplicar a ferramenta associada com o tipo de arquivo.
Engenharia de Software, Jair C Leite
Quem são os interessados nos 
requisitos?
• Requisitos do usuário
– Gerentes e contratantes da organização cliente
– Usuários finais
– Engenheiros da organização cliente
– Arquitetos de sistema
• Requisitos do sistema
– Usuários finais
– Engenheiros da organização cliente
– Arquitetos de sistema
– Engenheiros de software
• Especificação de software
– Engenheiros da organização cliente (possivelmente)
– Arquitetos de sistema
– Engenheiros de software
Engenharia de Software, Jair C Leite
Problemas comuns
• Os envolvidos* não sabem o que eles realmente 
querem.
• Se expressam num vocabulário diferente dos
desenvolvedores.
• Os envolvidos podem ter requisitos conflitantes.
• Fatores organizacionais e políticos podem influenciar 
os requisitos.
• Novos requisitos podem surgir durante o processo de 
levantamento/análise/especificação. 
• Novos envolvidos podem vir a participar do process.
• Podem haver mudanças externas – ambiente ou 
regras de negócios.
*Stakeholders: Envolvidos ou partes interessadas
Engenharia de Software, Jair C Leite
Como descrever os requisitos?
• A especificação dos requisitos deve ser:
– Completa – deve descrever tudo o que é necessário
– Consistente – não deve haver conflitos e contradições
– Não-ambígua – não deve levar a interpretações diferentes 
por desenvolvedores e usuários.
• Difícil de atingir considerando que existem diferentes 
tipos de envolvidos.
• Depende da precisão da linguagem utilizada
– Linguagem natural, informal – apropriada para os requisitos 
do usuário e do sistema.
– Linguagens gráficas, semi-formais – apropriada para os 
requisitos do sistema e do software.
– Linguagens formais – apropriada para uma especificação 
formal de software em métodos formais.
Engenharia de Software, Jair C Leite
Requisitos funcionais
• Descrição das diversas funções que clientes e 
usuários querem ou precisam que o software ofereça
• Casos de Uso
• Exemplos:
– "o software deve possibilitar o cálculo dos gastos diários, 
semanais, mensais e anuais com pessoal".
– "o software deve emitir relatórios de compras a cada quinze 
dias"
– "os usuários devem poder obter o número de aprovações, 
reprovações e trancamentos em todas as disciplinas por um 
determinado período de tempo.
Engenharia de Software, Jair C Leite
Requisitos não-funcionais
• Propriedades de um software, como 
manutenibilidade, usabilidade, desempenho, 
custos e várias outras 
• São exemplos de requisitos não-funcionais: 
– "a base de dados deve ser protegida para acesso 
apenas de usuários autorizados".
– "o tempo de resposta do sistema não deve 
ultrapassar 30 segundo".
– "o software deve ser operacionalizado no sistema
Linux"
– "o tempo de desenvolvimento não deve 
ultrapassar seis meses".
Engenharia de Software, Jair C Leite
Tipos de requisitos não-funcionais
Performance
requ irements
Space
requir ements
Usab ility
requ irements
Ef ficiency
requir ements
Reliab ility
requ ir ements
Portability
requ irements
Interoperability
requirements
Ethical
requ irements
Legislative
requirements
Implementation
requir ements
Standards
requirements
Delivery
requirements
Safety
requirements
Privacy
requirements
Product
requ ir ements
Or gan izational
requir ements
External
requ irements
Non-functional
requir ements
Engenharia de Software, Jair C Leite
Requisitos não-funcionais e métricas
• Velocidade
– Transações 
processadas/segundo
– Tempo de resposta ao 
usuário
• Tamanho
– Tamanho em bytes do 
software final
– Memória
• Facilidade de uso
– Tempo de treinamento 
necessário
– Número de telas de 
ajuda
• Confiabilidade
– Tempo médio para falhar
– Taxa de ocorrência de 
falhas.
– Probabilidade de 
indisponibilidade.
• Robustez
– Tempo de reinício após 
falha
– Porcentual de eventos que 
causam falhas
• Portabilidade
– Número de ambientes 
operacionais nos quais o 
sistema pode rodar.
Engenharia de Software, Jair C Leite
Engenharia de Requisitos – 1/2
• Requisitos mudam sempre!
• Requisitos precisam ser levantados, 
analisados, especificados, rastreados, 
verificados e documentados.
• Estas atividades ocorrem ao longo de todo o 
ciclo-de-vida do software.
• A Engenharia de Requisitos propõe 
modelos, métodos, técnicas e ferramentas 
para a realização destas atividades
Engenharia de Software, Jair C Leite
Engenharia de Requisitos – 2/2
• Estudo de viabilidade
• Levantamento
• Análise
• Especificação
• Gerenciamento
• Rastreamento
• Verificação e Validação
• Documentação
Engenharia de Software, Jair C Leite
O processo de engenharia de 
requisitos
Fonte: Ian Sommerville
Engenharia de Software, Jair C Leite
Estudo de viabilidade
• Decide se o sistema proposto é vantajoso e lucrativo.
• Deve verificar se:
– O sistema contribui para os objetivos organizacionais.
– O sistema pode ser construído com a tecnologia corrente e 
com o orçamento disponível.
– O sistema pode ser integrado com os outros sistemas em 
utilização. 
• Questões a serem respondidas por clientes e 
usuários:
– E se o sistema não for implementado?
– Quais os problemas atuais?
– Como o sistema irá ajudar?
– Quais serão os problemas de integração?
– Novas tecnologias são necessárias? Quais habilidades?
– Quais facilidades deve ser providas pelo sistema proposto?
Engenharia de Software, Jair C Leite
Levantamento de requisitos
• Obter os requisitos dos especialistas no 
domínio – clientes e usuários
• Principal problema: comunicação
– Usuários e especialistas não compartilham o 
mesmo vocabulário
• Técnicas de Comunicação
– Entrevistas
– Observação direta
– Encontros
Engenharia de Software, Jair C Leite
Análise de requisitos
• A análise possui dois propósitos:
– Permite julgamentos sobre a qualidade dos 
requisitos do sistema
– Elaborar um modelo de alto-nível do sistema com 
os principais componentes e suas interfaces
• Abordagens para a análise
– Análise Estruturada
– OMT
– UML: Casos de Uso e Diagramas de classes
Engenharia de Software, Jair C Leite
Especificação de requisitos
• Descrição objetiva, precisa e completa dos 
requisitos do software
• A especificação de um requisito funcional 
deve determinar o que se espera queo 
software faça, sem a preocupação de como
ele faz
• Requisitos funcionais podem ser descritos 
por Diagramas de Casos de Uso – UML
• Requisitos não-funcionais são descritos 
textualmente.
Engenharia de Software, Jair C Leite
Verificação e Validação de Requisitos
• Validação
– “Estamos construindo o sistema certo?”
• Verificação
– “Estamos construindo certo o sistema?”
• Consistência
– Os requisitos não devem ser contraditórios.
• Completeza
– Os requisitos devem considerar todas as necessidades e 
restrições do envolvidos.
• Viabilidade
– Existe tecnologia e recursos suficientes?
Engenharia de Software, Jair C Leite
Abordagens para levantamento-
análise-especificação
• Etnografia
– Técnica de observação da antropologia.
– Considera que os requisitos são derivados do contexto 
social e organizacional.
– O engenheiro-analista se insere no ambiente de trabalho. 
• Cenários
– Descrição de possíveis situações de uso. 
– Estimula o questionamento (5W 1H)
• Casos de Uso
– Baseada em cenários mais diagramas.
– Parte da UML e fundamental para o RUP.
• Definição de Requisitos Orientada a Pontos-de-Vista 
(VORD)
– Analisa e descreve os requisitos a partir dos pontos-de-
vistas dos envolvidos.
Engenharia de Software, Jair C Leite
Gerenciamento de requisitos
• Requisitos mudam durante e depois do 
desenvolvimento (média de 1%/mês)
• Causas:
– Novas necessidades de clientes e usuários
– Mudanças na tecnologia utilizada
– Mudanças em leis, normas ou padrões
• As mudanças nos requisitos podem causar 
impacto nos requisitos relacionados
• As técnicas de gerenciamento visam rastrear 
e controlar estas mudanças
Engenharia de Software, Jair C Leite
O processo de levantamento-análise-
especificação-validação.
Engenharia de Software, Jair C Leite
Documentação
• Normas e padrões
– ANSI/IEEE STD 830-1993
– MIL-STD-2167A e MIL-STD-498 
• Tópicos comuns
– Descrição geral
– Interfaces externas
– Requisitos funcionais
– Requisitos de desempenho
– Restrições de design
– Atributos de qualidade
Engenharia de Software, Jair C Leite
Documento de requisitos do IEEE
• Introdução
– Propósito do documento de 
requisitos
– Escopo do produto
– Definições, acrônimos e 
abreviações
– Referências
– Visão geral do restante do 
documento
• Descrição Geral
– Perspectiva do produto
– Funções do produto
– Características dos usuários
– Restrições gerais
– Suposições e dependências 
• Requisitos específicos
– Esta é a parte substancial 
do documento, mas não 
existe uma estrutura 
padrão, variando de acordo 
com o método utilizado.
– Deve conter a arquitetura 
do sistema, interfaces 
externas e as funções 
(serviços) que o sistema 
oferece.
– Os requisitos não funcionais 
são colocados aqui 
também.
• Apêndices
• Indices