Slides

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
No n-fu nctional
requ ir ements
Pro du ct
requ ir ements
Ef ficiency
requ ir ements
Reliab ility
requ ir ements
Usab ility
requ irements
Perfo rmance
requ irements
Or gan izational
requ ir ements
Po rtability
requ irements
Delivery
requirements
Ex tern al
requ irements
Intero perab ility
requ irements
Implementatio n
requ ir ements
Sp ace
requ ir ements
Ethical
requ irements
Stand ard s
requ irements
Leg islative
requ irements
Privacy
requ irements
Safety
requ irements
Engenharia de Software, Jair C Leite
Requisitos não-funcionais e métricas
• Velocidade
•
• Tamanho
– Tamanho em bytes do
software final
– Memória
•
Robustez
– Tempo de reinício após
falha
– Porcentual de eventos que
causam falhas
• 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.
– Transações
processadas/segundo
– Tempo de resposta ao
usuário
•
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 que o
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 levantamentoaná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-devistas 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áliseespecificaçã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
•
– 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.
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
•
•
Apêndices
Indices
Engenharia de Software, Jair C Leite