Page 1

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

Engenhaira de Requisitos  

Engenhaira de Requisitos

Read more
Read more
Similar to
Popular now
Just for you