Engenharia de Software
Engenharia de Requisitos
Engenharia de Requisitos O cliente sabe o que é necessário? Usuários finais conhecem as características e funcionalidades?
Como o sistema irá evoluir?
(PRESSMAN, 2006) Engenharia de Software
Requisitos de Software
Descrições das funções e restrições
Requisitos de usuário: requisitos abstratos de alto nível
Requisitos de sistema: descrição detalhada do que o sistema deve fazer
Especificação de projeto de software: descrição abstrata do projeto de software. Acrescenta mais detalhes`aos requisitos de sistema
Requisitos funcionais: são declarações de funções que o sistema deve fornecer
Requisitos não funcionais: restrições (tempo, processo, padrões) sobre os serviços ou as funções. Engenharia de Software
(SOMMERVILLE, 2007)
Requisitos de Software
Requisitos funcionais
Dependem do tipo de software e dos usuários
Requisitos funcionais de usuário e de sistema
Ambigüidade nos requisitos (p. ex. “telas apropriadas”)
Devem ser completos e consistentes
À medida que as revisões acontecem, ou em fases posteriores, os problemas são descobertos e o documento de requisitos alterado
Engenharia de Software
(SOMMERVILLE, 2007)
Requisitos de Software
Requisitos não funcionais
Podem estar relacionados a propriedades, tais como: confiabilidade, tempo de resposta
Podem definir restrições para o sistema (dispositivos de E/S, p. ex.)
Se referem ao sistema como um todo
Falha em cumprir um req. Funcional X Falha em cumprie um req. Não funcional
Surgem conforme a necessidade dos usuários (orçamento, políticas organizacionais, interoperabilidade com outros sistemas)
Engenharia de Software
(SOMMERVILLE, 2007)
Requisitos de Software Requisitos não funcionais
Requisitos de produto
Requisitos de eficiência
Requisitos de facilidade de uso
Requisitos organizacionais
Requisitos de portabilidade
Requisitos de confiabilidade
Requisitos externos
Requisitos de interoperabilidade
Requisitos de entrega
Requisitos de implementação
Requisitos éticos
Requisitos de padrões Requisitos legais
Requisitos de desempenho
Requisitos de espaço Requisitos de privacidade
Engenharia de Software
Requisitos de segurança
(SOMMERVILLE, 2007)
Requisitos de Software
Requisitos não funcionais: exemplos de métricas
Velocidade Transações processadas por segundo Tempo de resposta ao usuário/evento
Facilidade de uso Tempo de treinamento Número de frames de ajuda
Confiabilidade Taxa de ocorrência de falhas Disponibilidade
Engenharia de Software
(SOMMERVILLE, 2007)
Requisitos de Software
Requisitos de Usuário:
Funcionais e não funcionais sem muito detalhamento
Características técnicas do projeto devem ser evitadas
Problema com a clareza dos requisitos
Requisitos de Sistema:
Devem ser uma especificação completa e consistente (o que – e não como – o sistema deve fazer)
Ponto de partida para o projeto
Diferentes modelos podem ser incluídos
Problemas com a linguagem natural
Reduzir a ambigüidade (linguagem natural estruturada, notações gráficas, etc)
Engenharia de Software
(SOMMERVILLE, 2007)
Requisitos de Software
Algumas questões:
Os requisitos funcionais são mais difíceis de serem quantificados? Podemos então afirmar que, em etapas posteriores, caso eles não sejam quantificados, podemos ter custos elevados para analisá-los e verificar se eles estão de acordo com a especificação?
Falha em cumprir os requisitos funcionais X requisitos não funcionais. Quais as possíveis conseqüências?
Engenharia de Software
(SOMMERVILLE, 2007)
Requisitos de Software
Estrutura de um Documento de Requisitos (SOMMERVILLE, 2007):
Prefácio
Introdução
Glossário
Definição dos Requisitos do Usuário Arquitetura de Sistemas Especificação de Requisitos do Sistema
Modelos de Sistema
Evolução de Sistema
Apêndices
Índice
Engenharia de Software
Engenharia de Requisitos
CenĂĄrio e Panorama
ER precisa ser adaptada Ă s necessidades do processo, do projeto, do produto e do pessoal.
Engenharia de Software
(PRESSMAN, 2006)
Engenharia de Requisitos
O que é ER?
Compreensão do problema Conjunto de tarefas que levam a um entendimento do impacto do software sobre os negócios Como os usuários finais vão interagir com o software
Quais são os participantes?
A importância da ER
Produtos gerados
Cenários de usuário; funcionalidades; modelos e especificação
Eles estão corretos? Engenharia de Software
(PRESSMAN, 2006)
Engenharia de Requisitos
Tarefas da ER
ER fornece o mecanismo para entender o que o cliente deseja.
Analisando as necessidades
Avaliando a exeqüibilidade
Negociando uma solução razoável
Especificando a solução
Validando a especificação
Gerindo os requisitos
Engenharia de Software
(PRESSMAN, 2006)
O Processo de Engenharia de Requisitos Estudo Estudode de Viabilidade Viabilidade
Análise Análiseee Elicitação Elicitaçãode de Requisitos Requisitos
Especificação Especificação de deRequisitos Requisitos Relatório de Relatório de Viabilidade Viabilidade
Validação Validaçãode de Requisitos Requisitos
Modelos Modelosde de Sistema Sistema Requisitos Requisitosde de Usuário e Usuário e Sistema Sistema
Documento de Documento de Requisitos Requisitos
Engenharia de Software
(SOMMERVILLE, 2007)
Engenharia de Requisitos: Início do Processo
Identificação dos interessados Facilidade, usabilidade, ...
Funções, infra-estrutura
Orçamento? Usuário
Gerente de Marketing
Gerente de Negócios
Mercado?
ES
...Diferentes pontos de vista
Requisitos inconsistentes e conflitantes Engenharia de Software
(PRESSMAN, 2006)
Engenharia de Requisitos: Início do Processo
Primeiras questões
Engenheiro de Requisitos: Quem solicitou? Quais são os usuários? Qual o benefício econômico?
Equipe de Software: Quais são as saídas geradas? O ambiente de negócios Restrições de desempenho
(PRESSMAN, 2006)
Engenharia de Software
Engenharia de Requisitos
Estudo de Viabilidade
Concepção
Objetivo:
Estabelecer um entendimento básico do problema,
os usuários,
a natureza da solução,
a efetividade da comunicação e colaboração entre clientes e desenvolvedores.
Engenharia de Software
(PRESSMAN, 2006)
Engenharia de Requisitos Estudo de Viabilidade
Perguntas que indicam que o sistema vale a pena!
“contribui para os objetivos gerais da organização?”
“pode ser implementado com a tecnologia atual, dentro do prazo e do orçamento?”
“pode ser integrado com outros sistemas em operação?” Engenharia de Software
Engenharia de Requisitos Estudo de Viabilidade (cont)
Qual o impacto de não desenvolver o sistema na organização?”
“Quais o problemas com os processos atuais?”
“Como um novo sistema diminuiria esses problemas?”
“Que contribuição direta o sistema trará para os objetivos da empresa?” Engenharia de Software
Engenharia de Requisitos Estudo de Viabilidade (cont)
“As informações podem ser transferidas para outros sistemas da organização?”
“E poder ser recebidas a partir deles?”
“O sistema requer tecnologia que não tenha sido utilizada anteriormente, na organização?”
“O que precisa e o que não precisa ser compatível com o sistema?”
Engenharia de Software
Estudo de Viabilidade (cont) Relatรณrio de Viabilidade:
recomenda se o desenvolvimento deve continuar.
pode propor mudanรงas no enfoque, no orรงamento, no cronograma.
pode sugerir outros requisitos. Engenharia de Software
Engenharia de Requisitos Levantamento Parece simples, nĂŁo? Basta perguntarmos ao usuĂĄrio !!!!!
Engenharia de Software
Engenharia de Requisitos: Levantamento
Coleta Colaborativa de Requisitos
Especificar o problema
Propor elementos da solução
Negociar abordagens
Especificar um conjunto inicial REUNIÕES
(PRESSMAN, 2006)
Engenharia de Software
Engenharia de Requisitos: Levantamento
Como essas funções e características atendem às necessidades dos usuários?
Cenários (casos de uso)
Quais são os produtos finais desta etapa?
Declaração da necessidade e viabilidade
Escopo do problema
Clientes, usuários que participaram
Lista de requisitos
Conjunto de cenários de uso
Protótipos (PRESSMAN, 2006)
Engenharia de Software
Engenharia de Requisitos
Levantamento
Clientes e usuários: o que vocês querem?
Quais os objetivos do sistema?
O que precisa ser conseguido?
Como o produto se encaixa nas necessidades do negócio?
O sistema será usado no dia-a-dia? (PRESSMAN, 2006)
Engenharia de Software
??????
Engenharia de Requisitos
Levantamento: Por que é difícil?
Problemas de escopo (limite do sistema mal definido, detalhes técnicos desnecessários são especificados)
Problemas de entendimento
Problemas de volatilidade Omitem informações Requisitos conflitantes Requisitos ambíguos Requisitos difíceis de testar Cliente
Eng. Sistema
Engenharia de Software
(PRESSMAN, 2006)
Engenharia de Requisitos
Elaboração
Informações são expandidas e refinadas
Enfoca o desenvolvimento de um modelo técnico (funções, características e restrições)
Modelagem de análise Criação e refinamento de cenários de usuário
Resultado: modelo de análise (define o domínio do problema informacional, funcional e comportamental)
(PRESSMAN, 2006) Engenharia de Software
Engenharia de Requisitos ... Acho que você está pedindo demais
... Os requisitos estão conflitantes! Cliente
Eng. Sistema
Negociação
Requisitos são priorizados e ordenados
“Estimativas” (grosseiras) do esforço são realizadas para avaliar o impacto do requisito
CUSTO PRAZO
(PRESSMAN, 2006) Engenharia de Software
Engenharia de Requisitos ... Acho que você está pedindo demais
... Os requisitos estão conflitantes! Cliente
Eng. Sistema
Negociação: Exemplo
EasyWinWin: A Groupware-Supported Methodology For Requirements Negotiation
(PRESSMAN, 2006) Engenharia de Software
Engenharia de Requisitos TĂŠcnicas de Levantamento de Requisitos
Slides aula 4
Engenharia de Software
Engenharia de Requisitos: Análise
Objetivo
Estabilidade do modelo à medida que ele evolui
Elementos do Modelo de Análise
Elementos baseados em cenários.
Elementos baseados em classes. Por exemplo: diagramas de classes
Elementos comportamentais. Por exemplo diagramas de seqüência
Elementos orientados a fluxo
(PRESSMAN, 2006)
Engenharia de Software
Engenharia de Requisitos
Especificação
O que é? Um documento escrito? Um modelo gráfico? Um modelo matemático formal? Cenários de uso? Protótipo?
A especificação é o produto final
Função e o desempenho
Restrições (PRESSMAN, 2006) Engenharia de Software
Engenharia de Requisitos
Validação
Avaliação dos produtos quanto à qualidade
Examina a especificação para garantir que todos os requisitos foram especificados
Inconsistências, omissões e erros são detectados e corrigidos
Produtos de acordo com as normas estabelecidas para o processo, o projeto e o produto
Principal mecanismo: REVISÂO TÉCNICA FORMAL
Exemplo de um Checklist (PRESSMAN, 2006) Engenharia de Software
Engenharia de Requisitos
Checklist de validação: exemplo
Requisitos claramente definidos? Podem ser mal interpretados?
A fonte do requisito foi especificada?
Está limitado em quantitativamente?
Relacionamentos?
Está violando restrições de domínio?
Pode ser testado?
Pode ser relacionado a algum modelo de sistema previamente criado?
(PRESSMAN, 2006)
Engenharia de Software
Engenharia de Requisitos
Gestão dos requisitos
Objetivo: identificar, controlar e rastrear requisitos e suas modificações. Identificação Identificação do requisito do requisito
Tabela Tabelade de rastreamento rastreamento
Exemplos de tabela de rastreamento Aspectos Específicos
Rastreamento de fontes de requisitos Rastreamento de dependências Rastreamento de interfaces
A01 R01 R02
A02
A03
Exemplo: Rational RequisitePro (www.rational.com) RTM (Integrated Chipware - www.chipware.com) (PRESSMAN, 2006)
Engenharia de Software
A04
Engenharia de Requisitos
Negociação:
Funcionalidades e desempenho podem ser questionados em função do custo e do prazo Clientes (necessidades satisfeitas) e desenvolvedores (orçamentos e prazos realistas) ganham.
Validação Requisito consistente com o objetivo, sem restrições contraditórias? Requisitos estão especificados em um nível de detalhes suficiente?
Todas as funções foram incluídas? Há necessidade do requisito? Ambigüidade? Requisitos conflitantes? Requisitos podem ser testados? (PRESSMAN, 2006)(SOMMERVILLE, 2007)
Engenharia de Software
Engenharia de Requisitos Técnicas de Validação
Revisões de requisitos: podem ser formais ou informais. As revisões formais devem ser conduzidas através da verificação da consistência, erros e completeza do requisito. São verificadas também:
facilidade de verificação; facilidade de compreensão; adaptabilidade: alterações no requisito podem provocar efeitos significativos?
Gerenciamento de requisitos
Requisitos para grandes sistemas são modificados freqüentemente Familiaridade dos usuários Diversidade de usuários (diferentes requisitos e prioridades) Restrições orçamentárias e organizacionais X requisitos dos usuários finais Modificações na empresa e no ambiente técnico Impacto das mudanças do requisito (facilidade de rastreamento) Engenharia de Software
(SOMMERVILLE, 2007)
Engenharia de Requisitos
Exercício: Em algumas situações, matrizes de rastreamento são difíceis de manter e manusear. Apresente pelo menos duas situações nas quais as ferramentas podem apoiar o processo de gerência dessas matrizes.
Engenharia de Software
Referências Bibliográficas PRESSMAN, R., 2006, “Engenharia de Software”, 6.ed. - São Paulo: McGraw-Hill. SOMMERVILLE, I., 2007, “Software Engineering”, 8th. ed. Addison Wesley.
Engenharia de Software