Engenhaira de Requisitos

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